I'm still alive, thanks for asking. Though it doesn't feel too much like it. The stress at work is rather improving than lowering. But I sort of managed to reach an important step last thursday finally with the bind-to-pdns transition we are doing, so I thought I could present me with some gifts. Interestingly I just were at the bank in the morning to withdraw my christmas money... So I thought I could go to the cinema again. The people with which I was in the cinema before didn't ask me lately to join them anymore, so I have to kick my ass myself anyway. So I drove to the cinema complex, and being not too late was able to go a bit shopping, too. I presented me with three (or four, because one was a double) CDs: Mike Oldfield "Ommadawn", Garbage "Bleed Like Me" and Kylie Minogue "UltimateKylie". Besides I usually prefer albums to Best Of Albums I thought the Kylie double CD was a good deal nevertheless. "Harry Potter and the Goblet of Fire" was the movie I watched, finally. Of course people who read the book will miss the Veela, the Leprechaun, Dobbie!! and various other things. But appart from the usual cutting you get with longer books the movie itself wasn't too bad. I really enjoyed it, especially because I met two friends right before going in and got the promise to go with them to Narnia today. Yeah! Friday was very special, too. I was invited to some christmas party, at viennAventura. I really enjoyed the evening, I fully support their concept. Take a look at the nice christmas flash Diana did for the website as long as you have the chance to!
After some glogg, helping to write a christmas picture story including the photo shooting and decorating their christmas tree with handdrawn glitter balls I went happily home. I took my dog out for a walk, and when we were around the corner I heard my cat cry for me! After a week being outside and almost already thinking of never seeing him again I heard him crying for me like hell! It was sooo great to hear him, I went over to him, picked him up and took him home with me again. Of course I wasn't able to do any work that weekend but only cuddle with him all the time. Fortunately for him he was in a very cuddly mood himself, too. ;) Guess he missed me too.

So the final implementation detail in the embargoing scheme is providing a tool to move stuff from the embargoed and unembargoed queues into the archive. The existing tool the security team use is called “amber” (after the inimitable Amber Benson). amber’s pretty simple: it takes a DSA number, and the .changes files you’re looking at; then asks for confirmation, accepts the packages into the archive, regenerates Packages and Release files, fills out a template advisory with details from the deb and mails that off, and uploads the files to ftp-master for inclusion in the next stable release. There are a few problems with that. One is it doesn’t allow for rejections. Another is it doesn’t provide the security team with the opportunity to edit advisories while the packages are being prepared. Another issue is that the entire program has to run under sudo with full archive priveleges. Enter “dak dsa” aka “newamber”. The new tool aims to do more or less the same thing, but with a little more style. First, it provides a small interactive interface, so that processing an advisory now looks like:

$ newamber DTSA-25-1 smb4k_*.changes
Create new advisory DTSA-25-1? y
Advisory: DTSA-25-1
Changes:
 smb4k_0.6.4-0.0etch1_alpha.changes
 smb4k_0.6.4-0.0etch1_hppa.changes
 smb4k_0.6.4-0.0etch1_i386.changes
 smb4k_0.6.4-0.0etch1_m68k.changes
 smb4k_0.6.4-0.0etch1_mips.changes
 smb4k_0.6.4-0.0etch1_mipsel.changes
 smb4k_0.6.4-0.0etch1_s390.changes
 smb4k_0.6.4-0.0etch1_sparc.changes
Packages:
 smb4k 0.6.4-0.0etch1 (alpha, hppa, i386, m68k, mips, mipsel, s390, source, sparc)
Approve, [E]dit advisory, Show advisory, Reject, Quit? 

