David Axmark Resigns From Sun 229
An anonymous reader writes "From Kay Arno's blog we see that David Axmark, MySQL's Co-Founder, has resigned. This comes on top of the maybe, maybe not, resignation of Monty. We saw earlier this year that Brian Aker, the Director of Architecture, has forked the server to create a web-focused database from MySQL called Drizzle. The MySQL server has been 'RC' now for a year with hundreds of bugs still listed as being active in the 5.1 version.
What is going on with MySQL?"
Sombody finally FINISHED a program! (Score:5, Insightful)
I have used MySQL for nearly 7 years now. ... 30 databases ... many servers and operating systems from MS to Linux. ... as small as 200k to one as large as 900MB.....I have never had a single issue with any of them in all that time, ever.
Sounds like somebody got a program working right and, instead of tweaking it some more and breaking it again, quit.
After decades of information technology it's ABOUT TIME that happened.
WAYTAGO!
Re:MySQL sucks (Score:4, Insightful)
Re:That's the power of the open source license. (Score:1, Insightful)
Development is only as good as the developers.
If the majority of the developers make their living from a single corporation, and when that corporation doesn't allow them to do further development on the project, it's going to take a big hit.
To be sure, open source makes the process harder since others may still be willing to maintain the "still open sourced fork", but when a project comes to a certain size and complexity it will be really hard to replace the lost developers...
Re:MySQL sucks (Score:5, Insightful)
Yeah, I had to snigger at that. The project I'm responsible for has a database that's gotten up to tens of gigabytes in size. MySQL was chosen before I came along, and knowing what I know now, I'd definitely consider alternatives, but for the most part, it serves our purposes.
Re:Sombody finally FINISHED a program! (Score:3, Insightful)
Sounds like somebody got a program working right and, instead of tweaking it some more and breaking it again, quit.
Yeah, because requirements never change.
Re:How long... (Score:5, Insightful)
At least Schwartz got properly 'punished' for the company's poor performance - he received only $11.1 mil. pay package for 2008.
It's really tough being CEO today.
Re:That's the power of the open source license. (Score:5, Insightful)
Theoretically, yes you can fork the code. But there are broader issues than the legal ability to fork.
This has put a huge question-mark over MySQL's long-term viability. For a fork to be viable, you need a critical mass of developers. But we've seen 2 key ( founding ) developers leave, and Oracle buy InnoDB.
If Sun bought MySQL to further the project, then where is the evidence that this is happening?
If Oracle bought InnoDB to further the project, then where is the evidence that this is happening?
Of course you could argue that neither company is obliged to do anything. But alternatively you could argue that both companies have behaved in an explicitly anti-competitive way. This is itself is of course no surprise to anyone other than the US justice department.
Re:Drizzle? (Score:4, Insightful)
Don't use stored procedures. They concentrate ...
You obviously have very little experience ...
Horses for courses, mate. There are good arguments in either direction. Personally I tend to avoid stored procedures not for performance reasons but for pragmatic ones. For one, it's easier sometimes to get a change approved in an application than it is to talk someone into approving a change -- any change -- in the database schema, no matter how trivial, and for another it's easier to migrate or replicate a database to another platform's database (say, Oracle to DB2 for example) when you're only worried about transferring tables and views, not logic. And it is true that the simpler it is, the easier it is to scale. Databases tend to scale by lock-managed clustering, applications by horizontal means (sometimes simply adding another apps server). One tends to be easier than the other.
Sucking data out in bulk can be a good idea too, for safety reasons -- I've seen bank OLTP databases frozen because someone thought it would be safer to set a read-only lock on a report scan, not realising they were using the wrong consistency setting across the entire database & thus forcing the rest of the users (thousands of them) to operate off the DB's log file, then killing the job mid-way after a few hours only to discover he had to face a few hours rollback....
Like I say, horses for courses...
Re:Drizzle? (Score:5, Insightful)
Don't use stored procedures. They concentrate ...
You obviously have very little experience ...
Horses for courses, mate. There are good arguments in either direction.
Yes. Which is exactly why sweeping generalizations like "don't use stored procedures" are idiotic. There are a wealth of cases where stored procedures are best practice.
Re:Goodbye MySQL (Score:3, Insightful)
Or use a better DB: PostgreSQL
Re:MySQL greetings (Score:4, Insightful)
Would you say otherwise if it wasn't amicable?
Re:MySQL sucks (Score:3, Insightful)
Then you my friend, are only using MySQL as an advanced file pointer.
Simple things like firing triggers during cascading events, ensuring the client gets the engine he requested are features MySQL does not have.
MySQL is a nice toy database, but until they change from best effort to ensuring our data, it should never be used for anything critical.
Oracle also took down Berkeley DB (Score:5, Insightful)
...
If Sun bought MySQL to further the project, then where is the evidence that this is happening?
If Oracle bought InnoDB to further the project, then where is the evidence that this is happening?
...
Oracle also took down Berkeley DB. It's still there but buried rather deeply. If Oracle is contributing to BerkeleyDB, then now is a good time to be vocal about it and collect some good karma.
Re:MySQL sucks (Score:5, Insightful)
No I'm not kidding.
PostgreSQL does not support any of these, they are all add on. On top of that none of them are viable for critical environments, some work by replicating through triggers, some work as a middle layer, none of them can guarantee your data in case of primary failure, and none of them has proper sub second fail over (except for Sequoia who doesn't support triggers and procedures) - trust me I've been researching this extensively and there are no FOSS databases that handles this.
Re:MySQL greetings (Score:2, Insightful)
Your cents are worth it :-)
Who has contributed or donated to the MySQL project while actively using MySQL in a production environment?
I am somewhat perplexed by the attitude of some users towards open source. Software? FREE. Support? FREE. Developer wishes to change jobs? NOT FREE.
What the f*ck are we thinking?
Re:Drizzle? (Score:4, Insightful)
Don't use stored procedures. They concentrate computation in the database server which is harder to scale than the application servers.
Ahh, sadly this is what "MySQL database thinking" has wrought.
The mystical grail of the enterprise "scaling." Like many things, conventional wisdom often evaporates when confronted with facts. Can stored procedures load the server? Sure, if you are doing something bad. For the most part stored procedures reduce server load.
(1) Stored procedures can be "pre-compiled" SQL which saves CPU time in the planner. (In databases with such an architecture).
(2) Stored procedures allow data selection beyond mere SQL and can lead to the reduction of data transfered from server to application.
(3) In PostgreSQL, for instance, one can create an index based on a function (like a stored procedure), so:
create index on mytable myindex (foobar(mycol) );
select * from mytable where foobar('froboz') = foobar(mycol) ;
Generates a query that uses and index and doesn't do a full table scan.
(4) Computers today are seriously fast, so much faster than the data storage systems that CPU capability is almost infinite with regards to I/O. Any CPU work that can be done at the server to reduce I/O load will probably improve general scalability.
Basically, stored procedures and functions would not exist, i.e. no one would have created them, if they did not help. Saying that "don't use stored procedures because they load the server" is the same logic behind "don't use power tools because they are dangerous." Yes, if you are ignorant, power tools present a huge danger, however, neglecting them means a lot more work. It is better to educate ones self and use the more powerful tools. Those tools would not exist if they did not provide a positive contribution.
Re:MySQL sucks (Score:4, Insightful)
For cost, for robustness, for functionality, MySQL is a far poorer choice than PostgreSQL.
I've used lots and lots of databases, relational and otherwise - MSSQL, Oracle, DB2, Informix, Unidata, etc. etc.. MySQL looks great to people who haven't got much experience with other databases, and it looks like a chunk of shit to those of us who have. I'm not even talking about database size. I'm talking about functionality level stuff - views, useful subselects, a single reliable table type that supports transactional data writing (and for that matter, a transactional layer that isn't shitty). Features that are always coming in a future version, but are already available in other products - ones that can be had for free.
There's no compelling business case for MySQL over another product, except that you might need to make use of a crappy open source project that's tied to it.
Re:That's the power of the open source license. (Score:4, Insightful)
Why fork it? Just let it die.
There is a serious, open source, Object Relational DBMS [postgresql.org] available.
Yes, and Vim is better than Emacs. Why don't we discuss that too?