Help convince Dell to leverage LSI to Open Source MegaCli

I’ve just submitted “Leverage LSI to Open Source MegaCli” to the Dell IdeaStorm website:

Dell makes some awesome and affordable hardware. Many new Dell machines have the PERC 5/i SAS RAID controller, which is a rebranded LSI MegaRAID SAS.

LSI makes some nice RAID cards. Dell likes LSI. Dell made a deal with LSI to provide the chips for their fancy new PERC 5/i cards.

We buy machines with these cards in them. We need to monitor our RAIDs, rebuild them, and do all manner of other maintenance tasks. We do not expect LSI to provide perfect tools. LSI is a hardware vendor, and it’s understandable that they provide terrible *software*. What is NOT understandable, though, is why LSI’s terrible tools are closed source.

What is further incomprehensible is why Dell is willing to accept this situation on behalf of their enterprise customers. Has anyone from Dell even tried to use the tools LSI provides, and Dell recommends, to manage a RAID array on Linux?

MegaCli is the worst command-line utility I have ever seen, bar none. But, we don’t expect LSI to make it better, we expect LSI to OPEN SOURCE it. That way we software professionals can spend our own time to make them better. We need better tools. We are willing to work for free. Give us the source, or give us good documentation, but give us something.

We’re willing to provide infinite amounts of value to both Dell and LSI. Dell has enough clout with LSI to make this happen. Please make it happen.

Signed,

Jeremy Cole
Open Source Database Guy

Please go there and “promote” this if you care about Dell and RAID!

Breakdown in MySQL Enterprise process

In the past few days, MySQL Community 5.0.41 was released. While reading through the changelog, I noticed the following entry:

The patches for Bug #19370 and Bug #21789 were reverted.

Upon looking at Bug #21789, I noted that it was originally committed in MySQL Enterprise 5.0.32, released December 20th, 2006. The next community release which would have contained the patch is MySQL Community 5.0.33, released January 9th, 2007. This means that not only was the patch not vetted by the community, but there was a full 20 days between the enterprise release with the patch, and the next community release which contained it. According to MySQL’s release process, it could have been a full 5 months, given the right timing…

The patches were rolled back in MySQL Enterprise 5.0.40, released April 17th, 2007. Yes, the patch was committed without much vetting, and then had to be rolled back, 118 days later, in the “enterprise” version of MySQL. Why?

Back when MySQL first polled me about the community/enterprise split, I told them that this would happen. The reason it happened, of course, is that MySQL willingly shut down its only avenue for vetting these sorts of patches. They made a similar split to RedHat Enterprise Linux (RHEL) vs. Fedora Core Linux, but for some reason broke the process at the same time: they produce releases of community much less often than enterprise. That means that nobody in the community is testing the features that they stick in enterprise. They just get pushed out with no public vetting.

The way that RHEL and Fedora work is that all the shiny new stuff is pushed into Fedora first. After it has been deemed that the Fedora process, plus plenty of internal vetting, has been successful, those patches or new versions are merged into RHEL either for the next patchset, or the next full release. This, of course, means that Fedora is always ahead of RHEL. That’s exactly the idea. RedHat is betting that enterprise users (whatever that really means, these days) want a stable slowly-moving release that is “guaranteed” to work, and easy to keep up with.

On the flip side, Fedora is great for users who want the latest and greatest all the time—primarily desktop users and developers—people who are willing to work through the quirks and contribute a bit back in the way of feedback. People that like to run yum update a couple times a week. What do they get in return? A (usually) good product that is completely free.

Why did MySQL reverse the process and make it (in my opinion) useless? I suspect their sales team thinks it would look bad if the community users “get more” than the enterprise ones. But, take a look at the MySQL releases themselves, discounting any other “features”—which are debatable—that you receive with MySQL Enterprise. Why would I pay to get a release with the same unvetted, broken, may-be-rolled-back patches as everyone else gets? Why would I suggest that our customers pay?

I love you, Akismet

Blogging used to be fun.

Then it started to suck. Spam sucked. Life sucked.

Now life is good. Spam is no more. Matt told me to use Akismet; I was skeptical. I am no longer skeptical. I love you, Akismet.

Akismet has caught 501,725 spam for you since you first installed it.

Yup. Since January 15.

Enough with the circling

