Why You Shouldn't Panic About Closed Source MySQL Extensions 171
jfruhlinger writes "Oracle has released proprietary extensions to the open source MySQL database, seeming to reinforce the worst fears of those in the open source community who opposed Oracle's acquisition of MySQL in the first place. But open source observer Brian Proffitt urges you not to panic: This dual source strategy really isn't unusual in the commercial open source world, Oracle has already released a bevy of open source improvements to the database, and anyway the EU extracted a commitment to keep MySQL open for another four years when it approved the Sun-Oracle merger."
lol (Score:4, Funny)
open source observer Brian Proffitt
lol
Re: (Score:2)
Brian, is that you?
Re: (Score:2)
I disagree. This thesis tends to spring from the fact that jokes must have a subject, and if the subject is not human, then it is often associated with, created by, maintained by, nurtured by, protected by, or advocated by some human or group of humans. As a counterexample, I once watched Jimeoin [wikipedia.org] poke some good-natured fun at moths!
I also don't like the instant assumption that making fun is derogatory. Like in this case, nobody is disparaging Proffitt as a person. I
Re: (Score:2)
Those that don't get it, won't find it funny. Whether you laugh at them (those who don't get it) or not, does not have to be related to why the joke in itself is funny or not.
Re: (Score:2)
Re: (Score:2)
Last month, I called out the FSF for generating FUD about Android and Linux using the GPLv2 and trying to get people to put pressure on the Linux devs to "upgrade" to GPLv3, w
Just another 4 years... (Score:3, Insightful)
Re:Just another 4 years... (Score:4, Insightful)
Finally Oracle will either "donate" MySQL back to the community or keep it closed source and everyone will move over to PostgreSQL.
4 years is 2 Server and, depending on your scneario, 1-3 Software Generations away so let's not panic before Oracle has committed to anything.
Re:Just another 4 years... (Score:5, Informative)
Its already forked :)
http://mariadb.org/
Re:Just another 4 years... (Score:4, Informative)
Its already forked :)
http://mariadb.org/ [mariadb.org]
And to http://www.drizzle.org/ [drizzle.org]
Re: (Score:2)
I think mariadb is probably a better choice... from the site:
MariaDB is primarily driven by developers at Monty Program, a company founded by Michael "Monty" Widenius, the original author of MySQL
Re: (Score:2)
It's not written "Drizzle - a database for Azure"
Re: (Score:2)
Re: (Score:2)
Call me when drizzle runs on something besides Linux.
You may be right. I'd been messing with Drizzle for a few weeks (it was the lack of PHPMyAdmin that was stopping me). Today I switched from MySQL to MariaDB in less than an hour and PMA V3.4 works with no trouble.
Lets hope Canonical stick it into Oneiric
Re: (Score:2)
Poisoned chalice devalues forking... (Score:5, Interesting)
And, as with OpenOffice, the community will fork the Database and add a bunch of useful features to it.
Finally Oracle will either "donate" MySQL back to the community or keep it closed source and everyone will move over to PostgreSQL.
I suspect the binary-only extensions from Oracle are part of an attempt to prevent that sort of thing. After all, if a large part of the user base becomes reliant on non-forkable proprietary extensions during the next few years, then forking MySQL when Oracle's commitment to keep it FOSS expires would be largely fruitless. Moreover, relying on these extensions may also make it harder to port one's DB and related applications to Postgres or other alternatives. Furthermore, a MySQL donated to the community would be worthless to those who need the extensions (and nothing prevents Oracle from making those extensions quite expensive later). Conceivably, the extensions could even make it easier to port to a commercial DB offering from Oracle, if they are cunning enough.
For this reason, I'd say Mr. Proffitt is utterly wrong: there is much to worry about in these extensions. Each proprietary binary extension is potentially a poisoned chalice, and should be viewed as such.
Re: (Score:2)
I suspect the binary-only extensions from Oracle are part of an attempt to prevent that sort of thing. After all, if a large part of the user base becomes reliant on non-forkable proprietary extensions during the next few years, then forking MySQL when Oracle's commitment to keep it FOSS expires would be largely fruitless.
That's an obvious possibility but for now its just "extensions": monitoring and and mostly fancy stuff for enterprise dba. Nothing the big majority of mysql base can't live without (if of any real interest at all). Anyway if your software depends critically on this kind of stuff (or any other propietary candy) then you have bigger problems to worry about than Oracle.
Re: (Score:2)
I don't think it is as bad as you think.
The part of the user base that would become dependent on these extensions would be the same users who are already OK with the idea of paying for MySQL. Isn't this a very small fraction of MySQL users? None of the myriad FOSS projects that depend on MySQL would be affected, and few (if any) of those FOSS projects would ever move over to the proprietary version since it would force them to adopt a dual-license model as well (which is darned near impossible to do retroac
No program is an island (Score:2)
The only people who get screwed are the people who signed up for the proprietary version up front.
And, in theory, the only people who get screwed by Microsoft are those who signed up for Windows. But it turns out that if you have a large enough impact on the software ecosystem, you can make life miserable for those around you, even though your neighbors want nothing to do with you.
(It works that way for actual ecosystems, too.)
Re: (Score:2)
I fail to see how the proprietary version of MySQL could ever have a large impact on the software ecosystem. The Open Source version will remain free now and forever (as a fork if necessary); there's an excellent FOSS alternative (PostgreSQL); users who are accustomed to paying for DBs will mostly continue to use MS SQL Server, the full-blown proprietary Oracle database product, or DB2 (possibly with a tiny minority of them jumping ship for the proprietary MySQL); and Oracle simply does not -- and will not,
Re: (Score:2)
The part of the user base that would become dependent on these extensions would be the same users who are already OK with the idea of paying for MySQL.
The way it works is this: some highly specialized commercial product that you DO pay for decides to use/bundle these extensions. Then your systems department, being innately cowardly, gets uber-paranoid about doing anything at all to MySQL that might affect the stability/suportability of these extensions. Suddenly, magically, you essentially have a closed-source system. Sure you have the MySQL source, but you dare not do anything with it.
Re: (Score:3)
OK, but under this scenario you're already locked into a closed-source solution anyway (this hypothetical other commercial product). I don't see how something that solution depends on also being closed-source makes things any worse.
I still fail to see how this move by Oracle represents a serious (or even moderate) threat to FOSS. MySQL has been dual-licensed since day 1. Are people just now waking up to the fact -- 16 years late! -- that whoever owns the MySQL code base is allowed to have their own propriet
Re: (Score:2)
This sounds like a rather week strategy to me. Presumably anything they can make proprietary extensions do will have an OSS alternative before too long. That having been said, anyone who uses these proprietary extensions knows that Oracle can make them expensive if they want to - so if that really is a problem, they just wont be used.
I do however share your concern that Oracle will stop at nothing to milk some money out of MySQL - and unlike OpenOffice.org, MySQL is used everywhere by a very large amount of
obligatory joke about typo (Score:2)
sounds more like a 208 week strategy to me
Re: (Score:2)
From what I read in the trades, the big reason that the EU allowed Oracle to keep MySQL during the acquisition was that Postgres exists.
Re: (Score:2)
I used msql back in the day, the precursor of MySQL. But never for anything serious.
It's good to have competing projects, but I think we need to look to a fork of MySQL rather than something that FOSS developers won't want to get behind.
Thet won't even keep it as closed, it'll be dumped (Score:2)
They have no good financial reason to support 2 seperate database systems. In those 4 years they'll simply migrate all their paying MySQL support customers to the Oracle DB and once thats done the MySQL codebase will no doubt be quietly forgotten about.
Re: (Score:2)
If MySQL is still an important part of the FOSS ecosystem by then, interest will shift to MariaDB (or some other fork), and/or someone else will pick up the FOSS version of the MySQL codebase and maintain it. On the other hand, if the majority of the FOSS community is moving on anyway by that point (e.g. to PostgreSQL), then it won't matter if MySQL is "quietly forgotten about".
Re: (Score:2)
"They have no good financial reason to support 2 seperate database systems. In those 4 years they'll simply migrate all their paying MySQL support customers to the Oracle DB and once thats done the MySQL codebase will no doubt be quietly forgotten about."
I doubt that. MySQL is nowhere near as complete as Oracle, but on the other hand it is considerably simpler to deal with. Oracle will most likely keep MySQL as an "Oracle Light", which doesn't contain all the fancy enterprise features of Oracle, but is quic
Re: (Score:2)
If you aren't interested in how well it performs, Oracle already isn't that hard to set up. It's not that expensive either.
Re: (Score:2)
I just migrated... (Score:5, Interesting)
from MySQL to PG. It was easy. You should do it too.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's a very worthwhile tradeoff, and something that we rely upon for the majority of our complex projects. Knowing that your data is always integral and internally consistent, enforced by rules in the database itself, is an enabler for rapid development of the various interfaces and processes that interact with that data. Need to use a better tool for the job for one aspect of the system? No worries, interface directly with the same database knowing it won't break anything instead of being limited to acc
Re: (Score:2)
I converted using some tools and a short guide, it was simple. I'm also using ORM (ActiveRecord), which brings me to your last statement there: "but I did not think it was feasible for agile development." -- So you are doing so much development IN the DB/DBMS you would even consider something like that? Just what kind of development are you doing? (I'm not attacking you here, I'm honestly interested - I touch the DB and raw SQL as little as possible)
Re: (Score:2)
You can do something like this:
INSERT INTO (col1) foo SELECT * FROM (VALUES (1),(2),(3)) AS newdata(col1) WHERE col1 NOT IN (SELECT col1 FROM foo);
This will create a record for values 1, 2 and 3 if and only if they do not already exist.
Yes, the syntax is considerably longer.
FYI, the normal process for scrubbing during dataload is to create a temporary table holding the data, massage it there, then insert into the real structure.
Re: (Score:2)
e.g.
-- Do following in psql #1
begin;
INSERT INTO (col1) foo SELECT * FROM (VALUES (1),(2),(3)) AS newdata(col1) WHERE col1 NOT IN (SELECT col1 FROM foo);
-- then this in psql #2
begin;
INSERT INTO (col1) foo SELECT * FROM (VALUES (1),(2),(3)) AS newdata(col1) WHERE col1 NOT IN (SELECT col1 FROM foo);
commit;
-- Then go back to psql #1
commit;
The way to do this without having to rollback is to use locks (postgresql allows locks that don't block a
Re: (Score:2)
In addition, the PostgreSQL syntax gets even uglier if you want to insert a new row if it doesn't exist, but update the existing data if it does. For MySQL, it's (parametrized query):
INSERT INTO sometable (field1, field2, field3)
VALUES (?, ?, ?)
ON DUPLICATE KEY UPDATE field1 = ?, field2 = field2 + 1, field3 = SomeComplexFunction(field3,field4)
Re: (Score:2)
Re: (Score:2)
Transactions are good for handling this, but if you already have a large code base using MySQL (and as such are probably not using transactions) then there is a point there about migration not being all that simple.
That said, I don't really get the agile argument.
Re: (Score:2)
Yes you can use savepoints but you now need to write extra code:
1) to handle the savepoint.
2) to correctly distinguish between "retryable" errors and "nonretryable" errors.
3) to retry transactions.
More code to debug, test, document and support.
In contrast, the "lock table, insert if row does not exist, update if it exists" and rollback everything if "stuff happens" seems simpler to do correctly.
You SHOULD still use uniq
Re: (Score:2)
Eh, pgAdmin III is already pretty darned good - the only thing missing is the ability to import/export data sets through the UI to other ODBC data sources (which would rock).
Setting up pgsql is not that hard anymore either - there's enough understanding out there now of how pg_hba.conf works (and why you want to configure stuff like that in a way that can't be touched by the database).
Re: (Score:3)
Because there are a lot of types of data:
Re: (Score:2)
I used Ruby/Rails with Postgres just fine on a very complex project, and I think that's a reasonably agile environment? The database migrations functions in Rails permitted management of state of database in dev, test, staging and production perfectly. It was actually the best setup I've ever had for that. You could see exactly what changes happened on each system, and you could very easily roll your code back to a particular date, roll the database back to the same date, and the structures and system data,
Re: (Score:2)
Re: (Score:2)
Very handy.
Re:I just migrated... (Score:5, Informative)
Migrating from MySQL to PG may be easy, but migrating from MySQL to MariaDB is trivial.
Re: (Score:2)
Excellent heads up. Somebody mod this guy up!
Re: (Score:2)
from MySQL to PG. It was easy. You should do it too.
OK I call forth the combined wisdom of /. to advise me how to do this.
There's gotta be the perfect wiki / website / script / blog / checklist / incantation / whatever for this, right?
I am completely uninterested in migrating databases at the level of "SELECT name, phonenumber FROM t_phonebook WHERE name=vlm;". I think I can handle that by myself, thanks.
I am worried about my replication system, my vast collection of weird indexes and their possible expanding obesity on the NAS, my triggers which are mostly
Re: (Score:2)
I can't (easily) migrate a couple tables at a time from mysql to pg because that would make joins difficult to impossible across the two DBMS, correct?
Funnily enough, postgres does actually support foreign tables with mysql as a backend.
For the few migrations I've done. I've found custom scripts to be the easiest way of getting good results -- you're unlikely to find an automated tool that will look at your VARCHAR(15) column and realise that it should be translated into postgres' native "IP address" data type, or that your column of integers represents a number of seconds so it should really be an "interval" type, or that the "lat" and "lon" columns sho
Re: (Score:2)
Funnily enough, postgres does actually support foreign tables with mysql as a backend.
This could work... then I could gradually move them over into native tables... interesting.... I think I'm developing a plan here...
Re: (Score:2)
Having migrated a few applications from MySQL to Postgres, the truth is, it will be painful, but the result is you will be a LOT more confident in the quality and manageability of your data. Start here [postgresql.org]
PostgreSQL has all the datatypes that MySQL has, and more (see especially the ), and usually with far less limitations. Any character type can be up to 1GB in size if needed, for example.
The biggest sources of pain will likely come from character set handling (some MySQL oddities there) and MySQL's ready accep
because (Score:3, Informative)
because of postgresql?
"open for four years" (Score:5, Insightful)
By "keep MySQL open for another four years", they mean "pay lip service to its life support, then on day 1462 stop even that". Sorry, but unless one of independent forks really takes off, I'm not going to even look at something else than Postgres. For that "bevy of open source improvements", what exactly has been added? Heck, MySQL development has been dormant even during Sun days.
Re: (Score:2)
How long did it take for LibreOffice to take over from OpenOffice?
You'll probably see a perfect replacement fork for MySQL the day it's open source life ends.
Open, but poisoned. (Score:3)
How long did it take for LibreOffice to take over from OpenOffice?
You'll probably see a perfect replacement fork for MySQL the day it's open source life ends.
Perhaps the binary-only extensions from Oracle are part of an attempt to prevent that sort of thing. After all, if a large part of the user base is hooked on non-forkable proprietary extensions during the next few years, then forking MySQL when Oracle's commitment to keep it FOSS expires would be largely fruitless. Moreover, relying on these extensions may also make it harder to port one's DB and related applications to Postgres or other alternatives.
For this reason, I'd say Mr. Proffitt is utterly wrong
Re: (Score:2)
I agree. They're such amazingly obvious traps that you don't even need to be a Mon Calamari flag officer to spot them.
Any organization inclined to pay for MySQL official support or non-free extensions is probably 3/4 of the way to buying the entry level of full Oracle anyway. Whatever you say about MySQL, the probable market for that strategy already doesn't care about free-as-in-libre and will probably just shrug and open the wallet wider when free-as-in-beer goes away. They've already drunk the kool-aid;
Re: (Score:2)
Wouldn't anyone who cared about this issue enough to switch to a fork also avoid binary extensions in the first place? It's not as though they are essential to MySQL - or if they are, their functionality will be replicated in forks soon enough.
Re:"open for four years" (Score:5, Informative)
As if PostgreSQL didn't have it's own ecosystem of commercial-only extensions, too (EnterpriseDB, GreenPlum, just to name a few) ... the big difference here is that in the MySQL ecosystem Oracle is the only one that can do such dual-license stunts while in the PostgreSQL ecosystem anybody can ... (whether that's good or bad is a different story)
For "improvements"/"what's been added":
* lots of multi CPU scalability work (although part of it came from Google/Facebook and other sources where Sun/Oracle 'just' did the integration work)
* MySQL Cluster got a *lot* better in Sun/Oracle days
* the InnoDB plugin improved InnoDB affairs a lot (and this has been Oracles baby even in the Sun days)
* connectors, e.g. PHP/mysqlnd
* more interesting InnoDB improvements (e.g. fulltext indexes, finally) are in the queue, how these are going to be licensed remains to be seen though
It's not that everything is going into the optimal direction with MySQL under Oracle (i'm not working for them anymore for a reason), but saying there has been no development ever since the Sun acquisition is not fair, and i don't see any reason to believe that things will radically change on day 1462 either ...
Re: (Score:2)
Heck, MySQL development has been dormant even during Sun days.
And yet it still seems to be the most popular FOSS database, in spite of this. I'd say this is an indication of a mature product that already meets many users' needs. Even if Oracle orphans it, the situation going forward won't be much (if at all) worse than it already was under Sun. Users who had a problem with the stagnation of MySQL have already moved on (or are in the process of moving on) to something else.
Re:"open for four years" (Score:4, Funny)
The original version had a default Sabbath value of SAT, while the two common forks use either FRI or SUN.
Re: (Score:2)
InnoDB has been added in 2001
Yeah, but it's the DEFAULT now. They probably had to change a whole 10 LOC for that.
Re: (Score:3)
InnoDB has been added in 2001. Replication has been there since forever. You're listing old features of MySQL, not additions done by Oracle.
InnoDB becomes the default storage engine in MySQL 5.5 [mysql.com], a non-trivial change from earlier versions (where MyISAM was the default).
Semi-synchronous replication [mysql.com] is a new feature of replication in MySQL 5.5.
All of the other features mentioned by the AC are also either new or singificantly changed in 5.5.
Why you shouldn't panic? (Score:4, Insightful)
...because if you aren't already running some better DBMS, chances are that you are probably generally unable to panic about any DBMS quality.
Short sighted numbskulls... (Score:2)
Re: (Score:2)
Thats the point - four years is plenty of time to migrate to one of the forks, or off of the MySQL platform altogether.
If it takes a fork more than 4 years to become viable, chances are its never going to become viable - so start supporting the forks now if you absolutely need to remain on the MySQL platform.
This whole rigmarole has amused me from the start - there has never, ever been any guarantees that Sun would have kept MySQL going as a commercially supported project (lots of periods with very low rate
Re: (Score:2)
I always thought the Sun/MySQL arrangement was odd from the start. I've seen full Solaris installations include a "postgres" user and the PostgreSQL database software (which I was glad to see) so Sun was already working along side an open source database. So what w
Enjoy your crumbs. ...oh stop looking at the cake (Score:3)
Free software is about setting minimum levels of respect: the four freedoms.
Many projects go beyond this, by using copyleft, by assisting community participation, by being transparent, etc.
By abandoning this standard, Oracle shows itself as just another free software freerider, not to be trusted and not worthy of community support or good will.
Re: (Score:2)
If only I had mod points...
You express a thought that is lost on so many here: It's the spirit of F/OSS that is being violated here. You nailed it on the head calling Oracle a "freerider," because that is exactly what they are doing, leeching off the work of others for their own gain (whether present or future).
If any post sums up this what Oracle is doing wrong, the parent is it.
Re: (Score:2)
Interesting. Possibly this is a case that demonstrates why BSD/MIT/Apache licenses are superior to GPL? When Oracle acquires a copyright title on a product such as MySQL released under GPL license, they can release closed source mods to the code and convert the community to a locked-in position, whereas no other player can do the same? Everyone but Oracle is "stuck" with a viral license now and so Oracle has a huge advantage in terms of controlling the community with proprietary extensions? Hmm.
Quite the contrary (Score:2)
When a GPL'd project gets bought out, we can end up with one freerider: the purchaser.
With BSD/MIT/Apache licences, we get lumped with unlimited freeriders, no purchase necessary. That's why companies who aren't interested in freedom put so much work into advocating those licences.
Re: (Score:2)
So companies who create/sell GPL aren't trying to benefit from freeriding on GPL? Like SugarCRM, Compiere or "old MySQL?" My experience is that (some) GPL software is released by companies who want to specifically prevent other companies from horning in on their business by re-using their codebase in a competitive way (no one but the original rights holder can release proprietary extensions or resell the product under other licenses). Not to start and GPL/academic license debate - but can you point to some
VirtualBox (Score:4, Interesting)
In VirtualBox v4.0, Oracle released the core as an open-source projet and the proprietary extensions as a plug-in. This proprietary extension is free for home use but commercial users must by a licence. The extension is not 100% necessary but does provides some very useful features, such as being able to connect to the "console" of a headless VM. Cool right?
Well, not really. There is at the moment no way to actually buy such a licence from Oracle, so all the people using VirtualBox v4.0 with this extension in a business are technically out of compliance.
VirtualBox is cool, but they really need some leadership from Oracle.
Re: (Score:2)
In VirtualBox v4.0, Oracle released the core as an open-source projet and the proprietary extensions as a plug-in. This proprietary extension is free for home use but commercial users must by a licence. The extension is not 100% necessary but does provides some very useful features, such as being able to connect to the "console" of a headless VM. Cool right?
Well, not really. There is at the moment no way to actually buy such a licence from Oracle, so all the people using VirtualBox v4.0 with this extension in a business are technically out of compliance.
VirtualBox is cool, but they really need some leadership from Oracle.
The VirtualBox guest extensions were released under the Oracle PUEL [virtualbox.org]. IANAL, but the PUEL itself doesn't seem to say what you think it says.
The actual PUEL [virtualbox.org] seems to center around the following restriction (emphasis mine):
2 Grant of license. (1) Oracle grants you a personal, non-exclusive, non-transferable, limited license without fees to reproduce, install, execute, and use internally the Product a Host Computer for your Personal Use, Educational Use, or Evaluation. “Personal Use” requires that
Re: (Score:2)
Guess it will no longer be in the linux repos (Score:3)
I would think most distros will have policies that will make this a second class DB or drop it entirely. It rules it out of Debian for the next release, openSUSE will drop it to non-oss, gentoo wont like binaries and so on.
Having to go the Oracle website to get it would put off the majority of new non-commercial users or anyone wanting automatic update notification.
Re: (Score:2)
Re: (Score:2)
Does it rule out PostgreSQL from being released with Debian as there are commercial/non-oss extensions to it like EnterpriseDB?
Sure, the non-GPL "Enterprise Edition" will not make it into any distribution, but for the GPL edition licensing would not be the reason for not distributing it any longer (although other reasons may lead to one of the forks becoming the default and Oracles GPL version only an alternative, but this will for sure be not for license reasons alone if/when it happens ...)
Re: (Score:2)
You are right the the core is still good (so I guess GP was alarmist) but the moment new releases are not GPL it will be rejected as foreign by a lot of distros*. Yes there are some that wont care as well i guess.
Forking mySQL is not as likely as OO as there are other alternatives that could be work on instead and will not have the trademark.
openSUSE has switched java versions due to lack to openness.
Re: (Score:2)
Ummm... what? Debian has no problem distributing dual-licensed code, as long as one of the licenses (the one which applies to the version in their repositories) is GPL-compatible. Oracle can't "take back" the GPL-licensed version, so where's the problem for Debian?
Re: (Score:2)
Well it appears there is still at least 4 more years for the base package. I should read the article and the extent of the extensions. But that does not change that some distros might use this as an excuse to drop the oracle product from first class support and the default install.
Unless half the dev team defect there will be no devs able to release patches and security updates let alone new versions so it falls behind and will be less secure. There are no patches to from upstream.
Eternity Calls (Score:2)
a commitment to keep MySQL open for another four years
If four years are rated a long time I wonder about the implications regards short term memory, assuming a universal scaling factor.
CC.
Relax (Score:2)
No problem here. (Score:2)
I don't use MySQL. I use MariaDB. I've looked at Drizzle too. Drizzle is "for the cloud".
For all practical purposes, MariaDB is a binary drop in replacement of the same MySQL version (for example MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 & MariaDB 5.3 are compatible. MySQL 5.5 will be compatible with MariaDB 5.5). http://kb.askmonty.org/en/mariadb-faq [askmonty.org]
Please help fund MariaDB.
FOR THE LOVE OF GOD MAN, POSTGRESQL (Score:2)
After the release of Postgresql 9.x. MySQL has no place, period. MySQL can't even get UTF-8 right. Bug laden transaction support. TS engine? CRAP. Trash OO wannabe. If you do not need the features, then use mongo or couch. I don't know why anyone would use it knowing Postgresql exists.
mysql = java = sun = oracle = trash
Re: (Score:2)
Love it - great post. I'm on this boat too. If your shit is so simple you just want a pile of data in a real fast container, use couch or mongo. If you want SQL b/c you need SQL use Pg. That is all.
not a change (Score:2)
The proprietary extensions were there before, all the way back to mysql ab. You just had to pay for them before.
From the article, they are enterprise monitor and enterprise backup. Backup at least has been reimplemented by percona as xtrabackup.
Re: (Score:2)
Or just stick to current generation MySQL and move to whatever fork will inevitably be created when time is due to upgrade.
Re:Migration Window (Score:4, Informative)
forked: MariaDB is drop-in replacement for MySQL (Score:2)
Mod parent up.
Re: (Score:2)
That doesn't mean another fork won't happen in another years. What features will be added to MySQL that MariaDB doesn't have? Either those features get merged into MariaDB or a fork happens when Oracle wants to shut down MySQL.
Re:Migration Window (Score:4, Informative)
What features will be added to MySQL that MariaDB doesn't have?
Oh, maybe you meant "what killer features that have been already in MariaDB are still not in MySQL"? Yeaaarh, I'm sure you made a mistake. In this case...
Ever wonder why MySQL is still stuck with a single core taking 100% of your CPU, while other cores are idling doing nothing? MariaDB, and it's been more than a year it does, had multi-threading. If you didn't know, it's been written by one of the main authors of MySQL in the first place, that felt he shouldn't stay in this Oracle world. And he's doing very well, by himself... The good thing: MariaDB is ABI compatible. Yes, it's a pure replacement. Remove MySQL, install MariaDB instead, and there you go, you got a multi-threaded MySQL. That alone is enough to convince any decent admin.
Re: (Score:2)
Jesus dude, you need to relax with the post spamming. We get it... there are already forks of mysql.
He's being an advocate of his project. Maybe he is a little enthusiastic about it, but it's part of the job.
Re: (Score:2)
Re: (Score:3)
I've migrated dozens of BIG sites from MySQL to PostgreSQL over the last couple of years, and I can confirm that more RAM was needed in some cases. But since this was on enterprise-class servers running 64-bit OSes (on SPARC and amd64), adding some GB RAM wasn't a big deal. The result was even better performance, both on Solaris and FreeBSD. The applications were never short of CPU cycles though.
So if y
Re: (Score:2)
Wow. This statement qualifies you as a classic incompetent. Are you lying too? :D
It's an AC thread, they're prolly both incompetent liars.
It strikes me that PostgreSQL may well be the bigger load. 3-4 times the hardware? Not under the same conditions.
Re: (Score:2)
Given that MySQL is GPL and that all the users of MySQL you talk about are likely using the GPL version, nothing will change. People will keep using the MySQL version(s) in question.
Should Oracle decide to be a dick about it and close the source or charge money for it, a fork will appear and (as happened with xfree86 when the license was changed in ways people didnt like) a fork will appear. People (and projects) using MySQL will keep using the same MySQL versions they are using or if they need a newer vers
Re: (Score:2)
"In the case of IBM, IBM cannibalized some of it's internal proprietary software sales, but in turn sold more services, a lesson it learned back with the original IBM 5150 BIOS and MS-DOS."
I think this is trying to suggest that IBM intentionally opened the early 80's PC architecture and then sold more as services.
That wasn't true. IBM certainly sued the first cloner (Compaq) early and often, but didn't win---maybe today it would. Then, because of the anti-trust restrictions that IBM was under at the time, i
Re: (Score:2)
MySQL has been a game changer in the database market offering for little or no cost a product which directly competes with Oracle offerings in some market segments.
You're thinking of PostgreSQL. MySQL has never been competition for anything Oracle has been considered for. They are two completely different classes of software. Anyone who was considering Oracle and MySQL really needed nothing more than MySQL and should have never been considering Oracle. By acting like the two are in some sort of competition for the same customers, you pretty much show that you have no fucking clue what Oracle is for, how its used, or how it should be used. In short, by comparing M