Slashdot Mirror
Oracle Acquires Innobase
A short time ago, Oracle announced its acquisition of Innobase, the Finnish company that makes the GPL'd InnoDB table storage engine. Among MySQL users, the separately-written InnoDB is almost as popular as the native MyISAM engine, and is considered to be more advanced for most purposes. Slashdot has, except for search, run entirely on InnoDB for the past year or two so we're as concerned about this as anybody. Brian Aker, former Slashdot coder and current Director of Architecture for MySQL AB, comments: "InnoDB is GPL, so once again the beauty of the open source market is at play: there is no lock in, and we can continue to develop Innodb as we see fit. The code is out there and we plan on continuing to support it. The largest database vendor in the world just confirmed that the market for open source databases exists."
I would think that it was the users of InnoDB that confirmed that the market for open source databases exist.
Also, what about IBM and their open-sourcing of Cloudscape? Don't they count?
If you post it, they will read.
The MySQL business model works following way. They enforce the GPL and if you want to get out of the GPL you have to pay, just like qt, but MySQL has a problem there. Qt has its own codebase, MySQL does not, they rely on Berkley DB and on InnoDB, obviously there must be some relicensing contract between them so that people can relicense the InnoDB code non GPL, so what if Oracle refuses this relicensing in the future. MySQL might have a problem bigger than it seems on their hand. BDB is not the best repo (ask the SVN guys) and InnoDB is now in the hands of Oracle. Not that I would be sad to see MySQL going the way of the dodo, but this issue is bigger than it seems.
I do know there are at least several developers at MySQL AB who are intimately familiar with the InnoDB code, but I don't know if there are enough to fork the code and continue its development in the same vein as before. Frankly I will be surprised if this doesn't slow down 5.x development at least a little, while MySQL AB shuffles people around to get them up to speed.
"Because continuing InnoDB development is critical to upcoming versions of MySQL, and development of a database engine requires more than simply GPL'd code. In the past, Heikki Tuuri's company Innobase has been eager to develop InnoDB specifically for MySQL's needs, because MySQL was in a sense the only "platform" it ran on. But that's not likely to be true in the near future, or at the very least, not necessarily true.
I do know there are at least several developers at MySQL AB who are intimately familiar with the InnoDB code, but I don't know if there are enough to fork the code and continue its development in the same vein as before. Frankly I will be surprised if this doesn't slow down 5.x development at least a little, while MySQL AB shuffles people around to get them up to speed." -- Jamie
If you "get" pointers add me as a friend (116)!
Now we see the reason for all the endless pro-MySQL articles on Slashdot. They've been using it since the site's inception, despite superior alternatives like PostgreSQL.
If MySQL hooking up with SCO wasn't enough to steer people away, this probably won't either.
"Sufferin' succotash."
Perhaps the KDE project should take this as a warning, too. They're also heavily dependent on a third-party piece of software: TrollTech's QT.
Suppose TrollTech were to be bought out tomorrow, and they stopped releasing their work as open source software. While QT is open source software and could thus be forked, would the KDE project be able to muster together the talent to continue developing it? Or would it stagnate, in turn harming the entire KDE project? Has the project looked into the possibility of that happening, and if so, what are their contingency plans?
Cyric Zndovzny at your service.
Mysql could replace its transactional foundation (innodb) with postgresql.
This would give it a transactional foundation that oracle couldn't buy out from under them!
What, exactly, is the point of a DBMS that doesn't guarantee (or try to guarantee) data integrity??
.. why should I buy your managed fund? Why don't I just buy an S&P index fund and match the market?
Reminds of the mutual fund manager who was part of this exchange at a conference:
Customer: Your XYZ fund has underperformed the market each year for the past 5 years
Manager: Uhm, our fund isn't designed to beat the market.
Customer: W...T...F...??? *gets up and leaves*
MyISAM is a sad sad mistake and I wouldn't touch it for *any* application. The really sad thing is, the people who justify it by saying "it's faster" are usually the same ones who code in PHP, Ruby, etc., so it's not like they are blazing along at 10M transactions per day, yah know?
Which would you rather do? Buy a couple more boxes to spread out the load, or explain to your boss why the last 1,000,000 inserts are WRONG because of a crashed process a couple weeks ago inserting inconsistent data? Geez.
This is probably accurate. Oracle was most recently in the news, remember, saying that they wanted to "crush" Salesforce.com's competing CRM products.
u sh_salesforce/
http://www.theregister.co.uk/2005/09/30/oracle_cr
Since you can't really buy and destroy open source software, they may well be trying to throw a monkey wrench into it. InnoDB brought ACID compliance to MySQL, and the new 5.0 release brings, well, SQL to MySQL. Despite what I'm sure Oracle would say, this is a problem for them.
I know there are copious reasons people can bring up about why MySQL still can't hold a candle to Oracle. Those people are, in my experience, the ones who fail to appreciate that when money is, in fact, an object, "good enough" frequently trumps "unreservedly best." (While I'd agree with the ones who'd suggest PostgreSQL instead, MySQL has a great deal more mindshare, and if MySQL 5's new features hold up in practice, the gap between the two is much smaller now. Also, like it or not, having the database vendor provide commercial-level support, as MySQL AB does, trumps PostgreSQL's approach of "here's a list of independent consultants to call" for most companies.) I'm aware of more than one company that evaluated Oracle and chose MySQL anyway, because they decided the performance and stability gain for their particular application didn't justify the cost.
So would Oracle make this purchase solely to try to slow MySQL's progress? Absolutely.
I love the new CSS layout, truly I do. But the fact that it took a few years to implement it ...
...
No such fact exists, in fact. It took a few months, not a few years.
Had it been built on a solid MVC platform, the project should have taken a couple of days
That's nonsense. The great majority of the time spent on it was two things: making sure the code produced text (comments, stories, and so on) that was valid HTML 4.01 strict (which includes processing all old data), modifying the code to make CSS well-integrated into the system (so that it would play nice with sections and so on), and then actually designing the HTML and CSS. None of that would be eased, or even affected significantly, by whatever MVC platform you wish to conceive of.
(Slash actually does use, essentially, an MVC model, though not religiously; we have significant and pervasive separation, but not complete. But really, very few code changes were required to accomodate the view, except to supply new features to the view [such as the aforementioned automatic stylesheet handling on a per-section basis], so as to make the distinction from true MVC moot for the purposes of the discussion here.)
And even assuming it was just modifying the view (and we could have done it that way, in shorter time, but decided to do it better than that would have allowed): a few days? Obviously you've never worked on such a large system as Slashdot (which is not that large). There are scores of templates that need porting and testing. Just the view part alone is a several-weeks project, assuming you already have the thing perfectly designed, which of course, we didn't, as you make a lot of changes as you go along. You can't just wave a magic wand and turn thousands of lines of crufty HTML 2/3.2 into valid, strict HTML 4.01.
And adding Atom when RSS was already working? That should have been a lunch break project.
Yes, it was minor (though obviously not a mere hour, since code has to be written, tested, and so on). It was a few days going back and forth with one of the core Atom guys, since we had no experience with it. Then another day or two of modifying the code to be able to transparently handle multiple feed types, since 'rss' was hardcoded in a bunch of places. Then more testing, bugfixes, etc. Not to mention integrating it with FeedBurner, who currently handles our feed distribution.
But the original poster said there are no new features being added. I listed three significant ones added in just the last month. I would hope not all of them would take a long time to do, else they'd not have all been added in September
If you're creating a BLOG or web forum, foreign keys and transaction management aren't vital in the way they are for financial applications.
It is so easy (see the MySQL Gotchas site) to accidentally lose transactional and foreign key support even if you installed InnoDB libraries that it is pretty dangerous to depend on the notion that any of the "data integrity" functionality is actually in place.
And the classic sorts of MySQL(tm) applications were written for version 3.23, so it is common to be unable to use InnoDB on the longstanding web apps.
At OSCON, the MySQL AB guys seemed pretty uncomfortable with the notion that the new versions had to support all this data integrity stuff. This buyout can let them head back to what they are comfortable supporting.
If you're not part of the solution, you're part of the precipitate.
In his blog Oracle OS evangelist Omar Tazi raves about all the things that Innobase can do and MySql can't. Then he says: It'll be interesting to see how this affects MySQL. Stay tuned! Doesn't sound like a friendly takeover...