Milan Zamazal's Weblog

Ubuntu fixes the most important problem of Debian: its slow release process. Now, about half a year after the latest Debian release, I already move slowly from stable to testing and unstable. Not without reason, most often because new software versions fix bugs of their older versions in stable. More frequent operating system distribution releases can help to deal with that problem. I don't know whether Ubuntu is more stable or less stable than Debian, I don't use it regularly. But I know I've already installed Ubuntu instead of Debian more than once, because the more than two years old software distribution didn't run on new hardware or didn't provide software satisfying contemporary requirements. Ubuntu is natural choice then – it is very similar to Debian and it retains one of its big advantages providing completely Free Software distribution.

But I personally can't move to Ubuntu. The major problem of Ubuntu I can see immediately is its limited scope. Some Debian packages are unavailable for Ubuntu and most Debian packages are not present in the officially maintained part of Ubuntu. This is very different from Debian, offering a huge amount of officially maintained packages. I install new pieces of software frequently and with Ubuntu it might be very time consuming and tedious.

There were old good times when one could install magicfilter on his GNU/Linux system and send a file to a printer and the printer printed the file as expected. Since I started to use CUPS a few years ago it's no longer true. Whenever I send some PostScript or PDF file to my printer, I'm full of tension about what the printer will produce. Sometimes I receive output looking like printed at 50 dpi, sometimes the page content is scaled by factor 2 horizontally and/or vertically, sometimes characters kernings are broken. Whether it is an e-mail, a Web page or a PostScript document, I'm never sure that I can print it usably. I often start printing by printing a test page, because what I can see in gv may not be what I receive on the paper.

I can understand that new drivers need debugging, which is the case of printing images with Guttenprint for example. I appreciate the hard work of people who try to provide their best, equipped just with incomplete specifications (if any specifications are available at all) and with testing and reverse engineering reports from voluntary testers. But I really don't understand why people invent new great things which simply can't work as before, which produce the same broken result on any printer and won't get fixed for several years.

If you laugh now and point to other operating systems, calm down. I've recently tried to install Epson Stylus Photo R220 drivers on a Windows system and tried to perform nozzle check from it. When I perform nozzle check using the printer's buttons or with Guttenprint on Linux, the printer just prints the testing pattern. Not so with the Epson Windows drivers, which add (without warning) an extra action before printing the pattern: an excessive head cleaning which wastes about 6% (!!) of the complete ink amount of full cartridges. Now I can understand why so many people complain that Epson printers waste a lot of ink.

IIRC, I've been running Debian GNU/Linux on my primary workstation since summer 1995. All that time (almost 11 years!) the operating system ran without any single reinstallation, starting with the Debian 0.93R5 version and ending with mixed sarge-etch (post-3.1). I only performed upgrades, I've never reinstalled the system from scratch. None of the upgrades required immediate reboot as used to be (or even still is) required by some other operating systems. The system survived all the upgrades (including numerous development versions), kernel failures, user failures, experiments, hardware changes, etc. running daily or even 24 hours/day. Such a stability is exceptional and it proves that stability is indeed one of the primary Debian features and that Free Software is a very stable and future-proof platform.

The operating system is being reinstalled now. It's not because of its instability, the system still runs and can continue to run well, but my primary workstation gets upgraded to an incompatible hardware architecture (64-bit system). So I can't simply copy my operating system from the old hard drive to the new one as I used to do on all the former hardware (disk) upgrades.

After spending total amount of several dozens hours of fighting with the infamous udev arbitrary device name assignment, I've finally won. Device name assignment is absolutely underdocumented and I was able to get it work only thanks to the kind people sharing their experience and knowledge on the net. For the record, after a lot of googling and experiments I ended up with the following setup of the multiple network and sound cards on my Debian system:

• In module configuration:

options snd-... index=0
options snd-... index=1
options snd-... index=2

This ensures ALSA devices are assigned to the defined positions.

• In /etc/udev/udev.rules:

