Here's the funny thing. It doesn't matter anymore. Patrick's question is interesting in an academic sense, but it's mainly a distraction from what really matters. (Hint: What's the official Linux and who really cares? Ubuntu? RedHat? Debian? CentOS?)
Nowadays what matters is the set of available storage engines. InnoDB, Percona's XtraDB, PrimeBase's PBXT, Maria, Falcon, and several others are available or will be soon. I predict that for the foreseeable future, any MySQL distribution or derivative must support the storage engine plug-in API that MySQL 5.1 defined. And since that's the case, it largely won't matter which flavor you using.
Look at what's happened in the world of key/value databases in the last few years. More than a few of them speak the memcached protocol as either their native and default or an optional add-on. I suspect the same thing will be the case here. All MySQL distributions and derivatives will speak the "traditional" MySQL protocol (just like memecached has the old protocol). Some of them, notably Drizzle, will have other (newere, better) protocols available as well (much like memcached has the new binary protocol).
In summary, the choice of MySQL version or derivative won't matter as much as you might think because they'll have the same Storge Engine plug-ins available (thanks to the shared plugin-in API), they'll all speak a common protocol (this may not be true for replication--watch that area closely), and will largely offer the same subset of SQL and SQL extensions.
They'll all be supported by different groups/companies (including some "database appliance" vendors), will all be tuned differently and aimed at slightly different uses cases, and will certainly benefit from a lot of cross-pollination.
That doesn't sound so bad to me.
The fact that nobody can point to the "real" MySQL in a few years just won't matter. Does anyone ask (anymore) which is the "real" Linux? Nope. And for very similar reasons. Think of MySQL as "kernel" and Storage Engine as "filesystem" and you'll realize we've been down this road before.
We're looking at the upgrade from 5.0 to 5.1 soon at Craigslist and don't know if we'll be using InnoDB or XtraDB yet. Time will tell.
See Also: The New MySQL Landscape, which I wrote a few months back--before a good chunk of the MySQL team had left Sun.
Last week we tried a new Garlic Shrimp recipe that was so simple and delicious that we planned to try it again. On Saturday my wonderful wife came back from the local Safeway and presented me with 1 pound of shrimp as well as about 1/3rd of a pound of small sea scallops.
Here's what the final product looked like:
Preparation is simple and quick.
Cut 2 red chilies lengthwise and remove the seeds.
Rinse the shrimp and scallops, keeping the separate.
Using a garlic press, crush 6-9 cloves of garlic.
Add 5-6 tablespoons of olive oil to skillet or wok. Put the wok on high heat.
Once the oil is hot, add the garlic, chilies, and shrimp. Stir frequently. After about 2 minutes, add the scallops. Continue cooking for another 2-3 minutes until the shrimp are pink and the scallops are just starting to get a gold color on the outside (they'll still be tender inside).
Serve and enjoy!
For a while now, I'd been running Ubuntu 8.04 on my Thinkpad T61 (work machine) with Visual Effects disabled.
There were weird bugs with compiz and xterm that caused corruption at times. So I shut it off and never thought about it again. But a few days ago, I upgraded to 8.10 despite the apparent increase in WiFi related lock-ups I can expect to see (apparently I don't have the Intel wireless in this machine... grumble).
Switching virtual desktops, or "Workspaces" as they're called, seemed to be even slower than before--almost intolerable. Just for kicks I decided to go play with the settings.
Imagine my surprise when switching that selection from "None" to "Normal" resulted in an dramatic increase in virtual desktop redraw perfomance.
Counterintuitive, but yay anyway.
I haven't flown my glider much in the last year and probably won't be flying it again for many months. While that may not be ideal, it means I can spend less money by not paying for an annual inspection and can greatly reduce or eliminate the insurance costs. Or so I thought.
It just so happens that my insurance carrier emailed the other day to ask about renewing my policy (it's that time of year). I explained that I probably wouldn't be flying it and would probably let the policy lapse. The countered with an offer of "storage only" or "ground" coverage, which means that they'd still insure it for non-flight related damage.
Now gliders are kind of expensive to insure in the first place. The annual insurance bill is roughly the same as it is for our Cessna 182Q (which is worth twice as much as my glider). So I was looking forward to paying a lot less.
It turns out that moving to storage only coverage still costs roughly 67% (2/3rds) of what the full flight coverage is. I'm still trying to process that figure. That's like State Farm Insurance telling me that if I agree to keep my car in the garage for a year, they'll give me a 33% discount.
Apparently, (1) there is a lot of overhead in the insurance industry, and (2) they think I'm far more likely to encounter non-flying damage.
And, the best part is this... If I were to cancel coverage all together for the year, I'd have higher rates when I come back next year because of discounts I've accrued with them. "If you let this policy go and then come back later, the new policy offered will be about 15% higher in cost just due to the loss of those discounts." Strangely, I thought those discounts were the result of earning additional ratings (like my Commercial) and gaining experience and flight time.
It's no surprise that the first four letters of the insurance company most glider pilots use are "Cost", huh?
I haven't said a lot here about what I've been working on at Craigslist recently. But Craig mentioned me today in his blog and that made me remember that I should say something. :-)
Much of my work has been behind the scenes infrastructure stuff, but some of that is translating into new features that craigslist users can see. And, as of this morning, a lot more users are seeing the fruits of that labor.
As I noted a few weeks back in Sphinx Search at Craigslist, I've been hacking a lot on search. Here's a screen shot to show you what I've been calling "nearby search" (though "nearby results" is probably more appropriate).
If you run a search in a city and there aren't many results, we'll also run the search in nearby areas to see if we can find matches there too. The above example was a search for "2008 mazda" in my hometown of Toledo, Ohio. The "nearby" results are clearly separated from local matches and local matches are still given priority.
The feedback has been generally positive so far. Though, with any change, some folks aren't happy. I can't say it's going to stay in this exact form. We may need to tweak the interface, the radius of the nearby search areas, and so on. But on the whole I think it's a helpful improvement when you're looking for something that's a bit harder to find and you're willing to drive an hour or two.
As of earlier today, it's available in most smaller and medium sized US cities. It'll probably come to the remainder of cities before long too. I've been testing it for about a week and a half, starting with about a dozen cities and then adding about twenty more late last week. This morning I mostly flipped the big switch.
Of course, this opened the flood gates for similar feature requests: custom radius searches, state wide searching, search ALL of craigslist, etc.
In related news, a couple months back I expanded the search help page to include advanced search syntax, including grouping, negation, OR queries, and more.