Wandering Thoughts archives

Consequences of allowing packages to quiz users at install time

I suspect that one consequence of allowing packages to ask users questions at install time, as Debian does, is that it allows divisive packaging issues to stay unresolved because people can always say 'fine, we'll offer both options and let the user choose'. No one actually has to compromise or give in, so everyone sits around quietly nursing the issue until (if you are lucky) it all gets forgotten about.

(Of course, then you can have a new flamewar over what the default choice should be.)

This in a sense seems perfectly suited to how Debian seems to do things, since from what I have read Debian does not strike me as a place where there are strong authority figures who can make decisions and make them stick. It's possible that the ability to defer making completely final decisions on divisive issues is quite important in Debian's environment. (However, at this point I am speculating wildly, since I have no more insight into how Debian really works than reading Planet Debian off and on.)

As a sysadmin, I get to worry about another consequence of allowing packages to quiz users: there is less pressure to make the defaults sensible and useful, because you can always blame your users for not picking the right option when you asked them. In turn, this makes me nervous about turning on various Debian (and Ubuntu) 'never ask me any questions' options, because I can never be entirely sure that I won't be skipping a question that I really need to actually answer.

An interesting issue when yum upgraded gaim

A while back, the Gaim chat program got renamed to Pidgin for complicated reasons. Fedora duly released a pidgin package that said it replaced the old gaim package, and I duly typed yum update on my x86_64 machine, and things came to a screeching halt with errors about file conflicts. It turned out that the updates repository had both the i386 and the x86_64 versions of pidgin, and yum was picking the i386 version, which depended on various i386 packages that conflict with the x86_64 RPMs that I already had.

One reason that this could happen comes down to package naming. Namely, Fedora made the decision not to burn the package's architecture into the package name itself (unlike in the Debian world, where there would have been pidgin and pidgin-i386 packages). This meant that both versions of pidgin could assert that they replaced gaim, as opposed to something like 'pidgin-i386 replaces gaim-i386' for the lesser architecture.

In turn this is pretty much necessary to keep package naming sensible and not make a bunch of extra work as you migrate and not have packages that only differ in name. Otherwise, a native i386 only machine would have 'pidgin', but the exact same bits would be called 'pidgin-i386' on a multi-architecture machine.

(The way around this sort of issue is something like yum update pidgin.x86_64; this gets yum to pick the right version as the update.)

Linux kernel asynchronous IO doesn't work on sockets

I've been considering writing a fully asynchronous ATA over Ethernet target driver (I'm not entirely happy with the current one and its performance). If Linux asynchronous IO worked on sockets (specifically raw network sockets), there is a nice simple design where you just set up a pool of buffers and then cycle each one through a little state machine (network in to disk IO to network out).

(This works especially great for AOE because the protocol is both based on raw packets and completely unordered, so you never have to do packet reassembly and can treat each request independently.)

Unfortunately, a limitation of the current Linux kernel AIO support is that it doesn't support asynchronous IO on sockets; attempts to do async IO on them get silently converted into a synchronous operation when you submit the request. Although I haven't tested this, my impression is that the only things that currently support asynchronous IO is block devices and O_DIRECT IO, probably only on local filesystems.

(I believe that within the kernel, the marker to look for is things that return either -EIOCBQUEUED or -EIOCBRETRY when processing requests. In the relatively bleeding edge kernel source I happen to have handy, there doesn't seem to be very much that qualifies.)

Of course, the 'wait for aio IO to complete' system call has the traditional problem with new event systems in Unix: it only waits on aio events, which means that there's no good way to mix waiting for aio events with waiting for anything else. I'm kind of annoyed that people are still designing new system call interfaces with this problem.

(Technically, very recent kernels have an eventfd() system that one can hook to aio so that when aio IO completes, you get something on the eventfd file descriptor, and you can select() or poll() for it. In a year or three, I might actually be able to use that on the systems I'm interested in.)

Problems with EXA X acceleration on ATI cards in Fedora Core 6

As I understand it, a modern X server and its graphics card drivers has two choices for low-level hardware acceleration methods: the older XAA and the more recent EXA. EXA's big goal is to support the sort of fancy composition and graphics that modern desktops and programs want to use; in particular, if it works it speeds up Firefox's page scrolling for web pages with complex graphical backgrounds.

(If your card's driver supports it, you switch the X server to using EXA through an xorg.conf change. I am not going to try to summarize the details here; see the manpage for your card driver, such as radeon(4), and the xorg.conf manpage. XAA is the default acceleration method.)

When I read about this I was running into some web pages that Firefox was scrolling slowly, so I promptly leapt to try it out. However, I ran into some problems on my ATI-using machines:

• on my dual-head setup at work with both an ATI X300 and an ATI X750, solid window moves promptly got achingly slow. This is apparently a known issue with some EXA configurations, but in any case it meant that I turned off EXA at work.

• more seriously, I started to have erratic total system lockups on my home system (identical to my work machine except that it has an ATI X800GTO in a single-headed configuration). They seemed to be most often provoked by watching YouTube Flash videos, although I believe some happened just from using xine and perhaps other Xv-using applications.

  (I am not completely sure EXA is at the root of these lockups, but I haven't had any in a week since I reverted to XAA, and EXA is said to be 'possibly unstable'.)

Unfortunately, this may well matter in the future because of Cairo. Cairo is is more or less Gnome's 2D graphics library (it used to draw SVG graphics in Firefox, for example). Cairo makes heavy use of the XRender extension and thus assumes it will be reasonably fast, but the XRender extension is exactly what EXA is designed to speed up. No EXA means no fast XRender which means Cairo-based programs are probably going to perform relatively badly.

For now I have my fingers crossed that Fedora 7 has an updated ATI driver and X server that fix these issues, although I am not sure that I will have the courage to try it out immediately. (Having my home machine lock up erratically was really, really irritating.)

(Just to be clear, I using the open-source radeon driver, not ATI's binary fglrx driver.)