KERNEL=="eth*", SYSFS{address}=="00:11:22:33:44:55", NAME="wan"
KERNEL=="eth*", SYSFS{address}=="ff:ee:dd:cc:bb:aa", NAME="lan"

Note:

• Matchers have two equal signs, assignments only one.
• Hexadecimal digits of the MAC address in 'SYSFS{address}' must be written in lower case. Stupid, stupid, stupid.

Then the network devices are accessible under the names 'lan' and 'wan' and you should use them in '/etc/network/interfaces' instead of 'eth0' etc.

Linux has always been a nice free and stable operating system. But from the user's point of view it was somewhat primitive and lacking some basic features. Perhaps that was one of the primary reasons why GNU continued to develop another operating system, the Hurd.

But things have recently improved a lot. By integrating FUSE into the official Linux distribution and Linux-VServer into Debian Linux kernels, two important Linux limitations are mostly gone.

FUSE allows users to create their own virtual user-space file systems. That means the elegant facility provided by Hurd translators is available in Linux now too. It's finally possible to mount remote directories transparently, to create usable automounters, to implement new file system features in high-level programming languages, etc. and that all without root privileges.

There is still a missing feature though. FUSE currently provides only active translators that require explicit startup and do not survive the next reboot. Passive translators, i.e. permanent translators started automatically when their mount point is accessed are still not available. Hopefully they will be added to Linux too.

Linux-VServer allows you to use several virtual machines on a single hardware. It's something like running new Hurd instance inside another already running Hurd instance. Linux-VServer, unlike hardware emulators, allows separating independent tasks without any significant burden on the hardware – the CPU, RAM and disk usage overhead is negligible. With your processes running on different virtual machines, you are more protected against both accidental and intentional failures. For instance your web server can always run on a dedicated computer (as it should) without the need to dedicate it actual separate hardware. Then you can safely upgrade each service separately without the danger to damage other services and with the possibility to roll back to the original version immediately.

With Linux-VServer (or similar projects) hardware can be used more efficiently. Instead of having a lot of physical computers being most of the time idle you can build a few bigger physical machines running a lot of virtual computers for many users and uses. I didn't like the single big machine approach before because it required interaction with sysadmins. User: "Would you upgrade Emacs installation there, please?", Sysadmin: "What is it Emacs?", U: "It's a text editor.", S: "I don't use it.", U: "Would you still upgrade its five years old installation, I need new Emacs features.", S: "No, it could break.", U: "Hm, hopefully I won't reach my $HOME quota this time…". With Linux-VServer, the user can safely receive his own virtual computer and run his own operating system of his choice on it without messing with other users (and sysadmins, most of the time).

Linux-VServer is still immature, especially it lacks proper documentation, but nevertheless it's already very useful. Both FUSE and Linux-VServer are promising and give us a hope that a free and usable modern operating system will be available sometimes.

Well, not only proprietary drivers are crappy, they are just more crappy than anything else. Free software sometimes suffers from serious problems too.

I use a dedicated virtual machine to manage my printing services. One of the reasons I've put it on a separate machine is stability: While software on my other machines is updated, the printing server can remain untouched.

Now I know I can't expect that kind of stability from CUPS. I often upgrade my workstation. Suddenly printing from GIMP and PhotoPrint stopped working with the error message saying something like "Bad IPP request". After some attempts to find out what's wrong I've found that my CUPS client is of newer version than the CUPS server. Great – unless you use the same client and server software version on your network, CUPS may not work. So I had to upgrade the CUPS server, just because a workstation happened to use newer client version.

