Well, the crunch time is now coming and the real server move is about to happen this week (at the end of the March the old server will go offline forever, so the move has to happen this week, ready or not). So this will most likely be my last post ever to this weblog.

The forums are already in read-only mode, and I'm about to shut down the bug tracker too shortly so that I can do the final export of all the records and move them into the database on the new server. If you had an account on the old server you'll automatically have one on the new server too, although you will need to reset your password (I couldn't transfer across any passwords because none of them were stored in plain text, and rightly so of course).

At some point during this week email might temporarily go down, hopefully only for about an hour (delivery failures should be temporary), and the wincent.com domain itself will go down at roughly the same time too. When it comes back up we'll be running on the new server. If you make a purchase during that time you might have to wait an hour or two for your license information, but we'll soon be back to immediate automated delivery.

Keep your eye on my Twitter account if you'd like to be kept posted with updates; it will be my only avenue of communication during my brief stint in limbo:

• http://twitter.com/wincent

Just in case there is any interruption during the move, I've just opened a twitter account where I'll be posting updates along the way:

• http://twitter.com/wincent

Not really a twitter fan myself — I've always felt that the best place to post that kind of info is on my own weblog — but in a case like this it makes sense to have an offsite feed.

Unfortunately, most of the retailers in the US don't want to ship outside of the US. I found one who would: they quoted me over $160 shipping, plus $50 wire transfer fee (they don't accept foreign credit cards) and the cost of the mic on top of that for a grand total of $294. Ridiculous. That's 200€. Needless to say I'll be holding off until I find a better option.

My past experiences ordering computer components from the US have always been excellent, but it seems that things are different in the audio realm.

Update

Found a reasonably priced European supplier.

One of the things I'll be doing is replacing the teetering stack of disparate applications that I'm currently running (a mix of applications — Movable Type, UBB.threads, Mailman, Bugzilla, MediaWiki and a number of custom scripts — written in a mix of languages — Perl, PHP, Python and Ruby) with a single unified application, a custom job written in Ruby and built on Rails.

I'm taking the opportunity to greatly simplify things in the "Web 2.0" spirit (ugh, how I hate that term; but I've started to use it because it's lost some of its ridiculous hype feel and has now come to mean a set of widely understood characteristics). And it's actually quite a liberating experience. Each chunk of code that I delete makes me feel lighter, freer.

A similar thing happened with respect to the localization system. It was one of the first things I developed. It was elegant. But then I realized that I didn't need it. Out it went. There as no sense in building in the ability to localize the application "just in case". And doing localization well isn't easy. If it can't be done perfectly then I don't think there's any sense in doing it at all. I mean, I could take an English string like:

The requested %s could not be found.

Where the "thing" might be "resource", or "page", or "bug report". Whatever. I had machinery for translating that into Spanish:

No se ha encontrado el %s solicitado.

The trouble is that "page" in Spanish is feminine, while "resource" is masculine. You can't just drop in a different word without also changing the surrounding words to match its gender.

So I could have a simple but imperfect localization system which I might use one day, or I could write a massively complex and flexible system that handled all the thorny edge cases but at a cost of speed and complexity, or I could just rip out the localization system entirely and worry about it when and if I decided I ever needed it. I opted for the latter.

In the case of the weblog, I got it up and running and then added comments support. Then I realized that I don't necessarily want comments on my weblog. I've never used them before and I shouldn't start using them now just because that's what everyone else does. I'm not really interested in holding conversations with random strangers, in public, and hosting it on my own server. I didn't actually rip out the support for comments because I can imagine posts in which I will want to solicit comments, but I did turn comments off by default.

Same for the issue tracker: Bugzilla is horrendously powerful, but a lot of users found it scary. I just threw out the ability to define custom statuses (things like "CLOSED (WORKSFORME)") which I had mindlessly replicated because that's what I was used to from Bugzilla. No. Think about what you actually need and then write the tool that gives you exactly that, nothing more. For me that's the whole point of Rails. It's supposed to make it easy to quickly implement your ideas. Take advantage of that characteristic to write lean custom apps that do what you ask them to, rather than always trying to write the ultimate in reusable, flexible, generalizable code.

The translator itself consists of a hand-coded parser written in C paired with a scanner/tokenizer/lexer generated from a grammar specification.

