Thanks for the explanation! However, I'm not clear on a couple things:
We're talking in-memory MVCC here. This means you can add 1000 records, do a rollback, and the harddisk hasn't been accessed. Even if you commit, performance will eventually be magnificent compared with on-disk MVCC systems.
My first reaction is that PostgreSQL also does MVCC in memory - at least until the OS flushes its disk buffers. A write ain't a write 'til it's written. Is Falcon's memory management that much better than most of its host OSs'?
You can run larger systems on one server with this, than you would be able to run on a cluster with other database systems.
In practice, how much does this affect memory usage? Is its upper bound low enough that you can still manage giant tables on a reasonably affordable machine?
A DBMS featuring a "/dev/null" backend would be worthless for all applications other than entertainment value (not that MySQL has ever been anywhere near that bad). Unless a system is reliable enough to actually manage your data, every other feature is moot.
That's a good thing. For many applications ACID isn't worth the overhead. There are many applications where performance is more important than reliability, for instance because the data can be trivially rebuilt if something goes wrong.
Ironically, PostgreSQL often benchmarks much faster than MySQL, particularly when non-trivial loads are involved. When you can formally prove that a class of error conditions can't happen, you can stop testing for them.
So you're suggesting that people use something that they are not comfortable with, instead of something that they are and which is getting better at an acceptable pace?
Yes. I am indeed suggesting that people spend a few minutes learning how another Free, faster, and more powerful database works. If you're dabbling, then it's no harder to learn one than the other. If you're serious, then you owe it to yourself and your clients to know what's available.
is evidence that easier trumps better when it comes to the early adoption curve, something I wish the PGSQL folks had understood (or rather cared about).
But in something as mission-critical as a database, of all things, reliability trumps everything. I don't think they could have developed PostgreSQL any other way and still supported its primary goal of safety.
PGSQL should have thrashed MySQL long ago. If you wait long enough, competing projects will gain parity and the game is over.
What gave you the (wrong) impression that PostgreSQL folks have been sitting around twiddling their thumbs? Version 8.2 just came out within the month and includes several performance boosts that make it fly on our production systems.
OK, although I don't agree with it, I know that a lot of people use MySQL because it's the most common database supported by web hosts. Isn't it almost as likely for a hosting company to have PostgreSQL, though, as to upgrade to a bleeding-edge version of MySQL when this is finally readied for public consumption? Will this new backend give any extra functionality that PostgreSQL doesn't offer?
I fully expect them to announce that they're starting an x86 port, and it'll be ready in January of 2008.
Spoken like someone who abandoned their Amiga before the bitter end and didn't stick around for the true lunacy. A real Amiga announcement would claim that the new DEC Alpha port would be available for sale in Two Weeks (tm).
I loved AmigaOS. I used it for probably a decade after it had completely stagnated at the top levels, while its huge crowd of shareware developers kept shovelling great software out to Aminet. But come on, folks: Amiga is dead. Not dying; dead. All of the technical elegance I appreciated for so long has now moved into other systems (KDE and its KIOslaves are far cooler than Amiga's "datatypes" ever hoped to be), and other than keeping an emulator available for the occasional retro-gaming jones, I just can't see a single reason for its continued existence.
I'm the last one to criticize people for spending their days working on projects that look insane to everyone else, but this brings me pretty close. Rest in peace, Amiga. You were beautiful at a time when no other computer was, but your era has long passed. Leave us with our wonderful memories, and sleep well.
This comes up a lot, so skip this if you've read my take on the matter before.
One of my clients has a website that features an opt-in email newsletter. Each message is roughly 1MB in size (many pages, lots of images, etc.). He has about 25,000 subscribers. This means that near the first of each month, he's sending about 25GB of email out to people who want to get it. Under SMTP, this is no big deal - just give Postfix a list of recipients, and let it work out the delivery details. The mail queue gradually shrinks over time, and in the case of many customers at the same domain, his server can group all of those recipients into a single connection.
Under DJB's plan, he would send out 25K notices that the newsletter is ready. Whenever people arrive at their office in the morning and check their mail, his WAN connection would catch on fire as they all try to simultaneously download the message (or at the least overwhelm it in predictable waves: 9AM EST, 9AM CST, 9AM MST, 9AM PST). His service would completely fall apart.
Not only would spammers hurt under this plan, but so would every legitimate bulk sender (such as my friend and every mailing list operator). That's a price I'm not willing to pay.
#2 is what is called "entrapment", and is kind of a manufactured guilt. (i. e. they woudn't have been guilty of anything except that an undercover officer went and tried to convince them to do something illegal.)
Actually, my understanding of entrapment is that it involves coercion, eg they get you to do something you would not normally voluntarily do on your own. IANAL, though, so take that for what it's worth.
Now if I can just convince the last supervisor that Media Wiki is better than MS Word with Track Changes turned on (shudder!).
Easy. In event of an emergency, is your field tech going to find it easier to use his cell phone to browse the corporate Wiki or an unviewable Word document? There have been plenty of times when I've been grateful to have web access to some information I needed.
Can you give us some examples where Linus' decisions have seemed reasonable in the short term but proven poor in the longer term?
BitKeeper.
Care to provide specific examples supporting this broad, general attack?
If you consider that an attack, then you are way, way too personally invested in his reputation. I like Linus, but that doesn't mean he can walk on water. No, I'm not going to dig through 1,000 old news articles to build a dossier against him. In general, though, Linus does what he can to avoid making decisions for political reasons - he's said so in numerous interviews - even when the consequences of his decisions have unwelcome political repercussions on other people.
My basic strategy has always been to not care too much. It actually ends up working wonders - avoiding confrontation by just walking away. The thing is, I don't usually feel as deeply about some of the issues they feel strongly about, and that makes it easier just to ignore the politics - and as a result, the political consequences. That also allows me to concentrate on the things I do enjoy, namely the technical discussions.
Whether that position is good or bad is a matter for debate, but Linus himself is on record many times saying that he simply isn't interested in political discussions. I think it's pretty fair indeed to characterize him that way.
Linus is a pragmatist. He has constantly favored using the best tool for the job over religious fanaticism.
From another perspective, Linus's algorithm for deciding pragmatism is based on a greedy algorithm - it always spits out answers that look reasonable in the short term. He may be an excellent programmer and good project leader, but he seems to lack a sense of perspective.
He has said many times that he has no interest in software politics. Unfortunately for him, software politics has a terrific interest in him. He ignores it at his own peril.
If you don't distribute the application, why would copyright have an effect?
But the point is that you can distribute proprietary applications with bindings to just about any other major database without paying for client library redistribution rights. MySQL is the only one I'm aware of that won't let you do that.
You are proving that you don't really understand the technology or the business behind MySQL and are fine with throwing your lot behind myths that have been propogated for a long time now.
Jay, if I'm wrong, then is it my fault (as a potential customer) that I have misinformation, or yours (as my potential vendor) for not bothering to publicize your case? This is the first time I've heard of the backends you mentioned, and I follow tech news very closely.
It costs nothing to submit a story to Slashdot, so whenever you add support for a cool new backend or add major functionality, why not try to publicize it, especially outside your regular channels? Maybe MySQL vendors and partners are already up-to-date with your newest developments, but you've already sold your product to them. Do your company a favor: walk over to the Public Relations department and explain that your product is garnering a bad reputation in public forums. In the absence of good news from you, all we have is the bad news from anecdotes to share.
Add in that Bindings for MySQL are available for just about every language.
Caveat: those bindings link against GPLed libraries. It's not possible to use MySQL as a backend to proprietary applications without shelling out some cash. Whether that is good or bad is another issue. Note that even Oracle allows restribution of their client libraries under those conditions; this restriction seems to be unique to MySQL.
I apologize if you (mistakenly) thought I was trolling. However, the reality of the situation is that MySQL does not own the rights to its primary feature-laden backend. If Oracle decided to pull the plug on InnoDB - or worse, shift its direction so that it retains developer mindshare but becomes less useful for MySQL - then what's your fallback plan? Revert back to telling would-be users that ACID, stored procedures, etc. are unimportant and that they belong in client code?
If you have other plans, by all means let us know! In the mean time, the thought of building business logic on MySQL is growing scarier by the month. You can write me off as a troll if you want, but I think you'd be better off publically addressing these issues and making a liar out of me.
And one free bit of advice: for God's sake, distance yourself from SCO! That affiliation by itself is an enormous dealbreaker for a lot of people.
The differences are subtle but sometimes important. An example is where each distro puts startup scripts and how they are written. Some are even migrating towards Apple's launchd which is an entirely different animal from the customary SYSV or BSD scripts.
That's not a huge obstacle in and of itself, but multiply little issues like that by a few hundred and it's not so pretty. The Linux Standards Base was supposed to address a lot of that, but no one seems to be clamoring to support it.
Gotcha. Maybe I should have changed that to "for new development", as in starting-from-scratch projects where there are no database dependencies already in place. Is anyone still using MySQL in those situations?
I guess that's fair - my company migrated to supporting only "generic Red Hat Database", aka PostgreSQL.
Seriously, except in cases where you have no choice about database availability, I can't see a single reason to use MySQL these days. All of their cool features are owned by their competitors, and they're starting to pull desperate financing tricks like whittling away tech support and partnering with SCO. Are people still using it for new deployments, and if so, why?
I'm more interested in the word "designer" in the title of the article. At least one set of geeks was able to convince at least one person who gets paid for having fashion sense to hack their work to make it cool in a geeky way. Seriously, how often does that happen?
Slashdot Mirror
In other words, the first priority is reliability. After that, other considerations come into play. See? We agree.
My first reaction is that PostgreSQL also does MVCC in memory - at least until the OS flushes its disk buffers. A write ain't a write 'til it's written. Is Falcon's memory management that much better than most of its host OSs'?
In practice, how much does this affect memory usage? Is its upper bound low enough that you can still manage giant tables on a reasonably affordable machine?
No it doesn't.
A DBMS featuring a "/dev/null" backend would be worthless for all applications other than entertainment value (not that MySQL has ever been anywhere near that bad). Unless a system is reliable enough to actually manage your data, every other feature is moot.
Ironically, PostgreSQL often benchmarks much faster than MySQL, particularly when non-trivial loads are involved. When you can formally prove that a class of error conditions can't happen, you can stop testing for them.
Yes. I am indeed suggesting that people spend a few minutes learning how another Free, faster, and more powerful database works. If you're dabbling, then it's no harder to learn one than the other. If you're serious, then you owe it to yourself and your clients to know what's available.
But in something as mission-critical as a database, of all things, reliability trumps everything. I don't think they could have developed PostgreSQL any other way and still supported its primary goal of safety.
What gave you the (wrong) impression that PostgreSQL folks have been sitting around twiddling their thumbs? Version 8.2 just came out within the month and includes several performance boosts that make it fly on our production systems.
OK, although I don't agree with it, I know that a lot of people use MySQL because it's the most common database supported by web hosts. Isn't it almost as likely for a hosting company to have PostgreSQL, though, as to upgrade to a bleeding-edge version of MySQL when this is finally readied for public consumption? Will this new backend give any extra functionality that PostgreSQL doesn't offer?
Get developed by a company that doesn't hate MySQL, for starters.
Spoken like someone who abandoned their Amiga before the bitter end and didn't stick around for the true lunacy. A real Amiga announcement would claim that the new DEC Alpha port would be available for sale in Two Weeks (tm).
I loved AmigaOS. I used it for probably a decade after it had completely stagnated at the top levels, while its huge crowd of shareware developers kept shovelling great software out to Aminet. But come on, folks: Amiga is dead. Not dying; dead. All of the technical elegance I appreciated for so long has now moved into other systems (KDE and its KIOslaves are far cooler than Amiga's "datatypes" ever hoped to be), and other than keeping an emulator available for the occasional retro-gaming jones, I just can't see a single reason for its continued existence.
I'm the last one to criticize people for spending their days working on projects that look insane to everyone else, but this brings me pretty close. Rest in peace, Amiga. You were beautiful at a time when no other computer was, but your era has long passed. Leave us with our wonderful memories, and sleep well.
This comes up a lot, so skip this if you've read my take on the matter before.
One of my clients has a website that features an opt-in email newsletter. Each message is roughly 1MB in size (many pages, lots of images, etc.). He has about 25,000 subscribers. This means that near the first of each month, he's sending about 25GB of email out to people who want to get it. Under SMTP, this is no big deal - just give Postfix a list of recipients, and let it work out the delivery details. The mail queue gradually shrinks over time, and in the case of many customers at the same domain, his server can group all of those recipients into a single connection.
Under DJB's plan, he would send out 25K notices that the newsletter is ready. Whenever people arrive at their office in the morning and check their mail, his WAN connection would catch on fire as they all try to simultaneously download the message (or at the least overwhelm it in predictable waves: 9AM EST, 9AM CST, 9AM MST, 9AM PST). His service would completely fall apart.
Not only would spammers hurt under this plan, but so would every legitimate bulk sender (such as my friend and every mailing list operator). That's a price I'm not willing to pay.
Actually, my understanding of entrapment is that it involves coercion, eg they get you to do something you would not normally voluntarily do on your own. IANAL, though, so take that for what it's worth.
Easy. In event of an emergency, is your field tech going to find it easier to use his cell phone to browse the corporate Wiki or an unviewable Word document? There have been plenty of times when I've been grateful to have web access to some information I needed.
BitKeeper.
If you consider that an attack, then you are way, way too personally invested in his reputation. I like Linus, but that doesn't mean he can walk on water. No, I'm not going to dig through 1,000 old news articles to build a dossier against him. In general, though, Linus does what he can to avoid making decisions for political reasons - he's said so in numerous interviews - even when the consequences of his decisions have unwelcome political repercussions on other people.
From a a Wired interview:
Whether that position is good or bad is a matter for debate, but Linus himself is on record many times saying that he simply isn't interested in political discussions. I think it's pretty fair indeed to characterize him that way.
...and GCC and the ubiquitous GNU tools and the legal foundation that nurtured Linux.
Businesses are welcome to the party, but the day when business concerns steer all political decisions, I'm giving up and buying a Mac.
From another perspective, Linus's algorithm for deciding pragmatism is based on a greedy algorithm - it always spits out answers that look reasonable in the short term. He may be an excellent programmer and good project leader, but he seems to lack a sense of perspective.
He has said many times that he has no interest in software politics. Unfortunately for him, software politics has a terrific interest in him. He ignores it at his own peril.
But the point is that you can distribute proprietary applications with bindings to just about any other major database without paying for client library redistribution rights. MySQL is the only one I'm aware of that won't let you do that.
Jay, if I'm wrong, then is it my fault (as a potential customer) that I have misinformation, or yours (as my potential vendor) for not bothering to publicize your case? This is the first time I've heard of the backends you mentioned, and I follow tech news very closely.
It costs nothing to submit a story to Slashdot, so whenever you add support for a cool new backend or add major functionality, why not try to publicize it, especially outside your regular channels? Maybe MySQL vendors and partners are already up-to-date with your newest developments, but you've already sold your product to them. Do your company a favor: walk over to the Public Relations department and explain that your product is garnering a bad reputation in public forums. In the absence of good news from you, all we have is the bad news from anecdotes to share.
Caveat: those bindings link against GPLed libraries. It's not possible to use MySQL as a backend to proprietary applications without shelling out some cash. Whether that is good or bad is another issue. Note that even Oracle allows restribution of their client libraries under those conditions; this restriction seems to be unique to MySQL.
I apologize if you (mistakenly) thought I was trolling. However, the reality of the situation is that MySQL does not own the rights to its primary feature-laden backend. If Oracle decided to pull the plug on InnoDB - or worse, shift its direction so that it retains developer mindshare but becomes less useful for MySQL - then what's your fallback plan? Revert back to telling would-be users that ACID, stored procedures, etc. are unimportant and that they belong in client code?
If you have other plans, by all means let us know! In the mean time, the thought of building business logic on MySQL is growing scarier by the month. You can write me off as a troll if you want, but I think you'd be better off publically addressing these issues and making a liar out of me.
And one free bit of advice: for God's sake, distance yourself from SCO! That affiliation by itself is an enormous dealbreaker for a lot of people.
The differences are subtle but sometimes important. An example is where each distro puts startup scripts and how they are written. Some are even migrating towards Apple's launchd which is an entirely different animal from the customary SYSV or BSD scripts.
That's not a huge obstacle in and of itself, but multiply little issues like that by a few hundred and it's not so pretty. The Linux Standards Base was supposed to address a lot of that, but no one seems to be clamoring to support it.
Gotcha. Maybe I should have changed that to "for new development", as in starting-from-scratch projects where there are no database dependencies already in place. Is anyone still using MySQL in those situations?
I guess that's fair - my company migrated to supporting only "generic Red Hat Database", aka PostgreSQL.
Seriously, except in cases where you have no choice about database availability, I can't see a single reason to use MySQL these days. All of their cool features are owned by their competitors, and they're starting to pull desperate financing tricks like whittling away tech support and partnering with SCO. Are people still using it for new deployments, and if so, why?
I'm more interested in the word "designer" in the title of the article. At least one set of geeks was able to convince at least one person who gets paid for having fashion sense to hack their work to make it cool in a geeky way. Seriously, how often does that happen?