The CUPS server upgrade wasn't without trouble. Together with the 1.1 -> 1.2 transition the main configuration file was changed. Well, that's OK (only if I wasn't forced to fiddle with new configuration right now because of the client software update!). But I couldn't access the printing server because of some permission problem. After significant amount of time spent on discovering what's wrong I've finally got it: The 'Allow' directive doesn't work with host name, it requires an IP address. Sigh.

So CUPS started to work with my parallel port printer. Not so with the printer connected through USB. It reported to be unable to open the corresponding USB device. Even setting the device permissions to 666 didn't help. I ended up with downgrading CUPS to 1.1 on both the server and client machines.

I've never liked CUPS. CUPS is not a bad idea and it's fine when it happens to work well, but it has been making troubles all the time I use it. From what I've seen for several years of CUPS usage I have to say that Linux printer management is apparently in incompetent hands (not sure whether upstream or in Debian).

When I upgraded my computer, I wanted to make it available to my family even when I'm sitting in front of it (this happens most of the time). Natural way to allow this is to connect additional terminals to the computer. The simplest, cheapest and power saving kind of terminal consists just of a set of I/O devices, such as a monitor, a keyboard and a mouse or a TV with a remote control.

So I equipped the new computer with two graphics cards, assuming that connecting multiple input and output devices to the computer should be just a matter of having corresponding number of graphics cards and free USB ports available. Big mistake! Never, never underestimate software problems. It took me several months to make the multiseat setup actually working and still not without problems.

The very first problem was that X.Org 7.0 refused to run on the second graphics card at all. This is some mismatch between X.Org 7.0/6.9 and recent Linux kernels. After a lot of experiments and googling I finally found a patch that works for me.

Now I was able to run two different X servers, but only on different Linux consoles, i.e. not accessible in parallel. I followed the very nice Multiseat HOWTO, but it still didn't work – my X session has always frozen when I started the second instance of the X server sharing the console. After additional experiments and googling I've found it might be worth to try running different video drivers on each of the graphics cards. The two graphics cards I've got in my computer are the same, so I tried to run one of them with the X.Org ATI driver and the other with the ATI proprietary driver. Indeed, I can run two X servers in parallel now. Not without limitiatons: While the free X.Org driver runs fine, the ATI proprietary driver runs only on the first graphics card (it refuses to start on the second card), without 3D acceleration (compilation of the fglrx kernel module failed) and it freezes the computer when one logs out (this is a real problem that I don't understand since the X server is not restarted on logout). Another problem is that X.Org doesn't allow switching to a Linux text console when running multiseat.

An additional interesting observation is that one can't rely even on such basic things like that a keyboard works. My USB keyboard stops working very soon after boot and needs to be unplugged and plugged in again. Then it works fine, but if I do it when X has already been started, the mouse connected to the USB hub built in the keyboard stops working completely. AFAIK there is a lot of problems with USB keyboards on Linux, often without solution. Well, this is so called computer age…

About a week ago, I've upgraded CUPS from 1.1 to 1.2 on my print server. I know one should never touch a working CUPS installation, but as Debian 4.0 is based on CUPS 1.2 I'd have to make the upgrade sooner or later anyway.

Of course, after the upgrade my printing stopped working as usually. As this was my second CUPS 1.1 to 1.2 upgrade attempt I already knew about some problems of the upgrade process and could get run at least the CUPS HTTP and IPP interfaces. But the printers worked in weird ways such as printing a single page in several pieces put on separate sheets or stopping to work after finishing a printing job.

To keep the story short, after a week of various efforts I ended up with complete removal of printing software on the server and its reinstallation. Then the CUPS HTTP configuration interfaces started to offer right configuration items and after a few attempts I could get my printing run properly.

I can only hope that after the upcoming Debian 4.0 release Debian slows down its release cycle again, so that I won't have to suffer all the software upgrade headaches each one or two years… In the meantime, let we software developers think more about impact of the changes we make to our great software.

I've recently installed Debian etch distribution on an external USB hard drive. I was positively surprised how smooth the installation process was and how well the resulting system worked. Especially Czech environment was complete and well set up for the Czech speaking user without any need of further adjustments. The release managers and the debian-installer team do clearly good work and Debian 4.0 freeze may be short.

The only problem was how to boot from the USB drive. Initially it appeared to be easy as the computer offered USB booting in BIOS. But that didn't work, perhaps the BIOS was buggy. So I decided to make a bootable CD for the system.

