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?"
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
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.
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.
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.
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...
Do not mock my vision of impractical footwear
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.
Advice: on VPS providers
...
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.