Movin’ on up!
To the east side.
To a deluxe apartment
in the sky.

It’ s a bouncy, happy, gospel-flavored song. I always seem to think of it or hum it whenever I’m planning a move of some kind. The weird thing is, I never watched the show when it was on television. I saw the opening montage enough for it to stick with me, I guess.

So what’s moving over here? Well, the main server at Monty Program has been doing more than its fair share for a while, and it has done a decent job at it, but it’s time to give it a bit of a break, so we’re going to be moving some of its responsibilities to other servers over the coming weeks. The first service I’ve chosen to move is the AskMonty.org website. The move will happen on February 25th.

Thanks to the beauty of DNS, the move should be completely transparent to most users. There will be a brief period of read-only access while I copy the database from the old server to the new server, but that will only affect those that want to edit the wiki, or add things to worklog.

Of course, anything can happen during a move, so if you notice any weirdness on the site this Thursday, pop into #maria on freenode and let me or one of the other ops know.

Thanks!

Enabling Statistics

Statistics gathering is turned off by default in MariaDB 5.2. This is done to prevent the extra load on a server that this feature causes from happening unless you want it.

To enable statistics gathering, just put the following line in the [mysqld] section of your my.cnf file (or use it on the command line when starting the server):

userstat = 1

Now start (or restart) your MariaDB 5.2 server and statistics will be gathered.

Warning: If you switch back and forth between MariaDB 5.1.xx and MariaDB 5.2 (like I do on my MariaDB testing box), and use the same my.cnf file, be aware that the ‘userstat = 1″ line will not be recognized on versions of MariaDB prior to 5.2 and will cause errors.

Showing and Flushing Statistics

The User Statistics SHOW commands supported by MariaDB 5.2 are:

SHOW CLIENT_STATISTICS
SHOW USER_STATISTICS
SHOW INDEX_STATISTICS
SHOW TABLE_STATISTICS

If you want to restart the counters on any of these (like after you roll out a change to your application) you will find the following FLUSH commands handy:

FLUSH CLIENT_STATISTICS
FLUSH USER_STATISTICS
FLUSH INDEX_STATISTICS
FLUSH TABLE_STATISTICS

Information Schemas

The above SHOW and FLUSH commands are just easy ways to view and flush the actual statistics, which are stored in the information_schema database. Specifically, statistics are stored in the following tables in the information_schema database:

CLIENT_STATISTICS
USER_STATISTICS
INDEX_STATISTICS
TABLE_STATISTICS

The CLIENT_STATISTICS table stores information such as the number of concurrent connections from a particular client, the number of rows read by a particular client, the number of SELECT or UPDATE commands executed by a particular client and so on.

The USER_STATISTICS table stores the same information as the CLIENT_STATISTICS table, but on a per user basis.

The INDEX_STATISTICS table stores statistics on index usage and makes it possible to do things like locating unused indexes and generating the commands to remove them.

The TABLE_STATISTICS table is similar to the INDEX_STATISTICS table, but contains statistics on table usage such as the number of rows read and changed in a particular table.

More Information

Detailed information about User Statistics in MariaDB (including schemas for the various tables) is available on the askmonty.org website: http://askmonty.org/wiki/index.php/Manual:Userstat

At Monty Program we’ve been guilty of this. Up until a few days ago our main website, askmonty.org, was running the stock MySQL server from our chosen Linux distribution’s repositories. This was mainly done for system administration simplicity. However, MariaDB now has Debian, Ubuntu, and CentOS packages available for download and we saw no reason to not eat our own dog food. Yes, we could have taken the time to create custom build of MariaDB just for our own use even before our first beta releases, but like the barber with the bad haircut and the cobbler’s children with no shoes we are too busy improving MariaDB to focus on geeking up our web server with custom builds. For our production servers we would rather use standard packages like nearly everyone else on the planet. Why? So that we can focus on doing what we do best: making MariaDB the best version of MySQL you’ll find anywhere.

So how did the upgrade go? Swimmingly. There were a couple glitches due to some historical weirdness on our web server, but once those minor issues were resolved the install of the beta MariaDB packages was trouble-free. It just worked. All of the MySQL databases on the server were in perfect working order after the upgrade with the exception of a single table in one of the databases which was easily fixed with a “REPAIR TABLE dbname.tablename;”.

Oh, and before you ask: I performed a full backup of all of our databases to an external drive prior to doing the upgrade. I trust MariaDB as much as anyone can, but power outages, lightning strikes, earthquakes, floods, and even meteors hit Finland at the exact wrong time every once in a while and it would be just my luck to have one of those happen during an upgrade.