For the record, here is the process of making a bootable CD for an etch system on an external USB drive. Some steps may be redundant, I don't know, but the final CD worked and this is what matters.

• Connect the USB drive to a similar computer, mount it and chroot into it.
• Install the 'initramfs-tools' package.
• Add the following module names to '/etc/initramfs-tools/modules': 'usb-ehci', 'usb-ohci', 'usb-uhci', 'scsi-mod', 'sd-mod', 'usb-storage'.
• Run 'update-initramfs'.
• You can leave the chrooted environment now.
• Install 'syslinux' and read its documentation.
• Create a syslinux working directory as described in the syslinux documentation. Name the kernel image file 'linux' unless you want to change the defaults. Don't forget to put the following option (the only one required) into 'isolinux.cfg': 'APPEND initrd=initrd.img root=/dev/sda1' (change the names of the initrd file and root partition accordingly).
• Make the ISO image, burn it onto CD and boot it.

Sharp Zaurus SL-C1000 is shipped with its own Linux operating system based on Qtopia. The system is not bad, it is stable and although it requires some updates to become really usable, it provides nice PDA environment covering many areas of use. But it suffers of some problems: it's incompatible (as it uses Qtopia instead of X), contains a lot of proprietary applications and the available development environment is obsolete. Simply said it's difficult and annoying to port applications to the system.

So I decided to replace the Sharp operating system with pdaXrom, which is a free X-based operating system for (Sharp) PDAs. They say the operating system replacement should be safe as the Zaurus low-level system service menu is placed in ROM and can't be erased. First I tried to install the latest pdaXrom release, i.e. 1.1.0r121. This was a mistake as the device ended up seemingly completely dead after reboot. It took me a lot of googling and experiments to get it recovered and to install pdaXrom 1.1.0beta3 which seems to work fine so far.

The first advice: Don't install the latest 1.1.0r121 release, install 1.1.0beta3 instead (until some new stable version is released) which has reputation of being relatively stable.

The second advice: If you end up with a "dead" C1000, you can recover it as described on the TRIsoft site. But there is an important missing detail there: You need to press Fn+D+M to start the service menu, not only D+M.

I've been using two monitors with two graphics cards on my computer for long time. I've got another spare old CRT monitor so why not to utilize it? I connected it to a free VGA port on one of the cards and started experiments.

Compared to the two independent graphics cards setup, using two monitors connected to a single card handling a single desktop was relatively easy. By default the monitors show the same screen. I tried to setup Xinerama but these attempts have always finished with X server segmentation faults. After some more searching I've found that the proper tool to use, other than Xinerama, is XRandR. I just had to upgrade the xrandr utility to a newer version. Then it was easy, using xrandr one can play with dual monitor setups on the fly, without needing to restart the X server (which is equal to reboot on my dual card machine). And StumpWM works great with XRandR, I had just to figure out that the second monitor screen is nothing else than another frame.

The only problem is that the whole XRandR setup is limited to the total possible graphics card resolution, 1920x1200 in my case. So the second monitor is limited to 640x480 resolution in my setup. But it's still well usable for tasks like watching TV while doing something else.

After very long time I've finally found how to make my two USB keyboards and mice accessible under constant file system names. Here is the trick:

ACTION!="add|change", GOTO="keymouse_end"
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceProtocol}=="01", ENV{ID_CLASS}="kbd"
KERNEL=="mouse*", SYSFS{idProduct}=="0067", SYSFS{idVendor}=="0458", SYMLINK+="input/mouse-genius"
KERNEL=="event*", SYSFS{idProduct}=="0067", SYSFS{idVendor}=="0458", ENV{ID_CLASS}=="kbd", SYMLINK+="input/keyboard-genius"
KERNEL=="mouse*", SYSFS{idProduct}=="071d", SYSFS{idVendor}=="045e", SYMLINK+="input/mouse-ms"
KERNEL=="event*", SYSFS{idProduct}=="071d", SYSFS{idVendor}=="045e", ENV{ID_CLASS}=="kbd", SYMLINK+="input/keyboard-ms"
LABEL="keymouse_end"

