Slashdot Mirror
Is MySQL Slowly Turning Closed Source?
mpol writes "Sergei from MariaDB speculated on some changes within MySQL 5.5.27. It seems new testcases aren't included with MySQL any more, which leaves developers depending on it in the cold. 'Does this mean that test cases are no longer open source? Oracle did not reply to my question. But indeed, there is evidence that this guess is true. For example, this commit mail shows that new test cases, indeed, go in this "internal" directory, which is not included in the MySQL source distribution.' On a similar note, updates for the version history on Launchpad are not being updated anymore. What is Oracle's plan here? And is alienating the developer community just not seen as a problem at Oracle?"
And is alienating the developer community just not seen as a problem at Oracle?
Pretty much exactly this.
"Is MySQL Slowly Turning TheirSQL?"
Postgresql is also a Free Software multi-platform database. It was designed properly (unlike MySQL, Postgresqlwas designed with transactions in mind), has excellent internationalization support (proper 3 and 4 byte UTF, unlike MS SQL-Server with its UCS-2 or blob unicode [unless the very latest version has fixed this]).
Personally I prefer Postgresql to MySQL. While Postgresql looks more 'plain vanilla' I actually find it more straightforward to get easy things done (that is, pgadminIII doesn't look so flashy but I found it is much easier to get connected and get going than mysqlworkbench). YMMV of course, but if you are concerned about corporate control and the future of MySQL taking a look at Postgresql won't harm you - it is a nice(r) place to land if you have to.
Look, by no means FORK! am I a SQL expert, but I still feel FORK! compelled to express my FORK! opinon here. Face it folks, Oracle FORK! is evil. That said, if there is some way FORK! to create a parallel version, a version FORK! not intended to pay for a yacht, I would FORK! be all for it.
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
Oracle has been doing nothing more than gobbling competitors the whole time. Just because the haven't done it overnight doesn't mean that's not what they're doing.
Two of my imaginary friends reproduced once
MariaDB is a drop in replacement for MySQL which was forked a while ago: http://mariadb.org/
in girum imus nocte et consumimur igni
Can someone please explain the sweet spot in which MySQL is a better option than both SQLite and PostgreSQL?
It seems to me that SQLite is a much better option on the very low end, and by the time MySQL would be a better choice, PostgreSQL is an even better choice.
But Berkeley DB is another oracle product??
Larry Ellison believes in one thing: making money.
If publishing test cases doesn't make money for Oracle and they're not required to do it by law (license, etc) then they won't do it.
Stop pretending Oracle cares about anything other than money and you'll have a much more accurate and healthy view of the beast.
oracle is actually an acronym: One Rich Asshole Ceo, Larry Ellison
I put on my robe and wizard hat..
if they want to use open source database. Try Firebird SQL if you want to go light (lighter than mysql in most cases I've seen), or go with the big boys with PostgreSQL.
I'm not sure I share the same fear that Oracle will close-source MySQL. It's OpenSource, which means by definition that with every invisible line in the sand that they cross, more forks will appear.
Unless the version-enhancements that Oracle is adding are so great (um.. they're not) there's very little they can do to co-opt the technology without seeing it slip through their fingers.
------ The best brain training is now totally free : )
Shit, I didn't know that! I saw MariaDB and I didn't think to google to find out who or what that is supposed to be.
I guess I'm spoiled by proper editing and writing where it should have been phrased as such:
"Sergei from MariaDB, a MySQL Fork, speculated on some changes within MySQL 5.5.27."
But never mind, we should all google and research everything posted here because, not only do most folks talk out of their asses, but by missing some detail like that gives some pedant a chance to post something to make himself feel superior for knowing some esoteric and minor piece of information.
What if Oracle is planning to slowly slowly kill off/degrade MySQL? By with-holding the test cases / not putting in effort into new features/development. If opensource contributors cant test properly - they would create a buggy, unstable/inferior product in the future. According to what I know - Oracle is in the database business, MySQL is "competing" database of sorts... Why would oracle want to keep it around? Its not in their interest, right?
WHY is still anyone using mysql, when there is Postgresql?
Forking worked for Libreoffice, I dont see why it couldn't work for MySQL...
Someone should write an article with the headline "Is it reasonable to mention Betteridge's law of headlines every time an article appears whose headline is a question?"
The Tao of math: The numbers you can count are not the real numbers.
in the title of a story.
would prevent a lot of bad written summaries.
Okay, my head exploded... thanks.
I believe it is One Rich Asshole Called Larry Ellison
This would double overnight if MySQL were declared pariah non grata, which is precisely the negotiation taking place in this kind of discussion thread.
Speaking of PNG, you do recall the Unisys GIF debacle? When MySQL dies, may its tombstone read G.I.F.
I maintain a utility named peg that makes it straightforward to install a local copy of PostgreSQL in your home directory. It's aimed at developers who want a local copy they can tinker with as a non-root user. It even includes shell aliases for starting and stopping the server. If you have all the necessary development tools to compile PostgreSQL, you can have a working install in four lines of typing:
I haven't made things like building from one of the stable release versions easy yet, but that's mainly because my users so far use peg to hack on the PostgreSQL code and write/test new features. That would be easy enough to add if I saw any demand for it.
Compilation might see over the line of not being an "out of the box" install. Packaging the software takes far too much build and QA time for the people involved in that to bother for this fairly small niche, people who want home directory, non-root installs.
Note that while I mainly targeted peg at Linux systems, I've tested it and it can work just fine from OS X too. When I last used Homebrew to get all the development tools on the system on that platform, peg Just Worked after that.
I've run two big sites on PostgreSQL now, the first is a content management system for schools across the US with ~3M users with 1K to 3K active at the same time. 300G db on machines with 128G RAM, 34 15kSAS drives, HW RAID controllers and 48 AMD opteron cores. We ran a very aggressive autovacuum schedule, 8 threads with 1ms sleep and max work limit in the 5000 or higher range. We ran several other services on top of pgsql as well, a search engine, stats db, and session servers on it there. Each setup somewhat differently, all 24/7 and quite reliable. The main ~300G cms database was replicated by Slony, since it was setup some time ago when slony was the only real reliable etc replication engine at the time we started. Honestly, it was great performance wise, and reliability wise. Working around Slony for ddl updates is a gigantic pain in the ass tho. Things have gotten better.
The second site, in my current job is also 24/7 and on big hardware but is used as a core db for a storage system consisting of literally thousands of TB sized HDs. The actual db is only a fraction of our storage.
Once you teach your developers to be db centric (start with the data model and work upwards) and the little tricks of postgresql they usually are pretty happy with it. But if you don't have a pg specialist on staff the developers often hate using pgsql because it's NOT what they're used to.
An example is when I was teaching a new guy to use it and he was bitching at how poor insert performance was. He had a 10k file to import and it was about 10% imoprted after 10 minutes. I had him truncate the table and wrap the inserts in begin;commit; and the whole thing imported in about 10 seconds. This was back on pg 7.1 and php3.0 days. Pg has gotten much faster but the ratio of 10k transactions / individual inserts versus batching all 10k together is still quite large.
The fact that you can wrap anything except create / drop database / table or setval/nextval in a transaction and roll it back makes it amazing for development work. You can wrap some huge db updates in a transaction and if there's an error anywhere the whole thing rolls back and you can try again without cleaning up a half-updated db.
It's not perfect, but once you get a handle on performance tuning, autovacuum tuning, and replication it's pretty amazing both performance and reliability wise.
--- It is not the things we do which we regret the most, but the things which we don't do.