RIP Open Source MySQL
developers.slashdot.org
developers.slashdot.org
http://hub.opensolaris.org/bin/view/Main/
It's just not supported or maintained any longer.
They made some seriously cool stuff, and in their later years they were really quite progressive in their outlook and approach.
Jonathan Schwartz, for me anyway, kicked off the whole cool, open and chatty top exec thing that's so common now.
This is a common misconception about Sun. In fact, they were quite progressive from the beginning. They embraced a hybrid open/closed model from day one, for instance. They opened up some key technologies, such as NFS and SPARC. They maintained huge, comparatively, research budgets, with relatively few strings attached to productization of that research. Through the late 90s and very early '00 (Dotcom era) they were under constant pressure from institutional investors to cut research funding, but didn't.
In the end, though, I have to agre. I miss Sun (though my friends and co-workers probably do not miss me talking about how great Sun is)
[edit: cut-n-paste quote error]
Yes, and look how well it worked out for them...
Certainly PARC has been instrumental in many areas of technology, I don't think it's fair to dismiss most corporate research. In fact, at least in the land of technology, most corporate research has done good stuff.
When x86's starting eating away the profits of their SPARC business, it was abundantly clear they would have problems down the road. Computing platforms tend to move up and what's on your desktop now may be powering servers ten years from now (quite possibly because by then people will have spent ten years writing and learning how to write software for it).
Sun tried to disrupt the desktop with the SunRay series, but they never got to the right price point. I'd have loved to have a Niagara-based desktop and I bet that had one been available for Unix enthusiasts, Firefox would be rendering pages and tabs on dozens of different threads.
People often discount that, but I can say it from experience. Back in 1998, I had two machines on my desk at work: a 400 MHz Pentium II (or III) and a dual-processor 200 MHz Pentium (both running Windows NT 4). While the single processor was somewhat faster, the overall experience of the dual processor machine was much smoother, with very few pauses and hourglasses. A lot of software today is single-threaded for the sole reason processors have only recently become multi-threaded.
And x86's only became multi-core/thread after the NT kernel became mainstream.
Monty doesn't come to this with clean hands.
MySQL has splintered into at least 3 competing forks outside of the "real" MySQL: MariaDB, Percona and Drizzle.
It's required where you want to sell a restrictively licensed (GPL, say) open source project under a commercial license. If it's licensed under something like the Apache license or BSD, you can do what you want with it. But then, so can everyone else, so you don't have the advantage you would with the dual license and require copyright assignment strategy.
Please, stop spreading this meme. The only thing GPL restricts is companies who want to restrict the freedoms of their users. Software, sex and yes, users, are better when free.
Sure, the problems are caused by the contradictory licenses, but GPL is part of the problem here.
Because Pixar's code is licenced under another restricted licence (MS-PL) which is crafted to be incompatible with GPL. Apparently Pixar is talking with Ton Rosendaal (Blender development leader) about solving the licence issue so it seems it won't be 'impossible' after all. Likely some sort of dual-licencing solution will take place.
It's coercion which tries to make everything freer, but in this case made things less free.
I actually kinda like the GPL v2. The GPL v3 license is an abomination however and needs to die.
Before you jump on me about BSD license compatibility, let me add a caveat and explanation. The caveat is that although the texts of the licenses are at least likely incompatible, "everyone" (namely every free software-inclined lawyer I have asked about this issue) agrees that since the intent was to be compatible the GPL v3 should be read to be compatible, but no two lawyers give me the same answers. I have discussed this with both Eben Moglen and Richard Fontana however. Also one cannot dispute that the GPL v3 is clearly compatible with the MIT license since that explicitly allows sublicensing.
The problem has to do with section 7 additional permissions and additional restrictions in the GPL v3, as well as the lack of a sublicensing grant in any of the BSD licenses. The BSD licenses offer a public grant by the software author to all who obtain the source code. However, they allow other intermingled code to be subject to other licensing schemes. This is different from the MIT license which directly allows sublicensing (Author A publishes, I take his work, and change the effective license without changing the software, and sell it to you, offering only some of the rights I received). The GPL v3 arguably requires a sublicensing grant from a permissive license in order to be compatible and the BSD family does not give this sort of license.
So when I talked with Moglen he suggested it would be compatible because you could add whatever additional restrictions you wanted but those would be unenforcible until actual changes were made to the software. Since the license change would be unenforcible, he suggested, the original author would not have his or her copyrights infringed. Richard Fontana however has suggested that this is a bad assumption and that developers must not make such an assumption that this is safe.
Instead Fontana suggests that additional notices should be read broadly enough to include the BSD license (and license grant) as is. However, this guts the idea of additional permissions under the GPL v3 and the requirement that they be legally removable without altering the code. Since you can't reduce the BSD license to (GPL v3 + permissions that can be removed without altering the software), the license is not compatible with the text of the GPL v3.
This means that although the licenses are (everyone agrees) compatible, it isn't at all clear as to what this means. Nor is it clear if I write a BSD license which explicitly states that sublicensing is not permitted and that permissions can only be revoked upon altering the code, whether this would also be compatible.
In short the solution to a license which may have some corner cases is a license that lawyers can argue about endlessly.
It's certainly one of extremely few I've ever come across, and it's the only one which pertains to component/framework code like opensubdiv that I've seen, which is usually not GPL licenced either but rather uses permissive licencing like BSD/MIT.
>And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.
That's the whole point of GPL, to keep the source code open. Just like the whole point of MS-PL is to serve proprietary needs while still employing the reciprocal nature of GPL.
Tell me, how does "robust" translate to "there are more restrictions on what you can do with this"?
Yes. You won't be able to restrict your users with GPL.
"Robust" because the software, once licensed under it, will remain free.
"Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." -- the guidelines
FSF is an exceptional case. In practice, however, dispersed copyrights are more effective for the user community because no one entity can wreak havoc through strategic neglect or minimal compliance.
There's a lot in a software system that is taken for granted that the GPL doesn't cover.
This is an excellent opportunity to demonstrate that anyone can fork the MySQL codebase and create other plug-in replacement databases with it, such as MariaDB and Drizzle.
All that is lost is the MySQL name and brand.
PostgreSQL users and developers must seize the opportunity to show businesses that free software cannot be killed, not even by mighty Oracle. They and, most notably, Microsoft, have been trying to kill it for more than a decade now.
Because the anti-free-software FUD machine (fed in part by Oracle itself) is already having a wonderful time with this.
MySQL and PostgreSQL represent two very different implementation philosophies, and being able to choose between them according to taste and merits is a good thing.
Most of us have suspected that the MySQL project itself was going to die as it was acquired by Oracle, in the same way Open Office died when it was acquired by Oracle. This is a company where good software goes to expire, either due to a deliberate intention or gross incompetence I can't say but I suspect it's a mixture of both. However sad that may be for the MySQL (or OpenOffice) brand name, the code itself lives on and continues to evolve within a rich open source ecosystem.
Hence, sensational and petulant "RIP $PRODUCTNAME" articles are unnecessary. There is no threat to existing projects based on MySQL or any other successful open source project for that matter. Not only will this stuff be free forever, it will also continue to grow and be developed on its own.
The corporate assassination of open source projects will only work if we let it, it's a purely psychological game.
I do agree that injecting postgresql into every discussion without adding anything new is getting excessive. And declaring mysql dead is clearly premature. But let me respond to this particular point:
"Show some solidarity with a fellow open source project!"
I guess I never really saw MySQL as an open project.
* when I first started using mysql it was not under the GPL, it was under some free-for-non-commercial use license * They pretty much reject the standards completely (introducing nonstandard things like backticks that make migration away from mysql harder for no apparent benefit) * mysql never fostered an outside developer community (by which I mean people developing mysql itself) * the code is messy and poorly structured * the development ecosystem, like revision control and documentation (and now tests) don't seem to be open * the licensing of the client library is restrictive * they require copyright assignment (although not all of the forks do)
I hope one of the forks does manage to foster a more open community, but communities aren't built overnight nor are they transplanted easily.
Of course when you're talking about community, every project seems to have a different atmosphere. Linus Torvalds is famous for not accepting patches or contributions to the Linux kernel, so is that project really open? From the perspective of a developer using MySQL, the community has always been massive, diverse, and helpful. Maybe it was a different experience on the dev mailing list, I wouldn't know. But I do know that in the end, MySQL was open where it really mattered.
I can understand though that it was probably easier and more rewarding for an outside developer to get into the inner circles of Postgres than it was to essentially join MySQL AB back in the time when they still existed.
> I hope one of the forks does manage to foster a more open community, but communities aren't built overnight nor are they transplanted easily.
I assume you're talking about the actual engine development community, and I'm not certain that's really how a lot of open source projects actually work. It seems in most cases you simply have a core group of developers doing their thing, with occasional discussions and input from the outside. I might be wrong, but that's certainly my perception. The Postgres dev community might be different, again I wouldn't know.
As an app developer, I have different expectations about that. I'm not going to take part in any discussions about implementation details, nor am I likely to submit any patches. What I care about is software quality and proper documentation, those are not necessarily a function of community.
Agreed. My perception is more that it is turning out to be one and that is a good thing.
"But I do know that in the end, MySQL was open where it really mattered."
The GPL means that there's no real fear that licenses will be scarce. And the large user community means that there will always be people to offer basic support (free or paid) and consulting. To that extent, I agree.
As far as getting bugs fixed, adapting to new use cases and changes in the market, or just moving the product further, the jury is still out. Will Oracle do it? Can any of the forks do it?
Or the larger question: are you OK with calling MySQL, as a product (i.e. the engine), "done"? I'm not saying that in a negative way. We rarely talk about software that's done, or what it would take to finish a given product, or how much sense being "done" even makes.
"It seems in most cases you simply have a core group of developers doing their thing, with occasional discussions and input from the outside."
That's not how I would describe postgresql. There are lots of people that only occasionally submit patches and lots of people that take part in design discussions even if they never submit much code. It's pretty easy to start out as an application developer and then be sucked into a design discussion, and before you know it you are criticizing a design because it doesn't fit your needs.
Even if nobody has ever seen you before, if you jump into a design discussion and have a legitimate concern or use case that hasn't been considered then it will be taken as seriously as any developer.
"What I care about is software quality and proper documentation, those are not necessarily a function of community."
Absolutely correct. Although those things are also not a function of being open source or free of charge.
Perhaps Oracle's influence was a net positive. It continually reinforces that open-source software is more about contributing positively to the code rather than simply controlling the trademark. Mozilla could be seen as the anti-Oracle in this regard. The community believes their control of the Firefox trademark has been mostly a good thing.
Once Oracle bought MySQL, I saw a lot of the anti-MySQL comments in the PostgreSQL community die off pretty fast. The types of comments changed as well. Instead of the message that "we are much better technically than MySQL" (which is still hands-down true btw), the message was "if anyone asks, PostgreSQL cannot be acquired because there is no commercial entity to acquire." The shift was very much to let concern for Oracle start the conversation and simply explain why this cannot happen with PostgreSQL.
The very basic point is that anything PostgreSQL users can say here is redundant and really only belongs when answering people's concerns about the future. "Can this happen to PostgreSQL?" gets asked and most of us wait for that question before saying "no."
>MySQL and PostgreSQL represent two very different implementation philosophies, and being able to choose between them according to taste and merits is a good thing.
I guess you could say that. I would sum it up as "PostgreSQL is what you get when database hackers set about building a database to explore new concepts in. MySQL is what you get when you get application hackers building a bottom tier for their applications." MySQL's paradigm is fatally app-centric, however and I have a hard time seeing that as a good thing. I'd be happier if the app-centric db chosen was SQLite or Firebird DB.
The other thing to keep in mind is that MySQL really has been becoming less interesting as a competitor over time, and the Oracle acquisition has helped that along as well. Really, there's no point to bringing up PostgreSQL at this point. It just feels tasteless, like a victory dance on someone's grave (premature to be exactly equivalent but you get the picture). I'd rather see PostgreSQL targetting MS SQL and Oracle than MySQL. There is no honor in beating the weak. If we are going to go after someone might as well pick the strong :-D
Hence, sensational and petulant "RIP $PRODUCTNAME" articles are unnecessary. There is no threat to existing projects based on MySQL or any other successful open source project for that matter. Not only will this stuff be free forever, it will also continue to grow and be developed on its own.
Agreed on this point. But at the same time, corporate-sponsored open source projects (like MySQL) are uniquely vulnerable when compared to multi-vendor ones. The hard news to break to the HN crowd is that multi-vendor projects (like PostgreSQL), despite the fact that they are fundamentally more difficult to monetize, will eventually out-compete the single vendor ones which are more friendly to the start-up model.
I googled app-centric after reading this and I've come up with comparisions made with mouse-centric, computer-centric, user-centric and I don't really understand it. Are you using it as a synonym for single-user?
Basically the issue has to do with how MySQL folks and PostgreSQL folks see the RDBMS.
MySQL users see the RDBMS as the bottom tier for the applications they are developing. Consequently the system's design is aimed at letting the application steer the interaction. If the application wants to treat 30 February as a valid date, that's the application's call and the app can set sql_mode appropriately and allow such values to be stored or not.
In other words, with MySQL, the db is there primarily to serve the application.
With PostgreSQL, it's very different. The database is there not to serve the application but to manage data. The applications are just users of that managed data. In this model the database has a very different responsibility. You might therefore call PostgreSQL data-centric. Applications cannot decide how strict data handling should be because that would defeat the whole purpose of the RDBMS in the PostgreSQL worldview, which is the system which manages and ensures meaningfulness of data.
So MySQL sees the RDBMS as ultimately serving (and being accountable to) the applications and app developers. PostgreSQL sees it as ultimately being accountable to the data and DBA's. The problem is that this makes MySQL have trouble when multiple codebases are used to access the same data since each application could conceivably be operating on different sql_mode settings. Each application can therefore be seen to be interfering with the other apps' state rather than all consuming shared managed data.
Hope this helps clarify things.
One of the things I really liked about Firebird the last time I played with it is that it could be run over a socket or embedded as a library. The PostgreSQL community will not provide a library engine because of the fear that application bugs may cause corrupted data structures in the library. Again this is wholely consistent with PostgreSQL not really caring about the single app space that much.
What this means is that if you want to distribute an application, you can actually directly link your application to the database management component directly and this simplifies the management of your app. If you need to later move the app up to a dedicated server you can do that. Firebird makes this really easy and it does so without creating the flexibility on input (and hence the fact that so many variations must be handled on output) that MySQL does.
I respectfully disagree.
Building a community of database developers is no small task. PostgreSQL has spent a long time fostering a diverse group of developers, maintaining a clean codebase and infrastructure, and having explicit policies and procedures in place that make it easier for new developers to get started.
That has never been true for MySQL. Development happens largely because of the money that MySQL AB, then Sun, and now Oracle is paying.
Monty is trying to change that with MariaDB (I don't know as much about the others) and I respect that and I hope he succeeds. But it takes a while to go from corporate development to community development successfully -- it doesn't happen overnight, especially in a field like databases where it can be hard to find developers regardless of money.
Having one single corporate sponsor is always a very bad idea for open-source projects. I hope MySQL derivatives have learned this lesson.
And, I imagine, the dual-licensing thing has to go. That's no longer a viable way to sustain development.
Aside: why, oh why, did 3 mysql forks appear when MySQL AB was bought? Couldn't they coalesce around one alternative?
Ordinarily, I'm not against a little healthy competition. I think forks and trying new ideas is great. But the timing just makes no sense to me from any rational point of view.
"I suspect keeping up with it does not require as much effort as it did getting to where it is now... maybe... it will continue evolving."
True, but I'd hate to see the bar set that low.
They had different goals. MariaDB was to maybe make another billion and Drizzle was to be more parallel and remove all the Windows specific code, IIRC.
Percona Server exists because Percona has a great deal of deep hands on knowledge about MySQL tuning and internals, and has a live-or-die commitment to making MySQL work well, and taking patches from it's user community.
Maria and Percona server advance more or less together, and routinely swap patches back and forth.
DrizzleDB exists because some of the MySQL developers decided that Doing It Right was more important than maintaining old targets and maintaining backwards compatibility.
There is plenty of room in the MySQL user and developer ecology for both approaches. If you need MySQL, and you don't trust Oracle, or don't want to pay them, just swap in MariaDB or Percona Server, they are drop-in replacements. In fact, you should drop them in away, they have more bugs fixed and are more performant than stock Oracle MySQL.
As we've seen for years PostgreSQL users will quite happily and naturally remind everyone how much superior it is to MySQL (and every other database) at every opportunity.
* you don't need transactions
* you don't need foreign key constraints
* you don't need ACID-compliance
Granted many of these don't apply anymore, but then legacies live on interaction-wise. This being said, I know very few real Pg users who harp on MySQL anymore. Most of us figure that Oracle does better advocacy on this area than we can.
More like, technically true, but contrary to the whole reason for doing what they're doing.
Nobody puts a lot of work into something "honestly" not intending to replace the thing it's replacing.
They say this to appease the people who point out that it doesn't do all the same things.
If I built a better alternative to a common item, you could bet your bottom dollar i would be very "honest" about it not replacing that common item. The last thing that statement would be is "honest." It's appeasement.
I also think the best way to look at NoSQL is that it is just a further development on Stonebreaker's bottom-left quadrant database division--- object databases.
The more I get into it, the more I am astounded with the power of PostgreSQL to take over all these workloads on the low-end and more.
Exactly. When NoSQL "honestly" say, oh nooooooooo we're not replacing the traditional RDBMS approach, this is anything but honest.
It's like me building this suspended-rail system for inner-city transportation. Oh noooooooo I'm not replacing traditional cars and bicycles!
the way you get acceptance is by faking honesty that you're not at all replacing the traditional approach (that you're replacing.)
The power of PostgreSQL occurs from the power to ignore the relational model and take other approaches when it is helpful.
It's not even that much to do - support INSERT IGNORE, ON DUPLICATE KEY UPDATE, INSERT REPLACE, and make a "relaxed" mode where too long strings are truncated and NULLs inserted into NOT NULL turn into 0 or the empty string and you are virtually all the way there.
It would be a cool kickstarter to fund something like this.
I think it can be good to offer a few conveniences to make it easier to switch, but I think they should be limited in scope.
Postgresql is not trying to be mysql -- that need is already filled by MariaDB and others. Trying to pretend that postgres is mysql would just make users frustrated and disappointed.
Think about it like moving to a foreign country. The residents try to be as friendly and accommodating as they can when it comes to food, shelter, transportation, directions, etc. There are often even multi-lingual people in the critical places. But eventually the goal is to adapt to the local culture and bring a hint of your previous culture into the mix; not completely recreate your culture in a new place.
Postgres is doing great being postgres. To the extent postgres can accommodate converts from mysql, or oracle or sql server, then also great. But we're too busy inventing new stuff to endlessly chase the quirks of other systems.
I suspect more than a few syntax adjustments would be required before users could rely on the port. The upstream project (e.g. wordpress) would need to be aware that their users were trying to use postgres in order for such users to be actually happy.
I could be wrong, but I have not seen a port of a real app that came down to just syntax differences.
It might be a different story between two implementations that follow the SQL standard reasonably well (MySQL is pretty far from the standard in many ways), but even in that case I'd be cautious.
No there shouldn't be a mode in PostgreSQL for this. The problem is that this means abandoning the idea of hard data constraints.
http://www.mysqlperformanceblog.com/2012/08/16/where-to-get-...
* You can put the innodb doublewrite buffer on your spinning disks - that's the best place for it since it's heavy sequential writes. See section 2.2.2 here http://yoshinorimatsunobu.blogspot.com/2009/05/tables-on-ssd...
* The ability to tune various parts of innodb that were originally designed to perform well on regular disks - those with fast sequential access, slower random access, and no real wear considerations. See http://www.percona.com/doc/percona-server/5.1/scalability/in...
Here's a recent post from Percona showing MySQL vs Percona server on an Intel 320 SSD: http://www.mysqlperformanceblog.com/2012/02/23/percona-serve...
--
MariaDB is pretty nice too. Their team has introduced some sorely needed query optimizations (http://kb.askmonty.org/en/what-is-mariadb-53/#subquery-optim...) and it does include Percona's XtraDB.
I haven't looked at MariaDB 5.5 to see how it compares to Percona Server 5.5. I put Percona Server into production last fall and MariaDB was still at 5.3 at the time.
So far working great with some local wordpress/php apps as well as older django apps.
I'm migrating slowly but surely to PostgreSQL though.
To answer your question concretely, which I read as: "Why can't we easily change out a SQL RDBMS as if it were a common component?" I would say:
(1) Lack of standards compliance; in this case the SQL standard being the relevant one that MySQL doesn't follow.
(2) DB specific extensions that many apps have become to rely on, often also caused by the previous point: apps having to rely on non-standard extensions due to the non-existence of a standard feature that could have otherwise been used. An earlier poster pointed out a few of these above (INSERT IGNORE, ON DUPLICATE KEY UPDATE, INSERT REPLACE, ...).
(3) Due to a combination of both points above, supporting software in your favorite language or ORM either doesn't exist, is incomplete for a particular DB, or lacking in cross-platform support (e.g. the mylang-pgsql driver for Linux works but doesn't on Windows, OS X or some other major commercial UNIX OS like Solaris or AIX).
(4) Finally, for open-source DBs there is practically no code re-use that matters; I see this as very unfortunate, because it could be a unique strength that only open-source projects can take advantage of. One reason for this is legal: different open-source DBs have different or conflicting licenses. But regardless of that (putting on flame suit now) much of the reason for a lack of code re-use is due to the fact that C and C++ make it pretty difficult to do well--which is a point I find true across all codebases in general (i.e. different C, C++ codebases share very very little code).
Seriously, watch it. Very cool.
Who are you trying to impress by removing test cases and revision history? That just seems like a dumb idea all around. I cannot imagine what you are gaining from that.
What are you losing? Me, as a developer/user of MySQL and your software in general (in the cases where I have a choice, anyways). Also, I'll be avoiding you as a potential employer, now.
See ya