I can boot without manual assistance now!

My old mobile phone becomes a bit unreliable, so I look for a new one. Perhaps a smart phone would be useful, but I'm not interested in proprietary and virus prone OSes without available source code and lacking good development tools and community support. Given these constraints there are at most two options: Google Android and Openmoko (Neo FreeRunner).

If I understand it right, Google Android is actually not an option. It's built on top of a Java platform and can be programmed only by using a proprietary SDK. So it's not completely free, I'm forced to work in Java and I can't port my favorite applications to it. No, thank you.

Openmoko is an interesting free software platform, but there are problems. Neo FreeRunner phone is relatively expensive while lacking some basic features commonly available in cheap phones (EDGE, camera). But the real problem is that it doesn't seem to provide robust telephony services instantly. I'm looking for a device which I can use exclusively, not for a supplementary and rather expensive toy. If the basic phone functionality worked without any problems then I might participate on development of other features. Hopefully Openmoko (or other nice platform) reaches that state before my next mobile phone will die.

So my next mobile phone will be a simple phone, smart phones haven't grown up enough yet to satisfy my needs.

There are areas where free software community fails. Not for technical reasons or lack of resources, but because of management and strategic planning incompetence.

Once I got an idea to get a Linux handheld. There were two models available at the time: Sharp Zaurus and Nokia tablet. The Nokia tablet didn't have any keyboard so I choose Sharp Zaurus, despite its worse operating system.

The preinstalled operating system on the Zaurus was some old version of Qtopia combined with proprietary applications. It had some nice features but many problems, such as missing Czech environment, limited set of applications, no X support and obsolete development environment. Some improved versions of the system were available but the basic limitations were still present.

After some time I replaced the original system with pdaXrom, a free Linux based operating system for PDAs. It offered X Window System and more modern development environment so it was possible to port common applications to it. Nevertheless pdaXrom was no way complete and its development has deceased during the time.

Developers of several free Linux PDA operating systems decided to join their efforts in the Ångström project. So I replaced abandoned pdaXrom with Ångström. But Ångström offered only very limited set of applications and I've never managed to get its development environment working.

There were only two options remaining: Either to put my Zaurus to a recycling center or to install Debian on it. Fortunately I could find a Debian installation for Zaurus so after several years I got chance to run a full featured operating system on the device. Finally I could install Emacs and other basic applications easily. But there were some minor problems and I've later upgraded to an up-to-date Debian version. By replacing the old preconfigured kdrive X server with standard xfbdev X server I've lost touch screen capability. So my Zaurus remains mostly unusable until I have time to look at the problem and can get it fixed.

I really don't understand why free software developers waste their limited resources by developing new operating systems that are unmaintained, very incomplete, missing good development environment and generally not perfectly working, when a good and complete operating system such as Debian already exists. All what was need was to customize Debian a bit for use on the particular kind of device. I could see the same mistake was repeated by Neo Freerunner developers. Instead of focusing only on important things like handling calls and SMS, they tried to maintain a complete operating system. In the final result Neo Freerunner didn't provide reliable calls nor a complete operating system.

Community developers have painfully failed in finding a feasible way of making a good free operating system for PDAs. Nokia managers made a better decision by deciding to base Maemo on Debian, thus avoiding a lot of useless work. I don't know whether Maemo allows easy porting Debian applications to it using a completely free SDK. If it does then it may be (the only) promising platform unless Nokia decides to stop its further development. Other platforms are either not well maintained, or are not actually free (Android with its proprietary SDK), or are based on a platform that can't run common free applications (Android, perhaps Symbian as well).

When I was looking for a new mobile phone and looked at smart phones more than a year ago, I've found there has been no working smart phone equipped with a truly free operating system providing rich set of applications and nice development environment. It seems there happened at least two important changes in this area during last year.

