The Seven Secrets of Successful Programmers article was on reddit today. I found it to be simplistic enough to be inane. Also not particularly good advice in all parts. For example, the article says that "[m]ost compilers will strip the comments from the executable program". Strictly speakig this is true: there is probably one or two compilers out there that retain comments in the binary code they put out. They're so rare, though, that it is quite utterly pointless to say anything about it. Anyone who needs to be told that comments don't impact performance or executable code size needs a course in basic programming, not secrets about being successful. "A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?" I disagree with this: better advice would be "could someone understand the code if you remove all the comments?" It's the code that gets executed and so it is the code that should be used to communicate and not comments, except when code can't be made clear enough. For example: if you write a wrapper around malloc to check that it succeeds, a comment explaining why it is acceptable to just kill the application on failure would be good, and very hard to express with code. "In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end." Gee, that surely is a big secret that only successful programmers know about. "Expect the unexpected and deal with it. Before you open a file, make sure that the file is present." That's not a good way to deal with it. It's a race condition just waiting to blow in your face. The correct way is to attempt opening a file and then deal with an error if it failed. "Name your variables to aid readability. - - - The key is to be consistent and to be as informative as possible." Packing as much information as possible into a variable name can be a hindrance to readability. Too many people read advice like this given in well-meaning but misguided articles and then go on to name loop variables nElementIndex. The loop gets more readable if you name your loop variable just plain i. The loop variable is not significant enough to warrant all the attention from a reader that a long name requires. A short name in this context makes it much faster and easier to glance at the loop and see what it is doing. Obviously names with scopes longer than a (fairly short) loop need to be more descriptive. Here's my seven secrets of being a successful programmer.

1. Learn to worship the goddess of simplicity. KISS a lot. This is much harder than it seems: it's more difficult to be simple and good than to be complicated and adequate. Simplicity starts with the specification of the program or system, and needs to permeate the design, and the implementation, at every step.
2. Pick good tools, and learn them well. You need to know many tools, and know them well, or you'll waste time on doing unecessary things. Tools include software programs, books, algorithms, data structures, and mental models. Learn editors, programming languages, Unix command line tools, and so on. Learn at least three different paradigms for programming.
3. Learn how to learn and keep on learning. New stuff is invented daily, and you need to keep up with it, or you'll end up as useless as a COBOL programmer doing a web shop.
4. Develop debugging muscles. This is perhaps the hardest thing to learn, since no-body seems to be teaching it. You'll be spending most of your time doing it.
5. Learn how to do testing well. Unit tests, test driven development, black-box testing, integration testing, regression testing, test automation, ... There's lots of ways of reducing the likelyhood that code escapes your hands with bugs still in it. It will inevitably happen, but if you know what you do, you can be better than most everyone else. The industry standard for commercial, proprietary code seems to be around 20 to 30 bugs per thousand lines of code; the Linux kernel has less than 1, and is known as a cesspool of bug-infested muck, so surely you can do better?
6. Learn to write prose well. Then write a lot. If you can't write a README, a manual page, or the specification for your next work project, who's going to know about your great programming?
7. Oh, you need to learn how to program well as well, and that isn't so easy either. Knowing how to program well merely isn't enough to be a successful programmer.

Finding arm machines is not hard. In fact, everyone of you probably owns some of them. However, finding something suitable for Debian infrastructure usage is harder. For example Buildd load pattern requires not only a decent CPU, but above all good IO performance. Most ARM systems do not have a hard drive, and if they do like on personal media players like Archos pma400, the drives are slow and optimized to minimize power consumption.

Therefor, the logical place to look for machines would the NAS devices, like the already-being-Debianized Linksys nslu-2. NAS machines tend to (relatively) cheap, well available and need good IO performance. The main problem with NAS devices is the lack of RAM (to minimize costs they tend to have 32MB or something soldered to mainboard), so I was more than happy to spot a NAS with 256MB of ram:

Linksys NSLU2	Allnet ALL6500
266Mhz* ixp420	400/600Mhz IOP80219
32MB ram	256MB ram
USB 2.0	2xSATA & USB 2.0
100Mbit ethernet	2x 1000Mbit ethernet
95	350

