Remember The Chroot

Today I forgot that Postfix runs in a chroot by default on Debian. If you change files like /etc/resolv.conf or /etc/hosts, it has no effect on Postfix, unless you refresh the corresponding files in the chroot. Wasted quite a few minutes before the clue bat descended and gave me bruised ego. Stopping and starting Postfix (with postfix stop and postfix start respectively) provided the clue as the start command helpfully reminds you that the chroot is out of date.

It's good thing that this was on my own server so there was no customer watching me chase a problem caused by forgetfulness. Must be getting old. ^_^

Was It Worth The Effort?

Was it really worth all the considerable effort that went into developing KDE, GNOME, and the other less well known desktops environments?

Considering that Linux desktop usage has grown very slowly despite all the desktop environments becoming reasonably useable, it does seem likely that it is not the DE that is the problem. No matter how good the Linux desktop becomes, they are never going to be as familiar as Windows.

There are probably more people using Linux on mobile devices (without even realizing it) than there are Linux desktop users. Which only strengthens the question: why waste valuable developer resources on desktop environments?

Since I don't use any desktop environment, you may take my opinion with a liberal amount of salt.

Linux Kernel Versions

In the old days (^_^) kernel versions went like this: even minor versions (e.g., 2.0, 2.2, 2.4) were stable kernels; odd minor versions (2.1, 2.3, 2.5) were development kernels. The patch level, a third component of the version, indicated a bug fix release in the stable kernel, or a testing release in the development kernel.

All that changed in 2.6 when the kernel developers switched to distributed version control, first propriety BitKeeper, and then git. Everyone developed asynchronously on their own copy of the kernel source. Linus pulled changes from these distributed sources into his own tree and made release which were numbered 2.6.1, 2.6.2, 2.6.3, etc,.

Bug fix releases add a fourth number: 2.6.4.1. That always looked silly to me because the development and maintenance process hadn't changed that much to warrant extending the version number.

Today, 2.6.39 became the last 2.6 kernel because Linus released 3.0-rc1, in preparation for a 3.0 stable kernel. Future stable releases will be numbered 3.1, 3.2, 3.3, etc., and maintenance releases will be 3.0.1, 3.0.2, etc. I suppose there will even be a 4.0 at some point.

Linus was adamant that there would never be a 2.7 kernel. He was right. But something had to done about the version numbering. It was just silly.

Post Apocalyse

This morning my desktop computer, which runs Debian unstable, wouldn't boot. After a couple of hours, I tracked the problem down to a misbehaving udev package (version 169-1). Downgrading to version 168-2 solved the problem.

Just for once, I wish there would be an actual global apocalypse, then I wouldn't have to worry about fixing my computer just because I need to do some work. But I'm not that lucky. ^_^

Patience

Although it is obvious to anyone who has tried to use the open source drivers for the AMD R600-based devices, these Phoronix benchmarks show just how bad things are. And those tests were performed with the most absolute blending edge pre-release versions of all the software involved. In other words, it going to be a long, long time before any improvements show up in a release version. Patience, have you must.

You Broke My Eye Candy!

It is a fact that the Mesa OpenGL support on Linux is currently a bleeding edge work-in-progress.

Now, I can understand getting a little annoyed when it breaks. I've experienced this myself. However, it has never upset me to the point where I have to vent in a long rant. And, it would be completely over-the-top if the rant is about how Mesa broke my compositing window manager, which is basically just eye candy.

And yet, that is exactly what the lead developer of KWin felt he needed to do. Some people take their eye candy very seriously. I liked the one response which suggested turning off the eye candy until Mesa is a bit more stable. Well, duh!

Hiccups

I've developed a new problem with the Xvideo rendering system. The movie will jerk occasionally, usually during slow pans or tilts. The cause must at a low level as mplayer is not giving the usual, "Your system is too slow to play this," message.

I first noticed the problem with the final release of 2.6.37 but it exists in the -rc7 release as well, although the effect is a lot less frequent. I'm going to try the 2.6.36 kernel next. If the problem occurs there as well, I'll know that the cause is not the kernel, because 2.6.36 worked perfectly before.

