The Fugue

I had a heck of a time getting VMWare Server running on Ubuntu 8.04 (Hardy Heron). The problem is that the vmmon and vmnet modules fail to build against kernel 2.6.24. A little googling quickly reveals that you want the any-any-update patch, but that didn't work for me either. To be specific, vmware-any-any-update117c.tar.gz did not work. It turns out vmware-any-any-update-116.tgz works great. Maybe 117 is for the 2.6.25 kernel or something.

So, you do the vmware installation except for the vmware-config.pl step. Then you download and extract the above tarball and run runme.pl. Simple enough.

But when you try to run it, you get errors like this:

/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)

I'm not sure what the right way to fix this is, but this way works for me.

sudo cp /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/

I have two soundcards in my desktop: the built-in soundcard which uses the snd-via82xx module, and the nice soundcard which uses the snd-cs46xx module. Naturally, the speakers are plugged into the nice card.

When I installed Ubuntu 8.04 from scratch, the VIA card started showing up as the first card, and therefore the default card. (You can tell by looking at /proc/asound/cards.) I created the following /etc/asound.conf to remedy that problem:

pcm.!default {
  type hw
  card CS46xx
}
ctl.!default {
  type hw
  card CS46xx
}

Ok, so now all programs using ALSA's default device automatically go to the right soundcard. But apparently using the default device is too much to ask of some software, which apparently hardcodes hw:0 or (even nuttier) hw:0,0.

So what I really wanted was to fix the order problem, so that the VIA card doesn't steal index 0. On Ubuntu at least, the fix is:

echo 'options snd-via82xx index=2' >> /etc/modprobe.d/alsa-base

Now my /proc/asound/cards always looks like this:

0 [CS46xx         ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0xfb122000/0xfb000000, irq 20
1 [UART           ]: MPU-401 UART - MPU-401 UART
                     MPU-401 UART at 0x330, irq 10
2 [V8237          ]: VIA8237 - VIA 8237
                     VIA 8237 with ALC655 at 0xec00, irq 21

Back in the day, I cared about having my kernel as a Debian package. I used kernel-package, and I was happy. Then I started wanting to compile vanilla kernels and eventually the overhead just got to me and I stopped using it. I was not using kernel-package, and I was happy.

Recently, I revisited kernel-package for some reason I can't now remember. Wow, it has come a long way. Now it works with vanilla kernels, no fuss. Now it builds initrd images with a single command line option, no fuss. Now it is even easier than just building the kernel by hand (because I don't have to reconfigure the kernel from the stock kernel after make oldconfig due to the lack of initrd (no, I will never even try doing an initrd by hand)).

Here's all you have to do:

# download kernel source
cd linux
make oldconfig
# make menuconfig 
fakeroot make-kpkg --initrd kernel-image kernel-headers
sudo dpkg -i ../linux*deb<tab>

I spent some time over the weekend with git yesterday, so I finally have an opinion about it.

Distributed revision control systems are absolutely fabulous. If you haven't given one a serious go yet, you really should. My favorite is darcs. This post will address git from the perspective of a darcs user, and I might throw some comparisons to CVS or Subversion in, too.

git is really a lot easier to use than I had anticipated. I read lots of warnings in the documentation about how git is stupid (by definition, this is one of its goals) and how unless your needs are a lot like Linus' needs, it won't be right for you. I've found that to be unnecessary modesty. git is very usable as a distributed revision control system for normal people on any size of project. It's not as nice as darcs, IMO, but it does have better performance for large projects, and it doesn't trail far behind anyway. It's a lot nicer to use than GNU Arch, even in its raw form.

git pretends not to be an SCM, but rather a "filesystem". Whatever. git was written to do what Linus needed from an SCM, and it has never had any other purpose. Although it is conceivable that git could be used for other things, as it is quite general and flexible, that doesn't make it not an SCM. It certainly is like no SCM you've ever seen (at the low level) but it's still basically an SCM.

Nevertheless, if you look too close at git you'll be either overwhelmed by the sheer volume of low-level filesystem-like commands, or thrilled by them. However you don't need most of them, and if you ignore them you can enjoy git usability, with the added security of knowing that should you need to doctor your repository (or have a git guru do so) all the low-level commands you need are there. That is a bonus in my book, but mostly theoretical.

I think originally git had fewer scm-like commands and so people wrote Porcelains, like Cogito. Cogito is supposed to be easier to use and a more perfect SCM built on top of git. Frankly, I can't tell the difference between Cogito and git core, except that git core has more commands and options. Cogito does use slightly different terminology and command names, which only confuses the game. I think I'd rather learn the git commands and options that I need from well-written documentation and ignore the rest, than confuse myself with cogito. After only an hour or two of experience, I may be really missing the boat, so you might want to check it out anyway.

Compared to darcs, git feels very familiar. darcs' UI is more polished, but git has a much richer set of commands. One primary difference is that git does branching, where in darcs a branch is basically a new copy of the repository. Both are valid approaches, but the git approach does take less disk space (and network bandwidth) which is important for 300-400 megabyte repositories, like the kernel. I think I will probably continue using darcs primarily, but I will probably try out git more in earnest when I get a chance to see if it might be time to switch.

One thing I do not like about git is the tendency people have for providing their driver for hardware X in the linux kernel as a git repository. Hello! Nobody wants to download 350MB for your 10k of changes to the kernel. Nobody wants to run your bleeding edge git repository just so they can get your driver. That's idiotic. git makes it easy to make patches against whatever revision you want, so make patches against the latest stable kernel, or whatever RC version if necessary, and call it good. Providing access to your git repo is fine for developers, but don't expect it of users.

In summary, I will be using git for my kernels from now on. It will be easier to move around between versions, save me disk space, and allow me to do minor hacks without worrying about them surviving the next kernel upgrade patch. If I didn't already know and love darcs, I'd start using git for my projects. If you have wanted to investigate distributed revision control, check out darcs and git and go with whichever your gut tells you to, I think either one will serve your needs well. For heaven's sake, stop using CVS in any case!