*overclocked

The real shocker came when reading "Manual englisch": (arrows by me)

This bloody thing seems to have a DIMM socket!

GPL sources seem to be well available. Can someone from .de confirm if the memory is really there? (Why does so many cool hardware never end OEM'ed this north?) IOP80219 supports up to 1GB so it really seems quite promising :)

The hard disk on my notebook computer developed a number of bad sectors so I replaced it with a new 7200rpm 100GB drive. I've discussed my experience and gave details about using an encrypted root and LVM filesystem using the Linux 2.6 device mapper. While I found the disk speed acceptable using the encrypted filesystem, I did note that it was subjectively slower than using an unencrypted filesystem. This time, I used the bonnie++ disk benchmark to test the new disk. Raw disk benchmark

       ------Sequential Output------ --Sequential Input- --Random-
        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    4G 30299  98 47348  13 20552   6 29947  91 44758   5 137.3   0
       ------Sequential Create------ --------Random Create--------
        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
     16  3545  21 +++++ +++  3863  42  3350  20 +++++ +++   867   6

Encrypted disk benchmark

       ------Sequential Output------ --Sequential Input- --Random-
        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
   Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
     4G 18861  60 40812   9 10534   2 18530  58 30641   4 143.6   0
       ------Sequential Create------ --------Random Create--------
        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
     16  3150  87 +++++ +++  3510  92  2919  86 +++++ +++   900  35

While there is an overhead using the encrypted file system (which is likely magnified by using a 4-year old CPU, a 2GHz Pentium 4-M), the overall speed with the 7200rpm drive is acceptable and will be a boost compared to the old 5400rpm drive. While my notebook previously ran Debian Sarge, I thought I'd try something slightly different, the Debian offshoot Ubuntu Breezy. I found a few issues that had to be resolved to use the encrypted filesystems.

• Patching /usr/sbin/mkinitrd
  mkinitrd had the wrong devmapper library version. I had to change line 385 from /lib/libdevmapper.so.1.00 to /lib/libdevmapper.so.1.01.
• Add modules to /etc/mkinitrd/modules
  I added aes_i586, dm_crypt, and dm_mod to /etc/mkinitrd/modules.
• Modifying /etc/lvm/lvm.conf
  I use an encrypted physicial LVM partition to host my logical volumes. That way, I only have to encrypt the LVM physical partition. Subsequently when booting and decrypting the filesystem, I only have to give once the key to the physical volume and all of the logical volumes created in that partition will be decrypted. This requires some editing of lvm.conf to recognize the encrypted physical volume. I named the LVM physicial volume pv and then added /dev/mapper/pv to the filter specification in the devices section. Also, LVM has to be notified of the device mapper type, so the line types=["device-mapper",16] must be added to the devices section.
• Change the startup script order
  The script order in /etc/rcS.d/ needs to be changed so that cryptdisks is executed before lvm. This is required so that the lvm script will have access to the unencrypted physicial volume. This is simply done by renaming S28cryptdisks to S25cryptdisks which places it before the lvm script S26lvm.

After those bits of additional configuration, the encrypted root filesystem and encrypted LVM physical volume is working very well. Additionally, I'm using an encrypted swap partition, but there was no additional configuration required beyond what I previously described.

It’s official: I’ve joined the Free Standards Group as Chief Technology Officer and chair of the FSG’s Linux Standard Base (LSB) workgroup. (The FSG made some great additions to its board too.) This promises to be a breakout year for the LSB and for free standards in general, and I’m excited to be a part of it. Some of the things on tap for the coming year are:

• The LSB 3.1 release (which adds Desktop functionality to the ISO standard LSB Core, among other things)
• A crisp, well defined roadmap for LSB 4.0 and beyond, with increased emphasis on synchronicity with the major distros and stability, predictability and consistency of the LSB ABIs/APIs over time
• A renewed emphasis on increasing direct involvement of distros, ISVs, and upstreams in the LSB development process
• A developer outreach program that will make it easier than ever for software developers to target the Linux platform in a portable way (hint: ever wish there was a Linux Developer Network?)
• A franchised certification program that will allow third parties to integrate LSB certification into their own value-added certification offerings (our recent announcement that we’ve teamed up on a certification center in China is a hint of things to come here)

As with most major life changes, this one’s bittersweet in some ways, as in the process of embracing this exciting project, I’ve had to step away from another, namely Progeny, the company I co-founded way back in 1999 (!). It’s always hard to move on from something that’s been a big part of your life for such a long time, and it’s particularly hard when you don’t feel like you’re “done” yet. On the positive side, I leave Progeny in excellent hands, and I’m able to remain involved in that wonderful position called “advisor”. Speaking of Progeny, I’m exceedingly proud of all we accomplished over the years. Not only did we survive the .com bust, but we successfully reinvented ourselves in the midst of it all. Furthermore, we not only survived, we pioneered: we were among the first (if not the first) to build a business model around the customization and integration of open source code, a model that’s been adopted by some of the hottest open source startups of the past few years. I’m also immensely proud of the DCC Alliance—indeed, my new role with the FSG is, in a lot of ways, a natural progression from that latest waypoint in a string of projects that date back to 1993. That’s it for now. Watch this space for additional news about the LSB as it continues to unfold. Better yet, get involved and help make it all happen!

I've been relatively quiet lately because I've been plodding along, working on modular packages for Xorg. For those who don't know, the next release of Xorg will actually be two releases of the same code. One release, 6.9, will be based on the old monolithic build system. This system requires me to build every single part of Xorg whenever I want to update any one part. This means that whenever I push out an Xorg fix, no matter which component it's in, you have to download all the other components even if they are 100% identical to the previous version already on your hard drive. We've all lived with this for a long time, and while it's not pleasant, we all seem to get by. The packaging apparatus for this system is mature, stable, and well understood, if complex. That's why I've been able to get the 6.9 release candidate packages out to experimental fairly quickly after they are released.

The other release happening is for 7.0, which is obviously a major version number bump. The actual code you run for 6.9 and 7.0 is 100% identical, but the build system has been totally rewritten around the venerable autotools (you know... configure /make/make install). Each piece has been split out from the others so that you can build any one component without building all the others. This means that if we want to ship a driver update, you don't have to download all of the fonts and other things that weren't touched. That also means that you won't have to install the drivers for cards you don't own if you don't want them. Furthermore, it lowers the barrier for things like hacking on X significantly.

The problem with the modular tree is that the packages for it are brand new. Ubuntu shipped modularized versions of the libraries, and I've already stolen those, fixed them up for Debian, and built them locally (they're sitting in our svn repo, but running them won't get you anything at this point.) The server and driver packages are brand new, and I've been taking the packages from Ubuntu's development branch and working on them for Debian. Today was a milestone day because in addition to the libs, with Daniel Stone's constant help I've finally managed to build packages for the modular X server itself. Now I can't run it yet (I haven't packaged the drivers and a few other bits) but the fact that I managed to produce what will be a functional server package is a huge step, and constitutes the cornerstone of the whole thing.

Once we can create packages that can actually run on at least the machines of the XSF, we can start looking at getting the packages in to the archive. Since these aren't well tested like the monolithic packages, we'll have to do a lot of polishing to get them to the same level of quality. My goal is to get that done for etch though, and I think we can do it. Exciting things are happening, and I'm hoping that the modular packages will encourage more people to hack on X, leading to even more exciting things. Build that momentum.

Today was a good day in Debian X land. X.Org released the "zeroth" release candidate for both the 6.9 (monolithic) and 7.0 (modular) versions of the X.Org tree. I downloaded the 6.9 tarball, imported it in to the XSF svn repo, and got to work on the patchlist. I'd already ported a number from 6.8, and tonight I managed to finish the rest. Except for a massive GNU/kFreeBSD patch, every single patch in the debian tree has been ported over to 6.9. This work took multiple weeks with multiple people for 6.8 using dbs. Using our new quilt-based patch system I blogged about in the past, this took me about half a week, with the bulk of the work over the past two nights.

Now I haven't actually been able to build 6.9rc0 yet, nor have I been able to build 6.8 for a few days. There's currently a bug in the linux-kernel-headers package that breaks the X.Org build, so the XSF has been working on polishing the -5 release. Eugene Konev has fixed things to we now build HTML docs for xspecs again, for those of you who hate the postscript versions. David Mart nez Moreno has been doing an enormous amount of cleanup, generally dealing with a lot of the bugs that have come in and taking care of the new translations that have been flooding in almost as fast as we can change the debconf templates :-) Christian Perrier has joined the team as translation coordinator, so as soon as he can get svn access the X packages should be well taken care of in his amazingly capable hands. Finally, I've included a new script for /etc/init.d supplied by Petter Reinholdtsen that will give Debian LiveCD-derivatives a standard way of generating an X server configuration on boot. Nothing too fancy, but we're tightening up the package a bit more and those fixes have already been merged in to the 6.9 branch.

So if people need updated drivers from Xorg's HEAD, keep an eye out for 6.9rc packages to hit experimental. As soon as I can build and test them, I'll put them there for people to play with. My goal is to get 6.9 in to unstable on the day it's released by upstream. We're (or at least, I'm) going to begin work on 7.0 as soon as 6.9 hits experimental as well, borrowing one more time from Ubuntu and attempting to stabilize that packaging alongside them, if they haven't already beaten us to it completely :-) So things are moving and we're going to try and keep up the momentum.

Some people have also been asking about xcompmgr/transset packages. It's still not packaged for Debian because it's either slow or crashy, depending on your driver, although fixes are in the works. I may have found someone to maintain it for Debian, and I'll try and keep people posted about it when I know more.

Today was a very good day. One of those days where somehow things just go very well.

First, I managed to debug a problem at work over which I've been tearing my hair out for the past year. This means I can start generating some real data tomorrow and maybe even graduate one day.

Second, I checked my mail to find that kick-ass ftpmaster Joerg Jaspert has approved almost all the modular packages I uploaded to experimental. This includes the protocol headers and libraries which are a big chunk of the whole. He also gave me some stuff to fix up on two packages which didn't make it, so I'll be working on getting those two ready ASAP, but simply having some of the mass start to enter experimental is nice. Note: I seriously do not recommend running the modular stuff yet from experimental, since the change from X11R6 to X11R7 introduces a serious change that will break unless you know what you're doing or have a full X11R7 system (which you won't). I'm not even running 7.0 yet outside of a chroot, which brings me to the next item...

