Ubuntu 10.04: Pulseaudio, nfs, automounter and my dismay

I upgraded to Ubuntu 10.04 last night. Ouch.

My first problem was that, suddenly, the automounter was going totally berserk. It would randomly mount/unmount all of my NFS filesystems. I couldn't do anything.

This morning, I found the solution to that problem, but that only served to further confuse me: pulseaudio was freaking out over not being able to create a file under ~/.pulse. I deleted that directory and suddenly my automounter worked again... OK, that's spooky. I'm assuming that pulseaudio was loading audio drivers on startup and the fact that it kept re-starting meant that the module interface was constantly being banged around, resulting in poor service for any calls to loaded drivers. Surprising my system was stable at all, if that's the case.

Anyway now I'm finding lots of horrible little problems:

• Rythmbox used to hide itself when you clicked on its notification icon... no longer
• Pidgin seems to have been put into tabbed window mode by default which is painful
• Evolution seems to squirrel your password away and use it for the password to your keychain... this means that when your password changes, you have to remember the old one in order to access your saved passwords. It seems like this should at least come with a big red button labeled ("just start over") so I can stop having the password dialog box pop up.
• System services are no longer managed by the standard init.d script interface. Joy, a non-standard init. Just what I needed.
• Process names are getting more and more absurd. The fact that something is running on my system called rtkit is deeply wrong. I nearly had a heart attack before I googled for it (of course, it's not alone: liboobs was one I saw scroll by as I was installing)

Overall, 10.04 does not impress me. It seems to have been put together as a way to prepare for future updates rather than as a stable starting point for long term support.

PS: Another issue just cropped up: outbound mail from evolution seems to have been silently failing all day. I finally realized that people weren't getting my mail and went to check the settings. Sigh.

Git, BitKeeper and the Power of Open Source

Update April 2012: The comparison page that I reference now just mentions "other SCM", but a side-bar continues to compare their product only to non-distributed, circa 1980s and 1990s offerings.


Back in the mists of 2002, debate ran hot in the Linux development community. The debate was over a proprietary source code management (SCM) tool called BitKeeper that was used as the primary SCM for the Linux Kernel. When a dispute with the vendor resulted in a schism between the Linux developer community and BitKeeper in 2005, the tool was dropped in favor of a replacement written by Linus Torvalds over a one-month period. To understand the importance of this achievement, understand that BitKeeper was written by eight developers over the course of three years and McVoy, its primary architect and original developer estimated that it would cost $12 million to do it again in an ordinary, non-startup company.

Instead, Torvalds sat down behind his keyboard and set out to replace it. How successful was he? If you look at BitKeeper's comparison page with other SCM tools today, you'll notice that it compares itself to many other tools (and makes quite a few rather large errors along the way), but none of them is git. In fact, none of the list are any of the next-generation tools that have followed in git's wake such as Bazzar or Mercurial. Why? Well, git is simpler, easier and better. It also happens to be radically faster. There's no point in comparing yourself with such a tool in public, since it's only going to make you look bad to say that the free tool is radically better.

McVoy also made the claim that a replacement for BitKeeper wouldn't be possible because it was too hard and programmers capable of doing the work wouldn't do it for free. Why is this? Well, it comes down to graph theory and its application to text revisions. Recognizing text differences is hard enough, but to extend that to maintaining a directed acyclic graph of revision histories and branches in a distributed way... well that's downright hard. Sure, it's hard, but then so is writing a POSIX-compatible kernel. The fact that there are now three excellent options out there for distributed source code management that excel at doing just what McVoy said would be impossible to reproduce should go a long way to demonstrating that free and open source software development is one of the most powerful new paradigms of engineering to come along since the invention of the functional specification.