The police helicopter that has been circling for an hour is driving me crazy. Every night, they circle around in San Jose with their search light. Who are they looking for? I’m sure if they let us know, someone would give them up in order to make the constant “whiiiiiiiirrrrrrr zeeeeeee whuuuuurrrrr” stop. This totally ruins the windows-open-all-the-time spring/summer experience.

Madness continues: SHOW STATUS

Last month I blogged about the silly changes to the default for the SHOW STATUS command in MySQL 5.0 in Stop the madness: SHOW STATUS, and I filed MySQL Bug #19093: SHOW STATUS defaults to SESSION.

Well, it looks like Monty has spoken and this will not be fixed. That’s unfortunate, but oh well, I tried.

You can read the full text of Monty’s reply in the bug report itself, but his reasons for supporting the current behaviour boil down to:

  • It’s similar to what SHOW VARIABLES does. — Yes, this is true, but neither commands’ output makes sense, really. If you do SHOW [SESSION] STATUS, you get a mix of session-scoped and global-scoped results back, and there’s no way to tell which is which. Same goes for SHOW [SESSION] VARIABLES. Ugh.
  • MySQL 5.0 is considered “stable” now, so it’s bad to change it now. — I agree on this part, it’s bad form to change it now, but at the same time, very few people are really using 5.0, so this is in fact a good time to change it, before people find out that it’s broken.
  • MySQL’s documentation has long suggested that people use FLUSH STATUS and SHOW STATUS to find out how query was executed, which kind of works now. — Yes, the manual has suggested this, and a few people have made limited use of it, but come on, it’s impossible to use this in production, and it’s only even of limited value on a test server.

I suggested a compromise: To add a Scope column to the output of the SHOW STATUS and SHOW VARIABLES commands, which would indicate the scope of the value seen in the output. What do you think?

Stop the madness: SHOW STATUS

Are you a MySQL user? Have you tried 5.0? Did you notice that SHOW STATUS was giving you strange results?

Here’s the skinny: The SHOW STATUS command, which has been in MySQL, well forever, has had a long-standing feature request; to have the ability to report its metrics per-session. That functionality was added in MySQL 5.0, in the form of two new syntaxes: SHOW SESSION STATUS and SHOW GLOBAL STATUS to give the per-session and server-wide statistics, respectively. It’s great, and I’m happy to see it.

The problem comes in because of the default behaviour that was chosen for the basic SHOW STATUS with no SESSION or GLOBAL keyword—that is, the command that every MySQL DBA has been using for years—now defaults to per-session statistics.

Every tool, program, monitoring script, performance graph, etc., that uses SHOW STATUS (which is pretty much all of them) is broken in 5.0. Why? Well, for no reason, in my opinion. There is absolutely no advantage to defaulting to per-session statistics instead of the old standard of global statistics.

If you’re upset about this, add your comment to MySQL Bug #19093 and fight the good fight with me.

DHL: Clueless?

I recently signed up with Vonage, since it seems pretty cool. They sent me the VoIP adapter via DHL, who picked it up on Thursday, April 6th. It was sent 2nd day delivery, which means it should have been delivered on Monday, April 10th. Did I get it? Nope!

All through yesterday, April 10th, the DHL website claimed:

Est. Delivery Date: 4/10/2006

Today, Tuesday, April 11th, I figured I’d give them a call to see what’s up, and when I should expect to really receive the package, since the site still claims that the estimated delivery date is yesterday, which doesn’t inspire much confidence. The conversation went something like this:

DHL: Thanks for calling DHL, what can I help you with?
Me: I was sent a package which was supposed to be delivered yesterday, but I haven’t received it. I tracked the package on your website, and it still claims an estimated delivery date of yesterday, which can’t be right.
DHL: OK, can you give me the tracking number?
Me: OK, (reads tracking number)
DHL: Well, we have a lot of packages and not all of them go out every day etc. etc. … your package is here at the sorting facility, it hasn’t gone out today.
Me: Uh, well, it was sent 2nd day delivery, the 2nd day was yesterday. Should I at least expect to receive it today?
DHL: Well, I can’t really tell you that. I don’t know if it will go out today, it’s still here… I don’t know if you’ll get it today.
Me: Don’t you have some sort of service guarantee, or the shipping is free?
DHL: Uh, uh, I don’t know, you’d have to talk to billing about that, I don’t know anything about that…

What the hell? You are DHL. Your only real business is moving other people’s stuff around. How is this considered customer service?