 happiness. Okay, no, thank you. Okay, howdy everybody. My name is Arjen, I run a company called OpenQuery here based here in Brisbane, so welcome to my hometown. And we do remote database maintenance. I used to work for a company called MySQL, you may have heard of it. I skipped out just before it was bought by Sun Microsystems, which then got bought by Oracle, and that's a whole long interesting story. Now, many of my colleagues did similar things. They either went their separate ways or started other companies straight out of MySQL before it got acquired by Sun, or they didn't like Sun very much at some point, or the job changed and so on, and I wanted to do new things, so they left from there, and some people really, really didn't want to work from Oracle. And some others do, and that's a perfectly valid choice as well. I just want to make that perfectly clear. It just depends on what you want to work on, how you want to work on, and what kind of company you want to work for. I joined MySQL in 2000, and actually, I just walked off the screen. I joined MySQL in 2001 as employee 25. I left this employee as one of 450 people six and a half years later. She converted out. It kind of doubled every year in revenue, as well as a number of people. So I thrive well in smaller businesses that are kind of flexible with roles because I like to be involved in lots of different things, and the more corporate or enterprise-y or hierarchical company gets the less well I fit. I think all that over there could lose a little tweaking from the people over here, and I try to connect them, or I try to be one of those people, and people get upset about their turf and so on. At that point, it's time to move on. Of course, you can't change big organizations like that. Once they're built, you either fit there or you don't. You just need to know when to move on. So that's why I'm no longer there, and I run my own company the way I want to with people that work for me. So that's the idea of where Pupu will move on to. Around the time of the sun, take over Monty the original author of MySQL was working on various things, and at that point, he actually had the idea that, well, first of all, sun was the best candidate for MySQL to be taken over by. There weren't any other viable candidates and there were far advanced plans to float MySQL on Nasdaq. Essentially, the stock prospectus, the IPO prospectus was there. There's one photo which I've seen, but I can't copy. I don't have a copy of it of the executive team on the beach somewhere burning the prospectus. So we'll never see what they looked like, but they did exist. I'll believe the former CEO's word. So, yeah, essentially it was decided by the people who owned MySQL at the time that sun was the best candidate. Of course, there is a difference in what sun does, or what sun did, and what MySQL does. And the idea was that it would help solve some of the issues that MySQL has been struggling with in terms of development and being more inclusive in terms of incorporating community patches, because there's no real technological problem with it. It was a business process issue. Getting the interaction with the people right, getting the patches or the merge requests dealt with and actually having that interaction, also with copyright assignment and licensing and so on sorted. And that was just extremely painful and that some aspects were resolved within sun and some weren't. And Monty, being Monty, he got a bit upset and frustrated with the whole thing and he left sun microsystems. Started his own company called Monty Povram. And only couple of developers at that time joined him there, but over time more and more did just for their own particular reasons. And when sun got bought for Oracle, a lot of phone calls were made because people, well, they essentially signed up for something else, not working for Oracle and that was their particular choice. So they already had a branch of MySQL that they were working on that had some work done. Let's call it enhancements. So bug fixes that they felt were important or that they communicated, for instance, with open queries in which things are important because we have some spare time. What can we do? Because they were no longer being continually driven by sales. We need this new feature. We need this new feature. They could actually focus on bugs that have been lying around for years. They just need some prioritization. And Monty at some point called me, I have two weeks spare. What should I do? So I gave him some hints and he went to work. It was really great. It was cool to see that kind of stuff happen and things did happen. It was really, really useful. So they were working on a separate branch and at some point that got named MariaDB. Yeah? I'll skip some intermediate steps so then you know where MariaDB comes from. So you can call it a branch. I think realistically you can call it a fork. However, it still does feed or merge upstream from whatever Oracle produces and Oracle still, the company Oracle still develops MySQL as well. I want to make it absolutely clear. There's no reason at this point to believe that Oracle will stop doing that. They're being very good. They're putting resources into it. They're doing some very, very good development work, including new features and fixing things and sorting out issues that needed to be sorted. So there's no reason to believe that that will stop next week or tomorrow or next year. However, because of the corporate structure of things and the sales imperatives that they have within that organization, some things don't get done. For instance, what OpenQuery cares about is particular monitoring capabilities and logging capabilities. For instance, in a query, I would like to know whether a temporary table has been used in that query and whether the temporary table went to disk. Well, MySQL, the company had a solution for this and it's called, you subscribe to MySQL Enterprise, which was a subscription service. There's nothing to do with licensing, by the way. It's a service, which is a support system and then you can get the Enterprise Monitor tool. The Enterprise Monitor has a query analyzer and you put that in between the app and your database and then it just sits in between. It lowers your performance by about 5% and it will figure out whether you did that or not. There's another way of doing it. You look at the server code. You look at the function that actually creates a temporary table. You set a little bit. You check that bit for the particular thread. When you're looking at whether you're going to log slow queries or not, you check that particular bit and you add an extra line into the slow query log. That's exactly what we did. Now, from MySQL's perspective, it makes perfect sense to sell that tool. From my perspective, it makes perfect sense to hack up the server and it makes also perfect sense for the company to not incorporate that patch because it undermines part of their business model so that doesn't make salespeople happen, so it just doesn't happen. So that's the kind of thing that has been added was already added to MySQL 5.0 and has now been merged into MariaDB 5.1 and beyond. So that's the kind of stuff that we're talking about. So that's been going on for a while. Open query and a number of other companies were already dealing with patches from various sources. At some point we had, let me get this right. There's still pens here. That's excellent. Open query put together. Let's call it a distribution of MySQL called our delta.org. That's an R. You can still go there and get repositories and binaries and sources and so on for MySQL 5.0. So if you're still deploying MySQL 5.0 somewhere and you need the enhanced version, for instance, you need InnoDB to actually perform properly on multi-core systems, then you want to just go there. Not only can you download binaries there or packages, but the actual repositories. Those are Red Hat and CentOS and Debian and Ubuntu repositories. That's another thing that MySQL, the company, has never done. Never done Debian packaging and definitely no repositories for any of it, which makes, you don't want to download all the systems in your environment. You don't want to have to download all those RPMs. So repositories are kind of useful. That build infrastructure that we developed for that, which took a fair bit of time into it, was updated for version 5.1 and then updated for MariaDB and essentially handed over to the multi-program gang. So first of all, OpenQuery essentially was building, or the R-Delta project, which was mostly us, was building the packages and now multi-program is building the same packages with the same tools and publishing it from there and so we've passed that on. So that's how those packages came about. So there are now nice Debian packages and so on. There are at the moment no repositories. You'd have to download the packages now, but at least there are packages rather than having to stuff around with binary tire balls. We've messed up some things on the R-Delta site while transferring the build environment to multi-program. That no longer integrates with us like it used to, so we need to put in some extra work and make the repositories at our end work again. I hope that makes sense. Sorry, just clarify that the repositories are there and MariaDB are there. No, they're not. No, we were the only ones with the repositories, so they have now the capability of building the packages, not only binary tire balls, but also for every version of Debian and Ubuntu and Redhead and CentOS, all the packages and for some other platforms, but there are no repositories on that end. So there's a set of mirrors and you can download the RPMs like you would from anywhere else. Our Delta was the only place with each mirror to do the repositories, but it's just a matter of time for us or availability of time for us to actually fix that up again. If someone would like us to get that going quickly, it wouldn't hurt to talk to me and see if we can come to some kind of arrangement. It's purely a matter of availability of time. We've got more stuff to do, and it's of some benefit to our own work, but we can kind of get by because we're not big enough to, yeah, the economy isn't quite there, but if you're managing a lot of systems and it would be really beneficial to you, I'd love to drag a couple of hundred dollars out of you to make it work for me. It's not only my work, it's a couple of other engineers and I do need to get paid. So that would be very interesting to talk about then. OK, so who are the players in this ecosystem? So there's MySQL AB, the old company, which went into some microsystems, which went into Oracle, and just to be very clear, Oracle did not buy MySQL. They bought Sun Microsystems, which is a big company. It had lots of hardware software services and so on, and MySQL happened to be part of that particular package. I don't believe for a second that MySQL played any significant part in the decision of Oracle to buy Sun Microsystems. That would be slightly ludicrous. Does that make sense? That's just one different question. Do you think it was a plus or a minus or a right? That's a very good question. I don't know. You'd have to ask Oracle. I think it was overall a plus. I mean, MySQL has been a serious disrupter, and companies can't disrupt themselves. So if you talk to an Oracle salesperson now, will they sell you an Oracle product at a certain price, or will they show you a MySQL service at a certain price? I think we can work out which one it will be to follow the money. They're not going to spend time on the lower offering. It's an automatic upsell there. So yeah, sure. But that makes perfect sense. I'm not blaming for that. That's just the way things work. So that's very convenient. However, because MySQL is GPL and there's an ecosystem and there are other providers in the market that essentially have the same capabilities as MySQL, apart from licensing, but no one cares about that because it's GPL anyway, right? Well, there's some players that need to do certain linking, but overall it doesn't matter much. There are other people providing services like Open Query and Percona and the others that you see there. So there's no need to talk with Oracle if you don't want to. But if you want to do with Oracle, because you already have an arrangement with them, for instance, many companies use both Oracle and MySQL in the organization. It's perfectly normal. In my training, I very often get very experienced Oracle and DBAs and developers. And they just need a bit of an update. What are the differences from Oracle to MySQL? And then they need to deal with both. So if a company has that kind of environment, I'm pretty sure they would go with Oracle for those MySQL services as well. That makes sense. Corporately, that's easier than doing it any other way, I would think. But yeah, there are other companies. Percona is by far the biggest one in the US doing mainly consulting services, but also engineering. They work on a, let's call it again, a fork of InnoDB called ExtraDB. So that has lots of enhancements in terms of performance and also monitoring. So getting extra statistics out of the InnoDB storage engine, which is kind of nice. Settings that were in the source code as a static number have been made into a server variable so that you can modify it, that kind of thing. For instance, the number of IO operations inside InnoDB was at 100. That was just a number inside the core there. And someone at some point had a brilliant idea, well, our systems and our IO systems are quite a bit faster these days. What happens when you stick in 400 there? Well, your system actually works much better. So if you load up MarieDB now, I think it already defaults to 200 or 400 or whatever, but it is a setting that you can change. InnoDB, IO, underscore capacity is the setting. But you only get that setting if you use MarieDB or another version of MySQL that has that. If you download the stock standard version of MySQL from MySQL.com, you don't get that particular setting. Well, that's a bit of a hindrance. That's a bummer. So that kind of stuff is nice. Google uses, or at least has used in the past, that they were looking at other things, but still use it at the moment. They were using MySQL for AdWords and AdSense. Not the main search engine, but AdWords and AdSense. There's little ads on the side that ran pretty much on MySQL. They've done a lot of patching for that particular infrastructure. So some of those patches are Google specific, but many of them are really, really interesting. For instance, years ago, they built a semi-synchronous replication trick into InnoDB, which means that at least one slave in an infrastructure can be guaranteed to have the updates before the master, where you actually do the commit, returns to you. Well, that's kind of useful if that's what you want. Some instances you don't want that, and some instances you do. So that kind of fix has now been integrated in other places. The lead of that team, Mark Callahan, has moved from Google to Facebook. And so now there are Facebook patches. And there's other people working there. Guy who's also worked at MySQL as well as Wikipedia. Help me here, Stu. Domas, thank you. Domas Mitusa in Lithuania and in Vilnius. He's been quite active already with little patches in identifying bottlenecks in InnoDB because he's been one of the people who has been helping Wikipedia scale. And I do so with very few MySQL servers relatively, but using them optimally. And so they find funny bottlenecks. And he identifies them and files bug reports with the right people. But nowadays, he also produces patches. So he also systems. They do essentially the same thing. The difference is you probably already have your data in MySQL. So why would you rip it up, put it somewhere else, then do the calculation, put it back, join it on the stuff? You can do it inside MySQL. There are limitations to that too, but it's a convenience for a large set of use cases. Think, for instance, also RDF data. So you can now easily import RDF data and actually traverse it easily inside MySQL. That can be kind of nice, perhaps, depends on what you need to do. Social networking, if you need some social networking on your site, the OQ Graph Engine can definitely help you with that. You now get that for free. That's something you would have previously maybe looked at, been in pain with, and disregarded it as impossible. Take three steps back and try again, because those conclusions were based on normal relational systems. And this looks relational, but it does tricks. I'll leave that there. We also provided some patches into our Delta as well as MariaDB. So that's in plus the build system. And so when we contributed that, I mentioned our Delta itself. Montipugam now pretty much employs all the original optimizer people that used to work at MySQL AB. And I think that's been really important. There's other people who know a lot about the server, but these people have been working with particularly the optimizer environment in the core of MySQL for years. They know stuff that none of us do. And it would have been sad to see them disappear to various companies just trying to make a living. These are important people, and we need to keep them around. And they've been doing quite a bunch of interesting work, and we'll get to that on the next page. There's something called the Open Database Alliance. It's not particularly big right now, but it's a vehicle that the other companies that are mentioned here use to work together and actually provide services. So when you come to OpenQuery and ask for engineering work on the MySQL server core, we're probably not going to touch it ourselves. It depends a bit on what it is. We do know way around the source code, but we're not the experts. So we might ask Montipugam to do that actual work, but you can come to us and we'll make sure it happens. If someone comes to Montipugam with needs in terms of remote maintenance and server reviews and tuning in that kind of thing or training, they might send them to us. That's the way that particular thing works. And then one of the latest additions is SkySQL, which is essentially, let's call it the fork of the service division of MySQL AB. The original VP of Services, Ulf Sandberg, and quite a number of the support and training people at MySQL and Sundan Oracle are now in SkySQL offering similar services, I think also at a similar price point still. Maybe cheaper than what Oracle does now, higher than the price point that I'm using. But anyway, there's different providers of those services. Prokona also does training, by the way, but in the US. Now the interesting thing is that both PBXT and the OQ Graph Engine are, of course, DPL licensed. So in theory, you could just plug them into MySQL, right? Well, in reality, that doesn't quite happen because MySQL, the company, does the builds. There is a pluggable storage engine interface in 5.1 and above. Nasty because, or in reality nasty, because you actually need to compile it with the exact same compiler switches to make it work properly. Now you can kind of figure that out, and it kind of sometimes works. But you have to also compile it against the exact same version of the source code. It has way more dependencies. There's no simple binary compatibility, and there's no API versioning. Therefore, the only way to make a pluggable engine or another plug-in work is compile it in the same source tree at the same time as you compile everything else, and just leave it there as an SO library, and then install it and use it when you need it, and just leave it out if you don't need it. That's perfectly fine. So it still makes it a plug-in, but it's not something you can acquire from a third party and make work. It is theoretically possible, but in the practice it's just a pain to maintain. So those things are now integrated into MariaDB from version 5.2 and upwards, and that's really important because those community contributions are now actually inside MySQL, except we need to call it MariaDB just for trademark purposes. So this is the kind of stuff that you will see in MariaDB 5.2, and it is production ready. People use it in some really, really big Australian companies that we work with use it as well. So there's absolutely no issues there. Of course, there are bugs. There are bugs in every piece of software. Anybody who tells you things are bug-free is lying. We know it, right? We just admit it. Subqueries. Who here asked this earlier today? Who here uses subqueries? Yes. What's that mean? As a join. Absolutely. Yes, that's what you would be doing. Because subqueries kind of sucked in MySQL, didn't they? Because they were kind of... Yeah, yeah, they did suck. And the people who wrote it will readily admit that. They did a start of an implementation, did some stuff, made it work, and then they were sent off to other projects essentially driven by sales. Well, these same people have now finished the job because they're no longer driven by sales. They're working for Monty. They fixed it all. Well, nearly all. There's some little things that still need some work, but things like correlated subqueries, which really, really sucked. They just work now. It's just fast. It's beautiful. It's really, really so much faster. It's unbelievable. So do play with that. If you use subqueries, just download the 5.2. See how the same query suddenly works the way you'd expect it to rather than having to wait for a while. So I used to always tell people, OK, if you have a subquerie that can be written as a join, please do so. There's no longer any need for that with MariaDB 5.2 and beyond. So that's rather nice. Other longstanding bugs, just lots of little things. It doesn't serve to give you a long list here. There's a community contribution for virtual columns. It's kind of an interesting, interesting little trick. I don't have time to discuss that now. Plugable authentication, MySQL 5.5 also has that. So that's not particularly new. UserStats, I'll mention that one in particular because it can do something really funky that otherwise takes a heck of a lot of effort to do externally. It's a couple of extra statistics tables which when enabled because they eat a little bit of CPU power, of course. So they slow down the server a tiny bit. They track which users and originating IPs and tables and there's four different ones. And indexes get used. They're not only available is in show index underscore statistics but also in information schema and then a table in there with that same information. That enables you to do an interesting query. Through information schema, you can get a result set with all the indexes that exist in your system for particular database. So you could left join or do a sub query on that table. And the user stats, index statistics table, subtract one from the other and you can work out which indexes never get used. That's pretty cool. Now, why do you want to remove unused indexes? Any thoughts? Space? Ah, don't you have enough? You're adding the other head to every change to the index. Absolutely. Any right to that table is delayed by an index that apparently didn't get used. So that's really, really useful. There are possibly other ways to figure this out but not even the query analyzer can easily do this. They can do it in some cases but it's quite complex stuff and there's absolutely no need. MySQL server just knows these things. You just need to track it over time. So you don't leave this on all the time. You just leave this run for a day on one of the slaves and you figure it out. So that's the kind of stuff that OpenCrea uses on a regular basis which is why we really like it when a client says, sure, when we ask them, can we actually please run MariaDB or for 5G or the RDelta builds which also do the same thing. That really, really helps us do our work. That and many other little tricks. So the PBXC engine is built in FederatedX. The original Federated engine at MySQL was built by Patrick Calbraith and he left the company and it kind of was a bit abandoned inside. It wasn't a priority in terms of sales and so on. So it kind of became a development sideline. But Pat and another pharmacolic and friend of mine, Anthony Curtis, they've kept working on it, called it FederatedX engine. So when you now use the Federated engine in MariaDB, you're actually using the FederatedX engine. So essentially it has all the bugs from the other one fixed and it just perplaces the other one. So again, a bit of a fork replacement. OK, graph engine is built in. The MySQL key cache can now be partitioned, which can be useful. There's some pluses and minuses and there's still some work being done, but it's kind of handy. If you don't want some tables to interfere with other tables in terms of caching and getting chucked out of the cache while loading those indexes, that can make sense. There's some MySQL binlog and row-based replication enhancements that I'll just mention. There's lots of that work going on. There's already work being done on, let's call it, MariaDB 5.3. But essentially, there's still based on 5.1. There's also work being done, of course, on MySQL 5.5 and incorporating the changes that were done there, like the replication heartbeat, only incorporating those into MariaDB. So at the moment, you kind of have to choose, do you want MariaDB with all those nice changes and extras? Or do you want 5.5, which admittedly also has some cool stuff? At the moment, I choose the MariaDB thing because I know that MariaDB will get those other things as well, even though it's a couple of months later. Yes. Are there any syntax? No, not right now. At least it's backwards compatible. There can be some new and extras, like the virtual columns, add some extra trickery into the create table syntax. And of course, the OQ Graph Engine adds a complete new engine, as does PBXT. They don't add extra syntax there. They add extra information schema tables and other things and other capabilities, and in some cases, new server parameters. If you have a config file from MariaDB, you can't put MySQL back and make it work, because in some cases, you just need to comment things out. Upgrading is easier than downgrading, but that's always the case. At this moment, there are, as far as I'm aware, no binary incompatibilities. So in terms of the data storage, you should be able to move backwards and forwards. There is no particular plan to break that. I mean, it would be not particularly beneficial. However, there's no guarantee that someone in the ecosystem might break something at some point, which makes someone else unhappy. No way of knowing. And I hope that doesn't happen, but it's entirely possible that someone will make a commercial choice to do something that the others then it will really become a fork. At that point, you have to stop the merges. So I sometimes get asked, how do you hedge your bets at open query? I don't. I just use MariaDB. I don't do bet hedging. I don't fuss about it, because I know that MariaDB, at the moment, at least for the foreseeable future, still picks up all the other changes as well from all the different sources, including Oracle. So it gets the superset. It's just a slightly delayed superset, but I know it's done by people who know what they're doing. And I have their phone number. I can call Monty now and call him out a bit. If there was a real problem, and he would answer and fix it, or at least make an honest attempt and tell me the honest answer. And that's always useful. If he can't help me, he will also honestly say, which is better than you sometimes get with the salesperson somewhere, right? So owns? Who brought out 5.5? Yes, that was the corporation Oracle, the people working there. Well, that's one of the things they'd purchased. Yes, so when they bought some microsystems, which were the owner of MySQL, the trademark, and the nice dolphin logo, somewhere there, they got that name as well. And that's why when you do something that is more than just a little enhancement, you should call it something else, otherwise you're just in trademark nasty land, which is why it's called MariaDB. Absolutely, well, it can't not be. Well, a future version, I mean, they do own all the copyright, because all the contributions that have been made in the past have been essentially copyright assigned to whichever corporation owned the core at that point. And then license back. But it means that the organization that owned MySQL actually owns the code base, which allowed them to do all that nasty dual licensing stuff. Well, I say it's nasty now. I used to think it was half a good idea. I've grown up. And apart from the growing up, the world has moved on. It no longer makes any sense whatsoever in the current environment. As far as I'm concerned, five years dead, and you just have to make the salespeople stop doing silly things. It makes no sense in the current ecosystem. The thing is, it still makes the money. Therefore, they wanted to go. It was intended to drop it when MySQL Network first came out, which is now MySQL Enterprise. The intention was to taper off the licensing sales, because the services and MySQL Network subscriptions would take over. However, they both ended up being nice money. And as long as something keeps making money, you don't drop it. That's just one of those things that used to upset me and it's still kind of annoying on the sideline. I tend to try and ignore it. Other questions? Yes? Well, who is they? I mean, lots of people in the ecosystem are. So just to go back here, yes, Percona is actively hacking on InnoDB and calls it extraDB. MonteBegam is actively working on MariaDB, including those things from Oracle. Oracle itself is working on the MySQL code base, including the InnoDB component. I don't know if you know, but InnoDB was developed by a separate company years ago, InnoBase OU in Helsinki by Heki Turi. And that company was bought in 2005, 2006, by Oracle Corporation. They already own the piece, which essentially bought them a seat at the table. I've met Ken Jacobs, who was employee number 18. He's no longer with Oracle now. But I've met him numerous times at MySQL conferences and elsewhere. A great guy, really useful actually to MySQL ecosystem because he had some great input. He's a very wise individual. He has a lot of experience. He's been with Oracle since whenever it was developed. So yeah, all those people are still active. And lots of people in the community are working on things. The cool thing is that because of the way the development model at MonteBegam works, more community contributions can find their way in. MariaDB is pure GPL rather than dual licensed because MonteBegam doesn't own the copyright to the original code. They have the code base just like I have it on my system under GPL. So whatever they add, well, the bits that they add is, of course, theirs. But when they add the bit from OpenQuery, the OQ graph engine that is mine, PBXT is owned by Paul McCullough and so on, or by Prime Race, I don't know. Yeah, so all those contributions are out there. And it's now a bundle of GPL stuff owned by different people, just like the Linux kernel is and all the other modules and other components that are flying out there in GPL and that makes up our Linux boxes to put it correctly. So that's the overview. Here's some resources. Yes, I'll happily answer for the question. I think the question that was being asked is which is growing faster? But which one has the, generally, it's like trying to pick the winner, which one's, yeah. 5.5 has been in the works for a bloody long time. Let me put it that way. It used to be called version 6. Then it was called NextGenNG or something. And it was like a continuing tree that never went anywhere. Then there was a 5.6. Then suddenly 5.6 disappeared. Then 5.5 came out in product previews. And then suddenly, oh, labeled 5.4. And then in the end, 5.5 came out, hooray. So I don't know how many years I've actually gone by to make this thing happen. And lots of things fell by the wayside, like the pluggable backup thing that 6 was going to have. It's gone, poof, vanished, bummer. So online backup for all storage engines. That would be nice. There are other ways of doing it, but that idea wasn't bad tossed out the window somewhere. And there were lots of other interesting things in version 6 that went by. So in terms of versioning, I've kind of lost it really mentally and for business. So I think at the moment, in terms of the number of people involved, as far as I can see, the MariaDB and Wins, because it incorporates things from lots of different people, Oracle has internal development and can accept code contribution, but under very specific conditions. And there are business imperatives why they want to accept certain patches. So it's less open. Montipugam doesn't care about that. So they happily put in those things. They don't have an interest in not accepting something. In fact, they have a very strong interest in accepting as many things as possible for many people within reasonable sense. I mean, if it does really weird things to the server, that wouldn't make sense. But yeah. Yeah, yeah, absolutely. My business relies on it. Oh, this particular business of mine, yeah. So from that? Yes. Yeah, yeah, absolutely. He's there. Yeah, we're good mates. Now, where's my crystal ball today? Fair enough, but all I can give you is the information. I seem to have left my crystal ball. Yeah, that's the idea. But my crystal ball is as opaque as yours. It doesn't work particularly well for this kind of stuff. I think it was a Drupal call, actually. A Drupal done under a couple of, well, you were there. As in predicting what would be cool in a couple of years and so on. And damn, were people wrong. So yeah, that kind of stuff always happens. And that's why I use MariaDB, because of the interaction I've had with my former colleagues. I know the people. I know what they do and how they work. That MariaDB is a pretty good bit, also because it merges from the Oracle code base. Now, if Montyprogram and MariaDB were to completely disappear, there's still the Oracle code base anyway. And the code is out there. And other people are working on it, like Percona. So I think that code base is a solid thing to have around, which is why we use it now. If it were to disappear, I don't, well, if no more new versions came out, that's not a particularly harmful thing right now, because that version works pretty well. Drizzle is getting there. I mean, in the past, it has been strongly recommended you do not try that stuff for production, because they did rip everything to pieces and stuck it back together in a different way and rewrote things. Of course, things will break on purpose. And yeah, that's taken quite a while. But it's getting along really nicely. They've built a completely new replication infrastructure just to give you an idea of the complete re-engineering that they've done. The code base no longer looks at all similar to MySQL. They have some common heritage, and that's about it. There's some ancient history there. So yeah, for certain purposes, Drizzle will be the better choice. The intent there is particularly suitable for cloud type infrastructure, things with interaction with, for instance, Gearman and that kind of stuff, distributed kind of processing. And it's in part sponsored by Rackspace, which has an interest in that kind of cloud stuff. So yeah, it'll go in that direction. MySQL, of course, has a very large existing user base. So whatever it intends to do, it needs to keep in mind whatever it was doing in the past, which is support, I don't know, a couple of dozen million users installations, whatever. I don't know. I can't hedge bets any particular way. I think various of these players will be around for quite a while. Like I said, I have no reason to believe that MySQL will not be developed by Oracle in the foreseeable future. But I do know that when I talk to an Oracle salesperson, they will be plugging Oracle database, not MySQL database. And that might make an impact in the future on how much money they spend on it. So depending on where the revenue comes from, there might be different decisions. But that's just business imperatives. I'm not actually presenting anything in particular. There was one last question there, and then we need to finish it. Yeah, that's essentially it. Yeah, the code is available. There are enough people in the ecosystem and companies available to do stuff that support things that can fix bugs. And if you have an existing app that works, you can keep running that for a long time. We still see people using really, really old versions of MySQL. And should I upgrade? Please don't, because it works now. If it ain't broke, don't fix it. For those specialized environments, just leave it. If you're dealing with a bug, sure you should look at upgrading. I'm talking with someone who knows what has happened since. That's fine. But yeah, essentially, I don't think there's a problem. And I'm not really, I don't think it's really necessary for me to look ahead that far on what will be around in a couple of years. It'd be interesting to look out for, but for business reasons, I don't think it matters that much right now, because I know that the code base is out there and the people are out there. Okay, thanks very much.