Third, I finally managed to get the modular X server running entirely from what's packaged in our svn repo. This is a huge step because it means that I'm getting much closer to the full functionality offered by the current 6.9 packages. This is a major milestone for me personally, because I'm starting to see the end of what I set out to do when I took on the Xorg packages a few months ago. It also gives me a serious hope for shipping 7.0 with etch. Needless to say, I'm pretty happy.

Recently I put a new drive in my laptop, and unlike the last one (but like the one before), the 2.6 kernel cannot handle apm sleep with this drive. So I had to, horrors, switch to using acpi and software suspend and hibernate. Which, suprisingly, is working ok. But it was missing a little piece, something to put the machine to sleep if the battery got too low, and so I remembered this sleepd program that I wrote years ago and have been tying to ignore ever since despite people who persisted in using it for some strange reason. Apprently there's still nothing else to handle this job. So now I'm releasing version 1.3.0, with a bunch of patches and improvements.

I finally got out to Barnes and Noble today to spend the last of my Christmas/birthday gift certificates. Bought the last two books in Robin Hobb’s Farseer Trilogy as I have the first book but haven’t read it yet, as well as the third book in Robert Jordan’s Wheel of Time series. Incidentally, I was told by a friend that it’s only worth reading the first three books of the Wheel of Time, as it goes on forever and ever with little development. Please correct me if I’m wrong. I was tempted to buy The Atlas of Middle-earth but was swayed by my OCD at having unfinishes series (what on earth is the plural of that word? serieses? I want to say it doesn’t change, but that sounds funny) in my bookshelf. I’m still not sure when I’m actually going to read all these books, but, uh, I’ll figure that out eventually.

