mahiwaga

Now, granted, I’m no impartial observer. I’ve hated Windows since the 1998 iteration, and haven’t looked back. I used Linux as my primary OS from 1999 to 2002, then finally ended up buying an iBook and switching to Mac OS X (which was at version 10.1 at the time.) So I am confused by the outrage generated by drag-and-drop “installation” that is the method that Apple recommends to all developers. The article itself discusses the rationale for these guidelines, which I won’t regurgitate, but which I will refer to.

I do have to use Windows once in a while at work. But luckily I have no power to install or uninstall apps, and am glad to let the IT guys do their job. I do have a burning hatred for the pile of excrement known as IE 6, but unfortunately, one of the key apps we run depends on Active X, and the IT guys are (I think justifiably) paranoid about migrating en masse to IE 7.

Still, I was (until they stopped allowing writing to the Desktop, which makes it rather awkward to read research papers in PDF format, but that’s an entirely different rant altogether) able to download and install Firefox rather easily, since the installer allows me to arbitrarily choose any folder and doesn’t require write-privilege to C:\WINDOWS. Once I got into the habit of taking my USB Flash Drive with me everywhere, I just installed Firefox onto that.

But there are plenty of crappy Windows apps out there that require write privileges to C:\WINDOWS. And many of their installers have no way of specifying an alternate directory from which to run. Personally, I think this sucks.

In those barbaric pre-Windows days when I ran MS-DOS 4.01(!), I grew into the habit of creating my own custom file system hierarchy. C:\UTILITIES was in my PATH and held all my commonly used utilities, like PKZIP and grep. C:\WORDPRO contained WordPerfect and MS Word 5.5 for DOS. C:\PASCAL contained Turbo Pascal 7.0, which was my language of choice at the time. (Of course, there was GW-BASIC, and with MS-DOS 5.0, QBasic, but you couldn’t really write command-line utilities with those.) And of course, there was C:\GAMES.

So when Windows 3.0 forced me to stick all my crap in C:\WINDOWS, that made me unhappy. I tried to fight it as much as I could, but in the end, I gave up. Worthless apps, their directories, and their DLLs accumulated as I upgraded to Windows 3.11 and then eventually Windows 95, and very quickly DLL hell forced me to reformat and reinstall. Little did I know that this would become standard procedure for dealing with those damned BSODs.

My experience with uninstallers have pretty much been mostly unhappy ones. They’ve deleted DLLs I needed to run other apps. They’ve munged my registry so that I couldn’t easily boot back into Windows. They leave all sorts of worthless cruft all over the place. In an era where 120 MB of hard drive space was capacious, all those random useless files made a big difference. Especially since a 4-byte long file would consume an entire cluster. The thought of all those hours I wasted pruning my C:\WINDOWS directory to gain a few megs of hard drive space makes me feel nauseated.

But the back-breaker was DLL hell. I think this is the main reason why I hate Visual Basic and anyone who uses it as their primary development language. VB apps proliferated like E. coli in a Petri dish, and each app thought it would be best to install their own version of key DLLs, frequently rendering my system unusable. (Can someone tell me if they finally decided to do DLL versioning in Vista?) Random crashes from old and incompatible DLLs made me scared to install new programs. Although I guess it wouldn’t really matter all that much. The next reboot-and-reinstall cycle was only a few days away anyway.

Eventually, I grew weary of it, wiped my hard drive, and installed Red Hat Linux 6.0. Granted, it took me about a week to get PPP working and get back on the Internet, but installing X and Netscape was actually not too bad. I would break my system frequently by screwing around with configuration files, but I figured that if I had to deal with frustration, at least I was learning something.

Interestingly, it was Windows that made me decide to get a Mac. I figured I needed to get a laptop, but in 2002, there were very few laptops that would actually run Linux reasonably well. And the idea of buying an x86 laptop and have to pay for Windows, even if I wanted to run Linux, made me sick. So it was inevitable.

Now packaging systems are all well and good. I wrestled mostly with RPM back in the day, and these days I mess around with the apt-get-derived Fink Project (a system of ports of open source packages to Mac OS X) There is great satisfaction in being able to confidently uninstall an app you don’t want anymore, despite its files being scattered across the multiple directories of the file system hierarchy standard. A single command and it’s gone. No obsolete dynamic libraries to worry about. No cruft you need to get rid of manually, except maybe in your home directory.

Still, you can easily run into dependency hell, particularly if you downloaded stuff from third-party repositories because you had the burning need to run bleeding-edge software. You could avoid all this if you stuck to your distribution’s standard repo, but there was a lot of cool stuff you’d be missing.

The other solution was just to roll your own. Write your own spec files and build your own packages. Nice if you’re willing to do it, but probably not newbie-level kind of stuff. While the standard UNIX incantation should be easy enough for a newbie who doesn’t have a phobia of the CLI, the problem with ./configure; make; make install is that you just can’t easily uninstall that.

So: the concept of bundles. Like most of the nice things about Mac OS X, this was actually already a feature of NEXTSTEP. Everything you need to run an application is stored in the bundle. Don’t like the app? Toss it into the Trash Can. Or type rm -rf Random.app if you like. No harm, no foul. No accidentally deleting system-critical DLLs or trashing the registry. No having to uninstall all the apps that happen to depend on the library you want to get rid of.