Choosing edit will grab a copy of the template and run vi – the template will only be filled out when you approve the upload though, since the values might change before then. Accept will do more or less what old amber did; though instead of mailing the filled in advisory draft it’ll just leave it in the filesystem instead. Of course, running vi (well, $EDITOR) generally means you can get a shell too, so running the command with full archive priveleges is a bit much – at least if you’re trying to have any sort of granularity to your security regime, which was, after all, the whole point of this exercise. So instead of running the entire command as the katie user, “dak dsa” instead has to escalate its own priveleges, in this case using sudo and specific options, such as sudo dak dsa -A -- foo.changes to approve foo.changes. Fortunately sudo and the apt argument parser are cooperative enough to allow “dak dsa” users to invoke “dak dsa -A – *” as katie, and thus have only the very limited access we’re trying for. Obviously the above is taken from the testing-security team – it’s the same source and i386 packages, recompiled on other architectures by the security.debian.org testing autobuilders. It’s shown up a few flaws in the autobuilding for etch: (a) the amd64 autobuilder isn’t active; (b) the arm buildd can’t seem to find its chroot in between running apt-get install and apt-get remove; (c) the s390 buildd only works if the source is on ftp-master; (d) of the five m68k buildds that will take packages for security.debian.org updates to testing, only two will succeed (a400t and poseidon). There’s also the notable problem that the chroots for the functional buildds have gotten out of date and that builds break somewhat obscurely as a consequenece. One of the test updates is also failing on hppa due to space restrictions. And of course, the above list is after a chunk of other problems have already been fixed. It’s worth noting that even if the above isn’t fixed for testing now; we’ll still need etch chroots for security.debian.org when we release, so those problems have to be dealt with at some point. And that the brokenness is the result of six months’ divergence from sarge; after a year and a half when etch releases – or the three years between woody and sarge’s release – it’s probably fair to expect worse breakage. Anyway, that’s just about it from me on this topic. Micah Anderson from the testing-security group is currently checking out the unembargoed facility, and has redone a couple of DTSAs on security.d.o. So presumably those guys will start working out whether security.d.o is something they want to make use of, and if so, working out what changes/tweaks are necessary for that. Though, unsurprisingly, I also still have to do some committing to CVS…

Today, my familiy and I visited the Audi forum in Ingolstadt, my dad got his new car there. The museum was really interesting, I made some pictures which I'm going to upload tomorrow. Unfortunately, it wasn't allowed to take pictures in the factory itself, but it was nice to see live what everyone knews from the television already.

After Bdale blogged about the 5.25" floppy drivers he had in his Fido BBS, I googled a bit and found the following nice gems: http://www.wps.com/FidoNet/FidoNews/1985/FIDO228.NWS:

        ============================================================
                                  NEWS
        ============================================================
        Bdale Garbee
        Sysop of L5NET Gateway, Fido 129/13
              Some Utilities I'm Looking for and Haven't Found
        There are a few public domain utilities I would like to
        locate for my Fido host, which I have unfortunately not yet
        found in my random wanderings around other Fido systems.
        I'm running a Tandy 1200HD, which is an IBM XT-clone.
        If you have any of the things I'm looking for, either send
        them to me by Fidomail, or send me a message detailing how
        I can get them.  Emphasis on public domain.  Sources
        desirable but not absolutely necessary (beggars can't be
        choosers!) 
.../...

http://www.wps.com/FidoNet/FidoNews/1986/FIDO333.NWS:

     =================================================================
                                  NOTICES
     =================================================================
     Announcing the return of the "HIP Shack" to Fidonet, now in
     Colorado Springs, CO.  The files and message areas are in
     the process of being reorganized, but Amateur Radio and SWL
     are still the primary themes.  I'm looking forward to
     hearing from everyone I've been out of touch with for the
     last 9 weeks...
     Bdale Garbee, sysop 128/18, 303/593-0766, 1200 baud, 24hrs

This seems to confirm that, despite our 6 months age difference (guess who wins?), Bdale is way much an old timer than my poor self, whose first appearance in the BBS world is around 1990. Anyway, I found this funny and wanted to share. Enjoy...

Ruby Code & Style is a new online magazine with high-quality articles about the programming language Ruby. In the first issue:

• Modular Architectures with Ruby
• Creating Printable Documents with Ruby
• Linux Clustering with Ruby Queue: Small is Beautiful

Definately worth bookmarking!

Alexa, obviously owned by Amazon and using Google to power its search function, has interesting graphs on the pageviews and reach of some websites. Interestingly, my personal homepage is now barely in the top million (which I consider impressive), but only the top 100.000 have publicly visible graphs. A very interesting graph I obtained is this: So the top three sites are yahoo.com, msn.com and google.com; followed by ebay, passport (what is passport used for except hotmail?) and amazon (English pages only, the worldwide fourth is a chinese search engine). I was really suprised to see MSN and passport that high, I would have expected google to be #1 actually. But I obviously underestimated how many people didn't change the Internet Explorer start page... Unfortunately alexa seems to be broken somehow - around 50% of my requests will result in a blank page I have to reload... and right now, I can't get any graphs anymore. Update: alexa works better now again, and I was pointed to Alexa Top Sites with some more top-ranked sites. Oh, and I wonder how these stats are generated. I first thought they are using click counters in search engines (most likely in google?) but OTOH that wouldn't explain yahoo or MSN being that high...

