Wandering Thoughts archives

Why apt is always going to be faster than yum

One of the things that people report (to put it politely) when they switch between a Debian-derived distribution and Fedora is that apt is faster than yum. This is indeed the case, and it is always going to be the case, because yum is simply doing far more work than apt is.

(Whether or not the speed difference matters in practice is another debate. It doesn't bother me, but then I use fairly fast and beefy machines.)

As I understand it, the different amount of work is ultimately due to a basic difference in how each system approaches dependencies. In Debian, the approach to dependencies is entirely package based; package A declares that it requires packages B, C, and D. In RPMs, the dependencies are mostly on things, like files and libraries; while you can make your RPM explicitly depend on packages, you generally don't.

The end result is that there are a lot more dependencies running around an RPM-based system than there are around a Debian one, and many of them are indirect dependencies (you don't depend on a package directly, you depend on something provided by a package). Thus, doing things on an RPM-based system means checking a lot more dependencies, in bigger indexes, and generally taking more steps in resolving each dependency to a package. In short, more work that deals with more data, which means slower.

(The RPM based system has bigger dependency indexes because it has to include files and libraries and so on in them, not just packages.)

As a side note, I suspect that it doesn't help that yum has larger indexes and downloads them a lot more often than apt does.

What Linux's RPC queue dump means, sort of

Since I went digging through the kernel source code yesterday, here is the meaning of the fields in the RPC queue dump that you get any time you write to /proc/sys/sunrpc/rpc_debug.

As far as I've been able to work out, the useful fields are:

(The --rqstp-, -action-, and --exit-- fields are better off ignored if you are not debugging the kernel; they are pointers to internal kernel structures. About all you can do with them is see which tasks have the same one.)

Unfortunately, there is no way to map from a particular RPC request to the processes that are waiting on it; the -pid- field is mostly useful for matching things up with any other debugging messages that you have the RPC system produce.

A brief mention of some tools for debugging Linux NFS client issues

Someone here recently asked for tips on debugging a mysterious Linux NFS client hang. I didn't have any answers, but I did happen to know where to look for some Linux-specific tools. (The person had already exhausted the abilities of things like tcpdump to help.)

The most obvious thing is to use the magic SysRq to get a dump of the kernel call stacks of all processes (the t command). Once you find the hanging processes in all of the output, you can usually see what operations they're hanging on, both high level and somewhat low level.

(Here's where I observe that it's a pity that there's no way to ask for a magic SysRq dump of a specific process. Hopefully someone will now tell me that I'm wrong.)

The Linux NFS client also has its own debugging hooks, accessible through /proc/sys/sunrpc; unfortunately, they're rather underdocumented and magical. What you want are the files rpc_debug and nfs_debug, each of which is a bitmap of flags that control which RPC or NFS events get logged; you write a decimal integer to them to set the bitmap's value, or a 0 to turn off all logging.

(In addition, writing any number to rpc_debug will give you a cryptic dump of RPC 'task' information. Having just read through a bunch of kernel source code, my opinion is that there is almost nothing useful in it unless you are a kernel hacker. If you really want this dump and nothing else, write a 0 to rpc_debug.)

The values for the various things you can get reports of are found in the kernel source in include/linux/sunrpc/debug.h (the RPCDBG_ #defines) and include/linux/nfs_fs.h (the NFSDBG_ #defines). You can use a suitably large value like 32767 to turn everything on.

Note that this can produce a lot of kernel messages very fast, especially if you turn on lots of things. Also, one of the big reasons this stuff is not documented is that it is primarily intended for kernel hackers, so to understand the results you may need to go dig in the kernel NFS and RPC code (in fs/nfs and net/sunrpc respectively).

(There are similar debug files for the NFS server and for the NLM. Exploring these is left as an exercise for the reader.)

A sysadmin's review of the ASUS Eee PC

We're not interested in the Eee as anything approaching a conventional laptop; we're interested in it as what I'll call a sysadmin's walkaround machine, something I can take with me to get access to our real machines, troubleshoot problems, and plug into hardware. The Eee is appealing for this primarily because it is really cheap and runs Linux; that it is also small and light is an extra benefit.

(We care about really cheap because it makes it feasible to buy everyone their own machine, instead of having only a few laptops in a central pool.)

The Eee works great for this purpose. It is small enough to carry easily, its wired and wireless connectivity works (complete with a PPTP VPN), and its screen is big enough to run 80x24 terminal windows and ssh. With work you can even run moderately useful web browsers, but there is so little vertical space that I wouldn't want to try to configure a switch or something with it. It seems to have decent battery life, although I haven't tried to stress it.

(For scale, I can get an 111 character by 31 row konsole window, or 98x34 using xterm with a readable font. This is with the advanced interface, which gives me more vertical space.)

Everything that you would reasonably expect to work has worked fine for me so far: USB mice, USB keyboards, USB keys, external displays, even USB serial converters (although you will obviously need to install a terminal program to talk to your new serial port).

We got one of the 4G models instead of the 2G model, and for a sysadmin's machine this is the right choice. I've wound up installing a bunch of additional software and the 2G would not have had enough spare space, especially because the Eee is not so inexplicably missing a large pile of software that I consider essential; not just tcpdump and telnet and nmap, but even things like ntpdate and rsync.

Having said all that, while I like the Eee I would not spend my own money on one right now; the screen is too small, it runs too hot, and it is too heavy for my tastes. In private life I do not need ubiquitous connectivity to other machines and would like something that I can actually use comfortably for more than ssh sessions.

Oh, and to answer a Google query I saw in my logs: the Eee PC's power cable is 10 feet long. (And the power converter is one of the nice things about the Eee; it is a tiny unit, very easy to take along with you.)

What I needed to make my custom Fedora 8 environment work

One of my little peculiarities is that I use a quite custom environment, one that comes nowhere near a graphical login program, much less Gnome or KDE. One of the consequences of this is that I get to set up by hand a number of things that a normal environment runs automatically, like volume management.

These custom things keep changing themselves as I move from version to version of Fedora, so here is what I had to do to get my environment running nicely under Fedora 8:

• If you start your X session by hand yourself, you need to run both ck-xinit-session and dbus-launch to set up the client environment properly:

  /usr/bin/ck-xinit-session /usr/bin/dbus-launch --exit-with-session actual-session-script

  (Normal people probably want to run ssh-agent too, but I don't use ssh keys with passphrases. You can dig this stuff out of /etc/X11/xinit/xinitrc and associated files.)

• volume management hasn't changed; you run 'gnome-volume-manager --sm-disable'.

• in a change from the past, the right sound daemon to run is now pulseaudio. I found it necessary to remove its PID file beforehand too in order to make sure that it always started.

  (The PID file for me is /tmp/pulse-login/pid.)

Getting Flash to work on my 64-bit machine was a little intricate. I installed the 32-bit Flash RPM from Adobe's official repository and both the 64-bit and the 32-bit versions of nspluginwrapper, but this still left it unable to do sound. To fix that I had to install the 32-bit version of the alsa-plugins-pulseaudio RPM, which I had to fish out of the i386 Fedora 8 repository by hand (it is not available in the x86_64 repository).

(Someday gnash et al will work well enough that I can bid a gleeful farewell to the 32-bit Adobe Flash plugin, but I am not energetic enough to fight that particular battle yet.)