In other words: simple.

Now you may wonder just how efficient this is, to require every single app to contain every single library that it needs to run. In terms of disk space, not very. But when the smallest hard drive you can buy on the market is about 300 GB, who really cares?

In terms of RAM, apparently the OS is smart enough to recognize when a required shared library is already running and to make sure that it’s actually compatible with the app. So: most of the benefits of shared libraries. None of the potential for versioning disasters.

If you’re telling me that dragging an icon into your Applications folder (which happens to be standard in every Finder window, and as many have pointed out, is usually symlinked in the DMG file itself) is more complicated than running through an opaque installer, then clearly your definition of “complicated” does not coincide with mine.

In the end, I think it’s just a culture of groupthink amidst most Windows users, given that they happen to be mostly in the corporate sector. There is something “official” about an installer. It makes people feel like your app is legitimate. That the developers know what they’re doing, and who are we to question the developers? Never mind the fact that it’s all too easy to perform nefarious deeds in the name of installation. Or that most installers are putrid piles of feculent vomit that generally do the wrong thing and end up violating the integrity of your OS (and Mac OS X does not, by any means, escape this tendency.)

These are the same guys who will turn around and bend over and pull their pants down just because someone flashes a badge.

Although I guess it does explain why America is as fucked up as it is, but, again, that’s another rant entirely.

I can’t seem to get over Snape’s forlorn and hopeless devotion to Lily. On one hand, it’s really sad and pathetic. On the other hand, it’s heart-wrenchingly awesome.

In a way, the last thing Snape sees before he dies (quite horrifically and with much gore) is Lily’s eyes.

I suppose the thing that really gets me is that I can relate.

Carrying a torch for a lost cause for 10+ years? (And in Snape’s case, it really is a lost cause, considering that the woman he loves is dead.) Sure. It happens. Like I said, it’s sad and pathetic.

Sacrificing your life—not just dying, but giving up your every waking hour as a sacrifice—in the name of your unrequited and yet enduring, impossible-to-quench love? Oh, man.

I can’t wait to watch this part in the movie theaters, in three years or so. I hope they don’t cut it. This entire scene should be perfect.

In case you haven’t noticed, I’ve once again changed blogging engines. This change differs from previous migrations in that I actually imported my old posts. Of course, I haven’t sifted through the old posts yet, and I’m pretty sure a lot of them are pretty broken. I can’t believe I wrote 400+ posts in the past year and a half. Can you imagine if I actually dedicated this time to writing a novel or a book of poems instead?

I tried installing Typo about a year ago, and I eventually got it to work, it was painfully slow. So I slogged on with Wordpress which is actually a really good blogging tool that seems pretty easy for newbies to use.

There are, however, two problems I ended up having with Wordpress: (1) it is painful to write custom themes and (2) PHP is an ugly language. The two problems are not unrelated.

I admit, Perl is also an ugly language, but it’s not trying to be a templating language at the same time, either. (You have to install extensions for that sort of madness.) Which makes sense, since PHP uses a lot of Perl concepts. And while Ruby also owes a lot to Perl, ruby can actually be quite elegant in a non-obfuscatory kind of way. The difference between Perl and Ruby is that in Perl, you can write almost any program in one line. In Ruby, you can also write almost any program in one line, but you can also actually read it, too.

The other thing was that I had the vain hope that using embedded Ruby would allow me to avoid the dreaded nested angle-brackets. Alas, that is not the case, although if I want it badly enough, I can always use embedded Ruby to actually build an XHTML element so that I don’t have to nest angle-brackets, which is actually how XSLT handles things. Maybe you can do that in PHP, too, but I really got tired of trying to separate logic from presentation. And the prospect of duplicating code for the index view and the single post view was quite daunting.

With Typo, you can just deal with the templates, since all the logic is really in Rails itself, and what elegant logic it is too. You can create beautiful things when you don’t worry about CPU cycles, you know? (Did I mention that Rails, and therefore, Typo, is slow?) Thanks to partials, you can avoid redundancy. (Although I feel that XSLT manages to avoid redundancy, too, and it’s XML-compliant from the get-go, although most sane people I’ve met don’t care too much about that as long as the eventual output conforms to XHTML and XML standards.) No editing multiple template files for me. Just zoom into the spot and go to it.

But, anyway, we’ll see how things go. The only thing that creeps me out is the fact that using an RDBMS as storage leaves me vulnerable to lock-in. Mostly because I’d rather not (re)learn how to interact with an RDBMS, and screwing around with SELECT statements seems to be the only foolproof way to actually get my data out of there in the eventuality that I want to move to yet another blog engine. Luckily, most of the major players have conversion scripts, although, as you might notice (for now), the Wordpress 2 to Typo converter isn’t exactly a finished product.

On the other hand, I have yet to try to migrate the files from my own hand-rolled static blog engine (mainly because I accidentally nuked the source files a long, long time ago and will therefore have to scrape raw HTML. Bleh.) Moving the blosxom stuff will probably be easier. It’s been trivial to convert a blosxom blog entry into an actual XML document. Now all I have to do is learn XML-RPC (yay) and the MetaWeblog API, and then I’ll be golden. (Yeesh!)