Yet Another Linux Blog

First I followed the ModularDevelopersGuide, using their script to get the Xorg sources via git. I had to install the git-core package first. This pulled down the whole Xorg src tree.

Then I followed this Xgl compilation guide. Install the cvs package, and use it to get cairo glitz and Mesa. You already have compriz and Xgl inside the Xorg src.

Build cairo glitz as on the page I linked. You’ll need to install the autoconf and automake and libtool packages. Use sudo update-alternatives --config automake to make sure you’re using autoconf1.9.

* autoconf –version must report 2.59 or later
* automake –version must report 1.7.x
* libtool –version must report 1.5
* pkg-config –version must report 0.9.0 or later

Next, we buld mesa 6.5. In order to get the make command to complete, I had to install the

sudo apt-get install x11proto-*

packages from beerorkid’s repo. In the process, I think I managed to update ~20 other packages from his repos, but now Mesa builds. Of course, one of his packages IS the Mesa 6.5 build…

Next we want to build compriz, still following the guide. I have to install libglib2.0-dev in order for compriz to build.

Then something else didn’t work, and I got fed up, and I just installed the compiz-gnome package and then Xgl wouldn’t build so I just installed the xserver-xgl package.

And then I found a nice summary of how to set this up for my ATI card: http://www.compiz.net/viewtopic.php?id=389

So the main difference between apt-get install packageX and aptitude install packageX is that aptitude will also install all of the packages that packageX recommends, which apt-get will merely mention them. Aptitude will also add those packages to its own database and remove them if you remove packageX. Aptitude will also remove the unneeded dependencies that were automatically installed when you installed packageX, essentially integrating the functionality of deborphan. Here’s a more verbose description: Aptitude page at Psychocats.net

Also, it turns out that Synaptic doesn’t remove dependencies when you remove a package either, and that feature will be implemented soon: Launchpad spec. I’m not sure what all the fuss is about. I can probably count on one hand the number of times i’ve removed a package from my system, much less cared about unused dependencies sitting around on my disk. It’s better to leave them there than to ever need to re-download them. I don’t know who these users are that keep removing programs and their dependencies from their systems.

I decided to take it upon myself to help solving this bug in tar: Debian #377330. I was unable to reproduce the error on a clean install of Debian Etch on my spare AMD64 machine, so I decided to check if it might have something to do with the filesystem, as suggested in one of the bug comments.

Turns out that the Debian installer doesn’t work properly when you make the root partition XFS. Both grub and LILO errored out while trying to configure the boot sector. Worse yet, trying grub-install again locked up the machine completely. After some searching of the bug repositories, I was unable to find a current bug reporting this issue, but was able to find bugs from 2004 and 2005 for this same issue. I went with the workaround suggested in #debian on freenode, which was to use an EXT3 boot partition. This same problem is inherited in the current Dapper installer.

Running the “make check” on top of XFS also didn’t produce an error.

… as old as emacs vs. vi!

I spent about an hour today learning how to use the info pages.
info info

The Info reader seems to be based on emacs and has very similar keybindings, compared to man, which has keybindings similar to vi (and less and more, etc). Thus, a lot of the eternal emacs vs. vi discussion applies. From the Debian tar manpage:

The GNU folks, in general, abhor man pages, and create info documents instead. The maintainer of tar falls into this category. This man page is neither complete, nor current, and was included in the Debian Linux packaging of tar entirely to reduce the frequency with which the lack of a man page gets reported as a bug in our defect tracking sys‐tem.

If you really want to understand tar, then you should run info and read the tar info pages, or use the info mode in emacs.

Problems with this man page should be files as bugs against the Debian tar package, not submitted to the tar maintainers.

22 September 1993

However, no one but the GNU folks use Info for their manuals. On the plus side, typing info apt-get gets you a reformatted man page, since an info page is not available. At least there’s this graceful failure mode.

The great thing, IMHO, is the excellent documentation that doesn’t leave you stranded. You can sit down any new user and have him/her spend the day reading man man, info info, and working with vimtutor and with the emacs tutorial, and they’ll learn quite a bit about how to get around the OS. However, I think I’m still more of a vi fan. Once you learn vi keybindings, you get all of the man and less functionality for free, while even if you know emacs, the Info reader has some additional keybindings that are not standard emacs keybindings.

On the other hand, emacs is considerably more powerful than vi if you know LISP, because then you can easily extend the emacs functionality using ELISP. Vi’s scripting language is less standard (although it also supports scripts in Tcl, Perl, Python and Ruby).

The downside of all this is, of course, the steep learning curve. There is no way that my parents would be willing to invest their time into vimtutor or the emacs tutorial. Even for an enthusiastic computer user, these requirements may be too much.

The menus and cross-references in the info pages are nice, but they were invented before HTML and didn’t really catch on. I believe that today, there should just be a concise man page, and then nice HTML documentation instead of the info page.

My opinions were formed after using Ubuntu Hoary/Dapper on a number of platforms, the most notable of which were a Dell Inspiron 600M with a Radeon Mobility 9000 GPU and a Compaq SR1710NX with ATI Xpress 200 onboard video.

Conclusion: If you want the least hassle with video/X/OpenGL issues under Linux, make sure you have an NVIDIA card.

I won’t bother to go into too much detail here, suffice it to say that I’ve had nothing but problems with ATI hardware/drivers and no problems with the NVIDIA hardware/drivers. The open-source ATI drivers may be better than the open-source NVIDIA drivers, (both part of the Xorg project,) but they really only support a small subset of ATI chips (IIRC the R200- and some R300-series GPUs).

Today is a good learning day:

1. I refreshed my memory about RAID levels, because someone mentioned that it’s a good interview question.
2. I saw another (older) Lessig lecture, from OSCON 2002, and read up on the differences between the CC licences. I would probably choose Public Domain for my writings.
3. I watched the SICP lectures 1a,1b,2a,2b again. I’m still slightly confused by the construct with two lambdas in it.

I listened to a lecture that RMS gave in NYC. It was his usual Free Software speech, but with a few new plot twists which I haven’t heard before. I’m surprised that he can come up with so many stories to illustrate the same lessons in his talks. Get a copy of the video or the audio here: http://punkcast.com/905/.

Meanwhile, I’m working on a Ruby on Rails app. Here’s a couple of scripts that I’ve found helpful:

1. svnrails.rb (original).
2. svncommit.rb (original).

The first script will create a new rails app, import it to your repository, and check out the trunk. Use it like so:

The second script will commit all of your changes after you edit some files. Run it from your rails app directory.