Up until now the scanner used a ANTLR-generated lexer using the "C target" (although ANTLR itself is written in Java, it can target multiple languages, including C). The C target is the current speed king among ANTLR targets and is likely to remain so for the foreseeable future. It too is engineered with speed in mind and is quite frugal with resources (for example, when emitting tokens it maintains pointers into the input stream rather than making a copy of the substring for each token).

And the results were quite snappy. But for some time I've had the sneaking suspicion that a Ragel-generated scanner would be faster. I suspected this even though ANTLR uses all sorts of clever tricks like trying to predict which path to take and only backtracking if prediction fails.

You see, Ragel generates simple state machines: the building blocks of regular expressions. Whereas ANTLR is like a complex and unpredictable magic clock, Ragel state machines are totally transparent and predictable. I've spent many months trying to use ANTLR on a number of different projects and in every case except for this wikitext translator I've ended up putting it aside because I couldn't divine the incantations required to make it do its black magic. Ragel, on the other hand, is absurdly simple. You can build complex things out of it, but the base components are easily comprehensible. Compared to ANTLR, Ragel is incredibly easy to learn.

Why Ragel should be better

So I suspected that Ragel might be a bit quicker. No amount of prediction in a predictive lexer can beat a pure state machine, which by definition is going to run in constant time because it simultaneously explores all possible paths. When you add backtracking into the mix (as a result of trying to always favor the longest match) then you lose your constant time but it should still be fast because the state machines themselves are so efficient.

One of Ragel's key advantages is that there is absolutely zero internal function call overhead. This is because the are no internal function calls; everything is done with basic C control structures (for loops, gotos, case statements and the like). Once you're in the Ragel machine you can stay there until you've scanned all the text.

Another advantage is that it's trivial to do everything in UTF-8 using Ragel. ANTLR is a Java tool and so it uses UTF-16, which means twice the memory most of the time. The C target makes the unfortunate decision of using the obsolete UCS-2 encoding (basically the same as UTF-16 but without surrogates which means that it can't represent all Unicode codepoints and is no longer recommended for use) because that's what maps most easily onto UTF-16. I looked at overriding it to use some other encoding but it looked non-trivial and error prone, and likely to break with every new ANTLR release.

Using UTF-8 with Ragel, on the other hand, should be much more memory efficient. 99% of all input is going to belong to the ASCII subset of UTF-8 anyway, which means that in most situations we'll be using exactly half the memory to process our text. We'll also be avoiding cumbersome and wasteful conversions back and forth between UCS-2 and UTF-8 (all input you get from Ruby/Rails is going to be in UTF-8). When we do need to go beyond ASCII it should still be relatively quick. We'll take only a small speed hit because the kind of trivial bit-shuffling required to deal with multi-byte UTF-8 characters is exceedingly fast on modern CPUs.

And apart from performance I think I just wanted to use a tool that I actually understood, and that had a fathomable, deterministic relationship between the grammar you fed in and the recognizer you got out from the other end. And when I say "fathomable", I mean "possible to be understood by a mere user rather than only the author of the generator himself!". So I was tempted to switch to Ragel even if the performance gains where minimal or even non-existent.

Let me give one quick example of how ANTLR can be a difficult beast to tame. Consider this rule for recognizing URI tokens:

URI : HTTP URI_CHARS (SPECIAL_URI_CHARS URI_CHARS)*;

This basically says you want to recognize as a URI a sequence that looks like "http", following by a bunch of "URI chars" (things like letters, numbers, and so on). And you also want to include "special URI chars" (things like the period) provided that they are followed by more "URI chars".

This is what allows you to correctly tokenize sentences like the following:

My website is http://wincent.com/.

You don't want that last period to be included in the URI when you turn it into a hyperlink, but you do want the first period to be included because it's followed by "com".

Well, it turns out that the above rule won't work in ANTLR. Upon seeing "SPECIAL_URI_CHARS" it will try to be clever — too clever in this case — and predicts that what it is about to scan is in fact "SPECIAL_URI_CHARS followed by URI_CHARS". If you feed in a text like the above ANTLR will throw a recognition exception because its prediction turns out to be incorrect.

So you have to write the rule like this using a predicate:

URI : HTTP URI_CHARS ((SPECIAL_URI_CHARS URI_CHARS)=> (SPECIAL_URI_CHARS URI_CHARS))*;

