MySQL Released Under The GPL

Bryan Mattern was the first of hundreds to note that MySQL is being released under the GPL, as well as forming a partnership with VA Linux (which of course now owns Andover). This means nice things like it can move out of non-free in debian, and that the postgress/MySQL debate can now be argued in terms of features instead of license. MySQL's license was definitely a hurdle for the FAISC ^[?] so I'm really glad to see this happen.

Comments

Re:Good, now would..

[Abcd1234]

Ooooh, I'd definitely disagree on this one. As an example, when it comes to writing code which tracks inventories, etc, for online purchasing, it's VERY necessary to have transactions. After all, what happens if two people try to buy the same item, of which there is only one left in stock? You get a phantom read (or was this one a fuzzy read... I can't remember :). The only way to avoid this sort of thing is to support proper, serializable transactions, or to do what you'd do with mySQL... lock the table. :) The point is, any time you have a high number of concurrent database accesses, some of which include updates, you definitely need transactions (or more stuff at the application level to prevent this sort of thing, which is what you need to do with mySQL).

Re:Is this a trend?

[tzanger]

Well, now is a good time to start the debate, which do you like better and why? I like them both equally, but then again, I've only run MySQL in enterprise, how does postgress hold up to real strain?

MySQL in enterprise?
How'd you do that without transaction support or are you doing the checks and balances in your code?

I've settled on Postgres because of the transaction issue and because I write my code so that most of the grunt work is done in the database. Why use your cgi to do the sort or the ordering when the database (supposedly) should be able to do it faster? Why use PHP to pick and choose the columns from a generalized select when your database is designed to pick and choose?

I like Postgres (7) because now I don't have to have shared libs to fake foreign keys. Data integrity is a big thing for me and MySQL doesn't seem to have a whole lot of support for it. Yeah it's fast as hell but how much faster than Postgres 6.5 or 7?

I've seen the benchmarks pitting Postgres and MySQL. What I'd like to see are these benchmarks performed with somewhat more "realistic" criteria. I don't do select a,b,c,d from mytable where a=whatever; -- my SQL statements are set up so that the bulk of the work is done by the database itself and the resultant data given back to my program is already ordered, sorted and formatted how I need so that all I have to do in the program is wrap it in HTML and spit it out.

I thought that was the whole idea behind using a database over a flat file or other "roll yer own" database setup?

While I'm on this mini rant, where are some real benchmarks between Perl (with and without mod_perl) and PHP (with and without Zend)? I really don't care if PHP can compute a FFT in 1/3 the time that Perl can; 99% of my cgi scripting is feeding and recieving data from a database connection or parsing some kind of human-readable input into something the machine can use, not doing heavy computations. What are the speed comparisions in a realistic situation?

Don't get me wrong -- I started out with PHP and gradually found myself using more and more Perl just because I could reuse my modules in my other (non-cgi) code. I found myself questioning my use of PHP every time I typed the <?php tag. It's not a good thing to mix code and content, which is pretty much the biggest advantage PHP has over Perl IMO. It makes it very easy to do exactly that.

If I wanted speed over all, I'd write in assembly or C and do the CGI that way. What real advantage does PHP have over Perl?

Re:Good, now would..

[arthurs_sidekick]

Why does every story on MySQL have to contain a complaint like this (and why are they always moderated up to the heavens)?

A MNemOnic I offer to the world: MySQL is Not Oracle. It doesn't try to be one, that's not the goal. Yes, it isn't a heck of a lot more than an SQL frontend to a flat file system. That's all some of us want. OK, subselects would be nice, but IIRC they're working on that. But this constant kvetching about lack of transactions should really stop. If you want something with transactions, use Postgres or Interbase or pay for it.

I am becoming *such* a cranky old man.

Re:Is this a trend?

[Rilke]

I'm not sure what the original poster meant by "enterprise", but the choice should really be based on your needs. Sure, some apps need SPs and transactions, and some really don't.

Take slashdot. I've never looked at the code, the DB needs are pretty simple. Keep track of the user names and passwords, and keep track of the threads and subjects. There's no real complicated joins or formatting required.

And data integrity, vis a vis transactions, just isn't important. Is somebody changing the moderation score on a topic while somebody else is accessing that topic? Who cares? So the moderation score of the thread won't match up. This isn't your checking account, the top line doesn't need to be consistent with the bottom line.

Lots of apps, even in the enterprise, fit MySQL's problem domain, and lots do not. Everyone compares MySQL to PostGres, but it's a bad comparison. If you need transactions or SPs, then you really need them, and using MySQL and trying to emulate these features in code is a very bad idea. If MySQL fits your needs, then it's blindingly fast and the best tool for the job. If those aren't your needs though, then you need something different.

PHP vs. Perl: I've seen both types of projects go to pieces. The problem with PHP is that you start with a lot of HTML and a little code, which makes PHP seem perfect, but over time you wind up with lots of code that isn't organized at all because it's embedded in all your HTML pages, which makes the code very hard to maintain.

Perl, of course, has the opposite problem. You start with a simple database app with very little formatting, which makes a mod_perl script perfect for the job, but over time you start to add bells and whistles to the user interface until you again wind up with your code and HTML totally interspersed, which again makes maintenance very difficult.

I'd love to see a really good book on code organization for the web. It's a very complex subject, and I generally feel like most of us are constantly re-inventing the wheel.

Re:In a word: NOTHING

[chrisd]

VA Does in fact have such a department. It contains:

• Chris DiBona (Me)
• 
  Joe Arruda
  Kit Cosper
  Josh Freeman
  

And two others. This doesn't include the 200+ employees who came -directly- from lugs, users groups, and oss projects. So, yeah, we care.

I assure you that we care very much about VA's ability to make money. We like money. Money buys stuff. But money and helping linux continue to grow and prosper are not mutually exclusive and is what we do here.

As far as immunity, if someone puts a copy of the source code to solaris, you think that we want to accept the liability that person has invited upon him or herself? Hell no. Also, you don't seem appreciate the projects we host and have gotten the angry lawyer calls about. I'm just waiting for the freenet call. When Livid was hosted here on our network, I sent out an email to the guy telling him we would not pull the software without a court order. The AAC decoder has already gotten us a call from Dolby labs, luckily they had released teh very code they were -yelling- at us to pull down themselves into the public domain.

We put a -hell- of a lot of work into sourceforge, but we're not going to be everyone's lawyer, we expect that project leads are well able to take care of their own legal issues. We don't take ownership of their code, why should be accept thier liabilities?

So there is your answer, if you'll take the time to understand it.

If anyone cares about what Bowie is babbiling about with regard to ocmmunity.themes.org, it's been detailed here on slashdot often enough. Just look for my or bowies post on the topic.

Chris DiBona
VA Linux Systems

--
Grant Chair, Linux Int.
Pres, SVLUG