Slashdot Mirror
MySQL's Creator On Why the Future Belongs To MariaDB
angry tapir writes "When Oracle purchased Sun, many in the open source community were bleak about the future of MySQL. According to MySQL co-creator Michael "Monty" Widenius, these fears have been proven by Oracle's attitude to MySQL and its community. In the wake of the Sun takeover, Monty forked MySQL to create MariaDB, which has picked up momentum (being included by default in Fedora, Open SUSE and, most recently, Slackware). I recently interviewed Monty about what he learned from the MySQL experience and the current state of MariaDB."
Arch Linux also made the switch three days ago: https://www.archlinux.org/news/mariadb-replaces-mysql-in-repositories/
Personally I think the future belongs to Postgres. :)
Oracle is now behaving like Monty's old company MySQL AB, trying to force volume users to pay to play. Remember MySQL AB's rigid enforcement of the GPL, with a dual licensing option? I wonder if MariaDB is subject to the same type of licensing games.
Nice dream.
Because JesusDB would drop tables for your sins. Perhaps NoahDB would be better. Built-in disaster recovery - it saves just enough data to replicate everything after the disaster is over.
The part he left unsaid was "MariaDB is the future because that's where I will make my money".
Remember, this is the guy that tried to get a merger court to give him the rights to MySQL back again after he sold them to Sun for a nice sum of money.
I was thinking why not name it OurSQL
You have 5 Moderator Points!
Which Helpless Linux zealot/MS basher do you want to mod down today?
NoahDB is not bad, a duplicate record of each kind.
How about JewDB though? You know it has to be good with business transactions. You definitely don't want a AlQaidaDB, it'll blow up ever so often and the DHS will be on your ass at all times.
I would like to know what specifically Oracle is doing so badly. I've been watching MySQL for a while as we use it at work, and it seems that a lot of advancements have been made in MySQL since the Oracle takeover. They've released 5.5 and 5.6. They haven't let it stagnate. They've released a ton of new features. They still have the free version easily available on their website. It seems like their prices have gone up if you want the supported version, but there are other providers out there.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
The part he left unsaid was "MariaDB is the future because that's where I will make my money".
Except that he put a lot of effort and money into organizing a team of developers for the last four years. Just compare what's going on in Oracle's land vs this fork.
It's another case of OpenOffice vs LibreOffice.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
http://monty-says.blogspot.co.uk/2009/12/help-saving-mysql.html
http://monty-says.blogspot.co.uk/2009/12/help-keep-internet-free.html
http://monty-says.blogspot.co.uk/2009/10/importance-of-license-model-of-mysql-or.html
why not just use postgres?
jeez
Many providers don't offer this in their cheap standard package. That's a major problem for Postgres I think. Then many popular webapps like Wordpress or Magento are mysql only, and I don't think it will happen soon that they will work with Postgres. Oh and if they did, most of their plugins won't work, so nobody will make the move.
Without the GPL, Mariadb would not exist.
I believe he is referring to the efforts to divest the MySQL trademark and copyright from Oracle as a condition of the acquisition of Sun by Oracle by EU courts. Not very nefarious as it was under the assumption that Oracle would destroy MySQLs viability in the future.
The more interesting part of that whole issue was when you look at how the US pressured the EU court to approve the merger unconditionally.
Oracle didn't buy Sun for MySQL, it bought it for Java. Everything else was a distraction that it now has to do something with.
Although (irrespective if we believe the specific numbers or not) ~1% of desktop users are Linux users, I think that 1% is a very significant one containing much of the people doing community contributions to open source projects (either patches or good bug reports). Because of this, I think the fate of the two ex-Sun projects OpenOffice and MySQL is very uncertain, despite having a massively higher user share thanks to MacOSX and Windows users and an established brand. Long-term, I think the developer mind share is more significant and that is obtained by being the default option in various Linux distros.
PostgreSQL date handler error?
al-Qaeda already means "the base"
wiki:
Experts debate whether or not the al-Qaeda attacks were blowback from the American CIA's "Operation Cyclone" program to help the Afghan mujahideen. Robin Cook, British Foreign Secretary from 1997 to 2001, has written that al-Qaeda and Bin Laden were "a product of a monumental miscalculation by western security agencies", and that "Al-Qaida, literally 'the database', was originally the computer file of the thousands of mujahideen who were recruited and trained with help from the CIA to defeat the Russians."[278]
Yeah... my lips get tired too when I have to read a long news article
If you were making $50k an hour, is there any reason you were using lightweight databases in the first place when given that income you could've trivially just stumped up for something a bit more reliable like Oracle or MSSQL Server?
Having worked with many different SQL Databases. MySQL, Microsoft SQL, DB2, Informix.... I have found that PostgreSQL is actually a really damn good Database system. Its fast powerful and very configurable. Sure the other guys will have some advantages over PostgreSQL, but I found PostgreSQL has the advantages where I find it counts for my use, for heavy processing, not just storing and retrieving data.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
why not just use postgres?
jeez
Ironically, the fact that PostgreSQL is a better DB makes it easier to convert from PostgreSQL to MySQL than the reverse. MySQL attempts to error correct your SQL queries while PostgreSQL is much more strict. The upshot of this is that queries that works and are tested in MySQL have a good chance of not working and need to be checked (doubly so if the original programmer tried to be clever).
The company I work for is in the beginnings of a transition. Our PHP and C software have an easy switch to convert between the two databases but now we get to check to make sure every query works and returns the same results in both databases. The cleanup of our queries will be good in the long term but for now it's a LOT of work.
Shite? Seriously? Postgres handles data more safely than MySQL. It has less risk of getting taken over by a giant like Oracle. It's fast. It's Free. Are you just trolling or what?
Michael Widenius has two daughters, My and Maria.
http://en.wikipedia.org/wiki/Michael_Widenius
ayottesoftware.com
You say "needlessly duplicative" like it's a bad thing.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Can I point existing code at Postgres rather than MySQL and have it work?
If not, that's kind of a problem.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Depends on what the code is. For example, if you've been using PDO in PHP, then probably no problem, since there is an abstraction layer between your code and the actual SQL calls.
Don't blame me, I voted for Kodos
The only thing Oracle is doing wrong is thinking that no one could be bold enough to try and sell the same product twice.
It's a gutsy move. It really is. Sell MySQL to Sun. Claim Sun's purchaser is doing __________ (fill in the blank with whatever evil nasty thing you like) with it. But that's ok, MariaDB will save you from that. Distributions flood to it to get away from the nasty big evil corporation, and suddenly Monty has legally taken back control of what he sold for a cool billion dollars.
The best part about it, is if Oracle says anything about it, then it just looks like they are trying to trash talk the little guy who is just trying to do the right thing for
the community.
And before you think of flaming the idea, remember, Monty is very much the businessman. He almost invented using the GPL as a weapon. He stopped releasing any connector or client licensed as LGPL so he could claim that even using MySQL as a back-end for something else required the entire front-end to be GPLed too - either that or pay him for a commercial license.
The next company to buy something from Monty better get an iron clad agreement never to fork it.
It's a MySQL problem. Postgres is SQL standards compliant, MySQL isn't.
It's a postgres problem - because I'd love to drink the koolaid and use postgres rather than mysql, but you'll note projects that implement specifically against MySQL rather outnumber those that either use postgres specifically or allow you the flexibility to choose.
I'm not a programmer - I just don't have the skillset. So the chances of my botching it up should I have to manually "port" the various web applications and the like are too high for my liking.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
It gives you two slightly different wheels to choose from, that's a good thing. Apparently some people feel like working on different wheels.
And if monocultures aren't a problem than what's with all this Windows malware?
"When information is power, privacy is freedom" - Jah-Wren Ryel
Why the Future Belongs To MariaDB? Because he will sell it to another company and will become rich again? That's about his future I guess.
Okay, then MySQL should go away since PostgreSQL was here first and did it right from the start.
If you look at the development of MySQL over the years its been a long waiting game of features that should be prevalent in any proper DBMS system but the lead developers openly admit they were not database guys when they started out so it's not really any wonder that the product was lacking from the very beginning and still shows its weakness today.
So the benefit is that you have a good product that you can rely on and it happens to be free. For MySQL you have a mediocre product with broad deployment because it relied so heavily on programmers to do in the application what normal databases handle for the programmer. This usually makes programmers happy as they think they know data management. So with MySQL a programmer must also know how best to handle data management, with PostgreSQL you have proper data management built right in. The database server does work rather than just being a storage repository with the MySQL approach.
It's the fault of the users of MySQL for sticking with a non-compliant SQL implementation even when other compliant ones emerged. It's MySQL's fault for not becoming compliant in a manner that encouraged people to take them up on the standards. It's not PostgreSQL's fault that people built to a non-standard.
And don't even bother making the claim that PostgreSQL should have adopted MySQL's quirks. They had bigger fish to match/fry: SQL Server, Oracle, etc etc. They've actively been working to fix their problems in a standard manner, rather than breaking themselves to match one broken database that very few people actually use outside of simple websites, where it's relatively easy to port to a standard one.
Because everyone in the open source community has this insufferable "Me, too!" attitude, resulting in half a dozen needlessly duplicative efforts.
That's right. Open source developers should take a cue from the commercial database market: The vendors like IBM, Microsoft and Oracle don't waste resources on duplicate efforts, but instead they collaborate on the one single commercial SQL database engine available on the market today.
Ironically, the fact that PostgreSQL is a better DB makes it easier to convert from PostgreSQL to MySQL than the reverse. MySQL attempts to error correct your SQL queries while PostgreSQL is much more strict. The upshot of this is that queries that works and are tested in MySQL have a good chance of not working and need to be checked (doubly so if the original programmer tried to be clever).
This doesn't really fit in with the concept of being perfect with what you supply but flexible with what you accept though does it?
I can understand that Postgres is probably more standards compliant and it is very admirable that it helps you write better SQL by refusing to run badly optimised drivel. The problem with this approach though it is assumes that all developers want to write better SQL.
Many developers in the world of work don't give too hoots about the quality of the work they produce, they just want go work 9-5 then go home and do other stuff. We might not like it, but there are tons of them, I bet all the people who are working know at least 1 or 2 in their office (If your still at university then they are the guys study CS that hate you for being a geek, unfortunately they don't fail and crawl under a rock). These developers will complain loudly about things "not working" under Postgres and just blame the DB.
You can argue that Postgres is more standards compliant to management until you are blue in the face, but unless you can demonstrate real world benefits your manager is going to go with MySQL. Sometimes the efficiency of the better queries is a real world benefit, but often that is outweighed by the increased costs of training developers to use postgres (there are fewer postgres devs out there than mysql) since in many situations it is cheap to just throw hardware at a problem. Also the majority of the time efficiency is not really needed since very few people will use the system anyway.
Technical decision makers will often prefer the tool that is easier to use as the complicated one is probably beyond them. That is why the became managers.
I dont read
oblig
"Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy
The problem is that MySQL only looks easier on the surface. I'm not talking about badly optimized, I'm talking about queries are ambiguous and In many cases where MySQL should return an error it simply returns wrong data. The downside when trying to convert is that in a few cases we have found so far, the original author had simply kept modifying the query until the output until it roughly sent what it was supposed to and the result of that is unmaintainable code that everyone is afraid to touch.
The thing that never ceases to amaze me about Slashdot is that you can say the most uncontroversial thing and there will always be somewhere there to tell you you are wrong. You can say the world isn't flat and there will be someone here to tell you it is.
You are that guy, the guy telling me the world is flat.
Really, if you think MySQL is comparable to MSSQL in terms of stability then you really just shouldn't be working with databases at all. MSSQL and MySQL aren't even in the same class.
Some web applications needs A.C.I.D. transactions. No-relational distributed databases won't replace relational databases until they can do A.C.I.D. transactions. The distributed part is particularly hard for A.C.I.D. transactions, 'cos destroys the performance.
What happened was this: Mysql and Postgres got to the point of a usable release at about the same time. Mysql was very slightly easier for someone with a very limited skill set to set up, and was arguably slightly faster, so it quickly became the preference among the crowd that swarmed into "tech" thinking that throwing together some HTML pages was serious programming. This same crowd was also very attracted to PHP because it seemed really simple by comparison to Perl or C for making web pages a bit dynamic. By 2000 or so, it was entrenched as the "LAMP stack", and shared hosting providers were offering Mysql and PHP support as standard (well, sort of standard, with different PHP options available, different versions, etc).
After the .com implosion in 2001, you had all sorts of people billing themselves as programmers, but only being familiar with PHP and Mysql. Many of them are now working as independent website contractors and the like, and this same crowd is also responsible for writing most of the CMS's out there, which in turn means that they use the Mysql/PHP platform that they know, rather than learn Postgres or Python or Ruby or Java. And that means that Postgres support for CMS's is more often than not an afterthought.
I am officially gone from
I've never had any problem with any of them. I can also use both a Phillips and a flat-head screwdriver.
Well then call it not putting all your eggs in one basket if you like.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Except that he can't. MariaDB is a fork of MySQL and as such Monty does not own the publishing rights in order to sell them. He could sell a "license" of MariaDB, just as he could also sell a "license" of Linux, but he can't alter the licensing of MariaDB any more than he can alter the licensing of MySQL anymore, nor can he sell those privileges to others.
The real problem though is that it isn't MY code, it's some project's code. I have no code, I'm not a coder. I could try to port it, but the chances of be breaking things is significant.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
It's more of a database problem in general. The ANSI SQL Standard isn't broad enough. If the situation was reversed, if you had a project written specifically for PostgreSQL, you wouldn't be able to drop in MySQL, either. Or if the project was written for Oracle, you wouldn't be able to drop in MS SQL Server. As some people have mentioned already, MySQL isn't 100% ANSI SQL compliant. But even if it was, you still couldn't drop it in place more than likely, unless it was a very simple application and didn't use any functionality outside of the ANSI SQL standard.
AND, even if THAT were true, it would still depend on how it was written. Some languages, like .Net/VB or Perl, force you to use a sort of middle layer in the code. Basically you write code that talks to A database, but not specifically WHICH database. PHP, however, is only just recently adding this sort of functionality. If your project happens to be written in PHP (you didn't say but it's likely given the popularity of PHP) and has been around for awhile, then it's likely that it's written to talk to a SPECIFIC database, and not a database in general.
This means that even if the databases and the SQL used were perfectly compatible, it STILL wouldn't work because the code is written specifically to talk to MySQL and only MySQL. If this is the case, then the fault wouldn't be EITHER database, but the code (and perhaps to some degree the language used).
By the way, going based on the number of projects that outnumber one or the other isn't a good indicator. MySQL was pushed as an easy to configure/use sort of thing. A lot of hosting companies sold products based on having a LAMP (Linux, Apache, MySQL, PHP) stack, for example. Thus we have a LOT of projects that are written in PHP and written for MySQL. That doesn't make either better (nor can you infer the opposite). It just means it was marketed really well. It's like saying MS Windows is the best operating system out there because that is what most people use, or that whatever famous pop artist has written the best music ever because they are popular right now (and by comparison, no one listens to classical anymore so it therefore must be junk). Basically, it's a flawed argument.
Of course, none of that really helps you out because from the sound of your posts you're stuck with MySQL and won't have a choice to move to something else and I suspect that the detailed technically reasons aren't going to be as important to you as that fact. You might, for now, be able to drop in MariaDB as a replacement but that's only because it's a fork and is practically the same database (and for now very specifically tries to be 100% compatible). But give it time and it's likely the projects will drift apart enough that you won't be able to drop one in as a replacement for the other as easily as you'd like.
In short- a piece of software CAN be written to support multiple database backends, but the software has to be written specifically to do so. And if it is, it would have configuration options to select which database to use. If it doesn't, then it probably can't. And that will be true regardless of what the backend database is.
If you look at the development of MySQL over the years its been a long waiting game of features that should be prevalent in any proper DBMS system but the lead developers openly admit they were not database guys when they started out so it's not really any wonder that the product was lacking from the very beginning and still shows its weakness today.
People are thinking about MySQL and Postgres incorrectly. Someone explained the situation in the following way that made things much clearer for me:
Postgres is a (relational) database. MySQL is a datastore/backend for you web app. Postgres could be used for web apps or for actual database use cases. MySQL should properly be used only for the former.
MySQL (except perhaps in recent years) was/is not an actual database. It may look like a database, but it is not (or was not, until recently).
If you only have one set of code (e.g., your web app) accessing your MySQL instance, then as long as your code is relatively clean, it's not a problem. Once you have multiple sets of code, and need proper server-side enforcement of schemas, then Postgres is the one that does this properly. MySQL can finally do this in recent releases if you jump through enough hoops of different settings, but by default it does not do this, and so is not a proper database.
It is people thinking that MySQL is a "proper" database when it was/is not (e.g., ACID, enforcing schemas by default) the reason the debate arises. MySQL is a great backend for web sites—but that does not make it a general purpose database. It makes it a generic datastore.
MySQL can be made to act like a RDMS, but most people don't change the setting to use it that way. Postgres on the other hand come set up that way out of the box and you have jump through hoops to force it to NOT act like RDMS.
So feel free to use MySQL to solve whatever problems you have, but please don't call it a database unless you're running it without at least the following settings in the my.cnf:
default-storage-engine = innodb
sql-mode= \
"STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"
I haven't ever experienced problems with data not being available on MySQL either. Running several Drupal 6 & 7 sites on MySQL. Also, the company I work for hosts their main customer interface against on MySQL and they haven't had any problems in the several years it has been running either.
Is that an issue from 'ye olde' days? I love your posts, but from what I am reading here, it seems like some have problems with bugs in MySQL that aren't actually there anymore. Either that, or I have just been insanely lucky to not have experienced any of them? I'm running Debian stable with apt sources from (http://packages.dotdeb.org stable). So my MySQL version is 5.5.30-1~dotdeb.0.
I couldn't blame you in that regard though, once something leaves a sour taste in your mouth, it's hard to find reason to go back and try it again, I've done the same thing. Though this article is definitely inspiring me to have a look at both PostgreSQL and MariaDB. One gripe I had before (in drupal v6 about 2 years ago) was that PostgreSQL was purported to not support a 'distinct' select by the maintainer of the 'views' module (or possibly a random committer?). It made some of the configuration that I tried to do with views not work out correctly, so I ended up hacking the module code to add distinct support.
Drupal v7 now has a database abstraction layer though, so it now supports specialized queries based on whatever DB you choose to run it on. Drupal 8.. haven't tried it yet, but I looked at some of their DB code using PHP 5.4 traits, and it looks pretty slick. I'm was planning on putting together a new VM soon for testing out Drupal v8 on PHP 5.4, I'll definitely give PostgreSQL and MariaDB a shot.. though http://packages.debian.org/testing/database/ doesn't seem to have a package for MariaDB, looks like mariadb.org has its own repos: https://downloads.mariadb.org/mariadb/repositories/.
Should be fun!