That last bit says, "recognize SPECIAL_URI_CHARS followed by URI_CHARS, but only if you've first checked to see that there really are SPECIAL_URI_CHARS followed by URI_CHARS". In other words, ANTLR scans ahead, and then goes back and rescans the same piece of text again.

It would be nice if you could use ANTLR without having to know these little tricks. But even if you are fortunate enough to know them, you're still in a less than desirable position; backtracking in the event of a failed match is expensive, but this kind of backtracking and re-scanning in the case of a successful match seems just plain wrong.

Now let's look at the equivalent rule in Ragel:

uri = http uri_chars (special_uri_chars uri_chars)* ;

I think that speaks for itself, but I'll make an additional comment anyway. You can look at such a rule and know exactly what kind of state machine it maps to. Entirely predictable, and no black magic or fancy prediction logic under the hood.

The numbers

The initial numbers are in and I couldn't be happier. Ragel has exceeded my wildest expectations.

                                user     system      total        real
short slab of ASCII text    0.180000   0.000000   0.180000 (  0.182539)
short slab of UTF-8 text    0.320000   0.000000   0.320000 (  0.330065)
longer slab of ASCII text   2.740000   0.000000   2.740000 (  2.792006)
longer slab of UTF-8 text   5.000000   0.000000   5.000000 (  5.072432)

Each line corresponds to tokenizing a string 100,000 times. The ASCII examples are pure ASCII and represent the "best case" scenario for the scanner while the UTF-8 ones are for a "worst case" one in which the input text is swelled by 34-46% by multibyte characters.

If you look at the slow-down caused as you add more and more multi-byte characters you see it grow proportional to the number of additional bytes. That is: you're looking at a basically constant cost per-byte, regardless of the composition of the input.

So what are we seeing here? 8.24 seconds to tokenize 352 megabytes of input text, which equates to roughly 42.72 megabytes per second on my lowly iMac with its 1.86 GHz Intel Core Duo.

Here's the initial version of the Ragel scanner (although it may have evolved somewhat by the time you read this). As you can see, moving to Ragel comes at a small cost: you're running much "closer to the metal" and concerning yourself with pointers and token structures and the like. In a sense this is one of the things I most like about Ragel; I can actually see what it's doing and control it in every aspect: it's enigma-free.

But the cost brings a benefit too. Check out the corresponding numbers for the ANTLR scanner:

                                user     system      total        real
short slab of ASCII text    9.400000   1.870000  11.270000 ( 11.308913)
short slab of UTF-8 text    8.620000   1.880000  10.500000 ( 10.551956)
longer slab of ASCII text 132.380000  19.690000 152.070000 (153.296844)
longer slab of UTF-8 text 116.280000  19.510000 135.790000 (136.788652)

As you can see, Ragel wipes the floor with it. While ANTLR doesn't suffer any speed hit at all when you start using multibyte characters, its absolute processing speed is nearly 38 times slower than that of Ragel. It tokenizes the same input text at a rate of about 1.14 megabytes per second. That sounds pretty good, until you compare it to Ragel's 42+ megabytes per second.

A side note: when I originally published this article I reported figures for Ragel that showed it was "only" 10 times faster than ANTLR; turning on fast goto-driven FSM with the -G2 switch (as opposed to the default table-driven one) yielded a basically four-fold increase in speed. Now this really starts to get into the "mind-boggling" zone, how Ragel can produce scanners so much faster than the equivalent lexers in ANTLR's fastest target language. Can internal function call overhead explain such a large gap?

