Wandering Thoughts archives

Linux is a Unix

There used to be a meme going around to the effect that Linux isn't Unix and you shouldn't call it one (I say 'used to be' because I haven't seen it recently). This has always irritated me; not particularly because I'm a Linux partisan, but because it's such a small minded claim for Unix people to make.

When you ask people to support this, they generally point at two reasons: Linux is not entitled to use the Unix trademark, and Linux's code (often just kernel code) is not descended from Research Unix.

I do not understand Unix people who can make the first argument with a straight face. Leaving aside the fact that most of the iconic versions of Unix have not actually been able to call themselves Unix™, these people claim to believe that this narrow legality is more important than everything else that goes into Unix, that a sticker from some entity is more important than /etc/passwd and mkdir and creat() and PID 1 (to pick examples at random).

Or in short: Unix is more than Unix™, and always has been.

The second argument presumes that there is some magic contamination that has passed through the (kernel) code (even though no original AT&T code remains in things like the *BSDs by now) that was not transmitted through all of the things that the Bell Labs people wrote and people's experiences with Unix and so on. Having this now invisible line of descent somehow makes you special, no matter how little your kernel or overall source base resembles V7 or 4.2 BSD by now, while not having it is somehow so big a defect as to overcome all other points.

To me something is a Unix if it feels like Unix; if it follows the spirit, if it behaves pretty much like other Unixes, if I can find my way around it without problems.

Sidebar: to nitpickers on the Unix trademark

In theory the Unix™ trademark is currently attached to passing a set of compatibility tests. However, people don't point to the compatibility tests (because then Linux might qualify, along with less appetising things); they point to the trademark, which is subject to changing policies (and has changed policies in the past). Also, I believe that no current Unix passes those tests; there is an explicit grandfather clause for things descended from V7, because otherwise there pretty much would be no Unix™es.

Building your own kernel with the Fedora kernel configuration

There are a number of situations where you might want to do something like build a stock kernel.org kernel with the same configuration options as a normal Fedora RPM-installed kernel. Alternately, you want to compile a Fedora kernel with a slightly different set of options. These days, how to do this is slightly less than obvious and there is a gotcha or two.

First, you need kernel source. Fedora no longer ships an RPM with their kernel source all set up for you, so you have two options:

• just download the version you want from kernel.org and unpack it somewhere convenient, or
• fetch the kernel .src.rpm and set up to build it, which requires an RPM build environment. Once you have a kernel source RPM in your RPM build environment, you can get the source tree all patched up and ready to go with rpmbuild -bp kernel-2.6.spec.

Next, you need a kernel config file. The config file for a particular kernel RPM that you have installed is /boot/config-<release> (among other, less convenient places). However, if you are building by hand you don't want to use this configuration as it is, because if you try you will discover you wind up with a huge kernel image. The culprit is the CONFIG_DEBUG_INFO option, which causes the kernel to get compiled with -g; take it out following the directions in EasyKernelConfMods.

(The kernels in the RPMs are not this big because the RPM build process then strips the debugging info out and puts it in the kernel debuginfo RPM.)

If you are building a kernel.org kernel using a Fedora config file, there are two things to watch out for:

• if you are upgrading kernel versions, make oldconfig will probably ask you about a number of new options.
• make sure that you are using a base kernel version at least as recent as the Fedora kernel RPM. Fedora's current build practices do not put the subminor kernel version number in the RPM version (eg, the 2.6.20.8-based and 2.6.20.10-based kernel RPMs will both have an RPM version of just 2.6.20 plus a build sequence number), so you need to either inspect the kernel source RPM or the kernel RPM's changelog for the kernel you are running. You do the latter with:

  rpm -q --changelog kernel-`uname -r` | less

After that you are pretty much home free, assuming you are not rebuilding a kernel RPM. Doing that does not in any way fit into the margins of this entry.

What Linux bind mounts are really doing

Lots of Unixes have some form of 'loopback' mounts, where you can mount a bit of an existing filesystem somewhere else; they're called loopback mounts by analogy with the loopback interface. The general idea behind them is that they are a more efficient (and easier to use) version of doing an NFS mount from localhost.

(I suspect that Sun originated the idea, but I'm not sure.)

Linux's bind mounts (so called because they are done with mount --bind, or by specifying bind as the filesystem type in /etc/fstab) look like any other sort of loopback mounting. However, they actually operate in a way quite different from the usual idea of loopback mounting, and the difference has some important consequences.

What bind mounts are really doing is more or less mounting the filesystem again with a different inode as the root inode. Thus, if you do:

mount /dev/md1 /foo
mount --bind /foo/bar /bar

what you really have is /dev/md1 mounted twice, once with the root inode of the filesystem on md1 as the root of the mount point, and once with the inode for 'bar' in the root of the filesystem on md1 as the root of the mount point.

The mount command makes this hard to see by being misleading in its output, reporting things like '/data/home on /home type none (rw,bind)'. Because they use /etc/mtab, which mount maintains, things like df also report like this. More of the real state of affairs is visible in /proc/mounts, where the kernel itself reports:

/dev/md5 /data ext3 rw,data=ordered 0 0
/dev/md5 /home ext3 rw,data=ordered 0 0

Unfortunately the kernel doesn't report that what root inode /home is mounted with, which generally makes mount's output more useful once you know what is really going on.

One consequence of this is that once you've set up your bind mounts, you can unmount the original mount point, something which I believe is not true of things like Solaris's loopback mounts (and which definitely wouldn't be true of NFS mounts from localhost). There might be a use for this in obscure situations.

Sidebar: Deeper under the hood

Disclaimer: I am not sure I understand this correctly.

Under the hood, there are two things: actual mounts of filesystems from devices (or the network), and namespace-based views of such filesystems. Rather than create new copies of both, bind mounts create new views ('mounts' or 'vfsmounts') of the same underlying mounted filesystem.

This explains one limitation of bind mounts, which is that you can't change mount flags when you do a bind mount (so you can't have a bind mount that is a read-only version of part of a read-write filesystem). Currently, all mount flags are associated with the filesystem, not with the view, so all views have to have the same mount flags.

My view of Ubuntu

We use Ubuntu here, but by now I can't say that we're exactly fond of it. At this point we're using it not because we like it but because we lack a better alternative, which gives me a somewhat jaundiced perspective.

A disclaimer: this is about Ubuntu 6.06 (Dapper Drake, the LTS release that will be supported for a long time). Moving to more recent Ubuntu releases is not an option for us, because we need longer support periods than 18 months.

The good part of Ubuntu 6.06, and the reason we're still using it, is an unmatched combination of long term support plus a huge package selection. A large package selection is probably not important in 'enterprise' markets, but it is vital for us because our users want all sorts of software on the servers and we don't want to be building it ourselves.

(Debian might qualify, but there are two problems: first, it doesn't give me warm fuzzy feelings about having relatively current software when it releases, and second it would only have the long term support if it keeps up the current glacial pace of releases.)

Ubuntu's standard desktop experience is great, from the Live CD installation environment onwards (although the default desktop background is too dun coloured for my tastes). Lots of people around here are very happy with it, and with 6.06 you probably won't have to worry about OS upgrades for a good while.

The bad part of Ubuntu is that it only seems to work well for that standard desktop install. The moment you step outside of that, for example if you are installing a server, various wheels start coming off. Non-default or non-desktop installs seem decidedly second or third class citizens, regardless of what Ubuntu may say about server support.

(For example, while Ubuntu people like making worthwhile changes to how the system operates, they don't seem to push the changes through into packages that aren't in the default install, even if those packages are in the core. This causes me to live in fear of their great boot-time startup reform.)

Or in short: Ubuntu is slick on desktops, but stumbles badly on servers. Nor does it seem like this is going to change, since Ubuntu seems strongly focused on the (desktop) user experience.

The more I think about it, Ubuntu on servers seems like Debian with more current software (usually; Debian etch is probably ahead right now) and longer support, but also with more bugs and problems. And you get to run the same software on your servers as users are running on their desktops (assuming that your users stick with 6.06 on the desktop), which has various advantages.