This is a blog entry I wanted to write for about six weeks now, but I was busy with other stuff. In December 2005 I got curious why 2.4.32 wasn't packaged for Debian and investigated the situation a bit.

There are several reasons why 2.4 is still interesting:

- Kernel 2.6 is still a moving target...

- Some hardware is only supported with 2.4, for example older laptops which need APM and don't work with ACPI. Also some non-i386 machines.

- According to popcon, 6-7% of the i386 users have a kernel-2.4 image installed.

Unfortunatly, nobody from the kernel team is really interested in working on 2.4 anymore. They do security fixes for the 2.4 kernels in woody and sarge, for which I'm very thankful, but that's about it.

Even though 2.4 is moving very slowly nowadays (mostly security updates, very seldom new drivers are including), this is more work than needed, because every fix needs to be backported to 2.4.27 (and 2.4.18 for woody).

Of course there are some issues which need to be taken into consideration when thinking about whether it's worthwhile to have 2.4.3x in Etch:

- it needs gcc-3.3 to compile, gcc-4.0 won't work. Period. So gcc-3.4 also needs to supported during etch's lifetime - which will be something like 2009 when etch+1 will become oldstable (by current release cycles)...

- it's not sensible to have powerpc and amd64 flavors, and probably others. So this kernel package will not be arch any. (Which is not really a problem, but unusual.)