Nice. Very nice. The Xbox-Linux / Free60 team around Michael Steil has published a paper / wiki page called 17 Mistakes Microsoft Made in the Xbox Security System. I'm currently reading the paper, but I'm not quite through yet (the PDF is 13 pages long). It contains a very detailed analysis of the 17 types of mistakes Microsoft made (they made most of them multiple times)... The paper and the findings will be presented at the 22C3 in Berlin — this is one of the lectures I will definately be attending, that's for sure! Quoting from the article:

"[Conclusion: ]The security system of the Xbox has been a complete failure.".

Also nice: the earlier (now obsolete) version of the paper was called The Hidden Boot Code of the Xbox — or "How to fit three bugs in 512 bytes of security code" ;-) (via Golem)

The GNOME team has been sitting on top of ready-to-go GNOME 2.12 for way too many weeks now, but unfortunately a series of planned and unplanned transitions affecting unstable prevented us from moving them from experimental to unstable. Today's good news is that these transitions are either going well (C++) or not at all (freetype upstream), so the release team gave us green light to start a fun GNOME 2.10 2.12 transition. There are a few aspects in this cycle that makes it a bit special and a bit more complex. GNOME 2.12 in experimental uses dbus 0.50, which is API/bus incompatible with the previous version in testing/unstable, so when we upload GNOME 2.12, the new dbus will go in too. As KDE is also using dbus in a few places, KDE and GNOME uploads will need to happen at the same time. To make it even better, dbus 0.50 has been obsoleted by 0.60, which is again API and bus incompatible with the previous version. The GNOME and KDE teams have agreed on the following plan:

1. The Project Utopia people have uploaded dbus 0.60 to experimental, and is currently waiting in NEW.
2. The mighty seb128 will upload GTK+ 2.8 and Pango 1.10 to unstable RSN, so our first version of GTK using Cairo starts to get broadly tested in architectures other than i386 and powerpc.
3. Once dbus 0.60 is accepted in the archive, the GNOME team will rush to recompile GNOME 2.12.2 against this new dbus, and test that everything is ok with the new version.
   At the same time, the KDE camp will upload their shiny KDE 3.5 debs, compiled too against dbus 0.60, to experimental, for the first time.
4. When everything has transitioned to dbus 0.60 in experimental, GNOME and KDE will be uploaded to unstable.
5. Vorlon will take a deep breath and will try to figure out how to get the two monsters in testing at the same time. Vorlon, we love you. :)

This looks like it'll take months to do, but I really don't think it'll be the case. We hope to be ready for a full GNOME 2.12 upload to unstable, at long last, pretty soon. As always, the brave can still use GNOME 2.12 in experimental with the usual aptitude -t experimental install gnome-desktop-environment. More updates as stuff happens!

Somebody may have noticed, we've sent out kernel updates for sarge yesterday. It's been a lot of work that eventually lead to this update. Thanks to everybody involved, you've helped Debian a lot. Thanks for being patient when things weren't looking so well. The new 2.4 kernel fixes 13 and the new 2.6 kernel fixes 28 identified vulnerabilities. Both kernels are compiled for all affected architectures. It has been quite some work to identify and document all problems, test all packages and kernels, correct those with bugs and get them uploaded. The woody kernel still needs an update, even for older issues. I've already had prepared an update for one of the six 2.4 woody kernels and asked for help porting it a couple of months ago. Unfortunately, the person who offered help took two months to tell me and got pissed in the meantime. Currently, Dann Frazier is working on this, and he's done a lot of work for the recent sarge kernel update as well.