Sigh. I'll be glad when the AMD graphics support stablizes a bit. It is improving but there are plenty of hiccups (literally, in this case) along the way.

Life With Debian Experimental

The BZFlag fest last weekend was the first time I had used the 3D capabilities on my AMD R600 based card continuously for an extended period (e.g. more than an hour). The good news it worked. The bad news I had several GPU lock ups. In most cases the kernel driver's watch dog timer detected the lock up and reset the GPU, but on two occasions this safety feature failed and I had to hit the big red button.

After the second hard lock up, I checked Debian experimental for updates to the various libraries I am using to get the R600 to work. Lo and behold! There were several! I did not have another lock up after installing the updates, but this may just have been a fluke. It is hard to tell if the updates actually had any effect at all, really.

I must remember to check for updates in experimental regularly as it is not handled automatically by the package management system. This is a small safety feature as experimental packages could easily trash your system. This is life with Debian experimental.

Work Around

I found a work around for the joystick problem by force loading the joydev module. I still have no idea why this module loads automatically with a 32 bit kernel but not a 64 bit kernel, even though the 32 bit user space is identical. My Google-fu has not found anything yet.

First oddity I encountered with a working joystick attached to the system, was that MPlayer assumed the joystick was some sort of remote control. It wouldn't be a problem if MPlayer did not automatically disabled the keyboard control, when it detects a joystick. Digging through the MPlayer man page, an "-input js-dev=none" argument solved the problem.

The joystick works with Extreme Tux Racer, BZFlag, and TORCS, which is heaps of fun. Flightgear, which is the reason I got the joystick, isn't running properly for some reason, which is a bit annoying.

Linux Mystery

I bought a joystick for use with Flight Gear. It's just an average joystick judging by the reviews but it is known to work with Flight Gear, and it was on sale. Believe it or not, this is the first joystick I've ever used on Linux.

The kernel recognised the joystick immediately but the udev daemon failed to create a device node in /dev. The kernel was 2.6.36 from Debian experimental. When I rebooted into the 2.6.32 kernel from sid, everything worked correctly. But, the kernels were different in one other respect. The one from experimental was 64 bit while the one from sid was 32 bit.