- Both kernel 2.4 and 2.6 contain non-free firmware and drivers. I seriously doubt people want to deal with this issue and solve it for 2.4. For 2.6 it will be done, but for 2.4 ? As I see it, this is the biggest showstopper for 2.4 in etch, I would be happy to be proven wrong. As a starting point, you can look at this investigation by Bill Allombert about the the situation in 2.4.25.

Removing those files would be an option, but maybe we can also "borrow a better solution" from 2.6...?!

- if 2.4.32 or .33 shall be used in d-i/g-i, work on this integration needs to be started real soon now.

I have done some work on creating a linux-2.4.32 package which is based on the new kernel packaging. I got busy with videos for debconf-es2, so I didn't finish and commit this.

Horms made a presentation about the kernel packaging in debian for LCA and gave two options: a.) support and backport fixes for 2.4.27 or b.) go with 2.4.32. Somehow he did not consider the option of dropping 2.4 even if he calls it legacy ;-)

Besides technical reasons (security fixes handled by upstream, some driver updates and very few new ones) I think we should not forget that most people have no idea that 2.4.27 in debian is far closer to 2.4.32 than to .27, and therefore will think debian ships an outdated 2.4 kernel. So I think we should simply go for 2.4.3x, if it is sensible to support 2.4 in etch at all.

It "just" needs to be done, and I volunteer to do it (with the help of the kernel team, the porters and anybody else who wants to join), if this work will not be in vain.

Please send comments to the debian-kernel-mailinglist, where I posted this blog entry before. Thanks.