I've found Neo FreeRunner is still not dead. And looking at their latest news I can see a great change: Debian is taken seriously now as the primary operating system for the device. This means the phone can be equipped with a reliable operating system, I should be able to install my favorite applications on the phone, there should be a working development environment and it would make sense to contribute to the development of the phone software environment (nothing of that applied to the former OpenMoko operating system). For this fact, if I was buying a smart phone today, I would buy the FreeRunner without much doubts. So after fixing the wrong operating system strategy now the question is what will happen with the hardware. We'll see.

As for big vendors, Nokia is still interested in providing operating systems based on GNU/Linux platform in their phones and possibly future tablets. They've abandoned Maemo which is no pity. When I looked at Maemo web pages last time, I've got the impression that Maemo is a semi-free operating system providing only a very limited set of supported packages and not being worth to contribute to. Why simply not to use Android under such conditions? The only real advantage of Maemo might be that with a significant effort and patience one could in theory port his favorite applications and all their dependencies to the system, there is no such option with Android. It's better to avoid such systems.

Now Nokia joined its efforts with Intel on development of MeeGo operating system. Will MeeGo fix the problems of Maemo? They promise MeeGo itself will be completely open source, this is good. But will it provide all the important applications such as Emacs, KStars, Scid with Stockfish, etc.? I doubt, it's no easy thing to develop a complete operating system distribution and it's even harder under corporation umbrella where it's likely the distribution will be rather closed and driven mostly by marketing requirements. And if all the marketing wants is to provide just another Android and iPhone competitor then the question is again: Why not to use Android straight out? If Nokia would like to be different (would it?) then they could work on making Debian easily installable and runnable on their phones and tablets. Then those devices could be real killers in a certain market segment. We'll see.

Until recently I was a relatively satisfied Linux VServer user. But when I upgraded to Debian 6 about half a year ago, OpenAFS aklog stopped to work inside the guests. There were always problems with running OpenAFS clients inside VServer guests but this time I couldn't find any workaround. I had to solve the problem and I had to act quickly.

As VServer didn't look useable anymore I decided to move to Linux Containers. It's a similar virtualization approach, implemented in a different way. I can't provide any expert comparison of the two solutions as I'm just a home user. Here are my simple observations.

Linux VServer is generally more mature product (no wonder, it has been around for some years). It provides better management tools, including things like vserver-stat (summary information about running guests and resources consumed by them), vserver stop (safe stopping of a guest), vserver enter (a way to enter a guest directly from the host) or vapt-get (batch invocation of apt-get over all running guests). It defines a finer set of capabilities, e.g. you don't have to set the big CAP_SYS_ADMIN permission just to be able to use FUSE. And it contains hashify with the copy-on-write feature to save main memory, memory cache and disk space.

Linux Containers allow me to run some things in the containers that I've never managed to get running inside VServer guests (new OpenAFS aklog, OpenVPN). They provide more sophisticated device isolation (mknod /dev/null possible without permitting too much) and network isolation (each container can have its own routing and filtering rules). Configuration is easier. And they are included in the official kernel source. On the other hand they lack some important features provided by Linux VServer and I experienced several less or more annoying problems (but none of them preventing me from using Linux Containers completely). The implementation may improve rapidly, so it can be better now.

Both the projects lack good documentation.

There is some lesson with Linux VServer and Linux Containers. AFAIK, Linux developers have originally rejected the Linux VServer idea as unnecessary for several years. Apparently during the time they changed their mind and Linux Containers are here. The result of the lost years is that we haven't got a complete and well working solution yet. Well, we know that progress is sometimes constrained by our mental barriers.

Updates on my driver info pages:

• Updated information about Microsoft Natural Ergonomic Desktop 7000 keyboard, especially a link to a guideline how to make the zoom key working was added.
• Added information about Genius G-Pen F610 tablet.

