Oracle Makes More Moves To Kill Open Source MySQL
Very sad situation. http://techcrunch.com/2012/08/18/oracle-makes-more-moves-to-kill-open-source... Rasika
On 23/08/12 09:47, Rasika Amarasiri wrote:
Very sad situation.
Indeed, though not particularly surprising given their past history. It also highlights the potential dangers around working on software projects that require copyright assignment, in that unless you trust the people you are giving control of your code to never be acquired by others you are at risk of having it relicensed without your approval (as it becomes their code, not yours). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Quoting Chris Samuel (chris@csamuel.org):
It also highlights the potential dangers around working on software projects that require copyright assignment, in that unless you trust the people you are giving control of your code to never be acquired by others you are at risk of having it relicensed without your approval (as it becomes their code, not yours).
And in conclusion: MariaDB, Percona Server, OurDelta, and Drizzle beckon. -- Cheers, "Overheard a hipster say 'Quinoa is kind of 2011', Rick Moen so I lit his beard on fire." -- Kelly Oxford rick@linuxmafia.com McQ! (4x80)
Chris Samuel wrote:
It also highlights the potential dangers around working on software projects that require copyright assignment, in that unless you trust the people you are giving control of your code to never be acquired by others you are at risk of having it relicensed without your approval (as it becomes their code, not yours).
The counterargument is that if you don't do copyright assignment, and five years into a project you suddenly discover that an OpenSSL exception is a really good idea, you are completely fucked, because maybe one in twenty of your contributors have dropped off the grid in the meantime. Also, when you assign copyrights to the FSF (e.g. for Emacs contributions), one of the things you get back is what looks like a legal promise to "keep on being free forever". IANAL so I don't know if that holds any weight, but it seems like a reasonable response to your issue. And as Rick points out, you can always fork the last free version. The other downside of copyright assignment is that it's tedious. :-)
Stewart Smith <stewart@flamingspork.com> wrote:
It kills contributions. Anybody who works for a company of any size will have to talk to a lawyer. This is about as fun as it sounds.
And it's the same for non-profit organizations, universities of any size, or governments. One of the advantages claimed by LibreOffice when it was launched was that contributions could be made without requiring copyright assignment. Reportedly, the number of contributions from the community has grown steadily. Of course, there are other bureaucratic requirements that LibreOffice eliminated by comparison with openoffice.org as well, according to what I have read, thus it isn't entirely a question of copyright policy.
Quoting Trent W. Buck (trentbuck@gmail.com):
The counterargument is that if you don't do copyright assignment, and five years into a project you suddenly discover that an OpenSSL exception is a really good idea, you are completely fucked, because maybe one in twenty of your contributors have dropped off the grid in the meantime.
This is based on a misconception, almost universally held among the open source community, that signoff is required for any licensing change(to a collective work for which you're project lead), even one that causes no legally provable harm to the contributors, and that failure to get that signoff creates copyright infringement _even_ in those cases. http://www.catb.org/esr/Licensing-HOWTO.html#id2852366 Adding an OpenSSL exception, e.g., the one Phil Hazel added circa 2001 to the Exim MTA's GPL licensing, strikes me as the very model of such tort-free change. (I don't believe Phil requires copyright assignment.)
On Thu, Aug 23, 2012 at 10:47:57AM +1000, Trent W. Buck wrote:
Chris Samuel wrote:
It also highlights the potential dangers around working on software projects that require copyright assignment, in that unless you trust the people you are giving control of your code to never be acquired by others you are at risk of having it relicensed without your approval (as it becomes their code, not yours).
The counterargument is that if you don't do copyright assignment, and five years into a project you suddenly discover that an OpenSSL exception is a really good idea, you are completely fucked, because maybe one in twenty of your contributors have dropped off the grid in the meantime.
Also, when you assign copyrights to the FSF (e.g. for Emacs contributions), one of the things you get back is what looks like a legal promise to "keep on being free forever". IANAL so I don't know if that holds any weight, but it seems like a reasonable response to your issue.
IANAL either but it would seem to be a valid contract/agreement because both parties are getting something valuable out of the deal. FSF is getting the code and the contributor gets ongoing maintainence/inclusion of the code and the promise that it will always be free. that passes one of the most important hurdles for whether a contract is valid or not. i'd trust FSF with a copyright assignment. can't think of many (any?) others that I would. even if there was an intention to live up to the deal, anything can happen to "assets" like code if a company or organisation goes bankrupt or gets bought out. or if the programmer you've assigned your copyright to has changes in their ethics, dedication to free software ideals, or simply their financial situation changes for the worse.
The other downside of copyright assignment is that it's tedious. :-)
yes. craig -- craig sanders <cas@taz.net.au> BOFH excuse #72: Satan did it
On Thu, 23 Aug 2012, Craig Sanders <cas@taz.net.au> wrote:
IANAL either but it would seem to be a valid contract/agreement because both parties are getting something valuable out of the deal. FSF is getting the code and the contributor gets ongoing maintainence/inclusion of the code and the promise that it will always be free. that passes one of the most important hurdles for whether a contract is valid or not.
The contributor doesn't get ongoing maintainence. There is no guarantee that FSF ownership will make developers want to contribute to a project. The main thing that would make me want to give code to the FSF is the fact that they will enforce the GPL. I don't want to be involved in legal cases. If someone flagrantly violated the GPL on one of my projects I'd seriously consider offering the code to the FSF if they would take legal action. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Hi Russell
The main thing that would make me want to give code to the FSF is the fact that they will enforce the GPL. I don't want to be involved in legal cases. If someone flagrantly violated the GPL on one of my projects I'd seriously consider offering the code to the FSF if they would take legal action.
I understand the line of thinking, but it does sound like a plan to take out insurance when the house is already on fire. If the above is the desired intent anyway and you like FSF for the purpose, do the assignment now. Cheers, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://Upstarta.biz Personal blog at http://lentz.com.au/blog/
On Thu, Aug 23, 2012 at 01:50:08PM +1000, Russell Coker wrote:
On Thu, 23 Aug 2012, Craig Sanders <cas@taz.net.au> wrote:
IANAL either but it would seem to be a valid contract/agreement because both parties are getting something valuable out of the deal. FSF is getting the code and the contributor gets ongoing maintainence/inclusion of the code and the promise that it will always be free. that passes one of the most important hurdles for whether a contract is valid or not.
The contributor doesn't get ongoing maintainence. There is no guarantee that FSF ownership will make developers want to contribute to a project.
that's why i wrote "maintainence/inclusion". it's an inclusive or.
The main thing that would make me want to give code to the FSF is the fact that they will enforce the GPL. I don't want to be involved in legal cases. If someone flagrantly violated the GPL on one of my projects I'd seriously consider offering the code to the FSF if they would take legal action.
yep, that's another valuable thing that the code contributor gets in exchange for their code. craig -- craig sanders <cas@taz.net.au> BOFH excuse #40: not enough memory, go get system upgrade
Craig Sanders <cas@taz.net.au> wrote:
On Thu, Aug 23, 2012 at 01:50:08PM +1000, Russell Coker wrote:
The main thing that would make me want to give code to the FSF is the fact that they will enforce the GPL. I don't want to be involved in legal cases. If someone flagrantly violated the GPL on one of my projects I'd seriously consider offering the code to the FSF if they would take legal action.
yep, that's another valuable thing that the code contributor gets in exchange for their code.
I doubt, however, that copyright assignment is necessary for this. An organization concerned with defending the GPL could just contact contributors in the event of a dispute and obtain authorization from them to pursue an action in their names. I haven't looked into the details of this, but superfically at least, it isn't clear why this should be any different from an insurance company which has a right under an insurance contract to bring suet against allegedly negligent parties to recover damages. Either way, it's easier if the organization that runs the case is also the copyright holder, but I'm not sure how much of an advantage it is, as long as the contributors are willing to have proceedings brought on their behalf. I would expect the actual evidence and the level of involvement required of contributors, if any, to be similar in either circumstance.
On Thu, 23 Aug 2012, Jason White <jason@jasonjgw.net> wrote:
I doubt, however, that copyright assignment is necessary for this. An organization concerned with defending the GPL could just contact contributors in the event of a dispute and obtain authorization from them to pursue an action in their names.
From what I've heard the FSF has no interest in doing that.
I haven't looked into the details of this, but superfically at least, it isn't clear why this should be any different from an insurance company which has a right under an insurance contract to bring suet against allegedly negligent parties to recover damages.
An insurance company has to pay if no-one else does. Therefore they have a vested interest in the case as they directly lose money.
Either way, it's easier if the organization that runs the case is also the copyright holder, but I'm not sure how much of an advantage it is, as long as the contributors are willing to have proceedings brought on their behalf. I would expect the actual evidence and the level of involvement required of contributors, if any, to be similar in either circumstance.
No matter what happens if my code is involved in a legal dispute then qualified lawyers will argue the matter in court and my testimony will probably be important to the case. Whether it's me or someone else running the case, it won't be me making legal arguments. But I think that for copyright enforcement I would need to be involved in bringing the case to court. Copyright is about the rights of the "owner" not about damage to innocent third parties - unlike insurance cases. If I departed for regions unknown and didn't assign my code to the FSF or some similar organisation then I doubt that any legal action would be possible. Has anyone considered the option of writing a will to leave all their copyright to the FSF? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker wrote:
The main thing that would make me want to give code to the FSF is the fact that they will enforce the GPL. I don't want to be involved in legal cases. If someone flagrantly violated the GPL on one of my projects I'd seriously consider offering the code to the FSF if they would take legal action.
I would also encourage you to talk to the SFC & SFLC. They handle the lawyering and banking for a bunch of high profile projects, and IME they have a lot of clue. https://en.wikipedia.org/wiki/Software_Freedom_Conservancy https://en.wikipedia.org/wiki/Software_Freedom_Law_Center
Rasika Amarasiri <rasika.amarasiri@gmail.com> writes:
http://techcrunch.com/2012/08/18/oracle-makes-more-moves-to-kill-open-source...
The source trees are now up to date with the latest releases, which is nice. MySQL has, for a VERY VERY long time been a pretty closed development model. Any moves that Oracle are making here have been a *long* time in the making (at least 6 years). If you're wanting real free and open source software *projects* (not just source releases), may I recommend Drizzle and PostgreSQL. Very robust communities. -- Stewart Smith
On 08/23/12 10:57, Stewart Smith wrote:
Rasika Amarasiri<rasika.amarasiri@gmail.com> writes:
http://techcrunch.com/2012/08/18/oracle-makes-more-moves-to-kill-open-source... The source trees are now up to date with the latest releases, which is nice.
MySQL has, for a VERY VERY long time been a pretty closed development model. Any moves that Oracle are making here have been a *long* time in the making (at least 6 years).
If you're wanting real free and open source software *projects* (not just source releases), may I recommend Drizzle and PostgreSQL. Very robust communities.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main I Agree. Postgresql has done fine by me for nearly 10 years - and of course the main open source competitor to the "Oracle Database" itself (and other enterprisy databases). I thought it was rather odd that they (Oracle) bought mysql to begin with...
Julian.
"Trent W. Buck" <trentbuck@gmail.com> writes:
Julian wrote:
I thought it was rather odd that they (Oracle) bought mysql to begin with...
IIRC Sun bought MySQL, then Oracle bought Sun.
Yes, this is correct. MySQL probably considered an added bonus in that acquisition. -- Stewart Smith
On 26 August 2012 15:07, Stewart Smith <stewart@flamingspork.com> wrote:
"Trent W. Buck" <trentbuck@gmail.com> writes:
Julian wrote:
I thought it was rather odd that they (Oracle) bought mysql to begin with...
IIRC Sun bought MySQL, then Oracle bought Sun.
Yes, this is correct. MySQL probably considered an added bonus in that acquisition.
-- Stewart Smith
My understanding was that taking control of MySQL was a key part of the deal for Oracle to buy Sun. (from listening to http://twit.tv/show/floss-weekly/194) (along with Java patents). I got the impression Oracle was thinking MySQL was just too much like competition and getting their hands on it would be very helpful for selling their Oracle DB. Then many of the MySQL people forked / produced MariaDB after seeing what Oracle was doing to MySQL. It's just that most people don't know that MariaDB doesn't have the brand recognition and that people don't know that MariaDB is aiming to be as much a drop in replacement for MySQL as possible. I think they claim 99% compatible... I assume Oracle wants people to remain in ignorance as well. Andrew
Andrew Worsley <amworsley@gmail.com> wrote:
It's just that most people don't know that MariaDB doesn't have the brand recognition and that people don't know that MariaDB is aiming to be as much a drop in replacement for MySQL as possible. I think they claim 99% compatible... I assume Oracle wants people to remain in ignorance as well.
I know the above and I'm not even trying to pay attention to database software development. Anybody who has been reading Linux-related news over the last few years would know about MariaDB. People whose job it is to deploy database systems really have no excuse if they aren't aware of major shifts in the field such as the emergence of MariaDB and other forks following Oracle's purchase of Sun.
On Mon, 27 Aug 2012, Jason White wrote:
People whose job it is to deploy database systems really have no excuse if they aren't aware of major shifts in the field such as the emergence of MariaDB and other forks following Oracle's purchase of Sun.
Being aware of the changes does not mean necesarily being "well-informed" E.g. That's me at the moment, because my deployments are in the "just works" area, as Arjen describes. For the last years it was "good enough", my focus was somewhere else. It is sufficient time to lose track of some newer developments (e.g. the book on my shelf is a certification guide for MySQL 5.0, and it is around the knowledge I have, with few newer additions) In a few months time it will become more important to fine-tune a database system, and I am looking forward to do that, and am happy about information shared by people who "Have been there / Done that" :-) Thank you Peter
Hi Andrew, ----- Original Message -----
On 26 August 2012 15:07, Stewart Smith <stewart@flamingspork.com> wrote:
"Trent W. Buck" <trentbuck@gmail.com> writes:
Julian wrote:
I thought it was rather odd that they (Oracle) bought mysql to begin with...
IIRC Sun bought MySQL, then Oracle bought Sun.
Yes, this is correct. MySQL probably considered an added bonus in that acquisition.
My understanding was that taking control of MySQL was a key part of the deal for Oracle to buy Sun. (from listening to http://twit.tv/show/floss-weekly/194) (along with Java patents). I got the impression Oracle was thinking MySQL was just too much like competition and getting their hands on it would be very helpful for selling their Oracle DB.
Other people conjecturing the same thing doesn't make something true. Java may well have been a considering in buying Sun tech, but think particularly of the hardware expertise, service network and other assets. The thought that MySQL played a particular part in the Sun acquisition is somewhere between delusional and pretentious - that makes MySQL very very expensive indeed. It makes no (economic) business sense. Of course it was *convenient*, but that's an entirely different matter.
Then many of the MySQL people forked / produced MariaDB after seeing what Oracle was doing to MySQL.
Incorrect on the timeline: Drizzle and the OurDelta packages started before Sun got bought, and same for Monty leaving Sun and starting his own gig again (from which MariaDB came).
It's just that most people don't know that MariaDB doesn't have the brand recognition and that people don't know that MariaDB is aiming to be as much a drop in replacement for MySQL as possible. I think they claim 99% compatible... I assume Oracle wants people to remain in ignorance as well.
Those that care about Oracle tend to express their views in terms of hatred - I tend to see that in our OSS sphere as well as different corporate environments I deal with in my company. Cheers, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://Upstarta.biz Personal blog at http://lentz.com.au/blog/
On Mon, 27 Aug 2012, Andrew Worsley wrote:
Then many of the MySQL people forked / produced MariaDB after seeing what Oracle was doing to MySQL.
It's just that most people don't know that MariaDB doesn't have the brand recognition and that people don't know that MariaDB is aiming to be as much a drop in replacement for MySQL as possible. I think they claim 99% compatible... I assume Oracle wants people to remain in ignorance as well.
apt-cache search mariadb apt-cache search maria abakus - calculator for KDE libmng-dev - M-N-G library (Development headers) libmng1 - Multiple-image Network Graphics library maria - reachability analyzer for Algebraic System Nets maria-doc - documentation of Maria
Nope. Not there. Probably not available on the RHEL5/6 systems at work either, where we unfortunately have to live with oracle (and a bit of postgres and mysql). -- Tim Connors
On 29 August 2012 19:45, Tim Connors <tconnors@rather.puzzling.org> wrote:
On Mon, 27 Aug 2012, Andrew Worsley wrote:
Then many of the MySQL people forked / produced MariaDB after seeing what Oracle was doing to MySQL.
It's just that most people don't know that MariaDB doesn't have the brand recognition and that people don't know that MariaDB is aiming to be as much a drop in replacement for MySQL as possible. I think they claim 99% compatible... I assume Oracle wants people to remain in ignorance as well.
apt-cache search mariadb apt-cache search maria abakus - calculator for KDE libmng-dev - M-N-G library (Development headers) libmng1 - Multiple-image Network Graphics library maria - reachability analyzer for Algebraic System Nets maria-doc - documentation of Maria
Nope. Not there. Probably not available on the RHEL5/6 systems at work either, where we unfortunately have to live with oracle (and a bit of postgres and mysql).
-- Tim Connors
Hmm according to this site http://kb.askmonty.org/en/installing-mariadb-deb-files/ You have to add their repository to your /etc/apt/sources.list file: e.g. # MariaDB repository list - created 2012-08-29 09:56 UTC # http://downloads.mariadb.org/mariadb/repositories/ deb http://mirror.aarnet.edu.au/pub/MariaDB/repo/5.5/debian squeeze main deb-src http://mirror.aarnet.edu.au/pub/MariaDB/repo/5.5/debian squeeze main Don't know what the story is here - but perhaps it relates to the conflicts that you get with installation of files with similar/same names/locations as MySQL which is more widely used (at the moment at least :-) Andrew
Andrew Worsley wrote:
deb http://mirror.aarnet.edu.au/pub/MariaDB/repo/5.5/debian squeeze main
Third-party repos are bad party repos! This (below) is just lintian of the source package; I didn't have the inclination to build the source and there was no .changes for me to dget in the URL you linked to. E: mariadb-5.5 source: build-depends-on-essential-package-without-using-version build-depends: hurd E: mariadb-5.5 source: build-depends-on-obsolete-package build-depends: dpatch E: mariadb-5.5 source: not-binnmuable-all-depends-any mariadb-test-5.5 -> mariadb-client-5.5 E: mariadb-5.5 source: not-binnmuable-all-depends-any mariadb-test-5.5 -> mariadb-server-5.5 E: mariadb-5.5 source: not-binnmuable-any-depends-any libmariadbclient18 -> libmysqlclient18 E: mariadb-5.5 source: not-binnmuable-any-depends-any libmysqlclient18 -> libmariadbclient18 E: mariadb-5.5 source: weak-library-dev-dependency libmariadbclient-dev on libmariadbclient18 (>= ${source:Version}) W: mariadb-5.5 source: ancient-standards-version 3.8.3 (current is 3.9.3) W: mariadb-5.5 source: changelog-should-mention-nmu W: mariadb-5.5 source: debhelper-but-no-misc-depends libmysqlclient18 W: mariadb-5.5 source: debhelper-but-no-misc-depends mariadb-test W: mariadb-5.5 source: debhelper-but-no-misc-depends mariadb-test-5.5 W: mariadb-5.5 source: debian-rules-missing-recommended-target build-arch W: mariadb-5.5 source: debian-rules-missing-recommended-target build-indep W: mariadb-5.5 source: debian-watch-file-in-native-package W: mariadb-5.5 source: maintainer-also-in-uploaders W: mariadb-5.5 source: native-package-with-dash-version W: mariadb-5.5 source: patch-system-but-no-source-readme W: mariadb-5.5 source: source-nmu-has-incorrect-version-number 5.5.25-mariadb1~lenny W: mariadb-5.5 source: unknown-field-in-dsc original-maintainer W: mariadb-5.5 source: vcs-field-uses-unknown-uri-format vcs-bzr bzr://lp:maria I: mariadb-5.5 source: missing-debian-source-format I: mariadb-5.5 source: no-complete-debconf-translation I: mariadb-5.5 source: ored-build-depends-on-obsolete-package build-depends: gs-gpl I: mariadb-5.5 source: unused-override maintainer-script-lacks-debhelper-token debian/mariadb-server-5.5.postinst O: mariadb-5.5 source: maintainer-script-lacks-debhelper-token debian/mariadb-server-5.5.postrm P: mariadb-5.5 source: package-lacks-versioned-build-depends-on-debhelper 5
"Trent W. Buck" <trentbuck@gmail.com> writes:
Andrew Worsley wrote:
deb http://mirror.aarnet.edu.au/pub/MariaDB/repo/5.5/debian squeeze main
Third-party repos are bad party repos!
This (below) is just lintian of the source package; I didn't have the inclination to build the source and there was no .changes for me to dget in the URL you linked to.
All MySQL packages are fairly out of date with current packaging standards. All those who package MySQL and related products (Oracle MySQL, MariaDB, Percona Server) are attempting to fix things, but naturally we're all fairly busy and there's only X number of hours in the day. -- Stewart Smith
[This is for the lurkers; TimC probably already knows.] Tim Connors wrote:
apt-cache search mariadb apt-cache search maria [nothing useful] Nope. Not there.
Step #2 is: $ wnpp-check maria mariadb-server-core-5.5 (ITP - #565308) $ bts show 565308 # browser $ bts show -m 565308 # mutt, much better for large, threaded tickets If you then give a shit about the ticket, $ bts subscribe 565308 ...which assume you have a working MTA and $EMAIL is set appropriately (which should bloody well hold for all hosts :-/) If you want to actually contribute, #debian-mentors on Freenode can provide details on Debian packaging that are beyond the scope of this short email. PS: these tools come from dpkg-dev or devscripts packages, as "apt-file search bin/foo" will tell you (cf. dpkg -S / dlocate).
On Wed, 29 Aug 2012, Trent W. Buck wrote:
[This is for the lurkers; TimC probably already knows.] ... $ wnpp-check maria mariadb-server-core-5.5 (ITP - #565308) $ bts show 565308 # browser $ bts show -m 565308 # mutt, much better for large, threaded tickets
Ho ho ho! Thanks Trent, I didn't knows. All this time I had been tediously going to the .html page, downloading the mbox, breaking it apart and putting it in my correct ~/Maildir path and invoking my $MTA, and generally faffing about.
If you then give a shit about the ticket,
$ bts subscribe 565308
...which assume you have a working MTA and $EMAIL is set appropriately (which should bloody well hold for all hosts :-/)
Didn't know about that one, but do have a short little procmail recipe that can subscribe for me if I respond to a mail in the BTS. Meanwhile thankfuck debian BTS messages tend to not spam so much as RHEL. I subscribed to the recent leapsecond bug in the RHEL6 kernel, and have had about 50 emails so far about needinfo and versioning and other crap. All going to my private email address because I was silly enough to mention something from it (who else gets sick of them mentioning CVE fix relates to BZ #XXXX, not saying when said regression was introduced, and locking down said BZ so their corporate customers can't see the ticket in question even when logged in with the corporate account, and so can't work out whether we need to repatch the very recently frozen machines bureau wide?) -- Tim Connors
Tim Connors wrote:
On Wed, 29 Aug 2012, Trent W. Buck wrote:
[This is for the lurkers; TimC probably already knows.] ... $ wnpp-check maria mariadb-server-core-5.5 (ITP - #565308) $ bts show 565308 # browser $ bts show -m 565308 # mutt, much better for large, threaded tickets
Ho ho ho! Thanks Trent, I didn't knows.
Lurk in #debian-mentors on Freenode to learn such things (if you're an IRC kinda guy).
Julian <tempura@internode.on.net> wrote:
Postgresql has done fine by me for nearly 10 years - and of course the main open source competitor to the "Oracle Database" itself (and other enterprisy databases).
Postgresql seems to have been undergoing more rapid development over the last few years and to have attracted a growing community. I don't know whether there is any direct connection between this and perceptions about Mysql though. (The above is based on articles that I've read at LWN and elsewhere; I don't use database management systems in any of my work.)
I thought it was rather odd that they (Oracle) bought mysql to begin with...
Sun bought Mysql, then Oracle bought Sun. Nevertheless, I would expect Oracle to have welcomed the strategic advantage of purchasing an emerging competitor in the database market. This move has likely strengthened their business opportunities in relation to Web application deployments and other areas where Mysql reportedly was (and remains) popular.
In my observations, the development of postgres has been constant, perhaps there has been rapid increase awareness in its existence, although i haven't noticed that compared to the growing "nosql" hype or compared to the what mysql had for the last ten years (its the fastest database in the world). mysql is not really comparable to postgresql apart from the SQL suffix. However postgresql is comparable to Oracle Database/SQL Server/DB2. Perhaps Oracle intend on rebranding mysql to something like "Oracle Lite". Who knows. Julian On 08/25/12 14:02, Jason White wrote:
Julian<tempura@internode.on.net> wrote:
Postgresql has done fine by me for nearly 10 years - and of course the main open source competitor to the "Oracle Database" itself (and other enterprisy databases). Postgresql seems to have been undergoing more rapid development over the last few years and to have attracted a growing community. I don't know whether there is any direct connection between this and perceptions about Mysql though. (The above is based on articles that I've read at LWN and elsewhere; I don't use database management systems in any of my work.) I thought it was rather odd that they (Oracle) bought mysql to begin with... Sun bought Mysql, then Oracle bought Sun. Nevertheless, I would expect Oracle to have welcomed the strategic advantage of purchasing an emerging competitor in the database market. This move has likely strengthened their business opportunities in relation to Web application deployments and other areas where Mysql reportedly was (and remains) popular.
luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Julian <tempura@internode.on.net> wrote:
In my observations, the development of postgres has been constant, perhaps there has been rapid increase awareness in its existence, although i haven't noticed that compared to the growing "nosql" hype or compared to the what mysql had for the last ten years (its the fastest database in the world).
I don't know. I only read reputable news sources (such as LWN) and blogs from people active in the community.
Hi Julian, On Sat, 25 Aug 2012, Julian wrote:
mysql is not really comparable to postgresql apart from the SQL suffix. However postgresql is comparable to Oracle Database/SQL Server/DB2.
Do you have a good (especially recent) list of feature comparisons? I am using MySQL (and occasionally Postgresql) - but to keep track of all improvements isn't that easy. (BTW: The forks do not make it easier). Regards Peter
Hi Peter, ----- Original Message -----
Hi Julian,
On Sat, 25 Aug 2012, Julian wrote:
mysql is not really comparable to postgresql apart from the SQL suffix. However postgresql is comparable to Oracle Database/SQL Server/DB2.
Do you have a good (especially recent) list of feature comparisons?
I am using MySQL (and occasionally Postgresql) - but to keep track of all improvements isn't that easy. (BTW: The forks do not make it easier).
I find that tickbox lists don't make much sense in the real world. Apart from features, the different architectures of the different brands make them particularly suitable for specific environments and projects, and another very relevant aspect is familiarity of developers, and available skills of technical administrators (sysadmins, DBAs). Actually *understanding* those differences (which are not simply "PostgreSQL has more features", "MySQL is for the web", "Oracle is Enterprise", etc) Those regarding PostgreSQL, MySQL and Oracle as competitors really miss the point, particularly of why companies choose a particular brand for a particular task. Yes, deployments sometimes do shift from one to another (in any direction). That merely indicates that the deployment operates at a point of overlap where it doesn't matter much which brand is used - or it turned out that the deployment was less suited to the original brand and better suited to the new one. That's good. Companies used to deploy a lot of Oracle as a default choice, even where it was overkill or just generally unsuitable (many web-centric apps would easily fall in to this category, but not merely those). To remedy this, many companies now deploy MySQL in addition to Oracle. This is, in part, indicated by the fact that I've had an increasing number of experienced Oracle DBAs and Developers at my MySQL training courses. So rather than displacing Oracle completely, MySQL is complementary - they live side by side in companies. Similarly, PostgreSQL has been doing extremely well in the GIS space. Aside from such matters and the other described above, the perceived value of specific features and skills is going down - that is, companies now place less value on things like database administration than they do before, even though a serious deployment requires sane architecture at all levels, and ongoing maintenance to guarantee performance and scalability - a badly tuned database server does the job to an acceptable level, given its performance on modern hardware. So they can often get away with it for long, and neglect what an expert regards as fundamental and essential. We can lament and scream that "those companies are stupid and wrong", but understanding what their thought process is really serves us much better, and helps us focus on how to approach them. That is, if we want to do business, rather than merely be right ;-) Cheers, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://Upstarta.biz Personal blog at http://lentz.com.au/blog/
Peter Ross wrote:
Do you have a good (especially recent) list of feature comparisons?
https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_s... (IANADBA; I don't vouch for its accuracy.)
I thought it was rather odd that they (Oracle) bought mysql to begin with...
Sun bought Mysql, then Oracle bought Sun.
Before Oracle bought Sun, 4 years earlier or so, they bought Innobase who developed the InnoDB engine. http://en.wikipedia.org/wiki/Innobase http://www.innodb.com/company/ ... so acquiring the rest of the commercial licensing rights makes sense from Oracle's perspective.
So what's the upshot. Is Mysql about to be commercial or be killed? if either/or then alternatives start to look good? I thought it was rather odd that they (Oracle) bought mysql to begin with...
Sun bought Mysql, then Oracle bought Sun. Before Oracle bought Sun, 4 years earlier or so, they bought Innobase who developed the InnoDB engine.
http://en.wikipedia.org/wiki/Innobase http://www.innodb.com/company/
... so acquiring the rest of the commercial licensing rights makes sense from Oracle's perspective. _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
So what's the upshot. Is Mysql about to be commercial or be killed? if either/or then alternatives start to look good?
I thought it was rather odd that they (Oracle) bought mysql to begin with...
I'd expect a 'leaked' document soon revealing some internal plan to go closed source, then depending on the level of outcry, a confirmation or retraction. James
On 02/09/12 16:48, James Harper wrote:
So what's the upshot. Is Mysql about to be commercial or be killed? if either/or then alternatives start to look good?
I thought it was rather odd that they (Oracle) bought mysql to begin with...
I'd expect a 'leaked' document soon revealing some internal plan to go closed source, then depending on the level of outcry, a confirmation or retraction.
James
One scenario may be for Mariadb or other db to pre-empt by providing greater ease of installation. I don't particularly wish to compile code on our server prior to use. Maybe that/whichever db could even use existing tables. I haven't a clue whether this is even possible so apologies if I am off track. Roger
On Sun, 2 Sep 2012, Roger <arelem@bigpond.com> wrote:
On 02/09/12 16:48, James Harper wrote:
So what's the upshot. Is Mysql about to be commercial or be killed?
if either/or then alternatives start to look good?
I thought it was rather odd that they (Oracle) bought mysql to begin with...
http://en.wikipedia.org/wiki/Mysql#Product_history Oracle bought Sun who had previously bought MySQL.
I'd expect a 'leaked' document soon revealing some internal plan to go closed source, then depending on the level of outcry, a confirmation or retraction.
Given the way Oracle are handling many other things I expect that this is yet more evidence to support the theory that you shouldn't attribute to malice anything that can be explained by stupidity.
One scenario may be for Mariadb or other db to pre-empt by providing greater ease of installation. I don't particularly wish to compile code on our server prior to use. Maybe that/whichever db could even use existing tables.
MySQL and Drizzle are in Debian and the others aren't. Getting major distributions to support a program is a significant factor in determining which gets the most users. The fact that MySQL on Debian has traditionally been a lot easier to manage than pretty much any other DB server is a significant factor in it's use IMHO. There are more than a few servers running MySQL right now because it was the easiest option for me. Oracle Linux is not (yet) a major distribution. Given that Oracle have been difficult about security patches I expect that within Debian people will be making things easier to migrate from MySQL to Drizzle and other DB servers. Mariadb is not in Debian/Wheezy. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Roger <arelem@bigpond.com> wrote:
On 02/09/12 16:48, James Harper wrote:
So what's the upshot. I'd expect a 'leaked' document soon revealing some internal plan to go closed source, then depending on the level of outcry, a confirmation or retraction.
I agree this is possible. At the moment, it's simply a matter of not providing access to test cases, as I read the original article.
One scenario may be for Mariadb or other db to pre-empt by providing greater ease of installation.
That's generally up to Linux distributions to provide and has been covered in the thread already (including references to Debian packages etc.).
I don't particularly wish to compile code on our server prior to use. Maybe that/whichever db could even use existing tables. I haven't a clue whether this is even possible so apologies if I am off track.
My recollection is that MariaDB are trying to maintain file format compatibility with MySQL as you suggest. Disclaimer: this is based on articles that I've read; I'm not involved in database management systems.
James Harper <james.harper@bendigoit.com.au> writes:
I'd expect a 'leaked' document soon revealing some internal plan to go closed source, then depending on the level of outcry, a confirmation or retraction.
They've switched to an "open core" model. Some plugins are closed source. e.g. PAM authentication (both MariaDB and Percona Server have open source equivalents, even with more features than the closed one). -- Stewart Smith
On Wed, 5 Sep 2012, Stewart Smith wrote: [Oracle and MySQL]
They've switched to an "open core" model. Some plugins are closed source. e.g. PAM authentication (both MariaDB and Percona Server have open source equivalents, even with more features than the closed one).
iX 8/2012, a German magazine, has a longer article about the "MySQL universe" describing forks and tools around it. It focuses on Percona in particular. If you don't mind I summarize some of it for hopefully interested people here. The benchmark team left MySQL AB in Aug 2006 founding Percona. They continued to work on the GPL code of the storage engine InnoDB. The result is XtraDB. They offer MySQL (5.1 and 5.5) compatible versionds, with some extentions related to performance, monitoring and diagnosis. XtraDB can change block size without compilation - good for SSDs. You can configure FlashCache, a SSD backed buffer to increase performance. Under Linux it is using a kernel module developed in 2010 by Mohan Srinivasan and Mark Callaghan for Facebook. Percona has a mechanism to boost the warm-up of RAM hungry instances. It uses a LRU (last recently used) list to restore the buffer. The list is written all five minutes when the DB is up. You can preconfigure some frequently used SQL queries to be executed at start-up (in --init-file) to prefill the cache. There is an additional metadata schema INFORMATION SCHEMA for statistics, e.g. to see pages cached, client statistics.. e.g. an easy way to find clients and particular queries. innodb_lazy_drop_table is used to remove the related cache pagies genyly in the background to avoid a complete cache lock for other queries. XtrBackup allows a table backup without table locks, as well as incremental backups, and a compressed send-off to a backup server. The Percona tools offering various helpers. e.g. pt-duplicate-key-checker, pt-online-schema-change for lock free schema changes, pt-query-advisor to analyse the slow log, pt-visual-explain to show explains as a tree, pt-config-diff compares servers etc. Recently Percona introduced a XtraDB cluster. I may look into it soon. I found it quite interesting:-) Regards Peter
On Wed, Sep 5, 2012 at 11:43 AM, Peter Ross <Peter.Ross@bogen.in-berlin.de>wrote:
On Wed, 5 Sep 2012, Stewart Smith wrote:
[Oracle and MySQL]
They've switched to an "open core" model. Some plugins are closed source. e.g. PAM authentication (both MariaDB and Percona Server have open source equivalents, even with more features than the closed one).
iX 8/2012, a German magazine, has a longer article about the "MySQL universe" describing forks and tools around it. It focuses on Percona in particular.
The problem, as I see it with MySQL forks, is that there are too many of them. Monty has his own fork now, there are a few NoSQL forks around, and a few other ones still that are trying to differentiate themselves based on performance of added functionality. The community hasn't coalesced around a single development platform and is very fragmented and so none of these have really taken off. The fact they all go to these extreme measures to remain compatible with MySQL shows their struggles in getting traction. This is very much in contrast with, say the move from OOo to LibreOffice or from XFree86 to FreeDesktop.org's X servers. Cheers -- Aryan
Hi Aryan
The problem, as I see it with MySQL forks, is that there are too many of them. Monty has his own fork now
Drizzle is a fork. See it as separate, there is no compatibility. Traditionally, there have been some interesting patches around - by Percona, Google, Facebook, and others. The reasons for the existence of the patches is that quite a few did work on easier monitoring/management which for MySQL AB (later Sun, now Oracle) has been a key area for commercial offerings. While building the functionality in to the server makes perfect sense (IMHO), the companies have -for business reasons- chosen to build external products to attempt to do the same. Admittedly they're pretty good, but it's still silly if you look at it from this perspective. The OurDelta project (ourdelta.org) worked on packaging a set of these patches, not only to binaries but to distro packages (Debian, Ubuntu, CentOS/RHEL initially), as most users don't care much for compiling the whole thing, or recompiling when one bit gets updated. OurDelta has never been a fork, but rather akin to a distribution (like Red Hat packaged up Linux with some extra patches and stuff, so OurDelta packaged the enhanced MySQL). Monty left Sun Microsystems some time after MySQL AB choose to let itself be bought by that company, and shortly thereafter he started Monty Program and the MariaDB branch. I call it a branch as it still feeds from upstream (Oracle), and the reason for that is that the MySQL team at Oracle has actually been doing some good things. One could call it a "downstream fork", if you like. I worked with Monty to incorporate the patches that OurDelta had in to MariaDB, and Monty Program has also adopted our build system. So essentially what OurDelta had and did is now merged into MariaDB. Percona has some overlap in enhancements (such as XtraDB which replaces InnoDB in MariaDB) but also does some of its own things, so it's doing "Percona Server" which is really like a branch or a downstream fork of MySQL just like MariaDB. The reasons for its existence separate to MariaDB are business choices for its clients - branding. It does fly in the face of an explicit promise made by the Percona founders to Monty (I was physically present at that occasion), but it's a fact anyway. Monty owes me a nice bottle of special vodka because of this, he lost a bet ;-) I am not aware of other branches/forks that specifically exist as a binary or package. Facebook does some of its own patching, just like Google and others have done - much of that is internal although ideas and also code does get fed back to one of the branches, so that's good and does not mess with the ecosystem as such. It's a good example of how Open Source software can indeed be adapted by a company to suit its own specific needs, something that non-OSS software does not offer.
there are a few NoSQL forks around
A noSQL fork of MySQL? do clarify, as I don't see how that even makes any sense.
and a few other ones still that are trying to differentiate themselves based on performance of added functionality.
Probably covered above, but feel free to name specifics.
The community hasn't coalesced around a single development platform and is very fragmented and so none of these have really taken off.
Primarily, the community does not have access to the development platform as managed by Oracle. So it has to do its own thing anyway. MariaDB has its branches open on Launchpad - others can branch, add good stuff, and submit for merge. I got my OQGraph engine added earlier, and some other patches. The system works.
The fact they all go to these extreme measures to remain compatible with MySQL shows their struggles in getting traction.
You note correlation, which is correct. However, you have not proven causality. Binary compatibility makes moving from (for instance) MySQL to MariaDB a trivial drop-in. Client API compatibility has similar advantages - note that MariaDB has a superset now. Regardless of the merits of a particular branch, it's a pest to migrate if it involves significant effort, such as having to modify then recompile applications to work with a different API. The merits of having a common base client API was proven long ago when MySQL first got its SQL layer around 1995, and Monty specifically designed the client library calls to be backward compatible with mSQL - while sharing no common ancestry (mSQL was written by David "Bambi" Hughes on the Queensland Gold Coast - yes I've met him, nice fella), there were at the time some apps using mSQL whereas obviously MySQL was new. So with this library call compatibility, converting an mSQL tool to MySQL was trivial, and that was very useful.
This is very much in contrast with, say the move from OOo to LibreOffice or from XFree86 to FreeDesktop.org's X servers.
Both were very political cases, and to a degree that's also true for MySQL. Consider a distro looking at MariaDB and pondering whether to replace MySQL with it. Oracle can have very big hissy fits when it sets its minds to it. Which distro is willing to take that on? That is the primary conundrum, not technical merit or community traction. Drizzle, being a completely separate thing (it was merely started on an earlier MySQL codebase, so it shares common ancestry) is much easier, it can simply be added as it does not replace anything in terms of packages. If MariaDB were to ditch its binary compatibility to a degree, for instance by changing paths and some naming aspects so that it could (technically) co-exist with MySQL on a single server, then distros would have a much simpler task. However, that approach has problems also, as described above. Given the politics, there is not really a win-win situation and thus the process is quite slow. Perhaps too slow (not disagreeing there) but it serves to understand what's really going on... Regards, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://upstarta.com.au Personal blog at http://lentz.com.au/blog/
On Wed, Sep 05, 2012 at 03:48:27PM +1000, Arjen Lentz wrote:
there are a few NoSQL forks around
A noSQL fork of MySQL? do clarify, as I don't see how that even makes any sense.
it doesn't need to make sense. it just needs to be web-scale. and preferably at least as fast as /dev/null. craig ps: thanks for the history and comments. interesting reading. -- craig sanders <cas@taz.net.au> BOFH excuse #27: radiosity depletion
Arjen Lentz wrote:
Consider a distro looking at MariaDB and pondering whether to replace MySQL with it. Oracle can have very big hissy fits when it sets its minds to it. Which distro is willing to take that on?
Surely any of the ones not certified by Oracle as Oracle-compatible. I can't see e.g. Debian giving a shit about what Oracle thinks.
On 05/09/12 19:02, Trent W. Buck wrote:
Arjen Lentz wrote:
Consider a distro looking at MariaDB and pondering whether to replace MySQL with it. Oracle can have very big hissy fits when it sets its minds to it. Which distro is willing to take that on? Surely any of the ones not certified by Oracle as Oracle-compatible. I can't see e.g. Debian giving a shit about what Oracle thinks.
luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main I agree, I really don't think debian (or anyother distros) would give a damn about oracle and its non-compatible licenses, just look at what happened to sun(oracle) java packages? http://sylvestre.ledru.info/blog/sylvestre/2011/08/26/sun_java6_packages_rem... You now have to d/l it directly from their website. Whether similar will be done with mysql is yet to be seen, but SCO's come and go...
On Wed, 5 Sep 2012, Julian <tempura@internode.on.net> wrote:
I agree, I really don't think debian (or anyother distros) would give a damn about oracle and its non-compatible licenses, just look at what happened to sun(oracle) java packages? http://sylvestre.ledru.info/blog/sylvestre/2011/08/26/sun_java6_packages_re moved_from_debian_u You now have to d/l it directly from their website. Whether similar will be done with mysql is yet to be seen, but SCO's come and go...
The removal of Java packages is BECAUSE Debian people care about licenses. Now we do have some automated download systems for non-free software, the most prominent example is the flashplugin-nonfree which downloads and installs the Adobe Flash plugin for web browsers. There have been other such download packages for fonts, for game data, and for other things. So it's not impossible for someone to create a Debian package to go in non-free that downloads Java from the Oracle servers. I'm not aware of Oracle providing MySQL binaries without matching source, can they even do that? But if they did then it would be possible to have a download package but I expect that the Debian Developers in question would stick with the packages that they can build from source in such a case. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
"Trent W. Buck" <trentbuck@gmail.com> writes:
Arjen Lentz wrote:
Consider a distro looking at MariaDB and pondering whether to replace MySQL with it. Oracle can have very big hissy fits when it sets its minds to it. Which distro is willing to take that on?
Surely any of the ones not certified by Oracle as Oracle-compatible. I can't see e.g. Debian giving a shit about what Oracle thinks.
Oracle does care about keeping Oracle MySQL in the distributions and has dedicated extra resources to help with this. -- Stewart Smith
Hi Roger ----- Original Message -----
So what's the upshot. Is Mysql about to be commercial or be killed? if either/or then alternatives start to look good?
It's been commercial since 1999, there was a company MySQL AB. I used to work there (employee#25), and so did Stewart Smith and several other faces familiar to LUV members. Open Source and commercial are not contradictory, and there are many examples of this. MySQL cannot be killed as the sources are available, and sufficient expertise is concentrated in several companies including Monty Program, Percona, and the database team at Facebook (formerly the MySQL db team at Google). Oracle could cease operating the MySQL brand name or whatever. They could choose to no longer publish sources of future release versions. (there are a few permutations of each option) Neither makes much sense on the business level, as it triggers other actions they cannot control. Right now they have a seat at the open source database table, and a strategic stake in that market. If they "stop", the user base is still there, and so are the active players. It wouldn't be a case of "oh dear we must now all use Oracle RDBMS" or anything like that. As I described in an earlier reply on this thread (must be weeks ago now), my company Open Query tends to deploy MariaDB. Should Oracle no longer deliver anything (or anything useful) from upstream, MariaDB will stop picking up that stuff, but still maintain its own development and fixes. There would be no effective change for either us or our clients. In addition, if Oracle mucked around with either the brand or the OSS nature of future releases, that would be a trigger for Linux distributions to ditch MySQL in favour of (for instance) MariaDB. They'd essentially have no choice, as otherwise there'd be no updates. Given that there are these drop-in replacements, they're natural successors. But... Oracle is not stupid. Whether or not it understand OSS, it understands business and economics. All the above arguments can, as you've seen, be made purely on that basis - specific OSS considerations don't need to come in to it for a decent analysis. Oracle does tend to make business decisions that appear curious to us, as they hurt community or some aspects of the development environment. That's what's currently going on with things like no longer having some bugs public, and more. It is damaging in a way, but more in a "slow annoyance" fashion.
From my perspective, if things are going to proceed in that way (and I have no reason to suspect that it won't, given simple business and process imperatives), I hope that one or more big distros soon get the shits with the situation and make the jump. As someone else noted, having security issues properly dealt with is a big thing for Debian. Just sayin'.
I thought it was rather odd that they (Oracle) bought mysql to begin with...
We don't need to keep recycling this bit - they didn't. MySQL AB choose to be bought by Sun Microsystems, and later Oracle bought Sun Microsystems. Cheers, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://upstarta.com.au Personal blog at http://lentz.com.au/blog/
Thank you Arjen, a most informative piece and food for thought. Although I do think on reflection, that had I been aware of this, I would have set up our Drupal 7 systems in MariaDB or other instead of Mysql some 18 months ago. Cheers Roger
Hi Roger
----- Original Message -----
So what's the upshot. Is Mysql about to be commercial or be killed? if either/or then alternatives start to look good? It's been commercial since 1999, there was a company MySQL AB. I used to work there (employee#25), and so did Stewart Smith and several other faces familiar to LUV members.
Open Source and commercial are not contradictory, and there are many examples of this.
MySQL cannot be killed as the sources are available, and sufficient expertise is concentrated in several companies including Monty Program, Percona, and the database team at Facebook (formerly the MySQL db team at Google).
Oracle could cease operating the MySQL brand name or whatever. They could choose to no longer publish sources of future release versions. (there are a few permutations of each option) Neither makes much sense on the business level, as it triggers other actions they cannot control. Right now they have a seat at the open source database table, and a strategic stake in that market. If they "stop", the user base is still there, and so are the active players. It wouldn't be a case of "oh dear we must now all use Oracle RDBMS" or anything like that.
As I described in an earlier reply on this thread (must be weeks ago now), my company Open Query tends to deploy MariaDB. Should Oracle no longer deliver anything (or anything useful) from upstream, MariaDB will stop picking up that stuff, but still maintain its own development and fixes. There would be no effective change for either us or our clients.
In addition, if Oracle mucked around with either the brand or the OSS nature of future releases, that would be a trigger for Linux distributions to ditch MySQL in favour of (for instance) MariaDB. They'd essentially have no choice, as otherwise there'd be no updates. Given that there are these drop-in replacements, they're natural successors.
But... Oracle is not stupid. Whether or not it understand OSS, it understands business and economics. All the above arguments can, as you've seen, be made purely on that basis - specific OSS considerations don't need to come in to it for a decent analysis. Oracle does tend to make business decisions that appear curious to us, as they hurt community or some aspects of the development environment. That's what's currently going on with things like no longer having some bugs public, and more. It is damaging in a way, but more in a "slow annoyance" fashion.
From my perspective, if things are going to proceed in that way (and I have no reason to suspect that it won't, given simple business and process imperatives), I hope that one or more big distros soon get the shits with the situation and make the jump. As someone else noted, having security issues properly dealt with is a big thing for Debian. Just sayin'.
I thought it was rather odd that they (Oracle) bought mysql to begin with... We don't need to keep recycling this bit - they didn't. MySQL AB choose to be bought by Sun Microsystems, and later Oracle bought Sun Microsystems.
Cheers, Arjen.
Roger <arelem@bigpond.com> wrote:
Thank you Arjen, a most informative piece and food for thought.
It was, indeed.
Although I do think on reflection, that had I been aware of this, I would have set up our Drupal 7 systems in MariaDB or other instead of Mysql some 18 months ago.
Nothing prevents you from making the switch now.
On 05/09/12 18:59, Jason White wrote:
Roger <arelem@bigpond.com> wrote:
Thank you Arjen, a most informative piece and food for thought. It was, indeed. Although I do think on reflection, that had I been aware of this, I would have set up our Drupal 7 systems in MariaDB or other instead of Mysql some 18 months ago. Nothing prevents you from making the switch now.
Ok, How do I go about this please. Roger
Roger <arelem@bigpond.com> wrote:
Ok, How do I go about this please.
1. Find packages for your distribution. 2. Do some Web searches to identify any issues that people have had with the transition, and make sure you've addressed those, if necessary. 3. Try it first on a test machine to make sure everything works as you expect. Don't just install it on the live Web server - that's a recipe for unexpected problems. 4. When you're ready, go ahead with the installation. That's the outline. If you're lucky, someone on the list who has migrated will provide specific advice, but basically the above steps are the obvious way to proceed.
On 05/09/12 19:20, Jason White wrote: > Roger <arelem@bigpond.com> wrote: >> Ok, How do I go about this please. > 1. Find packages for your distribution. > > 2. Do some Web searches to identify any issues that people have had with the > transition, and make sure you've addressed those, if necessary. > > 3. Try it first on a test machine to make sure everything works as you expect. > Don't just install it on the live Web server - that's a recipe for unexpected > problems. > > 4. When you're ready, go ahead with the installation. > > That's the outline. If you're lucky, someone on the list who has migrated will > provide specific advice, but basically the above steps are the obvious way to > proceed. So basically it is not a drop in replacement as mentioned, and, is possibly fraught with problems.
Roger <arelem@bigpond.com> wrote:
So basically it is not a drop in replacement as mentioned, and, is possibly fraught with problems.
No, that's not what I'm suggesting at all. The principle is that you shouldn't be upgrading software on a live Web server that has real users without testing it out first and being confident that it will all work as expected. That applies regardless of what the software is. It's about exercising discipline in the transition process to avoid unwelcome surprises, however unlikely they are - unless of course you don't care about running the risk of lengthy downtime, in which case you can ignore the advice.
On Wednesday 05 September 2012 19:24:21 Roger wrote:
So basically it is not a drop in replacement as mentioned, and, is possibly fraught with problems.
No, Jason was just trying to help you out by describing good sysadmin practice at upgrading software which might have an impact on production services. The same would apply if you were doing a major upgrade of MySQL, or Apache, or the Linux distro you're using. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
Chris Samuel <chris@csamuel.org> writes:
On Wednesday 05 September 2012 19:24:21 Roger wrote:
So basically it is not a drop in replacement as mentioned, and, is possibly fraught with problems.
No, Jason was just trying to help you out by describing good sysadmin practice at upgrading software which might have an impact on production services.
The same would apply if you were doing a major upgrade of MySQL, or Apache, or the Linux distro you're using.
I'd argue that you should do it for minor upgrades of MySQL too. As in 5.5.X to 5.5.X+1. There have been some nasty bugs introduced in some of these point revisions recently that have caused many people to roll back to the previous version. -- Stewart Smith
Stewart Smith wrote:
I'd argue that you should do it for minor upgrades of MySQL too. As in 5.5.X to 5.5.X+1. There have been some nasty bugs introduced in some of these point revisions recently that have caused many people to roll back to the previous version.
That's what sid users are for :-) My rule of thumb (for production gear) is: unless it fixes a bug YOU care about, or adds a feature YOU need, leave it the hell alone. Because new code = new bugs.
On Fri, 14 Sep 2012, "Trent W. Buck" <trentbuck@gmail.com> wrote:
My rule of thumb (for production gear) is: unless it fixes a bug YOU care about, or adds a feature YOU need, leave it the hell alone. Because new code = new bugs.
If the people who maintain your distribution do a good job then it's really not that bad. When a new kernel version comes out I generally upgrade all DomUs that have direct user access (all web servers etc) immediately. It's not to hard to upgrade them and the risk is too great to do otherwise. For servers that are less convenient to reboot I will read the kernel package changelog and see if there's something that sounds important - for example I'll reboot my database servers if there's a risk of filesystem corruption... I don't generally install a new kernel on a Dom0 because if a user gets any opportunity to exploit a bug there then I've got bigger problems. For packages that aren't really mission critical I install all updates as a matter of routine. Presumably when Debian pushes an update for OpenOffice or something they have a good reason for doing so and the potential consequences of the upgrade not working generally aren't that bad. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker wrote:
On Fri, 14 Sep 2012, "Trent W. Buck" <trentbuck@gmail.com> wrote:
My rule of thumb (for production gear) is: unless it fixes a bug YOU care about, or adds a feature YOU need, leave it the hell alone. Because new code = new bugs.
If the people who maintain your distribution do a good job then it's really not that bad.
$coworker *did* point out to me that when I can easily distinguish security updates from <everything else>, I usually install the former with abandon. Specifically, the Debian and Ubuntu -security repos. I tend to use unattended-upgrades for that, partly because I never remember the aptitude limit to match only security updates: ~U~S~VCANDIDATE~Alucid-security
When a new kernel version comes out I generally upgrade all DomUs that have direct user access (all web servers etc) immediately.
I guess we have different classes of users. Most of the time I'm dealing with servers that only/mainly point inwards at an office LAN, where users are assumed to be benign.
It's not to hard to upgrade [the kernel on] them and the risk is too great to do otherwise.
Too risky security-wise or reliability-wise?
For packages that aren't really mission critical I install all updates as a matter of routine. Presumably when Debian pushes an update for OpenOffice or something they have a good reason for doing so and the potential consequences of the upgrade not working generally aren't that bad.
When I look at the changelog, it's very often something that matters to Debian but not to me, e.g. "fix typos in esperanto localization".
Russell Coker <russell@coker.com.au> writes:
On Fri, 14 Sep 2012, "Trent W. Buck" <trentbuck@gmail.com> wrote:
My rule of thumb (for production gear) is: unless it fixes a bug YOU care about, or adds a feature YOU need, leave it the hell alone. Because new code = new bugs.
If the people who maintain your distribution do a good job then it's really not that bad.
This is no longer possible for MySQL as Oracle has a policy of security by obscurity when it comes to security fixes, so it makes it basically impossible for distributions to backport just security bug fixes. -- Stewart Smith
"Trent W. Buck" <trentbuck@gmail.com> writes:
Stewart Smith wrote:
I'd argue that you should do it for minor upgrades of MySQL too. As in 5.5.X to 5.5.X+1. There have been some nasty bugs introduced in some of these point revisions recently that have caused many people to roll back to the previous version.
That's what sid users are for :-)
*If* they run your app in your setup. You'd be amazed as to the bugs that can exist for a very long time that are obvious... especially in a code base with as many crazy things as the MySQL code base. -- Stewart Smith
On 10/05/2012 11:39 AM, Stewart Smith wrote:
"Trent W. Buck" <trentbuck@gmail.com> writes:
Stewart Smith wrote:
I'd argue that you should do it for minor upgrades of MySQL too. As in 5.5.X to 5.5.X+1. There have been some nasty bugs introduced in some of these point revisions recently that have caused many people to roll back to the previous version. That's what sid users are for :-) *If* they run your app in your setup. You'd be amazed as to the bugs that can exist for a very long time that are obvious... especially in a code base with as many crazy things as the MySQL code base.
I've been watching this discussion for some time and am wondering about Sqlite which is used in Fedora and RubyonRails. I know it's not Mysql, but how does Sqlite rate against Mysql. Roger
Hi Roger
I've been watching this discussion for some time and am wondering about Sqlite which is used in Fedora and RubyonRails. I know it's not Mysql, but how does Sqlite rate against Mysql.
SQLite is available in many distros. It is indeed the default database for local testing stuff in RubyOnRails, which is useful. SQLite is a database library, not a database server. Comparing with MySQL is moot as they serve different needs. In terms of code quality, I have great respect for Richard Hipp who designed SQLite, he did a very good job. Obviously, since it's a much smaller code base with less complexity in terms of concurrency and other factors that MySQL has to deal with, it doesn't serve to compare there either. MySQL has had various code quality reviews in the past (by third parties, not paid by MySQL) and it came out quite well. As with all big/complex systems, there's plenty of older code that an expert (like Stewart) would do differently if it were coded from scratch now - but that's a matter of context and hindsight. Cheers, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://upstarta.com.au Personal blog at http://lentz.com.au/blog/
On Wed, Sep 05, 2012 at 04:27:50PM +1000, Arjen Lentz wrote:
[...] Oracle could cease operating the MySQL brand name or whatever. They could choose to no longer publish sources of future release versions. (there are a few permutations of each option)
Neither makes much sense on the business level, as it triggers other actions they cannot control. Right now they have a seat at the open source database table, and a strategic stake in that market. If they "stop", the user base is still there, and so are the active players. It wouldn't be a case of "oh dear we must now all use Oracle RDBMS" or anything like that.
True, making some overt action to make mysql proprietary or to try to kill it off would be counter-productive. It's the kind of thing that could trigger a mass exodus to either a fork of mysql or to a competing product like postgresql (and regardless of how they feel about mysql, Oracle definitely don't want people even thinking about switching to postgresql). OTOH they don't have to do anything, they just have to let things slide and not bother to release any significant updates to mysql. A moribund market leader wins by default (i.e. by the inertia of users), and doesn't scare the users away. A vague promise or a small code-update now and then could keep that going for many years, possibly a decade or more. User inertia is very powerful. People don't want to change how they do things (whether that change is an improvement or not), and they don't want to think that the time and effort they put into something was (or will be) wasted. As supporting evidence, i offer qmail. Amazingly enough there are still systems running it and even some people still installing it on new systems. It hasn't been updated since 2004 and even that was fairly minimal - it had been effectively dead for a few years before that. And, unlike mysql, qmail was never even a market leader...it hadn't had time to even begin to displace sendmail before postfix came along and ate its lunch (and sendmail's too). craig ps: <80 column lines, please. http://mailformat.dan.info/body/linelength.html -- craig sanders <cas@taz.net.au> BOFH excuse #127: Sticky bits on disk.
On Wed, 5 Sep 2012, Craig Sanders <cas@taz.net.au> wrote:
As supporting evidence, i offer qmail. Amazingly enough there are still systems running it and even some people still installing it on new systems. It hasn't been updated since 2004 and even that was fairly minimal - it had been effectively dead for a few years before that. And, unlike mysql, qmail was never even a market leader...it hadn't had time to even begin to displace sendmail before postfix came along and ate its lunch (and sendmail's too).
Qmail offered some significant benefits over Sendmail. The last new installation of Qmail that I witnessed was about 10 years ago, that was due to it being a lot better than Sendmail et al and having a LDAP configuration that was more similar to the Netscape one than Postfix - migrating to Qmail from Netscape was easier than migrating to Postfix. Qmail has some significant down-sides which include the fact that it sends bounce messages in situations where Postfix will send a SMTP 55x. This means that a Qmail server is much more likely to get into a bounce loop than a Postfix server. Qmail also isn't easier to configure than Postfix. For comparing MySQL to PostgreSQL there is the issue of data integrity features which are lacking on MySQL. But MySQL is easier to configure and run in my experience. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Wed, 5 Sep 2012, Craig Sanders wrote:
User inertia is very powerful. People don't want to change how they do things (whether that change is an improvement or not), and they don't want to think that the time and effort they put into something was (or will be) wasted. ... ps: <80 column lines, please. http://mailformat.dan.info/body/linelength.html
Speaking of not wanting to make a change! In your defence, his mail headers don't seem to include the format=flowed crap that would allow longer lines. I also believe USENET should stick with text and no attachments by default, however I can't but help wonder if web fora have won out over USENET because USENET format nazis kept on stamping on people who uuencoded attachments to their posts. The world would be a better place if the masses accepted USENET and there wasn't a proliferation of badly written BBforums all doing a poor job of badly reimplementing small parts of USENET. -- Tim Connors
Hi Anthony
I thought it was rather odd that they (Oracle) bought mysql to begin with...
Sun bought Mysql, then Oracle bought Sun.
Before Oracle bought Sun, 4 years earlier or so, they bought Innobase who developed the InnoDB engine.
http://en.wikipedia.org/wiki/Innobase http://www.innodb.com/company/
... so acquiring the rest of the commercial licensing rights makes sense from Oracle's perspective.
a) the acquisition of Innobase by Oracle earlier had zero impact (commercial, business, legal) impact on MySQL AB's business at the time. Sorry, can't give you details, but you can verify for yourself whether the landscape at the time changed. It didn't. There was (understandably) some apprehension with some corporates. b) as noted earlier, Oracle did not buy MySQL, they bought Sun Microsystems. To pretend that they spent all that dosh to get MySQL is ludicrous, it's not likely to have been even a consideration. To give such cred to MySQL is most flattering, but I don't think it'd be factual. The MySQL commercial operations (training/consulting, the enterprise subscription services, and that nasty dual licensing) do each generate significant revenue, it was and is a profitable operation. However, even at dozens of millions of $ a year, as part of Oracle Corp that's peanuts. From this perspective and various others (MySQL disrupts the "low end" of Oracle RDBMS market space), it would make most business and economic sense to spin it off into a separate company again. Regards, Arjen. -- Exec.Director @ Open Query (http://openquery.com) MySQL services Sane business strategy explorations at http://upstarta.com.au Personal blog at http://lentz.com.au/blog/
participants (17)
-
Andrew Worsley -
Anthony Hogan -
Arjen Lentz -
Aryan Ameri -
Chris Samuel -
Craig Sanders -
James Harper -
Jason White -
Julian -
Peter Ross -
Rasika Amarasiri -
Rick Moen -
Roger -
Russell Coker -
Stewart Smith -
Tim Connors -
Trent W. Buck