In order to be sure, I compared a 64 bit 2.6.32 from sid and a 32 bit 2.6.36 from experimental. (It's really great to able to swap kernels so easily.) After the test, it was clear the joystick only had a problem in the 64 bit kernels, regardless of version. Note that it's perfectly normal to run a 64 bit kernel with a 32 bit user space.

Despite narrowing down the problem a little, Google did not turn up anything useful. While it is possible that it's an undiscovered problem, it is much more probable that it is specific to my system. As to what the problem might be, I still have no idea yet. It's another Linux mystery. ^_^

Long Live Desktop Computing

Even as people are declaring that Linux on desktop is dead, Linux still runs fine on my desktop computer system. Of course, now some people are saying that it doesn't matter that Linux isn't taking over on the desktop, because desktop computing itself is dead.

Supposedly, people will be using their tiny little hand held computers to access their computers in the cloud, where they will do all the same things they did on their desks systems. On their tiny little hand held devices? Seems a bit optimistic to me.

Anyway, there should choices. And I choose to stick with a my archaic desktop computer, thank you very much. Now get off my lawn!

Linux, KMS, 3D, ATI, Oh My!

Yesterday I realized that accelerated 3D rendering no longer worked on my ancient ATI R200 based card. After some experimentation, I discovered that ATI accelerated 3D graphics now requires Kernel Mode Setting (KMS) to be enabled. This was a huge problem because Xv, the X accelerated video rendering system, has diagonal "lightning strike" tearing when used with KMS. I really wanted 3D back, though, so what to do?

Today, I was bored with work, so I decided to play with the ATI R600 based card which I bought way back in the spring. Initially it was very disappointing. The X server crashed almost immediately which was a regression from earlier tests: not a good sign!

Examining the system logs indicated that the problem appeared to be in the kernel, not the X server. I've been running a 2.6.34 kernel from Debian experimental and it so happens that a 2.6.36-rc6 kernel was available. Installing the newer version fixed the X server crash! Yay!

Accelerated 3D rendering now works on the R600 card but what about the tearing in Xv? Frankly, it was a bigger concern than 3D. If Xv didn't work, I would have to go back to the R200 card, which still supported an Xv mode that worked without KMS, and all this effort would have been for naught. So it was a great relief to discover that the Xv tearing problem has been fixed on the R600 card. Double Yay!

It's not often that one accomplishes anything while avoiding work, so I'm quite pleased with today's efforts. It's been a good day!

ATI 3D On Linux

According to this article, the open source 3D drivers for the older ATI R300-R500 graphics processors are much more mature than the newer generation R600/R700. I suspect that this indicates the age of the hardware that most developers own, but I could be wrong. I wish that I had known this before I bought an R600 based card. ^^

Not that it really matters, as cards using the earlier generation processors are quite difficult to find, unless you go the Ebay route. I'm still leery of buying electronics on Ebay. Call me paranoid...

3M Touch Screens

I had to configure a 3M touch screen on Debian 5.0 (lenny) for the embedded PC rebuild project. The short story is that the touch screen works. The long story is that it is kind of quirky.

The download is a .zip file. When you unzip it, you get a .bin file. When you run the the .bin file, you get the EULA. When you accept the EULA, you get a .tar.gz file. Feels like a Matryoshka doll! Why not just have the EULA on the web site when you request the download?

Why is it necessary to modify the the xorg.conf file? The file is changed not just once, but every time the system boots, and on every shutdown. I could forgive this odd requirement if the modified configuration file actually worked! Although the modified xorg.conf file is syntactically correct, the X server won't use the touch input unless you add the device to the ServerLayout section.

While I appreciate 3M's effort to provide a Linux driver, it feels like it wasn't designed by someone with a lot of Linux experience.

A Little Too Optimistic

My expectations of the open source support for more recent ATI GPUs was a little too optimistic. I bought a card based on the Radeon 3650 GPU which is released in 2008. I had no problem with basic 2D support. The first sign of trouble was when mplayer stumbled rather badly. The X server does not have Xv Video Overlay support for the 3650, which might be the problem.

3D support was much worse. I couldn't get a single 3D application or game to run properly. I was so hopeful that the ATI support was getting better, but it looks like it has some ways to go yet.

There may be tweaks one can use to get it working better, but I ran out time today. Since I depend on mplayer to work properly, I put the old graphics card back for now. I try the new card again after the next X server upgrade.

Old And Slow

I started playing with with 3D modelling software (Blender, Wings 3D, and MakeHuman) and was graphically (pun intended) shown just how old and slow my ATI 9250 graphics card really is. The older GPU has are several problems which are individually tolerable, but, when taken together, you've basically hit a wall.

I'm shopping around for a replacement card. I have three basic constraints: I'm on a very tight budget, I want an ATI GPU, and it must be an AGP card. AGP?! Yup, I'm not replacing the motherboard yet (see constraint #1) so that's the way it has to be. An older design such as this ATI 3650 should be adequate.

Nvidia may offer better performance but that really only matters to serious gamers. Nvidia's closed source Linux drivers are actually very good, but since AMD released the programming documentation for ATI GPUs, the open source drivers for have been improving slowly but steadily. They are far from perfect yet but with proper documentation available, it's only a matter of time.

Udev Rules! Not!

If someone tells you how great Linux is, they've probably never had deal with odd ball situations. Take udev, for example. Please! Take udev! I'm begging you! ^_^

I'm using the 8-in/8-out version of this USB I/O unit on a project. This hardware doesn't require any Linux kernel drivers which make me very happy. The manufacturer provides the source to a library which uses libusb to communicate with the device. The device does not store the firmware permanently so it must be downloaded every time you plug in the hardware. One quirk is that after the download, the device disconnects and reconnects with a different product ID, but the manufacturer includes udev rules to handle it.

My big mistake was that I setup the hardware on my desktop system, which is running Debian sid/unstable, before trying it on the production PC, which is running Debian lenny/stable. The configuration requires two udev rules (which are slightly different that the manufacture's version)

SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="001c", RUN+="/sbin/fxload -t fx2 -D $env{DEVNAME} -I /usr/local/lib/USB-IDIO-16.hex"
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="801c", GROUP="aiousb", MODE="664"

Of course, thinking that I could just copy this configuration over to the production PC, was just too optimistic. The first line works (the firmware is downloaded) but the second line doesn't set the device file group which is stuck as root.

After some (understatement! ^^) investigation, I found that the following udev rule on Debian lenny was causing the problem.

SUBSYSTEM=="usb_device", ACTION=="add|change", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", ACTION=="add|change", NAME="$result"

At first I changed my custom rule to match the SUBSYSTEM and ACTION attributes, which worked for hotplugging and cold boot, but not for a warm boot. On a hunch I added the original rule back again, which worked!

The final rule set looks like this:

SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="001c", RUN="/sbin/fxload -t fx2 -D $env{DEVNAME} -I /usr/local/lib/USB-IDIO-16.hex"
SUBSYSTEM=="usb_device", ACTION=="add|change", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="801c", OWNER="root", GROUP="aiousb", MODE="0664"
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="801c", OWNER="root", GROUP="aiousb", MODE="0664"

It looks a kind of clunky, so there is probably a better way to do it, but I'm way past the limit of my udev-fu, so I not going to poke at it any more. I'll worry about it when it stops working. Which will be at some inconvenient moment, I'm sure. udev works great, until it doesn't. ^_^

Disabling Radeon KMS

Kernel Mode Setting (KMS) for the ATI Radeon RV280 chip is not ready for primetime yet so i decided to disable KMS and revert to User Mode Setting (UMS) for now. KMS is the future but it is too immature on the Radeon hardware. Now, how do I disable KMS?

First I changed /etc/modprobe.d/radeon-kms.conf to

option radeon modeset=0

Then I ran update-initramfs -u to copy the change into the boot RAM filesystem, and rebooted. For some reason that doesn't disable KMS. Hmm. Figure out why or find another way? Door number two please.

Next, I added the kernel parameter nomodeset in /boot/grub/menu.lst. Run update-grub and reboot. Nope. KMS is still enabled. Hmm. Figure out why or find another way? Door number two please.

Next I replaced the nomodeset kernel parameter with radeon.modeset=0, again in /boot/grub/menu.lst. Run update-grub and reboot. Ding ding ding, we have a winner! Phew! Pant, pant!

It should be abundantly clear that KMS in the Radeon driver is a work-in-progress when disabling it takes that much effort. ^_^

Kernel Mode Setting

It looks like Kernel Mode Setting (KMS) for ATI chipsets has arrived on my Debian sid desktop system. As usual, I only realized this was happening after mplayer started complaining about the system being to slow. Errors in the X server logs revealed that indeed the Direct Rendering Infrastructure (DRI) was not working. Without DRI hardware acceleration, mplayer is definitely going to have trouble playing 720p video with soft subtitles.

This article indicated that the X server version was OK but I needed the latest Debian kernel package (2.6.32-10), which did indeed fix the DRI error and made mplayer much happier. However, it is not perfect. There are now artifacts appearing in the video during fast pan or tilt scenes. Even in an xterm, rapid scrolling results in noticable discontinuities.

The article mentions needing new microcode for the graphics chip. I haven't yet discovered if such microcode actually exists for the ancient R280 chipset on my ATI 9250 card. Or the problem may lie elsewhere. More digging is required. ^_^

Robotic Sailboats

Although I'm a dedicated land lubber, the technology in this robotic sailboat is interesting because the control system runs Linux. I assume (being a land lubber ^^) that controlling a sailboat isn't quite as easy as a powered boat, so it's impressive in that regard as well. A little bit of Googling turns up a few other examples (IBoat, Pinta, SPIN) and there is even organized competition.