Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why You Shouldn't Panic About Closed Source MySQL Extensions

Soulskill posted more than 3 years ago | from the time-will-tell dept.

Databases 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."

cancel ×

171 comments

Sorry! There are no comments related to the filter you selected.

lol (4, Funny)

Alex Belits (437) | more than 3 years ago | (#37453750)

open source observer Brian Proffitt

lol

Re:lol (0)

Anonymous Coward | more than 3 years ago | (#37454684)

open source observer Brian Proffitt

lol

Really? Really? What are you like 10 years old? I would expect more from someone who has been here for a while. Maybe you're just taking your anger out on others because people keep making fun of your fro. I've met Brian Proffitt and read some of his columns. He is not a joke, nor should he be portrayed as one.

Re:lol (0)

MrNaz (730548) | more than 3 years ago | (#37454730)

C'mon man. Laugh a bit. You'll live longer.

Re:lol (-1)

Anonymous Coward | more than 3 years ago | (#37454776)

There is a difference between a joke and making fun of someone. Which is what the OP was doing. I would think geeks would be sensitive to that.

Just another 4 years... (3, Insightful)

unixisc (2429386) | more than 3 years ago | (#37453758)

... after which Oracle will be @ liberty to digest MySQL as closed, and the EU will have nothing to say about it.

Re:Just another 4 years... (4, Insightful)

d4fseeker (1896770) | more than 3 years ago | (#37453766)

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.
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... (5, Informative)

Anonymous Coward | more than 3 years ago | (#37453784)

Its already forked :)
http://mariadb.org/

Re:Just another 4 years... (3, Informative)

Dark$ide (732508) | more than 3 years ago | (#37454340)

Its already forked :) http://mariadb.org/ [mariadb.org]

And to http://www.drizzle.org/ [drizzle.org]

Re:Just another 4 years... (0)

Anonymous Coward | more than 3 years ago | (#37454732)

>>
>>Its already forked :) http://mariadb.org/ [mariadb.org]
>>
>
>And to http://www.drizzle.org/ [drizzle.org]
>

Call me when drizzle runs on something besides Linux.

Re:Just another 4 years... (1)

dokc (1562391) | more than 3 years ago | (#37455116)

On the homepage is clearly written: "Drizzle - a database for the cloud"
It's not written "Drizzle - a database for Azure"

Poisoned chalice devalues forking... (5, Interesting)

AliasMarlowe (1042386) | more than 3 years ago | (#37454050)

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:Poisoned chalice devalues forking... (2)

znrt (2424692) | more than 3 years ago | (#37454238)

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:Poisoned chalice devalues forking... (1)

Just Brew It! (636086) | more than 3 years ago | (#37454280)

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 retroactively for anything that has community involvement in the development process).

When Oracle eventually pulls the plug on development of the FOSS version and jacks up the price of the proprietary version, the FOSS community can indeed fork (or jump ship to an existing fork like MariaDB assuming it is viable), since by definition they're not dependent on the proprietary extensions in the first place.

The only people who get screwed are the people who signed up for the proprietary version up front.

No program is an island (1)

DragonHawk (21256) | more than 3 years ago | (#37454546)

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:Poisoned chalice devalues forking... (1)

mfh (56) | more than 3 years ago | (#37454282)

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.

Whenever someone is pacifying me with poison, I often take careful note as to their disposition. If they are begging me to drink, and playing down the ill effects, then I know where their loyalties lie.

Re:Poisoned chalice devalues forking... (1)

tehniobium (1042240) | more than 3 years ago | (#37454388)

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 people. I guess pretty much the only good thing is that PostgresSQL is a solid alternative.

Re:Just another 4 years... (1)

Tsingi (870990) | more than 3 years ago | (#37454528)

PostgreSQL rocks, and it is the base of PostGIS. It competes on par with the major commercial databases.

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 (1)

Viol8 (599362) | more than 3 years ago | (#37453914)

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:Thet won't even keep it as closed, it'll be dum (1)

Just Brew It! (636086) | more than 3 years ago | (#37454306)

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:Thet won't even keep it as closed, it'll be dum (1)

GauteL (29207) | more than 3 years ago | (#37454564)

"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 quick and easy to set up without donating your second kidney and practising voodoo, sacrificing live chickens and all.

I doubt Oracle will think they have a good financial reason to support an open source database system, however, so MySQL will not remain open source beyond those 4 years (and several of those must have passed by now?).

Re:Thet won't even keep it as closed, it'll be dum (1)

jedidiah (1196) | more than 3 years ago | (#37454862)

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:Just another 4 years... (1)

GPLHost-Thomas (1330431) | more than 3 years ago | (#37453964)

Why do you care since we have MariaDB, which is already better (multi-threaded), and ABI compatible?

Migration Window (1)

Anonymous Coward | more than 3 years ago | (#37453764)

and anyway the EU extracted a commitment to keep MySQL open for another four years when it approved the Sun-Oracle merger.

In other words, in 4 years all bets are off so you better start migrating to Postgres, a community fork or something else now.

Re:Migration Window (1)

mwvdlee (775178) | more than 3 years ago | (#37453850)

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 (3, Informative)

GPLHost-Thomas (1330431) | more than 3 years ago | (#37453972)

Wake up. MariaDB has been around for some time already!

forked: MariaDB is drop-in replacement for MySQL (1)

KWTm (808824) | more than 3 years ago | (#37454096)

Mod parent up.

Re:Migration Window (0)

Anonymous Coward | more than 3 years ago | (#37454286)

Jesus dude, you need to relax with the post spamming. We get it... there are already forks of mysql.

Re:Migration Window (1)

Tsingi (870990) | more than 3 years ago | (#37454552)

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:Migration Window (1)

Talderas (1212466) | more than 3 years ago | (#37454320)

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 (0)

Anonymous Coward | more than 3 years ago | (#37454048)

No , thanks. No PostgreSQL for me.

If the purpose is to have a light, simple SQL database, MySQL will do it (enough for my life time). MySQL is being used on millions of web applications and I ensure you that not even 10% of them are interested to move to Oracle or even PostgreSQL.

I manage 2 million members and 200 million page views a month (up to 8000 concurrent along with apache) on a single 2xQuadcore server. Last time we checked we would need at least 3-4 times the hardware if we wanted to move to PostgreSQL.

Re:Migration Window (1)

Anonymous Coward | more than 3 years ago | (#37454066)

Last time we checked we would need at least 3-4 times the hardware if we wanted to move to PostgreSQL.

You're either lying or you're incompetent.

Re:Migration Window (0)

Anonymous Coward | more than 3 years ago | (#37454130)

If he's using MySQL then I suspect it's the latter.

Re:Migration Window (1)

znrt (2424692) | more than 3 years ago | (#37454368)

If he's using MySQL then I suspect it's the latter.

Wow. This statement qualifies you as a classic incompetent. Are you lying too? :D

Re:Migration Window (1)

Tsingi (870990) | more than 3 years ago | (#37454576)

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.

I just migrated... (4, Interesting)

Kagetsuki (1620613) | more than 3 years ago | (#37453776)

from MySQL to PG. It was easy. You should do it too.

Re:I just migrated... (1)

Errol backfiring (1280012) | more than 3 years ago | (#37453828)

Ah. And how do you convert the duplicate key / ignore inserts? I looked at postgress, but I did not think it was feasible for agile development.

Re:I just migrated... (1)

Anonymous Coward | more than 3 years ago | (#37453836)

Can you elaborate?
Why would you want to ignore inserts? That just sounds like sloppy programming.

I use postgresql for agile development and find it much nicer than mysql (one random example: ddl changes don't force a commit and can be rolled back - useful in intergration tests)

Re:I just migrated... (1)

Ja'Achan (827610) | more than 3 years ago | (#37453874)

For one, INSERT ... IGNORE is atomic, saves you locking over your "does it exist yet?" and your "no? Then add it" queries.

Re:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37453880)

atomicity is what transactions are for.

Re:I just migrated... (1)

Anonymous Coward | more than 3 years ago | (#37453902)

So why not use unique keys and handle the fallout (i.e. failed insert) afterwards?

Re:I just migrated... (1)

Anonymous Coward | more than 3 years ago | (#37454262)

This is quite possibly one of the stupidest technical statements I have read on Slashdot in quite some time. Handle the failed insert... good lord. *slaps people*

Another individual who responded got it right: transactions (read: START TRANSACTIO / COMMIT / ROLLBACK) can help here. But if you're using MySQL these are only available if you use InnoDB, which is a fucking nightmare in itself. Does this mean switch to PG like the thread implies? Absolutely not. Until PG's administrative and userland utilities improve, users will continue to use MySQL. Not to mention, open-source SQL engines suffer from the same problem most of the PC industry does: whoever comes first is usually who will win the battle (read: MySQL came first, PG loses no matter how technically superior it is).

Anyway, use transactions. Cleaning up after insert/delete/update/yourmom statements, manually, is *not* an easy task. It might sound easy, but it's really not.

Re:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37454452)

Do you want to rewrite that application for him/her?

Re:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37454126)

Sanitize your Data.
Copy your raw data to a temporary table, join with the final table to get those rows, that are no douplicates and insert them in the final table.

Re:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37454192)

Transactions + stored proc ... Many ways to do this. It's a special case of invalid data, therefore there's no dedicated function for it.

http://www.tek-tips.com/viewthread.cfm?qid=1493070&page=2

Re:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37454206)

Use INSERT ... SELECT ... WHERE NOT EXISTS ...

(Defeat idiot filter: Filter error: Don't use so many caps. It's like YELLING.)

Re:I just migrated... (1)

Anrego (830717) | more than 3 years ago | (#37454634)

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:I just migrated... (2)

Errol backfiring (1280012) | more than 3 years ago | (#37453932)

Because there are a lot of types of data:

Live data
Should off course not be in an upgrade SQL script
Settings
Insert-only, should not be updated when present. This is where you would use INSERT IGNORE (or INSERT .. ON DUPLICATE KEY UPDATE somedummyfield=somedummyfield if you dislike INSERT IGNORE)
System data
For instance, Object-Relational-Mapping data. Should be set to the new value. INSERT .. ON DUPLICATE KEY is perfect for this. What's more, with MySQL's multirow inserts, you can make statements that are legible even if you set more than one field. Standard SQL's MERGE command is the least legible command I ever saw, and as far as I know Postgress does not even support MERGE.

In agile programming, both structural and content changes are often necessary. These must be done on both local development databases, test databases and live databases. So you would want the SQL script in your source code control system and be able to run non-interactively. For an example, see Evolving A Database With MySQL [howtoforge.com] .

Re:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37453966)

Right.

We handle all of this above the ORM layer, so don't need such features in the db.

Whether using mysql or postgresql, the amount of hand-written SQL is actually very small indeed.

Re:I just migrated... (1)

znrt (2424692) | more than 3 years ago | (#37454296)

So you would want the SQL script in your source code control system and be able to run non-interactively. For an example, see Evolving A Database With MySQL [howtoforge.com] .

Ditto: you are tying yourself (unnecesarily) to specific implementations (that incidentally are going to be propietary soon, as it seems). That's not agile programming, it's shortsightness, or agile getting-in-trouble. Don't be lazy, write your data morphing scripts in whatever language you are using and ... fcuk Oracle :-)

This is another compelling reason for PG (0)

Anonymous Coward | more than 3 years ago | (#37455058)

As you pointed out, both structural *and* content changes are often necessary in agile programming. PostgreSQL offers a great opportunity to ensure that your database remains consistent during version migration/evolution: you can combine your DDL and live data changes in a single transaction that can cleanly roll back.

Let's say you are changing the schema of tables foo & qux and want to synthesize a new child table, bar, from some column data from foo + qux. After that you naturally want to inject FK's in foo & qux to link to the newly-created bar records. Of course, at this point you want to drop the now-redundant columns from foo & qux. No sweat: do it all in a single transaction in PG. It either goes or it doesn't. It will enforce all the triggers as well, so you are guaranteed that your new, NOT NULL FK columns are populated in all of foo & qux's records.

I love this feature, because I would rather have a combined update blow up than to leave my app in a "half migrated", metastable state between the old and new form of the schema, as might happen if I had to do DDL first and then live data migration separately. Besides, if my schema migration fails transaction validation on "live data", then that means I missed a corner case in testing and I should stop to review what I overlooked to avoid stomping production data.

Yes, you want these transactions to run non-interactively. With proper pre-flight testing you can get a very high confidence that your database evolution will "just work". However, it's nice knowing that if it *does* asplode the database won't have crapped itself and will merely roll back your pending DDL & live data changes.

Re:I just migrated... (1)

shish (588640) | more than 3 years ago | (#37453906)

I'm using postgres in what I'd consider an agile way -- I guess if you were typing SQL by hand then its strictness might hold you back (it also ensures that your data is valid, which I consider a worthwhile tradeoff), but we've been using an ORM to handle those sorts of details for us.

Re:I just migrated... (1)

myurr (468709) | more than 3 years ago | (#37454144)

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 accessing your system via a single ORM (or maintaining the configuration of two or more).

INSERT IGNORE etc. are nice to haves but hardly a deal breaker or a hinderance to rapid development when the other database features are taken into account such as performance under concurrent load or the far more intelligent query planner - both features that enable you to stop having to worry about these things in your code.

Re:I just migrated... (1)

Kagetsuki (1620613) | more than 3 years ago | (#37454178)

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:I just migrated... (1)

rtaylor (70602) | more than 3 years ago | (#37454430)

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:I just migrated... (0)

Anonymous Coward | more than 3 years ago | (#37454632)

Ah. And how do you convert the duplicate key / ignore inserts? I looked at postgress, but I did not think it was feasible for agile development.

Thanks, this is the best argument against "agile development" I have ever heard.

Re:I just migrated... (4, Informative)

buchner.johannes (1139593) | more than 3 years ago | (#37454140)

Migrating from MySQL to PG may be easy, but migrating from MySQL to MariaDB is trivial.

Re:I just migrated... (1)

Kagetsuki (1620613) | more than 3 years ago | (#37454188)

Excellent heads up. Somebody mod this guy up!

Re:I just migrated... (1)

vlm (69642) | more than 3 years ago | (#37454308)

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 used as a transparent logging system, and frankly most worried that little gotchas that probably exist that I couldn't possibly know about in advance. Maybe VARCHAR doesn't exist or it explodes on PG, maybe my favorite hashing functions don't exist inside PG, I donno that is the whole point.

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? And I have a true relational database system, required for consistency (the codd normal forms and all that)

I am not worried at the point that I must hire a consultant and stay at work all weekend rolling it. But I am worried enough to "buy a book" or study a website for awhile, and maybe think about rolling to PG.

Obviously I'm not the first or only to consider this.

Re:I just migrated... (1)

outsider007 (115534) | more than 3 years ago | (#37454316)

And wait for Oracle to buy them too? No thanks.

because (3, Informative)

roman_mir (125474) | more than 3 years ago | (#37453786)

because of postgresql?

"open for four years" (5, Insightful)

KiloByte (825081) | more than 3 years ago | (#37453792)

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:"open for four years" (1)

Anonymous Coward | more than 3 years ago | (#37453854)

"what exactly has been added"
JUST
high-impact enhancements to improve the performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity and crash recovery by default.
MySQL 5.5 also provides a number of additional enhancements including:
      - Significantly improved performance on Windows, with various Windows
          specific features and improvements
      - Higher availability, with new semi-synchronous replication and
          Replication Heart Beat
      - Improved usability, with Improved index and table partitioning,
          SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
          PERFORMANCE_SCHEMA
For a more complete look at what's new in MySQL 5.5, please see the
following resources: MySQL 5.5 is GA, Interview with Tomas Ulin:
    http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html
Documentation:
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html
Whitepaper: What's New in MySQL 5.5:
  http://dev.mysql.com/why-mysql/white-papers/mysql-wp-whatsnew-mysql-55.php

Just....

Re:"open for four years" (0)

KiloByte (825081) | more than 3 years ago | (#37454200)

InnoDB has been added in 2001. Replication has been there since forever. You're listing old features of MySQL, not additions done by Oracle.

Re:"open for four years" (1)

geminidomino (614729) | more than 3 years ago | (#37454824)

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:"open for four years" (2)

Zontar The Mindless (9002) | more than 3 years ago | (#37454982)

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.

Re:"open for four years" (1)

mwvdlee (775178) | more than 3 years ago | (#37453860)

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. (2)

AliasMarlowe (1042386) | more than 3 years ago | (#37453998)

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: there is much to worry about. Each proprietary binary extension is potentially a poisoned chalice, and should be viewed as such.

Re:"open for four years" (0)

Anonymous Coward | more than 3 years ago | (#37454014)

Chill out...who's trying to convince you from not using PostgreSQL? You're free to use that if you aren't interested in "even look"ing at alternatives such as the already-active, MySQL-forked, Open-vs-LibreOffice-akin MariaDB.

Re:"open for four years" (1)

Anonymous Coward | more than 3 years ago | (#37454076)

Heck, MySQL development has been dormant even during Sun days.

Just as well. Just because Jesus open sourced Judaism, doesn't mean that open source developers are Sabbath-exempt.

Re:"open for four years" (3, Funny)

JustOK (667959) | more than 3 years ago | (#37454110)

The original version had a default Sabbath value of SAT, while the two common forks use either FRI or SUN.

Re:"open for four years" (5, Informative)

hholzgra (6914) | more than 3 years ago | (#37454080)

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:"open for four years" (1)

Just Brew It! (636086) | more than 3 years ago | (#37454336)

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" (0)

Anonymous Coward | more than 3 years ago | (#37454434)

unless one of independent forks really takes off

MariaDB seems highly likely to take over where MySQL has left off, given that Monty himself is involved. For those who want some commercial support, there's always Percona, who also have their own fork. It seems more likely that Maria & Percona will converge rather than diverge, so you're not in much danger if you chose one over the other right now.

Why you shouldn't panic? (3, Insightful)

eexaa (1252378) | more than 3 years ago | (#37453866)

...because if you aren't already running some better DBMS, chances are that you are probably generally unable to panic about any DBMS quality.

POSTGRESQL (1)

Anonymous Coward | more than 3 years ago | (#37453868)

As I'm writing a new software application, I've chosen PostgreSQL for these reasons:

1. Very good quality of PostgreSQL and very good features
2. License (BSD)
3. Officially supported pre-compiler for embedded SQL in C/C++. Ironically there was such a pre-compiler for MySQL, but after the buyout it has been dropped from the official MySQL website (now Oracle) , however you can still find it elsewhere.
4. I don't want oracle men in suits asking me money

wolf in sheep's clothes (0)

Anonymous Coward | more than 3 years ago | (#37453920)

At the moment they are 'extensions'. In short order, core features will be added through extensions, and MySQL-GPL will just be a vessel for proprietary software.

Short sighted numbskulls... (1)

Stumbles (602007) | more than 3 years ago | (#37453956)

What happens after that fourth year? Pull your head out of the sand.

Re:Short sighted numbskulls... (0)

Anonymous Coward | more than 3 years ago | (#37454004)

The EU at least gave 4 ye3ars. The US did not even ask for that.

Re:Short sighted numbskulls... (1)

Richard_at_work (517087) | more than 3 years ago | (#37454610)

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 rates of activity while Sun was in charge), so why should Oracle really be burdened with offering more of a guarantee than Sun (or even the original MySQL company) ever was?

MySQL is open source, and the whole point of open source was to protect against being left out in the cold when the product is withdrawn - and yet here we are seeing that entire premise failing badly.

The problem is developers (1)

Anonymous Coward | more than 3 years ago | (#37453980)

If any 'fork' is to be taken seriously, it has to remain binary compatible (eg, can't simply dump and re-import), there are too many programs that rely on MySQL and MySQL only (ex, wordpress, which is used heavily) and have no means of using an alternative DB since they weren't written with any DBAL. Or there are cases like Xaraya and phpBB3 where the DBAL itself only knows specific versions of MySQL and doesn't functionally work with other DB's even if the core does since extensions may not be written using the DBAL.

As for switching to PostgreSQL, same as above, the products in question and many others, assume that the underlying DB is MySQL3 or MySQL4.

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. Trying to hold back innovation using copyrights and licences results in the ability to sell services being lost. Oracle is being rather dickish about Java, much like Sun was about Java, and I think in the end this doesn't bode well as it pretty much killed Java being adopted and the world has moved to JIT-LLVM types of development instead.

Unlike Sun Office, OpenOffice, LibreOffice, you can't simply fork when you don't like the company that buys it. Yes there will be attempts at forks, but they won't replace the previous popular flavor of the year unless that new version offers something attractive to switch for. As we all know, people don't flock to Gimp and Inkscape over Photoshop and Illustrator just because it's free and not owned by dickish companies. People use these products out of necessity.

So in the case of MySQL, there is a large installed base, just like the Apache HTTPD server itself, this is the norm, even if the underlying OS is MacOS, or FreeBSD. Low-end VPS systems only support Linux CentOS+Apache+MySQL+PHP and nothing else. You don't get to install anything that CPanel doesn't have unless you want to install everything manually by yourself.

Nobody cares about licenses when they can just tick a "install database" box.

Re:The problem is developers (1)

jonwil (467024) | more than 3 years ago | (#37455086)

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 version, switch to the fork.
VPSs and hosting providers using MySQL will keep using the same version they are now or switch to the fork with the "set up database" option being pointed at the new version.

I seriously doubt any fork is going to want to change the binary format or query language for MySQL in a way that breaks things for existing MySQL users (not if they want the fork to be relavent anyway)

Even LibreOffice hasn't changed things in ways that break binary compatibility as far as I am aware.

Enjoy your crumbs. ...oh stop looking at the cake (2)

ciaran_o_riordan (662132) | more than 3 years ago | (#37453986)

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:Enjoy your crumbs. ...oh stop looking at the ca (1)

pongo000 (97357) | more than 3 years ago | (#37454718)

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.

VirtualBox (3, Interesting)

AdamInParadise (257888) | more than 3 years ago | (#37453992)

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:VirtualBox (1)

Jahava (946858) | more than 3 years ago | (#37454234)

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 you use the Product on the same Host Computer where you installed it yourself and that no more than one client connect to that Host Computer at a time for the purpose of displaying Guest Computers remotely. “Educational use” is any use in an academic institution (schools, colleges and universities, by teachers and students). “Evaluation” means testing the Product for a reasonable period (that is, normally for a few weeks); after expiry of that term, you are no longer permitted to evaluate the Product.

In other words, it looks like the word "personal" is not a restriction on non-commercial versus commercial, but rather a limitation (of one) to the number of simultaneous users who may display guests remotely. The rest of the license doesn't seem to be changing this, so it seems to me that this is an accurate representation of their intentions. (On the side, it is one of the best-written comprehensible licenses I've seen in a while, so props Sun/Oracle). What they seem to want is for people to use this individually (commercially or non-commercially) and not try and use VirtualBox to set up an enterprise virtualization solution. This is consistent with the software itself, whose interfaces and features are very-much geared towards a single-user multiple-system scenario.

Now, historically, prior to Oracle's acquisition of Sun, VirtualBox's still released closed extensions; this was just accomplished by releasing two versions of VirtualBox side-by-side [wikipedia.org] . One of them was a limited open-source bundle, while the other was a full bundle released by Sun under a similar PUEL. The main difference is that the previous model released two separate versions, while the current model releases a single open-source core version and a set of closed extensions that augment the open-source version's functionality to that of the previously-separate closed-source PUEL bundle. In other words, VirtualBox under Sun seems to be operating roughly equivalently to VirtualBox under Oracle.

VirtualBox is an excellent piece of virtualization software ... highly-recommended to those who are using VMWare Player to run/test multiple systems in a development context. I, personally, feel it beats VMWare's pants off in that specific scenario.

Re:VirtualBox (1)

Just Brew It! (636086) | more than 3 years ago | (#37454366)

The OSE edition of VirtualBox includes a VNC server (as opposed to the RDP server included in the proprietary extension) that provides similar headless console functionality. The VNC feature appears to be disabled in the binaries they distribute, but is available as a compile-time configuration option if you build from source, or (I believe) enabled by default if you install from your distro's repository.

Guess it will no longer be in the linux repos (2)

nzac (1822298) | more than 3 years ago | (#37454016)

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:Guess it will no longer be in the linux repos (1)

Errol backfiring (1280012) | more than 3 years ago | (#37454056)

I think just the enterprise features won't be available. So developers won't use them if they can avoid them. What's more, you would have to have an "enterprise" licence for each developer and test machine. Ouch!

Re:Guess it will no longer be in the linux repos (0)

Anonymous Coward | more than 3 years ago | (#37454554)

An enterprise license for each developer? I think you need to read the license before sprouting bullshit.

The plugins are rather dull anyway, authentication using pam etc.
Rather pointless when you consider 99% of MySQL installations have 2 users: root and "the web server".

Re:Guess it will no longer be in the linux repos (2)

hholzgra (6914) | more than 3 years ago | (#37454100)

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:Guess it will no longer be in the linux repos (1)

nzac (1822298) | more than 3 years ago | (#37454288)

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.

Eternity Calls (1)

foobsr (693224) | more than 3 years ago | (#37454084)

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.

EU (0)

Anonymous Coward | more than 3 years ago | (#37454138)

... EU extracted a commitment to keep MySQL open for another four years when it approved the Sun-Oracle merger.

Communist socialist maoists! How dare they!

One more reason to stick to PostgreSQL (1)

Anonymous Coward | more than 3 years ago | (#37454158)

It's community owned.

Does non-open = non-free? (0)

Anonymous Coward | more than 3 years ago | (#37454298)

When it's not open in four years will that have anything to do with a full working version still being free?

Relax (1)

ThatsNotPudding (1045640) | more than 3 years ago | (#37454370)

You can trust Larry Ellison without question.

mysql... (0)

Anonymous Coward | more than 3 years ago | (#37454454)

has and always will will suck compared to alternatives such as postgres. I see no logical reason to use it.

Why You Should worry. (1)

Stonefish (210962) | more than 3 years ago | (#37454876)

Oracle which now owns MySQL is a database vendor.
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.
Improving MySQL scalability makes it compete in more market segments that before. This doesn't make sense
Improving MySQL authentication options makes it compete directly with the Enterprise Edition of the Oracle DB
Where is the benefit to Oracle in maintaining 2 competing database products? There is none.
Unless you are willing to play the long game.
Step one Gut hook the client, Oracle purchased MySQL for the customers, adopting an embrace and extend model binds customers to the product increasing cost associated with jumping ship. (Go on Oracle give those cigarettes out for free)
Step 2 Develop an migration path between MySQL and Oracle, hey guys there's no pressure (Maybe a MySQL front end on Oracle?)
Step 3 Migrate more components to a closed source model, ones that you really need
Step 4 Force users onto the Oracle back end
Step 5 Roll in cash and laugh

You fags (-1)

Anonymous Coward | more than 3 years ago | (#37454986)

It's not like you slashfags read the code, anyway.

Bullocks (-1)

Anonymous Coward | more than 3 years ago | (#37455068)

Bullshit

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?