I bought a new input device, Wacom Bamboo Pen & Touch tablet. I was careful enough to buy an older model and to check the device is supported on Linux. Based on my previous experiences I also tested the tablet on a Windows computer to be sure it actually works and I can handle it, so that I'm sure contingent faults on Linux are caused solely by the drivers and are not hardware or user defects. Installation of the Windows driver was quick and easy and the device worked well immediately.

Then I tried to get the device running on Linux. I installed a newer 2.6 Linux version, reported to support the device, and the newest released version of X.Org Wacom drivers. I added appropriate sections to my /etc/X11/xorg.conf. So after some hours of googling and updating the system I got an environment which should be ready for testing the tablet.

I restarted the X server and ended up with a frozen black screen, having to use a reset button on my computer. This situation had repeated for several times until I discovered the Wacom driver conflicts in some way with a Wizardpen driver, causing crash of the X server without recovering the keyboard and console. So I commented out the Wizardpen input device in xorg.conf and then could start X without having to reset my computer anymore.

The pen function worked well but the touch function didn't work well and the tablet buttons didn't work at all. I found out that although the given model number of the tablet should be supported in newer 2.6 kernels, there are actually several variants of the model and the newer ones are not supported in those kernels. So I installed the newest version of the tablet kernel drivers for Linux 2.6.

The touch function started to work in a different but still unusable way. After some exploration I found out that while the tablet kernel drivers support several versions of 2.6 kernels, not all fixes are backported to all the supported versions. My Linux was too old so I had two options (not counting giving up on using the touch function): either to backport the changes myself or to upgrade my system to a development version. I decided to upgrade and the touch function finally started to work with a recent 3.1 kernel, after I was forced to abandon my stable OS installation (I couldn't upgrade just the kernel because it was necessary to recompile OpenAFS modules for it, which is possible only with new gcc, which depends on new libc, etc.).

Nevertheless gesture recognition still didn't work as expected. I had to install the latest development version of X.Org Wacom drivers to fix that.

Tablet buttons still didn't work. After some guesswork I could get them working by changing my X.Org configuration, a wrong device was used in the sample configuration copied from wiki. After another round of googling I finished the device installation by tweaking the unsuitable acceleration settings, by adding tablet rotation support to my screen rotation script and by remapping the buttons. After many hours of googling, reading, editing, compiling, reseting and experimenting the tablet still doesn't work as well as on Windows after five minute installation, because of the limited set of supported gestures, but at least it can now do everything my mouse can.

Lessons learned:

• Hardware vendors still mostly ignore Linux users.
• It's best to avoid buying new hardware unless it is really needed. Spend saved money on something else (e.g. donation to Free Software Foundation, to developers of your favorite free software product or to any common charity you like).
• Don't buy a computer without a reset button if you intend to run Linux on it.
• The fact that just presence of two certain drivers in X.Org may cause the whole X server crash and loosing user control over the computer indicates there is something very wrong with software development practices (well, it's nothing new but the fact proves it's all not "just fine").
• Linux doesn't care about making driver backports easy. Don't buy new hardware unless you are ready to upgrade everything. Even then you may be forced to apply patches, compile, install, debug, read the source code and make fixes yourself.
• Using kernel modules not included in official Linux kernel is troublesome all the time. I'd abandon using OpenAFS only for this reason if Linux provided any reasonable network file system.
• There is no such thing like reliable driver information. Be ready for a lot of googling, judging and reading the source code yourself.
• I'd be helpless without access to the source code of various components.

In summary, device drivers demonstrate big problems. Hardware vendors are generally uncooperative, there are insufficient resources for reverse engineering and development and documentation of free drivers, software development practices are generally poor. If a device ever becomes reasonably supported, its remaining driver problems are unlikely to get ever fixed once the device vanishes from the market.

I consider device drivers being big blockers of development and adoption of new advanced operating systems. I could tolerate various problems of experimental operating systems, but it's hard to get any serious interest of new users and developers when the hardware doesn't work or suffers from big performance problems.

Is there a solution? I can't see any. Perhaps the only hope may be making coordinated campaigns targeted on hardware vendors and coming of new clever and enthusiastic Linux kernel developers.