Sun Apr 20 13:09:47 PDT 2008

(permalink) (comments)

Sat Apr 19 14:47:03 PDT 2008

As Project U-14 draws to a close, I've been spending a wonderful couple of hours on the couch playing with my laptop while Arlo naps.

Here's what I've been doing:

• Tracked down a bug that in gpsbabel that would make it crash if you gave it no filename to process. Turned out it was fixed late last year, and the new version will be in Lenny, but that was okay; the practice was good, it didn't take too long, and it turns out both the developers and I came to the same conclusion. I hope they know what they're doing, at least. :-) I'm unsure if I should file a bug in Debian or not; Lenny's coming soon, and I'm not sure of the usual practice in this case.

• Actually began work on Project U-13; I'm trying out fai-cd, rather than GRML. GRML's nice, but it's a way non-stock Debian install by the time it's done, and I'd like to stick as much as possible to stock Debian (OS of the OElder Goeds). We'll see how it goes.

• Read about how Dan Fucking Kaminsky managed to Rickrolled Facebook thanks to nasty DNS hijacking (similar to Verisign's Site Finder) by Earthlink and Comcast. No copy of the presentation up on his site, from what I can see, but I'm looking forward to it.

• Eating chocolate chip cookies my wife made. Yum.

(permalink) (comments)

Mon Apr 14 15:14:27 PDT 2008

Heads up for those of you using Blastwave and CUPS: after upgrading to the latest stable version, printing stopped working for me (and a few users :-). I eventually tracked it down to the movement of two files: suddenly

/opt/csw/lib/cups/filter/pstopxl
/opt/csw/lib/cups/filter/pstoraster

were moved to

/opt/csw/lib/cups/pstopxl
/opt/csw/lib/cups/pstoraster

resulting in many error messages like Unsupported format text/plain! and Hint: is ESP ghostscript installed?. Moving them both back into place and restarting CUPS fixed things just fine.

According to Bacula (yay Bacula!) both files were in the right directory as of last night, and Blastwave's file list for Ghostscript shows the new location for these two files. A bug has been filed.

(permalink) (comments)

Wed Apr 9 11:32:25 PDT 2008

This is one of the few things that would make me consider moving to the US right now.

(permalink) (comments)

Fri Apr 4 14:04:10 PDT 2008

There are always timesinks at a job: the things that suck up all your spare time, that interrupt what you're doing and force you on to something else. They're urgent, or they're complicated, or they're obscure and you only ever touch them every six months. If you're really unlucky, they're all three. They drain the life from you; a good day turns shitty, and an already-shitty day becomes nigh-unbearable.

The website is one such timesink at my current job. It's a veritable Grand Canyon of different technologies, databases, and code. You can examine it and, like a geologist, date particular pages or code with great accuracy, judging by clues like composition, surroundings, indentation patterns ("Oooh, K&R crossed with…crack?"), and previous experience. When an Urgent Request for Web Changes comes in (and they're all urgent), figuring out how to do it means figuring out how that particular page was generated in the first place: static? dynamic? CMS? And then you have to figure how you can meddle with it: logging into Mambo, the CMS of the damned? If it's static: does the URL map nicely to the filesystem, or is there a hidden Apache Alias directive somewhere? Do you have permissions to open the file, or will it take sudo to chown it, or another nagging email to a coworker to please check their changes into RCS? And if, God help you, it's dynamic…but no; that mess of spaghetti should stay down. There's no sense bringing it up again simply for prurient purposes.

Sunray terminals are another timesink. When they work they work very well. I like the energy-saving aspects of it — both electrical and my own; one machine to manage is always better than 40. But when they don't work, it's a pain. Has a session become wedged? Is it GNOME's fault? Has Adobe Acrobat decided to eat up all the CPU again? If so, is that worse than the security holes that remain unfixed in the later version? Why is Solaris 10 randomly not sending RST packets when it receives a SYN on a port it's not listening on? (If anyone has any ideas, please let me know.) Has a cheap switch, installed because no one believed that an office meant for one might someday hold four, gone off its meds again?

These things make me throw up my hands and and curse my fortune. I have no one unfortunate enough to be my subordinate, so it's up to me to hack and slash through the possibilities until it's finished, or at least put off for another day.

But LDAP is worse.

When it works it works very, very well. Failover works, replication works, and an account created here zips there without a moment's thought. But when it fails, it's urgent and complicated and obscure all at once, and sometimes in degrees polynomial.

At last count we have four different master-master replicas, running three or possibly four different versions of Sun's Directory Server (under six different product names, no less). There are replication agreements spanning versions that aren't even supposed to tolerate each other's existence, using two different encryption protocols and NetBEUI. Two completely different "helpful" management tools vie for our attention, lacking only flash plugins to trigger seizures. Only one server can be poked or prodded with a command line tool. Diagnostics are by turns nonexistent or endearingly fickle.

To be fair, the vendor documentation is vast and makes fine kindling, though its promise to fully document error codes like error 457758854b: BER error 45775885b4 is best regarded as a bitter joke by a jaded software engineer who died alone, unloved and without stock options. (Our own documentation is marginally better: no carbon is released when it is destroyed.) Thus, keeping track of ACLs (say), and exactly which unholy wrath you will invite upon your head should you make a mistake when granting or revoking privileges to read a particular entry, means digging through half-remembered conversations, drunken Google searches, year-old notebooks and a quiet, solitary introspection normally reserved for contemplating your own impending doom.

On top of everything else, LDAP encompasses everything, or nearly so. Email routing, website privileges, database access, even TCP checksum computation: all are kept in, or depend on, or just like to hold hands with, LDAP. It's enough to make me wistful for the good old days of NIS.

In a few minutes I am going to go back to work and try to figure out why a new account has stopped, in mid-replication, halfway between $UNIVERSITY and $OTHER_UNIVERSITY. It will take me the rest of the afternoon. I will use words that my own son does not know I know. And I will come out of it shrunken, withered, beaten down and humble.

(permalink) (comments)