Slashdot Mirror
David Axmark Resigns From Sun
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?"
It allows for disagreements to be resolved by disagreeing, even when there are corporations with lots of lawyers involved.
You can still fork it. No easy corporate lock down is possible.
----- "Profanity is the one language that all programmers understand."
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!
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
About 4.5 billion years?
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
Has anyone here used Drizzle?
I'm about to start a new web project and I get to choose the DB. I'm concerned over the lack of stored procedures though. My last big project used SP's for everything and honestly, while initial coding was a pain, in the long run it was a huge benifit.
I need a lean and mean webDB, so, if not Drizzle, does anyone have other recommendations?
About 4.5 billion years?
Well played, sir. Well played.
Anybody want my mod points?
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.
You are in a maze of twisty little passages, all alike.
there's no need to start dicksizing about the type of databases you manage. no one is claiming that MySQL is the best database management system out there, or that it can handle any kind of application. but for a certain range of applications it's a very capable and well designed database server.
not everyone needs a multi-terabyte database. and the utility of a RDBMS is not defined by database sizes it can handle. MySQL is so popular precisely because most sub-enterprise businesses don't need anything as robust as Oracle. so MySQL is therefore a much more cost-effective solution.
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.
Thanks slashdotters for being passionate about all topics FOSS and MySQL!
David's departure is in all ways amicable, and he will continue to be an ambassador for MySQL and for free and open source software in general. For some time already, David was working only part-time for MySQL. After about 25 years of working on MySQL and the projects that preceded MySQL, he very much deserves do whatever he pleases to.
Marten
SVP Database Group at Sun
(previously CEO of MySQL AB)
That won't actually happen as they should be bought up very soon. The only question is by who? Oracle, HP, IBM or one of the hardware giants they rebrand and resell?
The way things have been going the last few weeks, my bet is on the United States Treasury Department.
MySQL sucks
And your post, like my response, is pointless.
Oh, for the days when sig's didn't have to be cute...hey, wait a sec.
Never fear, this is a minor setback for him. I hear he's already writing a book about what he will do in the next act of his career.
Title: "My Sequel"
Soylent Green is peoplicious!
"and the utility of a RDBMS is not defined by database sizes it can handle"
;).
:).
Actually there is some relevance.
If you needed a database gigabytes in size a few _years_ ago, MySQL would have been a really bad choice (it still is crap, just less so IMO).
For MyISAM:
You would have to configure it to get tables bigger than the default 4GB limit (there's a number of row limit and table size limit). Hope you don't make the new setting too small so you're still working in the place when those run out too
For Innodb:
Before the single file per table, if you're moving about gigabytes of stuff, you end up with one huge multigigabyte innodb table.
For both:
Adding an index was the same as "alter table" and involved making a copy of the table.
So let's say you have a 40GB table and 40GB of space free. No index add for you
Keep in mind if you have plenty of space free making a copy of a 40GB table does take time.
BTW concurrent inserts to an innodb table with an auto increment field were slow till only recently (well allegedly they've fixed that).
"How about the "bad connection" issue where the database server due to no reason obvious to the developer will count to ten and then just refuse new connections? How about when MySQL trips over itself and locks it's own tempfile? How about the admin gui that pretends to let you change parameters but really doesn't?"
I've developed, debugged, administered, and administered MySQL databases for nearly a decade now, and I have never seen any of those issues you complain about.
"How about MySQLs abmyssal speed once it has to deal with larger tables?"
The InnoDB storage engine uses clustered indexes and is actually pretty good with large tables. Combine that with the partitioned table support in MySQL 5.1 and large tables are quite manageable. I have one OLTP application with well over 300M rows, and the server runs fine even though it is on commodity hardware.
"but there is no use in pretending like there aren't any problems ..."
Indeed, but they weren't what you mentioned here. I am looking for better CPU utilization on multicore systems, semi-synchronous replication, parallelized replication, better foreign key performance, and better join algorithms. Many of these features are planned of course but I want them now.
501 Not Implemented
Youre joking right? PostgreSQL supports several replication engines which works fantastic great and it has been doing that for years!
You have:
PGCluster
Slony-I
DBBalancer
pgpool
PostgreSQL table comparator
SkyTools
Sequoia
You can read about what Skype use replication for PostgreSQL here:
https://developer.skype.com/SkypeGarage/DbProjects/SkypePostgresqlWhitepaper
And Slony for example is developed by Jan Weick, a PostgreSQL core team member.
Lots of press about a not to large event. I have been working less with MySQL over the past several years (as the company has grown). And when we got acquired we got to big for me (I like to know everyone in a company).
A huge part of my work have been spreading FreeSoftware/OpenSource and I will continue to do that. And tell about the MySQL story many times more hoping to inspire others to try to start FLOSS businesses.
And I hope to meet many of all the people who made MySQL such a sucess many times over the coming years. /David (who posts so seldom he does not remember his slash login/password..)
...
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
Sun doesn't, but if you live in the Java world have you looked at Derby recently? We started out using it as an authentication database embedded in an app, and are now making more and more use of it. It supports transactions and hundreds of simultaneous connections, has very flexible configuration, and supports up to about 50Gbytes of storage. The last alone makes it more useful in many applications than the free versions of MS SQL Server. There are many applications currently running on MySQL which (in my opinion) would benefit from migrating to a tightly coupled all-Java solution. The Derby footprint is tiny, database backup and failover is now supported, and you can work with anything from the command line tool to the usual studio type applications. It has taken me 4 years to become a convert, after 8 years of MySQL, but now in the latest release I love it.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."