Oracle makes move to kill open source MySQL(techcrunch.com)
techcrunch.com
Oracle makes move to kill open source MySQL
http://techcrunch.com/2012/08/18/oracle-makes-more-moves-to-kill-open-source-mysql/?grcc=33333Z98ZtrendingZ0Z0Z0Z0Z0&grcc2=a121e3c06bfcc5573019c68937c7183b~1345472977381~fca4fa8af1286d8a77f26033fdeed202~unknown~1345117195375~98~0~0~0~0~0~0~0~9~3~
18 comments
MySQL and Java don't affect me much personally, but I think the way they've handled Solaris is a real tragedy for the industry.
Larry is the new Bill. I blame Jonathan.
Larry is the new Bill. I blame Jonathan.
I personally stopped using MySQL quite a while ago as well. Java, on the other hand, got resurrected for me with Groovy first, then Clojure (and a passing interest in Scala).
Yeah, I know about openjdk. But they don't provide official binaries for all I know (and certainly not for Windows, linking back to the Oracle distribution).
Yeah, I know about openjdk. But they don't provide official binaries for all I know (and certainly not for Windows, linking back to the Oracle distribution).
Larry has always wanted to have Bill's place in the world. He's a far worse monopolist than Bill ever was.
What's happening to Solaris ?
It is still open and available for download at http://opensolaris.org. It just isn't being supported by Oracle anymore since they are focused on Oracle Linux.
It is still open and available for download at http://opensolaris.org. It just isn't being supported by Oracle anymore since they are focused on Oracle Linux.
It isn't inventing the next DTraces and ZFSes.
FreeBSD is doing a great job of catching up with Solaris innovations. I love those guys! And maybe we can ride for a few more years on Sun's largesse. But who will push things forward?
FreeBSD is doing a great job of catching up with Solaris innovations. I love those guys! And maybe we can ride for a few more years on Sun's largesse. But who will push things forward?
No, the gate has been closed about two years ago. Solaris is not open source anymore. The illumos guys forked the last available version of the code and push it forward independently.
This test-case controversy was both discovered and ginned up by Monty and the MariaDB folks, who have much to gain by the rejection of Oracle's brand of MySQL and the promotion of MariaDB. While it may be part of some larger and sinister plan to "kill" open source MySQL as the article suggests, it seems more likely to me that it was simply a mistake, and one they'll walk back at some point.
If it is an anti-competitive move, it reminds me of the recent move by RedHat, who have started shipping their new kernels as one big source tarball, without patches, which undoubtedly pissed off both Oracle and the CentOS folks.
If it is an anti-competitive move, it reminds me of the recent move by RedHat, who have started shipping their new kernels as one big source tarball, without patches, which undoubtedly pissed off both Oracle and the CentOS folks.
From what I've heard withholding test cases is actually official Oracle policy, unlike, for example, the lack of updates to the launchpad repository. There wasn't any deliberate attempt to without commit history from launchpad - they were just slow in updating it.
"it seems more likely to me that it was simply a mistake, and one they'll walk back at some point."
How do you explain removing access to the source repository then? Or the fact that the documentation is not free to redistribute?
How do you explain removing access to the source repository then? Or the fact that the documentation is not free to redistribute?
How do you explain removing access to the source repository then?
I can easily explain it, because it never happened. Access to the MySQL source repository on launchpad is available for anyone to browse. Oracle is occasionally lazy about updating it, but they've never removed access AFAIK.
Or the fact that the documentation is not free to redistribute?
The documentation has never been free to redistribute, it was that way under Monty, it was that way under Sun, and it remains that way under Oracle.
I can easily explain it, because it never happened. Access to the MySQL source repository on launchpad is available for anyone to browse. Oracle is occasionally lazy about updating it, but they've never removed access AFAIK.
Or the fact that the documentation is not free to redistribute?
The documentation has never been free to redistribute, it was that way under Monty, it was that way under Sun, and it remains that way under Oracle.
it does not matter to simple rhel rebuilds like centos or scientific linux. it is unfortunate for the linux stable kernel maintainers. that's for sure though.
it is very different from this case. that it's a simple mistake is not very probable. see the java sec update controversy a few days ago.
it is very different from this case. that it's a simple mistake is not very probable. see the java sec update controversy a few days ago.
As mentioned in the comments see MariaDB (http://mariadb.org/), an open source fork of MySQL from before the Oracle acquisition. Like Hudson, MySQL will live on.
I've been using Percona for a number of years now. Are there any solid comparisons between Percona and MariaDB?
MariaDB ships with XtraDB, Percona's modified InnoDB engine. If you're planning on using InnoDB (which just about everyone is) the differences are pretty minor.
The big difference is that MariaDB comes with the Aria storage engine, which is a crash safe alternative to MyISAM.
http://kb.askmonty.org/en/about-xtradb/
http://kb.askmonty.org/en/aria-faq/
The big difference is that MariaDB comes with the Aria storage engine, which is a crash safe alternative to MyISAM.
http://kb.askmonty.org/en/about-xtradb/
http://kb.askmonty.org/en/aria-faq/
If you're using mainly InnoDB and want more reliability / performance / less variance in execution time - go for Percona, that's what they're specialising in. Also you can use the company for support when needed.
I don't think Percona sees itself as a fork: it is just MySQL + special Percona patches.
For those who try to stay away from TC: "it appears that Oracle is making its revision tests and histories closed source" sums up the few paragraph link bait ... :)
I used to enjoy working with Oracle databases, but the horrible pricing and high need for dba maintenance was always discomforting. Switch for a while to MSSQL, but then the market for Windows apps disappeared. Have been using mySQL with very little sort of DB satisfaction. Now I don't know why anyone would not choose PostgreSQL for almost any project. Oracle is a bad apple, making money with methods aking to extortion.
I still wonder why SQLite isn't used more. Granted for busy large sites/applications SQLite is the wrong tool. But most sites using MySQL are small.
Disclaimer: It's been a while since I tried to use SQLite for anything.
I've never really felt that it was actually easier to use than a client/server DBMS. I can imagine that it's good for some kinds of embedded applications, but for normal web applications I don't see any improvement in usability. Juggling files is not any easier than setting up a connection.
And there were always annoyances associated with the simplicity. All those "complex features" in a real DBMS turn out to be useful sooner than you think (and I don't mean "once in production" I mean while still in development). Even the simplest applications can usually benefit from good support for dates and times.
I think SQLite just drew the line in the wrong place for most applications (although it may serve a niche quite well). Oversimplification requires the developer to reinvent, which results in a much more complex system overall (or one that at least requires more work to develop and maintain). Key/value stores have similar problems for general-purpose application development.
I've never really felt that it was actually easier to use than a client/server DBMS. I can imagine that it's good for some kinds of embedded applications, but for normal web applications I don't see any improvement in usability. Juggling files is not any easier than setting up a connection.
And there were always annoyances associated with the simplicity. All those "complex features" in a real DBMS turn out to be useful sooner than you think (and I don't mean "once in production" I mean while still in development). Even the simplest applications can usually benefit from good support for dates and times.
I think SQLite just drew the line in the wrong place for most applications (although it may serve a niche quite well). Oversimplification requires the developer to reinvent, which results in a much more complex system overall (or one that at least requires more work to develop and maintain). Key/value stores have similar problems for general-purpose application development.
1. With the PDO (or any ORM) setting up and "using" SQLite is as easy as any other database.
2. There are several really nice front-ends to SQlite, along with the phpmyadmin like app for SQlite. Like MySQL you'll never have to use the command line (for most operations).
3. SQLite is now included with just about every scripting language (except MS' langs - where it's just a matter of downloading the app and an ODBC driver).
4. "Because it requires no configuration and stores information in ordinary disk files, SQLite is a popular choice as the database to back small to medium-sized websites." - sqlite.com
Simple websites. Would I run this site on SQLite? Of course not. Any shopping site with a million users? No. But a personal blog? Yes. A company website used for marketing and information (and maybe a few Contact US pages)? Yes.
There are millions of sites where using MySQl is over-kill. But everyone uses it because, like PHP, it's always there.
5. SQlite uses SQL. Very few commands aren't available.. like you can't write to a View. But I think that's true in MySQl too. There's a small list on sqlite.com. It even has transactions.
Simply put, if you don't require writing to the db from multiple sources (and lets face it, 80% of the sites out there don't.); running your app or site on sqlite is fine.
2. There are several really nice front-ends to SQlite, along with the phpmyadmin like app for SQlite. Like MySQL you'll never have to use the command line (for most operations).
3. SQLite is now included with just about every scripting language (except MS' langs - where it's just a matter of downloading the app and an ODBC driver).
4. "Because it requires no configuration and stores information in ordinary disk files, SQLite is a popular choice as the database to back small to medium-sized websites." - sqlite.com
Simple websites. Would I run this site on SQLite? Of course not. Any shopping site with a million users? No. But a personal blog? Yes. A company website used for marketing and information (and maybe a few Contact US pages)? Yes.
There are millions of sites where using MySQl is over-kill. But everyone uses it because, like PHP, it's always there.
5. SQlite uses SQL. Very few commands aren't available.. like you can't write to a View. But I think that's true in MySQl too. There's a small list on sqlite.com. It even has transactions.
Simply put, if you don't require writing to the db from multiple sources (and lets face it, 80% of the sites out there don't.); running your app or site on sqlite is fine.
"setting up and "using" SQLite is as easy as any other database"
That's exactly the problem. If it's easier, then maybe I'll use it. If it's just as easy, but does less, I have no reason to bother using it, for two reasons:
1. There is non-zero risk that I will need one of the other features.
2. Even if I don't, why would I want to spend time learning something if it isn't better (at something) than what I already know how to use?
I haven't seen any compelling reason to use SQLite outside of the mobile or embedded space.
"over-kill"
What do you mean by that, and why is it bad?
That's exactly the problem. If it's easier, then maybe I'll use it. If it's just as easy, but does less, I have no reason to bother using it, for two reasons:
1. There is non-zero risk that I will need one of the other features.
2. Even if I don't, why would I want to spend time learning something if it isn't better (at something) than what I already know how to use?
I haven't seen any compelling reason to use SQLite outside of the mobile or embedded space.
"over-kill"
What do you mean by that, and why is it bad?
""over-kill"
What do you mean by that, and why is it bad?"
It's not. I'm just pointing out that there are alternatives to MySQL. And for small sites/apps that don't require something like Postgres; that can be SQLite.
Frankly I miss the days when an easy to install and use database was available to the masses. Remember Paradox, dBase and Foxpro? Sure all those database where powerful (xBase, for example) and used to develop complex applications. But they were also used for simple applications.
I would love to see something equivalent to those online. Oh wait, there is; SQLite.
What do you mean by that, and why is it bad?"
It's not. I'm just pointing out that there are alternatives to MySQL. And for small sites/apps that don't require something like Postgres; that can be SQLite.
Frankly I miss the days when an easy to install and use database was available to the masses. Remember Paradox, dBase and Foxpro? Sure all those database where powerful (xBase, for example) and used to develop complex applications. But they were also used for simple applications.
I would love to see something equivalent to those online. Oh wait, there is; SQLite.
You can write to a view via triggers.
SQLite is not a real solution for anything needing to support more than one user at a time. It's fine for things like managing bookmarks within firefox, but not for a full relational database replacement. The write access is single threaded (at least last time I used it).
Well, mongo has write lock too, and people seem to use it a lot.
My experience with SQLite is that if you're using it as more than an object-store, you'll be disappointed by the limited subset of SQL it supports. And if you do just need an object store, Mongo is often a better fit and gives you flexible schema.
That said, as an embedded DB I would use SQLite.
That said, as an embedded DB I would use SQLite.
SQLite is very nice for simple single user apps :-)
MS SQL Server is mainly used by corporations for corporations, so there is a market and good money for apps and expertise in those circles if you have the expertise in the MS stack.
For OSS projects that require a RDBMS, PostgreSQL is a good choice. I instinctively choose it over MySQL years ago and have been pleased.
For OSS projects that require a RDBMS, PostgreSQL is a good choice. I instinctively choose it over MySQL years ago and have been pleased.
>Now I don't know why anyone would not choose PostgreSQL for almost any project.
No offense but people who make statements like this clearly don't know much about the current state of databases. PostgreSQL is pretty bad in many areas compared to the newer databases e.g. ease of clustering and sharding, developer friendliness, JSON support, tool support etc.
It's great as a replacement for a typical RDBMS but if you're working on a new startup project I would see no reason to use it.
No offense but people who make statements like this clearly don't know much about the current state of databases. PostgreSQL is pretty bad in many areas compared to the newer databases e.g. ease of clustering and sharding, developer friendliness, JSON support, tool support etc.
It's great as a replacement for a typical RDBMS but if you're working on a new startup project I would see no reason to use it.
Not sure what you mean by lack of developer friendliness and what specific tools you find it lacking. Postgres is a great choice for new startups that need an RDBMS and like having schema for their data. There is built-in JSON support in upcoming 9.2 release and most JSON-to-schema mapping should be done in application anyway. Sharding is easy to do at application level; you would lose ability to do certain queries across shards but most solutions offering automatic sharding are designed specifically not to allow most types inter-shard querying and instead offer map-reduce.
Sorry but PostgreSQL's JSON support is a joke. It is nothing more than a VARCHAR that validates. You can't search or index across fields and the way you actually query the JSON is cumbersome at best.
Also all of your arguments are "push to the application layer". Well my point is that with most of the newer databases you don't have to reimplement the wheel.
Also all of your arguments are "push to the application layer". Well my point is that with most of the newer databases you don't have to reimplement the wheel.
If you need to store arbitrary JSON fields in the database and index them, then you indeed are better of with some NoSQL database. But I strongly disagree with the statement that all new startups deal with that kind of data organization. Many problems have good structure and can benefit from imposing structure (schema) upfront. In which case any JSON you get will parse in the application, map it to your data organization and store in a clean strict relational format, with all indexable fields extracted to separate columns. I do not store my logs in Postgres, but I do store my billing transactions in Postgres. There are many different types of data with different tradeoffs involved. For most, Postgres is a great choice.
> ease of clustering and sharding, developer friendliness, JSON support, tool support etc.
Which RDBMS do you have in mind ?
Which RDBMS do you have in mind ?
Well some are better than others right. Riak/CouchDB are great when it comes to clustering/sharding. MongoDB has the best JSON support and is very friendly for developers. MySQL is proven, has the best tool support and most widely supported.
The fact is that just like one programming language doesn't satisfy all use cases. Neither does one database. So maybe PostgreSQL 'supporters' should stop trying to claim it is perfect for everyone.
The fact is that just like one programming language doesn't satisfy all use cases. Neither does one database. So maybe PostgreSQL 'supporters' should stop trying to claim it is perfect for everyone.
>RDBMS
>MongoDB
wat
>MongoDB
wat
It seems Oracle is on a trend to kill everything open source they've acquired from Sun. Java seems to be the only one left, and it would've happened already if they won the trial with Google, but I'm sure they'll do something equally dumb in the future to kill finally Java, too.
> It seems Oracle is on a trend to kill everything open source they've acquired from Sun.
Oracle is, above everything else, about monetization. If they can't make money out of it, they will either change it so they can make money out of it, or they'll kill it.
Sun was generally good at open-source (though not perfect by a long shot, OpenSolaris was not exactly a slam dunk and the CDDL was rather weird — and explicitly and expressedly made incompatible with the GPL), but they were rather bad at monetizing. Oracle's the exact opposite.
Oracle is, above everything else, about monetization. If they can't make money out of it, they will either change it so they can make money out of it, or they'll kill it.
Sun was generally good at open-source (though not perfect by a long shot, OpenSolaris was not exactly a slam dunk and the CDDL was rather weird — and explicitly and expressedly made incompatible with the GPL), but they were rather bad at monetizing. Oracle's the exact opposite.
IBM is also about monetization.
It also realizes that most of its monetization comes from professional services, and saw that 1) software subscription revenues were declining across the board, proprietary or Open Source, and 2) Open Source created (to IBM's lawyer's eyes) a possible threat to its patent holdings (a considerable revenue stream / business value themselves) which was best addressed by keeping core development outside the organization (Red Hat, Novell/Suse, Kernel.org, Apache.org).
Oracle's direction (as was Sun's somewhat schizoid approach to Free Software / Open Source before as noted by its supporting the Caldera/SCO Group attacks against Linux) are making it a non-credible source. Hence the forking of projects (Lumina, LibreOffice, OpenJDK, MariaDB, etc.) it had inherited.
It also realizes that most of its monetization comes from professional services, and saw that 1) software subscription revenues were declining across the board, proprietary or Open Source, and 2) Open Source created (to IBM's lawyer's eyes) a possible threat to its patent holdings (a considerable revenue stream / business value themselves) which was best addressed by keeping core development outside the organization (Red Hat, Novell/Suse, Kernel.org, Apache.org).
Oracle's direction (as was Sun's somewhat schizoid approach to Free Software / Open Source before as noted by its supporting the Caldera/SCO Group attacks against Linux) are making it a non-credible source. Hence the forking of projects (Lumina, LibreOffice, OpenJDK, MariaDB, etc.) it had inherited.
Well, there are some projects still going. But the joke is:
Q: Why hasn't Oracle ruined Virtualbox yet?
A: Because they're going in alphabetical order.
Q: Why hasn't Oracle ruined Virtualbox yet?
A: Because they're going in alphabetical order.
There are other open source projects at Oracle that are still "alive". Like Netbeans.
[deleted]
Why the quotes around "alive"? What has been happening with the Netbeans project?
They've dropped ruby. But other then that, nothing really. I Love (and use) Netbeans. I was just emphasizing that they are still alive.
But really I think the only thing saving Netbeans' butt is Java.
But really I think the only thing saving Netbeans' butt is Java.
"alive" :D
See previous submissions:
http://news.ycombinator.com/item?id=4400797 http://news.ycombinator.com/item?id=4397124
http://news.ycombinator.com/item?id=4400797 http://news.ycombinator.com/item?id=4397124
Time to brush up on Postgres or Firebird.
Let Oracle shoot off all their feet.
Let Oracle shoot off all their feet.
I don't know anything about Firebird. Is it really a good replacement for MySQL?
Firebird seems stable and fast enough, what it does lack is good client libraries. We looked at different database solution when rewriting our current webshop and Firebird was something we looked at, but because we're a Python shop we dropped it. I'm not saying that the current Python driver doesn't work, it does, but it doesn't seem to be updated very infrequently and it's still seems more like an InterBase driver than a Firebird driver. We went the Postgresql route, and why really, why wouldn't you?
Don't get me wrong, it's a great database and I know a company that use nothing else and won't switch if you paid them, ( They are use .Net ).
Don't get me wrong, it's a great database and I know a company that use nothing else and won't switch if you paid them, ( They are use .Net ).
I found it to be pretty solid and fast when I last used it, which was right after Borland Open-Sourced it. It was forked from Interbase.
Postgres is developing a lot quicker then Firebird. Also, management and replication solutions for Postgres are far more advanced. But what matters most (for me) is documentation. I can find everything I need to know right here:
http://www.postgresql.org/docs/9.1/interactive/sql-commands....
http://www.postgresql.org/docs/9.1/interactive/sql-commands....
I wrote an accounts receivable/payable app in Borland Delphi back in 2002. At the time Interbase was the easy choice. At that time, Interbase was transitioning to Firebird. I dropped it in as a replacement and it did its job fine. If you like MySQL, you'll miss auto incrementing Primary Key Columns that MySQL seems to have made so popular. It's not too hard to setup a trigger for sequence types, but it's not built in. (or it wasn't back then) All the tools for management were the Interbase tools. Most of my stuff is either MySQL these days or Postgres when I need good spatial support. I've messed with CouchDB a bit. I just don't see Firebird going anywhere for my needs.
Shoot their feet off how?
Most people saying "Time to switch from MySQL" (probably) aren't paying for MySQL. From a business perspective, those people are a net loss anyway. Getting them to switch to something else may actually save Oracle a little money.
Most people saying "Time to switch from MySQL" (probably) aren't paying for MySQL. From a business perspective, those people are a net loss anyway. Getting them to switch to something else may actually save Oracle a little money.
But they could happen in the future to work for a corporation that would like to pay, but as it stands they will never suggest using MySQL. Thus MySQL will slowly disappear from the youngs mindshare and Oracle will make no money at all on it.
How many people use a SQL DB without some form of support contract?
To do so is not too smart if your business relies on the DB to function.
To do so is not too smart if your business relies on the DB to function.
Let's hope someone forks it and teaches Oracle a lesson.
MariaDB is already a fork of MySQL, and many developers from MySQL now developing MariaDB.
Isn't MariaDB the fork by Monty, the original developer of MySQL who sold it to Sun in the first place, setting off multiple rounds of cashing out?
Four known forks so far (http://en.wikipedia.org/wiki/MySQL#Forks)
[deleted]
LibreSQL, where are you? :(
Isn't that what MariaDB is for?
Yes, Drizzle and MariaDB are two MySQL forks that are gaining good momentum. Let hope another OpenOffice -> LibreOffice move can be done again.
PostgreSQL.
That's like me saying "LibreOffice, where are you?" and you saying "AbiWord".
Is yours an informed opinion?
Postgres is an extremely high quality piece of software.
Postgres is an extremely high quality piece of software.
I think you misunderstood me. It wasn't a good analogy, though.
They were proposing an alternative when I want a fork of what I already use.
They were proposing an alternative when I want a fork of what I already use.
Apologies, I did misunderstand.
I cut a bunch of apps (and their large databases) over from MySQL to Postgres several years ago. It was tedious, but I've never had cause to regret it in any way.
When MySQL became Oracle I was very relieved to not have to think about the implications.
I cut a bunch of apps (and their large databases) over from MySQL to Postgres several years ago. It was tedious, but I've never had cause to regret it in any way.
When MySQL became Oracle I was very relieved to not have to think about the implications.
Well, personally, my favourite database is SQLite.
I don't build large apps, although for many-read-few-write-type sites SQLite isn't so bad.
I don't build large apps, although for many-read-few-write-type sites SQLite isn't so bad.
SQLite is awesome too. I use it whenever I can.
I personally like its simplicity, like the fact it's a single file and no messy authentication to deal with, and the simple data type set.
And also the docs are much more readable to me than for MySQL.
And also the docs are much more readable to me than for MySQL.
...and in the process opens the floodgates of possibilities for Drizzle, MariaDB, PostgreSQL, and everyone else. Oracle has already shown fairly conclusively it can do little else but mismanage its acquired Sun assets.
Isn't saying that MySQL and Java doesn't affect you like saying that Linux doesn't affect you because you use Windows?
These open technologies make the world turn.
These open technologies make the world turn.
[deleted]
TC;DR.
Don't anthropomorphize Larry Ellison
http://www.youtube.com/watch?v=-zRN7XLCRhc#t=39m25s
http://www.youtube.com/watch?v=-zRN7XLCRhc#t=39m25s
the line between what Oracle considers open and closed get fuzzier all the time. makes being a developer a pain in the ass.
No, it is easy: avoid anything touched by Oracle like the plague.
Unfortunately, that includes hardware too... A friend had 3 out of 13 Oracle servers die with random memory errors (persistent). Of course, if they had a 10K+ service contract they'd be happy to help.
In the enterprise hardware world, I don't know any vendor who will offer an answer other than "call your sales rep" to a customer who didn't buy a service contract.
It was a charity donation (by Oracle) of hardware and services, and the service contract wasn't part of the donation. The initial donation was laudable, but the hardware was weak. Needless to say, the 3 dead servers were not replaced.
How much did it cost to replace those 3 servers? >10K I bet...
This reeks of extortion. Let's sell the rejects to the customers without a support contract. That'll teach 'em.
Seriously, I never cared about that company as long as it was just selling expensive (but supposedly feature rich?) software to the enterprise, but it seems the alternatives to Oracle's java and MySQL need some more support, market- and mindshare.