In conclusion: Monty Program is now eating its own dog food, and it’s awesome.

I’d like to publicize an issue that the F-Spot developers have been slow to address:

<rant>

There is a good possibility that every photo you’ve imported to F-Spot has had its EXIF date tags altered without your permission and without F-Spot informing you that it has done so.

From bug reports going back over two years it is clear that F-Spot has a serious date problem.

What is the assigned severity of these bugs? Normal.

What is the status of these bugs? UNCONFIRMED.

How’s this for confirmation:

Mangled EXIF data as viewed by Gthumb

The above is a screenshot of the EXIF date information (as viewed by Gthumb) of a photo I imported to F-Spot version 0.6.1.3 for testing purposes. Prior to import, all three of the fields (DateTime, DateTimeOriginal, and DateTimeDigitized) had the same timestamp: 2009:10:26 13:37:11. This timestamp corresponds to when I took the picture: 13:37 on October 26th.

As can be seen, F-Spot has decided that the users are idiots and to update the fields with the values it thinks are best without telling anyone. It decided to set the DateTime field to the time when the photo was imported into F-Spot (as if that date is so important it needs to be saved for posterity). For DateTimeOriginal F-Spot decided that the appropriate time is the UTC time when the picture was taken (conveniently deciding that since my computer is currently in U.S Eastern Daylight Time, I must have been in the same timezone when I took the picture and that my camera was set to the correct time for my timezone at the time I took the picture). The EXIF date fields do not have timezone information in them so setting it to UTC is meaningless because there’s no way to tell from looking at the data that that is what you’ve set it to! The DateTimeDigitized field is the only one F-Spot left alone which gives us the strange paradox of the picture being digitized 4 hours before it was originally taken! <sarcasm>Yeah, that makes sense.</sarcasm>

This problem is so bad some users have resorted to writing perl scripts to try and fix things after the fact or launching the program in different ways to prevent the problem from happening. I am going to take the nuclear option and simply remove F-Spot from all of my computers.

An open letter to the F-Spot devs:

To whom it may concern,

Data corruption is ALWAYS a critical problem but you list bugs 340903 and 454082 as “UNCONFIRMED” with a severity and priority of “Normal”.

UNCONFIRMED? Normal? Who are you kidding? Data corruption is always critical and these bugs are years old and have been confirmed in your own bugzilla by dozens of users.

Regardless of whatever reason you had for introducing this stupid date-changing “feature”, you never change EXIF data unless the user expressly tells you to. That’s basic common courtesy.

You’ve known about this issue for over three years. You need to grow up, acquire a clue, and fix F-Spot’s terrible and destructive behavior. Yesterday.

Until then I will distrust F-Spot and anyone who says it is anywhere close to being a good, decent, or even “ok” photo manager. You and others keep telling me that F-Spot is awesome, that F-Spot is great, that it is the best Linux photo manager. I no longer believe you. From now on F-Spot is not getting anywhere near my photos. I’ve written about you before but I take all the good things I said then back. I was younger, more impressionable, and foolish. But those are just excuses. The fact is I was wrong. Yes, you appear to have some nice features, but your core has some rotten bits and I don’t eat rotten apples (even if only bits of them are rotten), I throw them away.

Goodbye,

Daniel Bartholomew

</rant>

Thank you for your order for the system XPS 1340. Unfortunately we’ve exhausted the supply for this item and can no longer fulfill your order. This message is to advise you that your order has been cancelled.

We apologize for any inconvenience this may have caused. We truly value our relationship and reputation with our customers. Please be assured that we are working hard to avoid similar issues.

As you may have noticed, Dell specifically indicates on our web pages, catalogs, advertising and order-confirmation that offers are subject to change and that Dell reserves the right to cancel orders arising from pricing or other errors.

Evidently it takes Dell nearly two months to discover they actually don’t have an item that is still listed for sale on their website!

Unbelievable.

Update:

I’ve checked and the Studio XPS 13’s with Ubuntu which Dell are selling now are different. Among the differences between the laptop I ordered and the choices available today are the following:

• Slower processors available and fewer to choose from.
• No Bluetooth option

There are probably others. Ok, so I can’t re-order the laptop I had ordered originally even if I wanted to. Fine. It is interesting to note, however, that these limitations are only for the Ubuntu version of the XPS 13. the Windows versions enjoy more processor choices including faster processors, the bluetooth module, more RAM, more colors and finishes, and so on…. In other words, Dell is pawning their junk off on customers who want to order a laptop with Linux.

This is not only unbelievable, it is also unacceptable.