Given that the perennial, uh, “discussion” about GNOME’s features is on us again, I thought I’d share the method I use to remove options from Quod Libet. I break them, and see how long it takes people to notice. Well, no, not really, but the amount of brokenness in an option is a good metric for whether or not people change it. One of the first options in QL was a checkbox for “Show album cover”. Sometime around 0.7 or it became impossible to turn this off, and I didn’t notice until I was redoing the preferences dialog for 0.11. Rather than fixing it, I just removed a few dozen lines of code and made it always on. No one has ever asked for it back (though someone probably will now). This has happened a couple of times. On a related note, three months ago Bram Cohen made an interesting post about configuration in software, which has been rolling around in my head picking up smaller objects since. There’s a lot of “configuration” that we don’t think of as configuration — for example, the volume in an audio player is stored in basically the same place (same file, GConf tree, whatever) as, say, where the program looks for files. But we only think of the later as part of our “configuration.” That’s because we control the volume “nearby,” in the same place we view it, but the location to look for files in a very different spatial place (an entirely separate window). No one would be crazy enough to put a volume control in a Preferences dialog. So “configuration” becomes synonymous with “hard to find”. The answer to configuration creep, then, is to provide as much direct manipulation as possible. At least from the UI perspective. You’re still screwed from the combinatorial explosion on the implementation side. Beyond that, one thing I’d really like is for context menus to be more common. That is, users should be able to expect to right-click on a widget, and change changable aspects of that widget. This also means making right-click involve no surprises — it shouldn’t activate buttons, shouldn’t delete things, etc. Otherwise people will be too afraid to right-click to try configuring. This feels like a good substitute for when direct manipulation isn’t really possible, because the most direct form of manipulation is already taken up by the widget’s primary purpose. Anyway, Quod Libet is going to be moving in this direction in the future. We already have plugins configurable in the same dialog where you turn them on and off. In 0.16 the tray icon has become an interface almost unto itself, and so it has a separate Preferences dialog now, launchable only from the icon. (It also only has one thing to configure, but that might change. Most importantly, it can grow, without getting in the way of people who don’t care about the tray icon.) For 0.17 I’m probably going to fulfill the common “display remaining time” feature request by putting a radio context menu on the time display. And so on. Fixing Real Bugs
But enough about UI wankery. Does anyone know of a nice C parser for Python? Inspired by a bug he found in mmapmodule, Michael’s written a tool to find type signature issues in CPython functions, but its usefulness is lessened by the fact it returns a ton of false positives and probably also misses many things as well. You Are All Self-Absorbed
My project for a class this semester involved trying to extract useful categories from the link structure of weblogs. Unfortunately it turns out weblogs are all about navel-gazing, and the link structure isn’t at all useful. The majority of shared links on Planet Perl,Debian,GNOME,Python pointed to perl,debian,gnome,python .org, and the majority on MSDN Blogs pointed to microsoft.com. Only about 10% of links pointed to a post on another weblog. Given that additionally weblogs tend to not have comments (and even if they do, people reply in another weblog post anyway), that’s kind of sickening. Can you imagine how much email would suck if only one out of every 10 mails got a reply? I wouldn’t be able to spend all day reading about how Debian’s FTP masters are doing their job properly.