To be fair to ANTLR, not all of the time in the benchmark is spent inside the ANTLR lexer itself; some of it is spent converting the input from UTF-8 to UCS-2 before feeding it in to the lexer. Seeing as we're only testing how fast the lexer can spit out tokens, we let it off we don't worry about converting back to UTF-8 at the end (in the real, non-benchmark scenario, that is a penalty that we'd have to pay).

Is it fair to penalize the ANTLR lexer in this way? I think so; it is asking for UCS-2 input after all, so if that's what it wants...

And to put things in perspective, 10% or less of the time in those numbers is due to the encoding conversion. As I said above, modern CPUs are well suited to doing the basic bit-shuffling required to convert to and from UTF-8, and the benchmark is using a hand-coded converter that I wrote in C.

The following table shows the performance of the custom converter (prefixed with internal) on the same type and quantity of input. The lines prefixed with iconv are for the same conversion, but done using the Iconv library which comes with Ruby. As you can see the internal coding converter is much, much faster, and is really only responsible for a tiny portion of ANTLR's performance problem:

                                           user     system      total        real
iconv    (short ASCII to UCS-2)        0.520000   0.010000   0.530000 (  0.531411)
iconv    (short non-ASCII to UCS-2)    0.590000   0.000000   0.590000 (  0.585507)
iconv    (longer ASCII to UCS-2)      10.770000   0.020000  10.790000 ( 11.009323)
iconv    (longer non-ASCII to UCS-2)  14.570000   0.030000  14.600000 ( 14.710083)
internal (short ASCII to UCS-2)        0.110000   0.000000   0.110000 (  0.106386)
internal (short non-ASCII to UCS-2)    0.150000   0.000000   0.150000 (  0.147468)
internal (longer ASCII to UCS-2)       1.300000   0.000000   1.300000 (  1.309406)
internal (longer non-ASCII to UCS-2)   3.700000   0.010000   3.710000 (  3.717417)
iconv    (short ASCII to UTF-8)        0.520000   0.000000   0.520000 (  0.544404)
iconv    (short non-ASCII to UTF-8)    0.580000   0.000000   0.580000 (  0.592008)
iconv    (longer ASCII to UTF-8)      11.810000   0.010000  11.820000 ( 11.858008)
iconv    (longer non-ASCII to UTF-8)  14.840000   0.020000  14.860000 ( 14.909430)
internal (short ASCII to UTF-8)        0.130000   0.000000   0.130000 (  0.133868)
internal (short non-ASCII to UTF-8)    0.180000   0.000000   0.180000 (  0.179611)
internal (longer ASCII to UTF-8)       2.550000   0.010000   2.560000 (  2.586608)
internal (longer non-ASCII to UTF-8)   5.280000   0.010000   5.290000 (  5.327419)

Future

The exciting part is that this is only the beginning. It's commonly held that in any kind of parsing or transformation it's the lexing that takes most of the time, so in one fell swoop I've optimized the biggest performance bottleneck in the transformer.

At the moment I've just made a scanner which spits out tokens one at a time, just like the ANTLR one did, but there will be a further performance improvement when I drop this in in place pf the ANTLR lexer because I'll be able to drop all of the tedious intermediate conversions to and from UCS-2 that I'm currently having to do in the parser.

Further down the track their is scope for even more optimizaton. Ragel machines can have actions embedded at them so I may even eventually decide to dump the whole "lex-then-parse" model entirely and just do all the transformation from inside the lexer, thus shaving off one more piece of overhead.

Ideally my host (Rackspace) would have slotted in a drive with a pre-installed OS on it, brought the server online so I could migrate my data over to the new drive and then rebooted from the new drive. I thought they use identical, standard hardware configurations to allow precisely this kind of thing.

So you'd be looking at two reboots, one of them accompanied by a few minutes of downtime to physically install the drive, and then a period in which some services didn't work properly because they'd need to be tweaked, set-up and configured only after booting into RHEL 5 for the first time. But overall impact to your website visitors would be fairly minimal. Once all that was done you'd be looking at another quick powercycle while they shut down the server to remove the old drive (you don't get anything for free from Rackspace).

I wonder how often Rackspace does this type of upgrade. As it was, they were suprisingly slow to offer the details of the procedure and offer options, and that's what makes me wonder.

After quite a bit of deep thought I decided that instead of staying with Rackspace I'd move on to another company. I've chosen INetU.

The good

Rackspace has a great network. They have a great track record, with the exception of the big data center incident last year. I know some people decided to leave Rackspace because of that incident; personally, for me that's not the reason I'm leaving. I know that even the best companies can make mistakes occasionally and I trust that Rackspace has learned their lesson.

Their support is indeed "fanatical" most of the time, if you measure it in terms of response time. For example, whenever I needed SPF records added to my domain names I could open a ticket and expect that the records would be updated promptly; most often in only a few minutes.

Likewise they have automated server monitoring in place and if a service stops responding they log in, investigate and fix it if possible. In general it seems they responded within a few minutes to such alerts and had solved the problem a few minutes later.

The average

However, I don't think the support is "fanatical" as it really could be. Response time is important but it is not the be-all-and-end-all. The "solution" to these alerts usually just meant restarting Apache. No attempt at identifying the real cause was ever made. When they did offer a cursory diagnosis it was wrong; I am not a professional system administrator but I was able to investigate and determine the real cause without too much effort.

It seems that their goal is to just close tickets as quickly as possible, but when you're paying several hundred dollars per month for managed hosting I expect a little better than that. We're not talking about bugs in third-party software or bizarre non-standard configurations; we're talking about the kinds of problems which can crop up in any bog-standard Linux box.

The bad

So why were my Apache processes dying every week or month? It turns out that the load was getting too high during the daily backup and the server was unable to handle all the incoming connections. It didn't happen every day or even every week, but when the backup coincided with enough load from other sources it was enough to make Apache temporarily unavailable to new connections, including the Rackspace monitoring service.

Turning off the backup is not an option, so the real problem here is that the machine is underpowered.

And this is where being with Rackspace starts to feel uncomfortable. Let me explain. According to Rackspace, the monthly fee is for a "solution" which includes the hardware and the support. The "solution" does not include up-to-date hardware, it includes only the hardware that was provided when you first signed the contract. After 2.5 years the value-for-money (performance-per-dollar) of the supplied hardware starts to look worse and worse. If the hardware included in your "solution" doesn't do what you need it to do then you must upgrade to new hardware at your own expense. The set-up fees and ongoing monthly costs for these hardware upgrades are utterly exorbitant.

As an example, I was quoted a $75 setup fee to install a 250 GB hard drive, and an ongoing fee of $50/month for the pleasure of using the new drive. Note that this is not an additional drive; that price is for removing the old 80 GB drive and replacing it with the larger one. This is ridiculous: the average price for a 250 GB SATA drive is now about $90, yet Rackspace would like to charge me $600 per year for the privilege of having one.

And you have to wonder why they even offered me this as an option when I said I wanted to upgrade to RHEL 5. I don't come close to using even half of the 80 GB drive I already have, so why would I want to upgrade to a larger one? When they make this kind of unattractive offer that addresses a problem the customer doesn't even have (lack of diskspace) it makes them seem totally out of touch with their customers' needs.

Let me indulge in another example. Another way of getting to RHEL 5 that they offered me was to set up a completely new server. I'd have to pay a $200 setup fee as well as $60 per month more than I am already paying (the new server would have a larger harddrive and a marginally faster processor than I have now, but it would still have the same amount of RAM — 1 GB — which is arguably the most important resource a web/database server can have). I just can't see the value for money in this offer.

INetU

In comparison, what can INetU offer? I went to them and explained what my concerns with Rackspace were: in a nutshell, that you get locked in to aging hardware and an aging OS (in my case they provided me with RHEL 3 even though RHEL 4 was already out), and if you want to break out of that jail cell you can only do so at considerable expense. They don't seem to reward customer loyalty and being an ongoing client over a period of years.

INetU is a much smaller company than Rackspace and my current perception of them (still currently an outsider) is that they try harder. They describe their managed support level as similar or better than Rackspace's "intensive" support level (at Rackspace I was merely a "normal" customer, not an "intensive" one). My experience with their sales representatives was very positive. Basically they worked with me to iron out a contract that addressed all my needs and concerns. I got the impression that they were trying to provide me with a solution that was truly satisfactory to me rather than just getting me to sign a contract as quickly as possible.

I did give Rackspace a chance. I told them what INetU was offering and said that I didn't want to leave Rackspace, that I'd much rather continue with Rackspace if they could just address my concerns about hardware and OS lock-in. But all they could offer me were $90 hard drives for $600/year and no ongoing solution to the lock-in problem.

So I'm off to INetU. Dollar-for-dollar, they offer beefier hardware and more IP addresses than Rackspace, they promise better support (which I'll be able to report on when I officially become a customer of theirs; so far all the communication has been excellent), and they provide exactly the kind of hardware upgrade path that I was looking for. Basically, they understand that when a customer pays several hundred dollars per month for a "solution", they want that solution to include up-to-date hardware. I'm not talking about CPU upgrades every six months; I'm just saying that every three years it's most definitely time to migrate to a new box, and you shouldn't be penalized for doing that kind of migration. Instead, they should recognize your loyalty and help you to make the move.

In the case of INetU they can set up a new server for you, put it online, and let you keep the old one online for 30 days while you migrate the data over. When you're ready you flip the switch. Effectively it amounts to a free month every three years, and a means of keeping your hardware up-to-date without incurring excessive expense and downtime. This is the way it should be. I believe this because for me "premium solution" actually really means "premium, up-to-date solution, today and tomorrow". This offer may not last forever, but I got it in writing because I explicitly asked for it, and it's basically the reason I'm moving. It's a nice way to start the relationship, with INetU specifically tailoring a solution that addresses my concerns.

So hopefully, this time really will be the last time I move hosting companies. The Rackspace server will be up until the end of February and the INetU one will be coming on line in the last week of February. I'll have five days of overlap in which to migrate all the data across before pointing the DNS at the new servers. As such, actual downtime will be zero — there'll be none at all — and there will probably be a day or two of hiccups where creases need to be ironed out on the new box (it is a new OS, after all).

Update: 13 February

Rackspace got in touch with me one last time to see if there was anything they could do to retain my business. It's a bit late for that seeing as I've already signed a new contract, but they did offer to keep my server online for an extra thirty days at no extra cost, just in case I have problems with my new host and decide to run back into Rackspace's open arms.

I don't anticipate having any problems with INetU, but I think this is nice gesture on the part of Rackspace. I've accepted their offer. A little bit of extra insurance never goes astray.

The average time between failures is dropping. Not long ago it was about one month, but now it's approaching three weeks, and if you look at the average over the last month the failures have been almost weekly.

Apart from the risk of damage to my data, I am starting to get sick of these Disk First Aid runs (during which the machine is unusable), which go especially slowly because Spotlight decides to reindex all of my volumes every time I have one of these failures.

On a tangential note: I received an email in response to my last post in which I complained about the lack of RAM in the low-end iMacs. It was pointed out to me that real-world RAM really is cheap nowadays (even if RAM from Apple is not). You can max out an iMac to 4 GB for a mere $100 at my retailer of choice (OWC), and for someone like me living in Europe and buying the RAM from the US you're still looking at only 85€ including international shipping.

Involuntary reboot stats to date

• Operating system version: 10.5.1
• Kernel panics: 7
• Hard resets: 18
• Total failures: 25
• Start of recording keeping: 21 May 2006
• Total days to date: 617 days
• Average time between failures: 24.68 days
• Uptime at moment of failure(s): a day or so

I was puzzled today to see excess SELECT queries whenever I saved a record. The queries were for attributes that were entirely unrelated to what I was manipulating.

I'll spare you the long story and cut to the chase. It turns out that these extra queries are generated by validates_uniqueness_of. I guess I should have known. The entire model gets validated whenever you save, even attributes that you haven't touched. I guess this makes sense.

Now, I am not really sure about the point of validates_uniqueness_of because it is vulnerable to a classic race condition; basically Rails checks "is this unique?" and if it is goes ahead and saves the record. Of course, in a multi-user application it's possible that what was unique a millisecond again is no longer so.

Basically validates_uniqueness_of can't provide you with any guarantees, and if that's the case then why bother using it? I had it in my app mostly for experimentation purposes.

The only robust way to approach this is to do what we always do when we have race conditions to worry about: go ahead and save the record and only if it doesn't work worry about what you'll do. In order for this to work you need to impose a database-level constraint which will cause an exception to be thrown if someone tries to create a duplicate (and of course, the database won't permit the creation of the duplicate to succeed).

Something like this in a migration should do it:

add_index :things, :attribute, :unique => true

Try to insert a "thing" with a duplicate "attribute" and MySQL will complain about a "Duplicate entry" and Rails will duly raise an ActiveRecord::ActiveRecordError which you can rescue and deal with appropriately.

If you're doing that then is there any point in keeping those validates_uniqueness_of calls? Perhaps. I guess if the probability of races is low then you can keep your application logic simpler by relying on validates_uniqueness_of for informing the user nicely that "that name is already taken", and rely on database-level constraints to handle the really nasty race conditions (and throw an irrecoverable error). I suppose it depends on how much traffic and contention you're expecting. If traffic is high and performance is a real issue then you might just want to get rid of the validation; it doesn't provide any guarantees and those extra queries will only slow you down.

Today we have the painters here painting all the rooms, which means that I've had to take the iMac out into the kitchen. As I've mentioned before, it has a wonky power socket, and this time it didn't want to boot up.

Several minutes of jiggling later I finally got the machine to turn on. Now I'm wondering which boot-up is going to be the last. One of these days the machine isn't going to power up.

Financially, I'm not in a position to buy a replacement yet. The cheapest model costs 1,169€ here but is handicapped with only a gig of RAM which would probably make it slower than this machine (which has 2 gig) despite having a faster processor (a 2 GHz Core 2 Duo as opposed to the 1.83 GHz Core Duo I currently have). RAM is very important for performance when compiling code in Xcode, mostly due to the amount of memory occupied by precompiled headers.

The top-end model would be a big improvement over my current machine — a 2.7 GHz Core 2 Extreme with 2 gig of RAM and a bigger screen (24" up from 17") and hard drive (500 GB up from 160 GB) — but it's out of my price range at 2,159€.

So really my only two options at this stage are to cross my fingers and hope that this machine holds up, or send it in for repair; and with the deadlines I have looming I just can't afford to be without this machine, even for a few days.

The regression was only in the development version and has never made it into a released version of Git, but I've been tracking the master branch for some time now (see "Tracking the Git maint or master branches") so I had definitely noticed the problem.

I'll be migrating to RHEL 5 (from RHEL 3). I don't have a firm date for the migration yet, and I need to do quite a bit of research before then about the best way to get all my data across. This will basically be a clean install on a new hard drive, the server should only be down for a relatively short interval, and then we'll come back on line and over the following hours I'll be transferring user accounts, mail, databases, software and everything else from the old hard drive to the new. So it will be quite intense, and most services will be interrupted for at least some of the migration. I expect to be transferring and configuring for several hours, possibly even the entire day.

One way to minimize the interruption would be to install the drive with the new system on it and migrate some of the data before rebooting, but I'm not sure how much time that will actually buy me, nor whether my host, Rackspace, would be prepared to do that (it would require them to install RHEL 5 on the drive in another machine, then uninstall it from that machine and reinstall it into mine).

I'm very happy about this because it means I will be able to gradually retire bits of legacy software and replace all of this with a single, lean, unified Rails application which handles everything for me (bug tracking, customer support tracking, forums, the wiki, and so forth).

Deploying Rails is a bitch by all accounts, but it's easier on RHEL 5 than it is on RHEL 3, (specifically, there are fewer pieces of additional software that you have to install, and you deviate less from the supported, auto-updated configuration). And once you've deployed it you've got one application stack to worry about instead of half a dozen.

As always I did a Disk First Aid run after the crash. This time there was a bunch of damage that needed to be repaired. HFS+: is the F for Farce?

Involuntary reboot stats to date

• Operating system version: 10.5.1
• Kernel panics: 7
• Hard resets: 17
• Total failures: 24
• Start of recording keeping: 21 May 2006
• Total days to date: 606 days
• Average time between failures: 25.25 days
• Uptime at moment of failure(s): a day or so

But I must confess, even though I am not in the market to buy any new Apple product right now, I am really impressed with the new MacBook Air. If I were to buy a laptop, this would be the one for me. I am not one of those people who wants their laptop to be their only machine; for these people the Air is not the right product. I'm a person who wants a portable to be portable; so for me the decision to leave out the optical drive is a very clever optimization. Ever since Apple dropped a 12" model from their line-up I've felt it was a gap. I still have my 12" PowerBook G4 (the aluminum one). It was a great machine and has never skipped a beat in all these years (over four years now, eons in computer time).

So if I were to buy a laptop, the Air would be the one. The most portable portable ever!

I've got the flu right now, so apologies for the voice.

Here is the commit where I integrate this procedure into Wincent Strings Utility.

Update

I've just seen this post on David Chelimsky's weblog that confirms that this indeed new for 3.8.0 and I wasn't just imagining it...

I currently make a bit of open source software available but also work on closed source stuff. If I thought i could make everything open source and still survive economically then I'd do it in a heartbeat. I suspect I'm not alone in feeling this way; as Brent Simmons recently said:

But I will say that, for me personally, this is a dream come true. Every developer wants to be able to work on the software they love, make a living at it, and give it to the world for free. Usually you get to pick two out of three — if you're lucky. Me, I get all three.

This very question came up on Slashdot yesterday. I'm gradually edging towards releasing more source, but it's a difficult path to tread. I'm probably still quite a long way off being able to go fully open, if ever. Think about it: if a company like Apple can't go all the way, how is the small operator going to do so?