Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

David Axmark Resigns From Sun

Posted by samzenpus on Wednesday October 08, @07:35PM
from the take-this-job-and-shove-it dept.
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?"
usenet it sun story yoursql
it sun
story

Related Stories

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by aqui (472334) on Wednesday October 08, @07:44PM (#25307315)

    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.

    • by vandan (151516) on Wednesday October 08, @09:41PM (#25308241) Homepage

      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.

  • Drizzle? (Score:5, Interesting)

    by Joe U (443617) on Wednesday October 08, @08:17PM (#25307559) Homepage Journal

    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?

    • Re:Drizzle? (Score:5, Informative)

      by krow (129804) * <brian@nOSpam.tangent.org> on Wednesday October 08, @09:28PM (#25308155) Homepage Journal

      Hi!

      We are still working on the first version of Drizzle. While folks are using it, I don't really recommend it at this point. When we feel like it is ready for adoption we will publicly start recommending it.

      Cheers,
            -Brian

      • Re:Drizzle? (Score:5, Informative)

        by afidel (530433) on Wednesday October 08, @09:20PM (#25308105)
        That advice is only appropriate in the expected query results are small, on large tables using stored procedures can significantly reduce the load on the DB by not requiring it to handle open connections while a large amount of data is streamed to the remote client.
        • Re:Drizzle? (Score:5, Insightful)

          by Nefarious Wheel (628136) on Wednesday October 08, @10:17PM (#25308481)

          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)

            by afabbro (33948) on Wednesday October 08, @10:58PM (#25308769)

            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.

  • MySQL greetings (Score:5, Informative)

    by martenmickos (467191) on Wednesday October 08, @10:08PM (#25308419)

    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)

      • Re:MySQL greetings (Score:5, Informative)

        by martenmickos (467191) on Thursday October 09, @01:12AM (#25309631)

        I think if you ask people who know me, they will say that I stand for transparency and truthfulness.

        If the departure had not been amicable, I guess I would not have commented on it at all, or I would have focused my commentary on whatever other positive aspect I could find.

        But the best may be to ask David directly. I don't want to publish his email address here, but it is not difficult to guess. Most early employees of MySQL AB, like myself, use firstname at mysql dot com.

        Marten

        P.S. Generally I am somewhat perplexed by the attention this topic is getting. The beauty of open source is that you can be actively contributing and participating in your favourite project whether you are employed by a certain company or not. So what's the big deal about David choosing not to be employed? He is not abandoning MySQL. With the enormous payout from the acquisition, the founders can now allow themselves to pursue whatever interests and daily routines they like. Good for them, and I think we should all just be happy that open source can provide not just software freedom but also financial freedom. Just my 2c.

      • Re:MySQL greetings (Score:5, Informative)

        by krow (129804) * <brian@nOSpam.tangent.org> on Thursday October 09, @02:27AM (#25310109) Homepage Journal

        If you look around there are couple of articles that quote David on why he is leaving. It is perfectly amicable, he just dislikes paperwork and would prefer to not deal with it.

              -Brian

  • David Axmark (Score:5, Informative)

    by Anonymous Coward on Thursday October 09, @01:31AM (#25309745)

    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..)

     

    • by mooreti1 (1123363) on Wednesday October 08, @10:36PM (#25308611)

      MySQL sucks

      And your post, like my response, is pointless.

      • by Ungrounded Lightning (62228) on Wednesday October 08, @08:01PM (#25307447) Journal

        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:5, Insightful)

          by ConceptJunkie (24823) on Wednesday October 08, @09:04PM (#25307955) Homepage Journal

          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:MySQL sucks (Score:5, Informative)

          by lysergic.acid (845423) on Wednesday October 08, @09:18PM (#25308089) Homepage

          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.

          • Re:MySQL sucks (Score:5, Informative)

            by TheLink (130905) on Wednesday October 08, @11:36PM (#25309015) Journal
            "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).
        • Re:MySQL sucks (Score:5, Interesting)

          by theantix (466036) on Thursday October 09, @12:02AM (#25309149) Homepage Journal

          "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.