It's been an interesting 24 hours. Monday
8:00 PM
I get home after working a regular day and having supper with a friend. 8:15 PM
One of our friend from church -- who happens to live a few blocks from my workplace -- calls. "Did you know your workplace is on fire?" "Uhh, no...." "Yeah, big fire, flames, dozens of emergency vehicles..." "Hmm..." So then I call my manager... "Did you know the company is on fire?" "Uhh... no...." "Yeah, sounds bad, I'm going to head in and see what's going on." 8:30 PM
I arrive at work. Cops have blocked all the entrances. I identify myself as an I.S. manager and am directed to the "manager area". (Others are kept across the street.) An eerie orange glow -- and lots of smoke -- is visible above the rooftop. This looks bad. We learn that something in the compressor room caught fire or exploded. Fire spread upward quickly. Most importantly, everyone got out without any injuries. 8:35 PM
Our T1 provider calls my cellphone. These are really, really good folks. I answer, as I'm standing next to a noisy fire truck. ISP: Hi. Just calling to let you know that your T1 is down and we're looking into it. Me: Hmm. That might be because it's on fire. ISP: Uhm, did you just say it's on fire? Me: Could be. There's a fire in the building and we're not allowed in just yet. Plus the electric company is trying to cut the power. ISP: OK then, I think we're going to assume the problem is at your end for now. This sounds bad. I know the I.S. dept. still has UPS power, since the phone system attendant is answering. But if the T1 is down, it seems that it must have burned up (its run goes very close to the affected area), and taken some phone lines with it. 9 PM
It's below freezing already, and I didn't bundle up very well. Several waiting -- but unused -- ambulances are nearby and the paramedics invite those of us waiting inside the heated vehicles. 9:30 PM
The CEO and CFO are permitted to tour the building with a firefighter. Word is that sprinklers have come on and there's water in the I.S. dept. This is potentially really bad news. The I.S. dept is in the basement and water has been a problem before, so we're prepared, but water and computers are never a good combination... After a little while, we are allowed inside as well. There is 1 to 2 inches of water on the floor in the basement, but fortunately nothing has reached the raised floor yet. The fire department supplies an AC generator to power the sump pump, plus 6 squeeges. We supply 6 people. We keep on the squeege duty until about midnight. Meanwhile, it turns out that a water pipe broke out in the shop near the fire. Water gets shut off. But the floor up there appears to unfortunately slope towards the staircase that leads to the basement. Water is coming down fast. We find what we can to block the path, and that seemed to just make the collection deeper. I periodically try to find someone that can bring a pump and a generator -- or something -- to help this get cleared up. Midnight
I head home. The water situation is improving, but not resolved yet. Others remain. Once home, I post a notice on our public website saying that our power, Internet, phone, and FAX lines are down. You just might have a problem reaching us. I also e-mail some consultants, saying that the reason the VPN doesn't work is that we had a fire. I also e-mail the new I.S. person who has an hour commute and advise him of the situation. Our fire was top story on one of the local newscasts. We watch the video of it, sigh at the annoying "on the scene" reporter (motto: "things were interesting an hour ago"), and turn in. 1AM
Time to sleep. Tuesday
6AM
Get up, in to work by 6:45. Everything is dead. No power, no water, no phones, no heat, no gas. Also, fortunately, no more water coming down. I call the other I.S. developer and tell him not to bother coming in right now, but maybe we'll call later. 8:30 AM
An impromptu meeting happens. The CEO sets communications as the #1 priority: phone and basic Internet access. Plants 2 and 4 have working power, so if we can bring up some servers and network gear on a generator, computers over there will work. No water in plant 1, where my office is. So nearest restrooms are a 5-10 minute walk through dark and damp areas. Bottled water, coffee, and donuts appear at the halfway mark to the restrooms ;-) 9:00 AM
Generators start appearing near the I.S. dept. After getting them powered up, proper extension cords found, etc., we start plugging in the phone system. Power strip 1 works. I flick the switch on power strip 2, and it all goes dead. This generator's circuit breaker keeps doing that every time we try to turn on the phone system. So we try generator #2. Phone system finally powers up. But all incoming lines are ringing at phones in sales. Volunteers go up to answer those phones. Meanwhile, phone tech shows up, and orders his own, larger generator. I call our person that's an hour away and tell him to go ahead and head in. 10:00 AM
Now we turn to the computers. We're going to have to be careful what we bring up so we don't overload the generator (and thus have an unclean shutdown on anything that's already up.) I recable power to some switches, our T1 router (ISP calls: the T1 just came up! yay!), and our firewall. Flick the switch on firewall. Generator stays up. Firewall emits a high-pitched whine. Eeep. Flick the switch again! After checking things out, we adjust the voltage a bit and determine that things are generally OK. I run the firewall on one of its two power supplies. At least if it burns one out, we can still run it off the other later. Turn it back on -- whines again, but it goes away after a few minutes. Phew. Next step: our main Linux file server. Flick the switch, and there's a satisfying "whoosh" from the fans. Excellent. Our developer shows up and observes later: "John, this was odd. When I got here, there were 7 guys standing around watching you boot up machines." 11:00 AM
Decision time. Our main ERP server is an AIX box. 8U. About a dozen disks. Certain to be a large draw. Can the generator handle it? Yes, it should. Should we power it up, given that it takes 45 minutes to come up and 20 to go down? We opt to try. I cable it up and press the power button. Nothing happens. But that is normal for AIX. After a few minutes, we start seeing hex codes on the LCD. A few minutes later, disks start coming up. All looks good... 11:15 AM
Orange alert lamp comes on for the AIX box. Uhoh. Turns out one of the drives in the RAID is bad. Time to call IBM, but at least it's mirrored to the box is up. IBM service calls are always "fun" for this. I spent a total of about an hour on the phone with them, 90% of which was spent with them analyzing error logs trying to find out what exact part number to give is, and 10% spent trying to look up our account information. Plus, the phone guy is now switching the phone system to his genset. He tries to hook it up through a home-type UPS, which is giving him fits. I get disconnected from IBM at least twice. Noon
My supervisor goes to Subway and brings in lunch for all four of us in I.S. since we don't really feel like we can leave. Word arrives that the generator that's powering the servers is leaking oil. Eeep. But it should be good until evening. On the plus side, the generator will automatically shut itself off when it runs out of oil. Won't damage itself. 1PM
IBM calls, trying again to get information about what exact part they need to bring out. Only 29 minutes on the phone this time. Word arrives that a 60kW generator has arrived that they will attempt to hook into the mains supply for the building. The main power distribution center has been burnt. Plus we aren't allowed to touch large parts of it since fire inspectors and insurance adjustors aren't done yet. But no ETA on the big generator. We make a preliminary decision to cut power to computers & the network at 5PM, and maintain the single phone system generator overnight. 2PM
Local IBM rep calls. He'll be out between 3:30 and 4. I say that'll be fine, but warn him that if he's any later, the power may be down. 3:45PM
IBM rep shows up, replaces the dead disk. It works. Whee. 4:15PM
I start powering down the AIX box. We then learn that ETA on the big generator is 5PM. So we start shutting down other servers as planned. 5PM
Big generator comes up. It works. We slowly bring up our systems. Everything is good. BUT -- we are basically maxing out the capacity on the generator. People will not be able to just come in and work like usual tomorrow. We'll be meeting in the morning to figure it all out. 6PM
We post signs at entrances warning people to not turn *anything* on. Finally head home at 6:30.

I’ve just returned from NIPS 2005. The conference was great, and I hope to post more later about my favourite papers, posters and talks. The highlight of this year’s conference was undoubtedly Jeff Bilmes, Michael Collins, Koby Crammer and Fernando Pereira’s summary of their workshop on structured learning for text and speech processing. Fortunately, I captured the entire thing on video for the enjoyment of the machine learning community (and anyone else who’s interested). So, without further ado, I present Jeff Bilmes (bass), Michael Collins (sax), Koby Crammer (bongos) and Fernando Pereira (vocals) performing “We Gonna Solve AI”. For those of you that wish to sing along at home, the lyrics are:

Summertime, and the learning is easy. Our problem is structured,
And the accuracy is high. Your funders are rich,
And your colleagues are good-looking. So grow little margin,
We gonna solve AI. Wintertime, and the learning is #-P. Our speech is recognized,
But we don’t know why. Our code is in MATLAB,
And our data’s synthetic. So grow little margin,
We gonna solve AI.

[*] sung “sharpee”

I hereby make it official: I won't be at DebConf6. Unfortunately, I can't make it, since I have to give class during that week. I find it unfortunate that a conference which was done during the month of July last time (which is an excellent time to do such a thing, IMHO) had to be done two months earlier this time; at that point, many of us won't be able to attend. But then again, I guess they have their reasons. Perhaps next year?

Josselin Mouette has thrown down the gauntlet -- Subversion is the One True Revision Control System and we should all just Stop Worrying and Learn To Love The Handcuffs. In particular:

[...] just use subversion, and if you feel it's missing features, please contribute them. By standardizing on subversion, we lower the barrier for people wanting to contribute, instead of increasing it by asking them to install and understand new tools.

Quick thought experiment, Josselin: replace "subversion" with "Java". Or "Perl", or "C", or even "Python" or "Ruby". Or any other language. It doesn't matter which one. Even if the language you substitute is a good one, and one you happen to like, it's still a fairly obviously braindead idea -- that there can possibly be One True Programming Language for all problems, and that there can never be any improvement that can't be bolted into the existing OTPL. Revision control isn't so much different from programming languages. Different systems will provide different advantages and disadvantages. There's also incremental and revolutionary improvement that will take place over time -- machine code to symbolic to procedural to object oriented -- that can never take place within the established framework. I happen to really like the distributed model -- it reduces (though, naturally, cannot eliminate) the division between the Blessed and the Peons in a project (those with direct commit access vs. the rest of us). You can get disconnected operation for (almost) free. Also, despite the assertions contained in your article, the "barrier to entry", ironically, is actually lower with a good distributed RCS than with Subversion. The barrier isn't what you think, though -- sure, using an unfamiliar RCS is troublesome, but it's a lot less hassle than learning a new language, and people do that on occasion to hack on a particularly interesting problem. The real barrier to entry is forcing anyone who isn't blessed with direct access to The One And Only Repository to use inferior development support tools. "An example!" I hear you cry. Gladly. This morning (literally) I got enough of a handle on the internals of Ruby on Rails to actually track down a bug that was irritating the crap out of me. Being a good developer, I wanted to use revision control to track my changes. In the All Subversion, All The Time "utopia", that would involve getting an anonymous checkout, making a copy, hacking on the copy, then (when all was done) running diff -urN between the original and the copy, and sending it all upstream with a manually-created log message (assuming I could remember everything I'd done). You also need to manually remember (or encode it in your directory or something) the source of your tree, so upstream can merge it reliably (and compare it against other equivalent work that may have been done in the meantime). Doing it better, I could do an anonymous checkout, and then import it all into a new Subversion repository (or directory) of my very own, and hack on it in there. Benefit: revision control of my changes. But it's non-trivial to create a new repo and import everything into it, and there's still no automatic record made of the upstream source of my new repo. Wanting to make a second change is even worse -- I either have to make a whole new copy of my source tree (disk is cheap, but this is getting silly) or just keep forging ahead with changing my existing tree -- so this second set of changes can end up being dependent on the first (which is Not So Great if upstream don't merge your first patch). In the "new repo" scenario, you can branch from the root of your new repo and continue hacking on your newly created branch, which is a good start, but it's still icky. And good luck having the system track new commits from upstream while you're working, too. If the project was using a DRCS, in contrast, the problem would reduce to making a branch into your local archive, hacking (committing at will), updating with new upstream commits as you go along, and then publishing your changes to a public place for reintegration (or, in some cases, sending your changeset via e-mail). Oh, and before anyone starts screaming "if anyone can branch, it will encourage forking!", consider which is more likely to result in a permanent fork (rather than a temporary independent line of development): a local set of changes in a tarball or local subversion repo, both of which are hard for anyone else to collaborate on without major pain; or a branch in a simple-to-publish (or push) designed-to-be-shared DRCS archive, which automatically keeps all of your interesting metadata intact and coherent across archives, merges, time, and space (and possibly even dimensions). This utopia doesn't really exist, and is hampered by everybody having their own Pet DRCS, but the problem, I'm fairly sure, is transient, and my main point isn't even so much against the choice of Final Ultimate Solution, or even the problem space, but more about the attitude that everyone should get behind Any One System and stay there. I can't imagine the world of pain we'd be in if Josselin had posted his message a few years ago (but with s/subversion/CVS/i, naturally) and everyone had followed his advice -- can you imagine per-file changesets with no effective merge capability for the rest of eternity? <shudder />

Xen

I updated the script I wrote to create new Xen instances of Sarge.

• http://www.debian-administration.org/articles/304/create-xen-image.pl.txt

It is still pretty nasty but it can now create a new Sarge installation with networking, OpenSSH, users and groups all in the space of a few minutes:

./create-xen-image.pl --hostname=vm01 \
  --ip=192.168.1.245 \
  --gateway=192.168.1.1
  --dir=/home/xen/

Unfortunately it doesnt live in a CVS module of its own, rather one I dedicated to hosting resources associated with articles on the d-a.org website. Maybe time to revisit that?

MouseTrap

Whilst in a quiet mood, waiting for my tea to cook, I decided to amuse myself by playing mousetrap - something I’ve not touched for a month or two. In a fit of enthusiasm I imported mousetrap into CVS - comments/feedback welcome. [Simplistic arcade game, uses SDL, Debian Sarge package available.]

The past few days I have been accumulating knowledge. I have encountered quite some new concepts and stuff they use here, but also old knowledge had to be refreshed. I have looked again at XML technologies as W3c XML Schema, RelaxNG, XSLT and XML in general. I had to dive into OCaml since that’s the main language used here. Fortunately I can make use of my past Haskell experience there. So now I have yet a new language to add to my used-programming-languages list. I have used my webspace provided by MACS to set up a page about all my internship work related stuff. It gave me another opportunity to make use of webgen again, what a great tool! Simple text files in a directory structure are converted to a site with such ease. A title, menu and navigation bar, all done automatically and it’s all static HTML in a nice XHTML 1.1 compliant package. MathLang I have read all the available presentations and papers on MathLang that I could find. At the TU/e I was taught the Weak-Type Theory by professor Nederpelt (which is a basis for this mathematical language), so I have some background in this area. I’ve tried to write a page about what MathLang is. I’ll probably have to improve the descriptions and make the whole thing clearer. The Plan My first task will be to write a MathLang-Core concrete syntax compiler that can generate the still to be defined XML format. The AST used in this compiling process should also be prepared so that the MathLang type checker can run on it. Once the compiling to XML is done, I might be able to use XSLT to transform it back to the original syntax, hence proving the equivalence of the two syntaxes. For monitoring my progress, see my online log.

Just reading the comments associated with a post from the reddit.com people about a rewrite of their entire site from Common Lisp to Python. The Lispers are screaming "noooooo!", the Pythonistas are grinning smugly, and the Rubyolas are asking "why not us?". In the middle of it all, comes this gem (unfortunately, posted by "Anonymous", so no attribution):

Real men would design a custom ASIC and write a new FORTH system optimized for Reddit, complete with custom developent environment, web server, etc. It would multiply the development time-to-1.0 by about 2-4x, but the entire system would be smaller than the ethernet plug, would handle a saturated gigabit pipe with sub centisecond latency, never crash, and use less power than your toaster. Everyone would be too busy saying "WTF is FORTH?" to bitch about you not using Ruby on Rails. Then you'd lose to the guy who did it in PHP (*turn* *puke*), because it's not about the technology, stupid.

I've been so busy, I haven't had time to blog. Rather than putting it off any longer, I'll just dump what I can remember. Last Wednesday, Sarah arrived after her holiday in Singapore, and from all accounts, had a great time. Photos as well. Sticking with the whirlwind theme, the next day, we had a "building warming" party at work for the new building we'd moved into the week before Michael and I started. The next night we had the work Christmas party, which blew the socks off any work Christmas party I'd ever been to before, and then on Saturday night we went to a party in San Francisco that we'd been invited to. On a life in general front, I'm still waiting for a Social Security number. The lack of one makes life a bit difficult for a lot of things. It also turns out that Sarah's work permit will take about 90 days to approve, so she's going to be a lady of leisure for the next few months. I've finally been issued with a work mobile phone (or "cell phone" as they call them), and so can stop roaming and paying through the nose for the privilege. We've found somewhere to live. We take possession of a 2 bedroom townhouse (split-level) in a complex in Mountain View that is 3 miles from work on the 18th. The rent is $1725 a month, which is a bit better than we were expecting. The complex we're renting in does have shared laundries, which we'd not too keen on before getting over here, but they're quite modern and secure, and there's a laundry block close to our townhouse, so hopefully it won't be too bad. The whole place had been renovated about 5 years ago, so it's all in good condition. We could have rented a 3 bedroom apartment (single level) in the same complex for about $125 a month more, but we're trying to actually make some money while we're over here... Driving on the other side of the road becomes fairly "normal" after about a week of doing it regularly. Sarah's adapted fine. Lane placement is the hardest thing, because your body's used to being in a certain spot on the road, and it's all different sitting on the other side of the car. We've managed to open a rudimentary bank account, even with my lack of Social Security number. Unfortunately I can't get paid until I have an SSN. Upside of that is that if it doesn't happen until next year, I presumably won't have to worry about income tax for this US financial year. Downside is kind of obvious... By far one of the stranger things of everyday life here is the lighting situation in the average residence. Lamps are all the rage, to the point that light switches don't exist in some rooms (notably bedrooms). Take where we're currently living for example. There's a light switch at the bottom of the stairs, there's one at the top. There's a bank of four in the living room, two of which control lights in the kitchen, and one the hallway. The last one controls a lamp in the corner of the living room, which is connected to a power socket (or power point as we'd call it). The bedroom with the attached bathroom (en suite) has two bedside lamps, and that is the sole source of light. The bathroom attached has light switches, and the walk-in robe has a light switch. It's so weird. So walking into a darkened bedroom involves walking all the way in, and fumbling around with a lamp. It's often easier to turn on the light in the wardrobe so you can see what you're doing first. I can't think of any reason for it, except tradition. It's not like they're avoiding wiring the walls or the ceiling, because it's done partially already. The bedroom has a ceiling fan, but where in Australia, there'd be a knob on the wall near the light switch to control it, it has a little chain you yank on. To add to the strangeness, there are two switches on the wall, one of which seems to allow you to turn off the ceiling fan if it's already been switched on by pulling the chain. The townhouse we're renting has a similar lamp dependency, so we're going to be making a trip to Ikea for some lamps it would seem. That's about everything I can recollect right now... Oh, I should point out that I'm really loving it over here.