Over one month ago, I truly hoped an evasive network misbehavior issue was solved. In the institute, we had a strange situation which caused a (seemingly random) stack of switches to go out to lunch and leave one of the floors without network access until it decided to restore itself (usually power-cycling it was not enough). The equipment, ten 4200 SuperStack switches, is new, we got it ~September, so I expected 3Com to give me at least some support on the issue. The behavior was apparently random, and I could not track it down, only (thanks to the very nice Cacti) prove it existed.
December 5 was terrible. The whole building's network refused to work. Switches were able to reply to my pings for no more than a minute after booting before they got flooded with "Spanning Tree CTRL MAC PAUSE: Quanta 65535" (according to another great tool, the Ethereal protocol analyzer).
I had been bugging the support people at 3Com for at least three weeks before this incident, they kept promising they would come soon to help us track the cause of the ellusive problem - We threatened to send the switches back and pursue reimbursement through whatever means we could (we had much better stability and performance with our old 10Mbps hubs, so my boss insisted on replacing them), so we got them to come. The answer they gave me? Upgrade your firmware to version 2.50 (not available at their website, of course) and disable spanning tree functionality at the switches.
I have to admit the big problem immediately ceased. This is not to say I was pleased with the response time or with the switches' software quality, but at least we could work.
Happily, ~7 weeks passed by with no major outages (although with a few small ones).
Yesterday, we got back the complete chaotic conditions. This time, though, I was able to get a good and useful tcpdump snapshot, passed it through Ethereal, and actually got something interesting (available to whoever requests it to me if it sounds interesting). In short: Something happens that confuses a switch (I guess it's a faulty NIC), and makes it request to all of the neighbouring switches (via spanning tree protocol - Yes, it's disabled, but still) for their complete ARP tables. But somehow, this noise or whatever keeps confusing it, so the spanning tree requests start repeating every two seconds for slightly over one minute. Then, the same switch which requested this information gets tired of too many ARP tables being thrown at it, and sends out a storm of packets (one each 0.04 seconds) asking every other switch _not_ to send updates anymore. This is broadcasted to all of each of the switches' ports, and the network dies.
My grudge against 3Com is: How come this frigging noise (at least that's what I assume it to be) on one of the ports kill all of the network? If a switch is supposed to be smart, would it be too much for it just to disable the misbehaving port?
Anyway... One and a half days went down the drain trying to find the cause for the problem, sending the report to the 3Com guy (who is very nice in person, yes, but that's by far not enough!), running up and down the stairs to reset different switches, lock down on the source of distress... And as my 3Com contact was busy with another client (who presumably had not yet given them money), I never got a call back from them.
All my good intentions to spend a nice quiet time coding for three projects we currently need to have ready soon (one of them is in production and many of you have used, my dear Comas conference management system, but requires heavy tinkering to be able to extend it) were stuck at that: Good intentions.
I seem to have locked down the problem in one of three computers (that is, network seems stable again once I disconnected them). I insist it must be a faulty NIC. My boss bets it's an ber-contaminated Windows machine. My boss' boss insists we should get the switches double-grounded just to be sure that's not the reason for failure. I am tired, bad mooded, and -again- bored you to death with a too-long blog entry.
Blame it all on 3Com.

That combination of flags is so good that I wish I could claim it was intentional.

Debian has currently two copies of the toolchain in the archives, namely the individual packages for binutils and gcc, and the toolchain-source package, which has traditionally lagged a bit behind the upstream release cycle but can be used to bootstrap a cross compiler environment. However, since there is a nearly endless number of targets, none of these exist as readymade binaries in Debian.
Today, I have been challenged with packaging a tool that offers an image to netbooting hosts, and this image is obviously only dependent on the target architecture. So I'd like to add the images as arch-all packages, but I still need to build them somewhere. Depending on a compiler that is only available on my system is a bad idea. Introducing i386 and powerpc cross toolchains into the archive is not a good idea either, as I would either leave out the libc stuff and end up angering those who want to do actual cross development, or introduce lots of duplicate headers.

Dave Winer: “[H]ow long before Iger gets Amelio’d?”

Coding

I have resolved to actually sit down and keep working on GNUMP3d until I have:

• Refactored all incoming request parsing.
• Updated all HTML templates to use the HTML::Template module.
• Reorganised each available theme such that it may be easily displayed in multiple languages.

Each of these things has needed doing for a while, but I find it hard to be enthusiastic. Still the addition of new test cases should make it more interesting, and is liable to make the code correct too.

Xen-Tools

It looks like the current version of xen-tools is moving to testing today which means I should be able to upload a new revision tonight. Maybe I should stop obsessing over the migration to testing of packages? I’m not too sure if I’m helping people by trying to make sure there is a “recent” version of each package in Testing before uploading to unstable. (Mostly because I don’t run testing, never have, and know nobody locally who has told me they do.)

Games-Devel

There is a new project interested in group-maintainership of Debian games: details here. I uploaded two packages to the shared SVN repository, but otherwise haven’t done anything. It seems like lots of people have grandiose ambitions, I guess we’ll see how it works out.

Had a busy couple of weekends with Rick visiting and us doing much sightseeing. I've been too busy to blog. The weekend before the one just gone was a long one on account of Martin Luther King Day on the Monday. We spent Saturday in San Francisco, Rick and I at Camp Sysadmin, as previously mentioned, and Sarah pottered around on her own (photos here). On Sunday, Rick and I went for a reasonable (28 kilometre) bike ride around the part of the bay accessible from the Stevens Creek Trail in the morning, and in the afternoon we all drove into the hills to check out the Lick Observatory. You can see the observatory as a little bump on the top of the mountains on a clear day, but it's deceptively further away than you think, because it's actually on top of the second line of mountains, not the first. We didn't expect to find ice and snow or for it to be zero degrees (Celsius) at the summit. We made it up just before 5pm, which was closing time, so we'll have to go again earlier in the day (and more appropriately attired) to check it out more thoroughly. Some photos here. On the Monday, we did a bit of a group outing with a few other people from work, including Tanya, who is visiting from the Dublin office and also in extreme tourist mode. We took a Caltrain in to Millbrae, and then switched to the BART for the remainder of the journey. Finally, we took a cable car from Powell station over to Fishermen's Wharf, where we wandered about for a bit, and then had a nice $11 cruise on the bay for an hour and a half, which went around Alcatraz and under the Gold Gate bridge. After that we caught another cable car back downtown, wandered around for a bit, and then met up with a few more people from work for a beer, and then had dinner at a nice Irish pub that we found. Photos from that outing here. On the Saturday of the weekend just gone, we drove to Monterey, mainly with the aim to hire Segways and fang around on them. Mission accomplished, and it was very affordable too. I think we'll definitely do that again. We also need to visit the aquarium. I really liked Monterey. It reminded me a lot of Berry, on the New South Wales south coast. Photos here. Finally, on Sunday (i.e. yesterday), we drove back to San Francisco, where Sarah, Rick and Tanya did the Alcatraz cruise/tour thing, and I spent most of the time riding the cable cars and street cars. The $10 day pass purchased on the cable cars is great value, as it seems to be valid on all of the San Francisco Municipal Railway (affectionately known as the "muni"). In the afternoon, we all went on a bus tour of San Francisco (the same one Michael and I did in July, but with a different driver, and slightly different route). Finally, we had a really nice dinner at an Afghani restaurant a few doors down from the backpacker's hostel that Tanya was staying in. Photos from the day here. Rick flew out tonight, and hopefully had a good time while he was here. We're certainly feeling a bit weary from all the sightseeing, but having visitors is always a good excuse to get out and do it. Next weekend, our friend Brett is visiting from Canada. No rest, I tell ya...

About two months ago, I started thinking about a highlevel, implementation-independent networking API for Scheme. Riastradh’s TCP proposal is well thought-out, but I was thinking of something that would extend naturally to other protocols such as Unix domain sockets, or SSL/TLS. I took the TCP proposal, generalized and extended it a bit and. The result is online, I am appreciating comments! I currently don’t have the time to polish this up to SRFI-ready quality and submit it, but hopefully will do so next year. Implementation Status After harvesting some feedback from the #scheme community, I started to implement my proposal for Scheme 48 originally as patch against the development version, but since that is unfortunatly not publically available, I decided to split it off and make it work with vanilla Scheme 48 1.3. Currently, the implementation covers almost the whole TCP part, modulo some holes to fill out. For the curious and brave, there is a snapshot tarball of the code is linked from the CSW - be aware that this is in half-finished state.

We all know a long time that CVS sucks; the author of that article (in 2002) listed his main gripes with CVS: missing file renaming and not being able to remove directories. So far so I agree completly, these two things make CVS annoying to use, and everyone, even casual CVS users, will stumble upon these mis(sing) features. At that point, both subversion and what later became GNU Arch (to my knowledge, the first Free Software, distributed RCS) were in pre-1.0 versions, but becoming ready for use by the braver souls. While subversion has certainly fixed the renaming and directory problems, subversion has a fundamental shortcoming, making it an obstacle for FOSS to reach its full potential: it restrains the developer that may come along and want to experiment with the code. And no, it is not enough that the developer can checkout the latest code and submit a patch to the mailing list. This might work on projects where such patches are both trivial and quickly fed into the repository. But for more serious work, you will want to keep track of your work for yourself, either so you can review and alter the steps (changesets) done later on, or since you have to submit it piecemeal anyway. It could also happen that another, non-privileged developer wants to work on a thing that needs your modifications, before your patch has been approved and committed, or even before you are fully done with polishing it up fully for inclusion into the mainline. This other developer may also be just interested in your work and like to test it, and while doing so, he finds a little bug and wants to fix it. All this does happen in the real world, even on a large scale, e.g. with Linux distributions, and it’s called branching. The problem with non-distributed RCSs is: you need write access to the repository to create a branch. This is both true in CVS and subversion (although in CVS, branching makes little sense, as merging is a real PITA). To get write access, you have to go through whatever hurdles there may be in that particuliar project until you are deemed worthy of commit access. It is of course clear why it has to be that way: would the developers of that project grant everyone and their dog commit access, they would soon be busy with undoing the damage done by commits that don’t meet quality (or other) criteria, and not having any time left for hacking. This is not a problem with a distributed RCS, however - you simply have (typically) one person maintaining the “official” version of the source code, typically that’s the same person that rolls release tarballs. For example with Linux, it is Linus (for the development branch). That person can have their own repository, where everyone else only has read access, and selectively pulls changesets (patches) from repositories of peer developers. I hope I was able to made clear why using non-distributed RCS for a FOSS project can restrain the possibilities, limiting indivual freedom. So, if you believe in freedom (and software freedom in particuliar), consider giving a distributed RCS of your choice a try. I can heartily recommend darcs, (altough I’m not sure how it scales to bigger projects) but there are several alternatives out there. And in case you want to migrate an existing project, or give your users and developers a choice of RCS, you can use tailor to migrate your old repository, or even establish a two-way gateway between two RCS.

Sometimes, coding for the web is like having a co-worker with a body odor problem. Everyone's far too polite to say anything, so you all put up with it and nobody tells the poor smelly soul. Meanwhile, they sense something's wrong but don't know what. Web browsers are so insanely great at making sense of tag soup, that if you code only for the end-result--a reasonable strategy, adopted by most when starting out--you can get into all sorts of tangles. Misery ensues: you're stuck with days of fiddling in the dark. You know something's up, but it's hard to see what's going wrong. In that sense, browsers are lousy at one half of Postel's law. They get the "liberal in what you accept" bit right, but they don't help the developer one bit in implementing "be conservative in what you do." Using three or four different validators for HTML, CSS, etc. often helps a lot, but the state of the browser as an integrated development platform leaves something to be desired. Firebug is a Firefox extension that goes a long way to providing integrated web application debugging. It is a full-featured error console that shows your errors in Javascript, CSS (a godsend!) and XML. Not only that, but it does full logging for XMLHttpRequest calls, so it's a powerful tool for debugging AJAX applications as well. Firebug also manages to bundle in a DOM inspector, and a command line for evaluating Javascript. With these features, Firebug should let me throw out about four separate extensions I already had installed that do a similar thing. The final star turn in Firebug's act is a Javascript call to log information to its console, the equivalent of the all important debugging printf() call in C. I hope this means this will make it easier to deploy things such as unit test frameworks for AJAX applications. Although its author Joe Hewitt cautions us to remember that Firebug is still an alpha release, I'd still recommend rushing to install it. If you're developing anything for the web browser this year, it's the most important tool you'll find. While it won't rid you of the problems of cross-browser compatibility, Firebug will speed you in uncovering the smelly bits of your web application.

bpgallery is my little bash script that uses the image magic tools to generate a simple static gallery, this release has some documentation fixes (tells you how to make themes!), fixes the annoying find warnings that were happening and fixes an escaping issue with URLs. http://www.sommitrealweird.co.uk/development/bpgallery.html