 Mikael, Monty Videnius will talk about MariaDB, and I think how it is the status in Debian and stuff. Okay, yeah, we'll do that. So, welcome to my talk about MariaDB, my square a little bit about the history where we stand on what we plan to do. But first I want to say that I'm a developer, I'm mostly at home sitting in my cellar and doing code. I do these talks just because I have a hard time saying no when people ask me to do that. And I of course want to ensure that everyone knows everything about MariaDB. In the good old times we had David Axmark doing all the talks and I was sitting home doing the development. But that said, I'm most comfortable in a discussion with people. So if you have any question at any time or want me to spend more time or less time on something, just tell me. We will start introducing Maria, who is giving the name to MariaDB. This is my youngest daughter, she turned nine a couple of weeks ago. And of course I was not at home, I was at Oskon. That's kind of the life of where you are, somebody who does lots of talks. And this is following the tradition that we had my oldest daughter, me giving the name of my squirrel. Little bit what I'm going to talk about. If not somebody wants me to talk about something else, which I can do of course. And the history is basically that I created my squirrel started with the coding in 1981. We released it as open source like in 95 GPL as 2000. And then it was eventually sold to Sun and I thought that would be a good place for my squirrel. Because Sun did understand development and open source. But when Oracle bought Sun with my squirrel, I saw it as one of my tasks to ensure that all the time I spent on this project wouldn't just get wasted. And we had lots of core developers who didn't want to work at Oracle. They said that they will quit and go to other companies or other projects. So I took them under my wings and created a company where all the core developer was owner of the company. And we had a task to keep my squirrel together under the name of MariaDB. Because during the way an open source project dies if you lose the core developers. So fortunately we are in, I know in the SkySQL we are 16 developers. All the core developers except a few is part of the MariaDB team. And our goal is to keep it talented together and also to ensure that my squirrel will always exist under another name if necessary. And we are working with the community very actively to ensure that we get much more people working on MariaDB. So who is using my squirrel here? Okay, so then you know a little bit about the history. Anybody using MariaDB? Okay, good. And that's kind of nice for me to see. When I started this four years ago, we were taught that we could get a lot of people starting to use MariaDB within one or two years because we had core people, we didn't know what we were doing and we were doing it the right way. Basically it took until January this year until we started to see mainstream adoption of MariaDB. But then you know that we are open source, binary compatible. We aim to always be that. And the main reason is that there's still lots of my squirrel users around 50 million my squirrel installations. We want to make it trivially for anybody to go from my squirrel to MariaDB. And currently it's like that. We have extremely few persons have any problems. So there were about seven MariaDB users here. Have you had any problem converting from my squirrel to MariaDB? Not anything, which basically is what I get everywhere. Basically nobody has a problem. And that's also why Red Hat was quite confident when they are now switching all the users from my squirrel to MariaDB. Of course, maybe one in a thousand will have some issues. But the good news is that the other 999 will have a better experience. So to do that we need to make it trivial. We need to have the same data on disk, on the wire, same file name, socket, ports. Because otherwise you can't just de-install my squirrel, install MariaDB and it should work. And that's actually the biggest problem for me to get MariaDB into DBN because you don't usually do that in DBN. Do something that is a full replacement. OpenOffice was one, but in this case you just switched to LibreOffice. And that became the political struggle I had for four years to try to get MariaDB into DBN. More about that later. What we are doing that is totally different from Oracle is that Oracle is trying to say that you can be part of our development team. You can please give us patches. The problem is that Oracle doesn't work with the open source community. They don't publish trees, they don't tell about roadmap, they don't even tell when a code drop will be done or not. So it's incredibly hard to do that. In the beginning we tried to give patches to Oracle, but actually it was so hard for us to do that. And actually it cost us more work by doing that. So we have stopped doing that. We only do that for serious security patches that we find. Because we don't want anybody to break in even into MySQL system because that could reflect bad upon us. So we are a true fork, not just a patch set. We are not depending on MySQL for development. We do merges every month just to ensure that we get all the new features and the bug fixes. But actually we have to go through all the code and review it and fix a lot of things. Because even if Oracle has some good developers left, they put a lot of new people on it. They have about 20 people working on MySQL. But the people don't know the code. They don't have anybody to ask because they have no core people left. So the code quality is deteriorating rapidly. There are some teams that are doing really good job. That's in the DB team and the NDB team. And then you have some other team who are doing a decent job like the performance schema. But the main code, that's deteriorating really, really badly. And that's why we need to review everything that we take in. So we have about 30 man years in front of MySQL. We are GPL only because we kind of like the GPL. And we also have to because we are based on MySQL. So there's no risk for any closed source extension or anything. And that's actually how I wanted MySQL to be in the beginning. So when I took investors in 2000, we made a shareholders agreement. We said that the investors are not allowed to change the license. It has to be on the server. It has to be GPL. And we were able to keep that promise until we were sold to sun. But after that when the product is sold and the company is sold, you kind of lose the hold on that. But we tried to keep it as long as possible. So during the five years or four years we have been working on the DB, we have done five releases. So we tried to do a release once a year. And we probably will do two releases of 10.0 with quite rapidly about half a year in between. We also work with the Galera team to do a true multi-master. And there's lots of users who are really interested in that because you see that there's a whole grail to solve the problem that if you have one master that is not fast enough, you can just add up to eight ten masters and things work quite nicely in certain setup. And you just get the scalability that you expect in the cloud environment. So these are the basic things we added in the releases. So 5.1 was basically my score 5.1. Plus we did an open source build environment because that didn't exist in my square. And that was actually my fault because we did a build environment that was supposed to be open source with my square AB and sun. We just never released it just because the maintenance of that wouldn't have time to handle a community. And we thought that we are doing the builds so why should we do that? And that was just wrong. We kind of didn't expect the future that happened. So we should have released that even we couldn't maintain it publicly. So we actually had to build a totally new infrastructure build bot and we have done everything with that open source. So if somebody wants to make a clone on MariaDB and put up your own build system, you can do that easily in one day now. It took us six months to get that done. And we also did a much better test suite. And then with MariaDB 5.2 we worked with the community and took all the important patches that we could find that made sense to put into MariaDB. And we added those. So MariaDB 5.2 is a true community release. With 5.3 we had the optimizer team. So the whole optimizer team, everybody has worked on the optimizer in my square, moved to MariaDB. And they continue the work that has been done in my square 6.0 and do an even better optimizer. I know we had having 5.3 have something that can compete with any other commercial databases. And even handle things that Postgres was previously said to be superior. So we are quite happy with that one. And the optimizer we have in 5.3 that is a little bit similar to the one that is in my square 5.6. Difference is that in my square 5.6 they took the code from 6.0 backported that, fixed a couple of small bugs and released that. In 6.0 the optimizer team had already worked three years in my square lab and son to do a good optimizer. And then they took that and worked four persons for three years to do an even better optimizer. And that's what we have in MariaDB. And that's why MariaDB in most cases for advanced queries is superior to anything that my square will have. And probably will ever have. We also have much better application. We have more features. And then MariaDB 5.5 was just a merge between 5.3 and 5.5. So we didn't add much in 5.5. Except a more efficient thread pool because 5.5 oracle started to do or change my square to be an open core product. And we have taken as a task to ensure that anything that oracle has closed source we will have as open source. So one of the most important things that they made closed source. They actually made a closed source because we already have that in my square 5.1 was a thread pool. And they did some improvements and closed it down in 5.5. Enterprise. So we added that to MariaDB, something that is as good or better as oracle has. We also added Sphinx and some interesting queries for large sites like limits row examined. That's actually really good also for ensuring that nobody can get access to your database and try to do queries. So we limit rows examined. If you add that to a query you can ensure that the optimizer will never examine or return too many rows. So if you have big database with security information like credit cards and stuff by adding limit rows examined you can be sure that nobody can access the whole table or do a join and try to query everything that you have. So we are now working MariaDB 10.0. We will have 10.04 hopefully out next week and 10.05 should be the first beta. So in this case we have backported those features in 5.6 that are of good code quality like in a DB and performance schema. We also got online alter table to work. So these are basically the most important features that you had in 5.6. The problem was that the replication code in my square 5.6 is really horrible bad. It said something that our team who had looked at it said that they don't want to have that because it's wrongly designed, it has too many limitations and they don't think we can ever get it to work or maintain it. So we decided that let's reimplement all the things that my square has done in replication. And there are also some other things that we just think are wrongly done. So we added global transaction ID in replication in a much better way than my square has. It's also compatible with the multisource extensions we have done. We are working on parallel application. So basically 10.0 is I think next week when we do 10.04 basically it's ready. The one thing that people have wanted for years, I said that the biggest limitation in my square is to ensure that the slave is as fast as the master. My square has in 5.6 done something for parallel slave. Basically that if you have different databases, those can be running parallel. The problem that in practice for most sites, that's such big limitations that it doesn't help them at all. We will have in 10.0, 5.0, a fully parallel application that is basically that the slave is as fast as the master for any query. So if you do lots of things on the master in parallel, the slave will also be able to do that in parallel. And we already have a demo version working in Bazaar for that. So we believe that we should be able to get that done by end of next month. So we have also lots of new features. Show explain is something that is really nice that if you have a query that takes a long time, you can do explain on a running query and you can see actually what did the optimizer do with it. So you can see that should you actually kill it or not. Multisource means that you can have lots of masters with different data, then you can add one slave and you can do parallel replication from all the masters to the slave. We have something in alter tables, we have done it even faster. Delete returning is something that is quite useful. I think it's an oracle extension that you can see the rows that you are deleting. So basically the delete plus select. We have speed up group commit even more. I will come to that. We added Cassandra as a storage engine and level DB. I think actually level DB is done also now. So we can actually combine NoSQL and NoSQL with MariaDB. We added connect, which I have a slide for. Really interesting storage engine and we are working on adding TokyoDB. We will talk about that too. And more statistics that you can see actually for each thread how much memory it's using. This one should work now. So these slides are just to show that what is actually the work we have done on the optimizer and why do I am able to claim that MariaDB is sometimes better than MySQL. So this is the work that we added in 5.3 and 5.5. MySQL 5.5, even if that was an oracle work, a long time on that, they never added any of the complex stuff. So they never did any optimization for the optimizer. In MySQL 5.6 they have taken the code that was in 6.0, added that to 5.6, and you can see basically which one are done. So they only had one optimization that they added that we didn't have, and we added that to 6.0. So these are not that important. It just means that most complex queries that should be able to execute faster can be executed faster. So the one couple of things that we didn't have yet explained for delete, update, and explain in JSON format. How many is using JSON here? Okay, so still I don't know if that's a good idea or not. We will do that because it wants to be compatible. We just haven't seen something really critical. We also care about all users and people are still using MyISAM for different reasons just because it takes less disks. So we speed up that some 250% already in 5.2. This was actually a community patch. We added optimizations that you can add more memory and you can get 3, 7, or 10 times speed up just by adding memory for queries. This works for queries where you are going to retrieve the same row multiple times when doing a join. This was the one slide where when I show in this one we usually get people to switch to MariaDB instantly. So because of a bug or the sign issue in a DB MySQL, even if it works quite good and with multiple heads normally, just as you add replication, it basically stops scaling, as you can see here. This was something that was a big problem for Facebook. So they created a patch for that to solve some of that and then they asked our team, can we do it better? And the blue curve is how MariaDB 5.5 scales. So this is basically MariaDB 5.5 MySQL 5.5. So by just replacing your MySQL 5.5 master with MariaDB without doing any changes, you basically get four or five times speed up. This is a blog by Mark Callahan from Facebook. So it's not from us. As soon as this blog was published, the replication team in MySQL said that we will also add a group commit. And they published away how they would do it. And what we thought was that the sign that they are proposing will never work. So in 5.6 when they add a group commit, we actually noticed that they copied our code. Slightly different. So this is how MySQL performed nowadays with 5.6 and this is MariaDB 10.0, where we have improved the group commit even more. And we will in 10.1 we will improve it one step more. The problem with the replication is that so the setup we are working on is that we have SkySQL who is doing frontline support to customers. And the MariaDB team, no working, no days working in SkySQL, we are handling all the hard issues. We see a lot of people having problems in MySQL replication. And even if we can fix most things in MySQL and MariaDB, we can't fix the replication problems that comes up basically weekly because it's design issues. Basically we have to recode the replication. So we just have to tell them to switch to MariaDB. So this kind of curve is the ideal curve. But replication is just so bad so people will get stalled things, they lose records and then all the slave dies. And we have looked at the code and just see that it's so full of bugs that we don't want to maintain. So I talked about the thread pool, that's something that Oracle decided to do, closed source. And the reason why you need a thread pool is that MySQL works with one thread per connection, which works quite nice. And when I designed that in 93, I thought that's something that should work quite good. But then you had CPUs that basically was one core. And for that the old system worked quite good. Now with many cores you had a problem that if you run basically 512 threads, you get your CPU going down with almost 30% and then it goes even down further. And the reason that the more threads you add because all these threads are running in the same memory and you can only handle that many threads at the same time or your speed is going to thread switching. And the solution to that is instead of having one thread per connection, you have a pool of threads, you basically say that let's have 64 thread handle all queries. That means that you have much less thread switching and then you get much better scaling. And this is the reason that Oracle did this closed source because the really advanced websites with lots of users kind of need that kind of scaling. But with MariaDB you get that for free. And the trick thing with the pool of threads, if you only have 64 threads running at the same time, assuming you get 64 queries that takes one over each, that case your survey is told, can't do anything. So this pool of threads only works when you have really fast queries that only take a couple of microseconds or a second. So what we have unique in MariaDB, you can run with both versions at the same time. So when you configure MariaDB, you get two ports. One is for thread per connection, one is for pool of threads. So as long as you direct all your fast running queries to pool of threads, then you can handle sites much bigger than you can do in MySQL today. So you need to take a little bit of water. Any questions so far? Anybody speaking English? Mä oot kyllä puhua Suomeekki, jos ältähän. Mä oot yleensä silloin paljon pienempi. So basically the NoSQL movement started with a blog from Twitter by a guy who hated SQL and wanted to prove that you can do much better with some of the NoSQL engines out there that was Cassandra. And the problem with the blog post back then was that you could have doing the exact scheme that was used for Cassandra. He could use that in MySQL and get exactly the same speed up. But anyway, the main reason for using NoSQL is that it's nice to be able to handle unstructured data where you have a different amount of columns per row. Because even if SQL is quite a very still language, you can't easily do a web store in a SQL where you want to have store attributes for every item you have. Because a computer has different attributes than a T-shirt that has small, large sizes, colors and so on. And also people were unhappy with the replication with MySQL because they were comparing most of the issues with NoSQL with MySQL. So there, they were comparing with Discord that basically said MySQL replication doesn't scale. So we fixed the replication and it scales comparable to many of the NoSQL solutions. With Galera, you get something very similar. But the unstructured data is still a problem. But we want to ensure that MariaDB would become a bridge between SQL and NoSQL. And to do that, we have done a lot of things. We added a handler socket which basically gives direct access to the DB and makes MariaDB as fast as Memcache for doing quick reads. We added Cassandra, we have worked on level DB and we also added dynamic columns which is a very simple way so you can have in practice different columns for every row. You're only having to learn, I think, six different functions. And we're using this as a building block for adding SQL. Now we're also working on MongoDB that MongoDB has a storage engine for MariaDB. And what the storage engine means is that you can select, you can update, you can do most things as you can do natively with Cassandra, for example, but you can use SQL. And you can also join Cassandra level DB and with the connect engine you can even do joins with Oracle if you like to use this legacy databases. So we have got a lot of questions. So why did we do MariaDB 10.0 instead of MariaDB 5.6? The problem is that because we are feeling uncomfortable with so big part of the MySQL code that we don't want to take it, we had to rewrite it. So doing the whole MySQL 5.6 and adding that to MariaDB 5.6 would take us one to two years. We didn't want to wait two years to do a release. So then we had three choices, calling it MariaDB 5.5, MariaDB 5.6 or something else. Calling it MariaDB 5.5, when we already have much more features and most of the features of 5.6 would be wrong. Calling it 5.6 and not being a 100% drop in replacement for 4.5.6 would also be wrong. So we just choose 10.0 to make things easy. So the plan is that we will do the merge between MySQL and MariaDB in two steps. 10.0 will have most of the features and 10.1 released hopefully in February, March next year will have everything. But we will do 10.0 in such a way that all the data on disk and on the wire is still the same. Maybe some options will not do anything but there will be options that have no effect than maybe speed. So in practice you should still be able to move from MySQL 5.6 to 10.0. For most cases we are not noticing anything. That's at least the goal while we are going. With 5.10.1 we can guarantee that 10.0 we can guarantee that for most but not for all. So with MariaDB we are doing open development, we are working with lots of the community and this is a big shift from MySQL lately and going back to the beginning of MySQL. When I started with the MySQL project in 1995 I was working actively with the community and showed that everything they wanted was added to the MySQL if it was possible and we had people helping us with some patches like porting MySQL to Windows. But in 2001 we had 15 employees in MySQL AB that was when we took investment of which 14 was developers and then I went to Morta Mikos who was the CEO and said that I can't do the community part anymore. We need somebody, we need a community team and Morta Ansa said that that's not why we got money from the investors we will do that later. In the meantime everybody can work with the community on their free time. But the effect was that between 2001 and 2005 we had nobody working with the community. So we still helped people doing connectors with the server all development basically except few bug fixes was done within MySQL AB. Community helped us with getting Ruby to work, PHP, Pearl, everything else. But it was kind of a monolithic structure and this was never the intention. So with MariaDB we had to go back to working actively with the community and showed that any patches that people have come in and also why I created them were part of creating the MariaDB foundation to ensure that we have a way to ensure that everybody can get reviews. And we also encouraged people to sponsor development within the company, employee developer who is working full time on MariaDB in other companies than just in SkySQL. And now we have seen a couple of companies standing up and saying that we will do that and we are working with them to employ people. Google already employed publicly one working full time on MariaDB but they have a team of ten engineers who is working around MariaDB. So we will see much more patches from Google in the near future. And we have from our side we have 100,000 of downloads from MariaDB, probably one million users but things are changing rapidly, I will come to that. So this little bit about database usage according a survey for a fine group that overall MySQL has about 80% of all database. It's actually 12 minutes. This is when we started. I can argue for two minutes then I lose. But basically MySQL has 80% SQL server, Postgres, Oracle, MongoDB, MariaDB, DB2, Cassandra, Redis. This just shows also that we did two surveys, one in 2009. This is how much people use MySQL and how they predicted the usage would be. 2012 they did the second survey and this is the MariaDB usage. MySQL usage actually has gone up and the predicted usage is slowing down a little bit but on the other hand at the same time it's slowing down they expect that the database uses to go up four or five times. So if we still are at 2017 65% running MySQL and MariaDB we still are the dominant database and my job is to ensure that this is completely green and we are kind of getting there. So I said that in January things started to change. The first news that causes people to notice MariaDB globally was when Wikipedia announced MariaDB. They moved the English server and it went so good so they are now moving other servers. I think they maybe have moved all of them already. And then Mozilla blog that they are moving to MariaDB, Fedora voted 7.0 that they will replace MySQL with MariaDB. OpenSushi has included MariaDB a long time, known as default, slack words. Basically everything except DB and Ubuntu more or less, which is the reason why I am here. And also in April Google said that New SQL offering is based on MariaDB. Fusion IO is heavily pushing MariaDB they are working us with improving MariaDB on Fusion IO but they are doing it in such a way that all the extensions will be soon available also for other memory cards. So that's nice. And Red Hat is including MariaDB Red Hat Enterprise. I think also that OpenSushi Enterprise will include MariaDB as far as I heard, but I haven't seen our official statement about that. This shows that basically people expect that New SQL everybody is talking about how much market share, how much money there will be. But according to the four five one the search group the MySQL market share will continue to be much bigger than New SQL, at least for the coming few years. We have had lots of people coming to us and saying that in the beginning that they have problem with Oracle because the license prices has risen dramatically since Oracle acquired Sun and in practice MySQL is no more expensive than Oracle if you want a license from Oracle. At least for the oil market. One of the problem has been that the libraries has been GPL and Oracle is not even going to companies are only doing monitoring services they are not distributing MySQL but they are using the client library and they are trying to get them to pay for it. So we created the LGPL client library based on MySQL 3.23. It's compatible with the current one and anybody can use this. We also are working on we did a Java and we should have ODB-C LGPL client library ready within one month I think. And this has been also sponsored by the foundation. Anybody using TokiDB? TokiDB is just a very interesting engine this is the only candidate I see that can actually potentially replace in ODB. And we will add that to the next version of MariaDB. They decided to become open source two months ago and we are working with them to get it fully integrated in MariaDB and just not taking the current code actually improving it to use facilities that only exist in MariaDB to make TokiDB even better. We also sponsored the connect stories engine which is an engine that can read a lot of different formats from this and use those natively. So MySQL has a MariaDB has a CVS stories engine that's read only. By using connect you can read and update CVS engines. You can also use ODB-C to connect to Postgres Oracle. So we know that people have been really interested about that and I've seen a couple users who are using this to do joins between MySQL and Postgres. And you've got six minutes. Six whole minutes. Or four if you ask that guide. Don't trust him. Should I worry that the light doesn't stay on? No I shouldn't. Good. Okay, so. Thank you. You can't see my slides because they're on here. One of the things that has changed since MariaDB was started is much more of a focus on community. As we've been changing the structure of how people can contribute to MariaDB we felt that it was very important to start an independent foundation to be the focal point for community activity so that it was no longer under the control of a single company. And so at the end of last year Monty created a MariaDB foundation and I joined in and started helping him without this spring. Since then we have established a board of directors for the foundation. That includes Jeremy Uzawodny from Craigslist who's also a major MariaDB user that wasn't on Monty's list just now. And we have Sergey Golubchik and then there's Monty, myself, Andrew Katz who's a lawyer in the UK who's helping us with governance and the chair of the board is Rasmus Johansson who is helping Monty with administering his business and is now working with SkySQL. That board is now putting together new governance for the MariaDB foundation and we hope that during September we'll publish that governance on the internet and we'll be hoping there'll be a lot of people with an eye for open source governance coming and telling us what's wrong with it and giving us a substantial quantity of pull requests to fix it up and make it into good independent governance. The rough timetable of that is to publish in September for the board to consider the feedback in late October for us to have a board vote establishing those new bylaws as our new governance in November and then to have community board elections to replace these current hand selected board members with community selected board members. Probably the model that we'll be using will be to have 50-50 board elections 50% coming from commercial members of the foundation who are providing us with our funding and 50% coming from the contributors and committers to MariaDB so that the board is not under the control either of the commit team nor of the commercial contributors but remains a balance between the two. The reason we're doing that is because the foundation employs a small development team. Our goal is not to develop all of MariaDB that's the job of the community of committers but we do feel there's a need to have a central team who are doing build, sustain and package so making sure that the build system works and that there is a working repository making sure that we are sustaining so reintegrating the changes that are coming upstream from MySQL. Next slide. Producing packages and we're very keen indeed to engage with Debian. You may remember that I've engaged with Debian before on trying to get OpenJDK into Debian and so I know what's involved in getting a package and we're very keen indeed to become the slaves of your MySQL package maintainers so that you become fans of MariaDB as a database package in Debian and we're also extremely keen to have Sergey become the slave of your security team so that you don't have any security issues and so that you're able to have a transparent and accessible security experience rather than a fater company security experience which I suspect is what you have at the moment. The foundation is funded by the membership fees of commercial sponsors we have four or five at the moment and a growing number of commercial sponsors so that's why they will appear in the governance is because you can't take money from people and tell them that they don't get a say however we don't intend to give them control we intend to make sure that they have a say but ultimately the project is going to be under the control of the committers and we're going to ensure that by making sure that the committers are actually the only people who have a say over what goes into the code so this foundation is not going to be able to set the technical direction of MariaDB it is purely going to be providing the environment in which the technical activity takes place our goal is to make sure that MariaDB becomes the dominant provider of the API that MySQL currently provides however we understand it's very important to stay compatible so we're going to try and make sure that as far as it's possible to do so as Monty's been saying through here that MariaDB is compatible with MySQL it's not the world's most exciting subject governance and that's why Monty got me to do it because it bores him and I'd be very pleased to discuss this with anyone that is interested in digging into exactly what we're doing I'm going to stay until the end of lunch and I would be very pleased to discuss that and that was only four minutes Monty actually five with who's counting so finders sponsors and developers are welcome so we have two two other developers including me paid by the foundation and one documentation writer so this is the conclusions and I have 30 seconds so I assume you can read that and then we have 20 seconds for questions so when Weezy was released we had the topic of the release goals and I asked in Debian Devil what was the future of MySQL and MariaDB in Debian the maintainers said that they were planning on having both for Jesse and do you know more about it what's their intention what's going to happen in Debian do you know now or not so we are talking here with Debian about how to continue I'm not 100% sure that I got your question but if I understand correctly you will ask how I see how Debian should go forward with using MySQL and MariaDB more or less or did I misunderstand something that's not something I can decide on I can only influence you and the other distributions all of them has said that we use MariaDB by default and if you want you can install MySQL some of those doesn't even allow you to install MySQL which I think is stupid because I always like to make the users happy so how I would like to see it personally would basically have MySQL and MariaDB packet and then one packet that people can choose which one they should use like you had in the past for Java because that would give them maximum flexibility when it comes to what's the logical thing to do I think that you should be compatible with other distributions and not make it hard for people to switch from open source to Debian or something like that so in that case working with MariaDB would be the best what we can promise you is that we have people on our side that we will put up that will answer and solve any issue that comes up in Debian To summarize that that's exactly the question we came here to ask you and we're very willing to put so we've got some staff in the foundation I'm very willing to direct those staff to be the slave of your package maintainers and to be the slave of your security team to make sure that MariaDB shows up in Debian either as the only MySQL API provider or as one of two MySQL API providers and exactly how to do that I know that the people who should decide are not us but your MySQL package maintainers if you would like a MariaDB package maintainer that's not the way Debian works you don't appoint one one doesn't show up and say here I'm here to help we're here to be slaves so I'll tell your package maintainers who they are I know who the package maintainers are security team want to help you but your question is the question we want to ask you rather than the question we want you to ask us On my watch we are now already four minutes over time so I guess I have to use the hallway track to answer more questions and yeah, thank you for the talk