Enterprise Unix Roundup: A Taste of Linux Kernel 2.6

There are some who judge the Linux kernel in the same way they
consider wine. While the 2.0 and 2.2 series are remembered as good
vintages, the 2.4 series was a troubled one that required a lot of
point releases before people got around to trusting it much. It also
had the unfortunate distinction of undergoing a major overhaul to a
critical subsystem (the virtual memory manager) midway through its
life.
A feature freeze in the Linux kernel has some developers concerned, but it's likely the hobbyist/enterprise partnership that drives Linux will lay those fears to rest. Plus: Sun offers free downloads of Solaris x86 ... and tips on the Unix slay command.

So with a new kernel on its way (version 2.6), there's a
natural curiosity about how this particular vintage is going to shape
up: smooth and unsurprising like 2.2, or maybe a little tart, like
2.4.

We won't claim to know, because outside skimming the release notes
for each development release we don't much play around with the Linux
kernel's development versions (the odd-numbered ones, such as the 2.5
series which just gave way to the 2.6-testing versions). There's no
real future in it for the sorts of things we're doing day-to-day
around the Roundup Ranch.

When Linux kernel 2.6.0 is released, though, we have a reliable
testbed machine we'll try it out on, and we'll probably spend several
months following releases closely, monitoring the usual mailing
lists, and listening for what others are finding. We suspect there
are a lot of Linux users like us, especially in the enterprise space,
who won't want to bother with release chasing, and they'll want their
favorite distributor to go through a round of patching and packaging.

There will be, however, a lot of folks who will start pressing the
new kernel into service almost immediately. We know of one eager
Web master who considered his adoption Linux 2.4.0 the day it
was released as a point of pride. We thought he was crazy. But out
of those many people like him, the real strength of Linux' design
methodology will come to the fore: There will be a lot of folks
hammering away at the "final" product, paving the way for refinements
over its lifespan that will make the later point releases as smooth as
other classic kernel vintages.

It's an interesting point of contact
between the hobbyist/"consumer" world and the enterprise world: By the
time you get around to adopting the new kernel for your production
servers, a lot of folks with considerably less at stake than a
data center or financial application will have caught much that would
have made your life difficult. While there are some heroic figures in the
Linux development community, there are also a lot of folks tucked away
in the Red Hats and SUSEs who will work on the current series with an
eye to making it useful for the products their bosses are trying to
sell.

That's why the minor tempest over Linux 2.4 series maintainer
Marcelo Tosatti's decision to freeze new features in order to
encourage developer attention to the 2.6 series seems ill-considered.
The argument goes that the best and brightest of the Linux developer
community will move on to the 2.7 development series right away,
spending no time with the 2.6 series out of a desire to chase down the
newer, more interesting challenges.

While it's probably true that the
superstars will move on, the quiet pros will still be plugging away,
adding refinements and listening to the massive testing community out
there. It's part of the appeal of the Linux development process now
that the project has become so intertwined in both the grassroots
developer community that spawned it, and the enterprise community that
has come to depend on it.

We're predicting the same smooth finish for Linux 2.6 that we got with
the versions that came before it.

In the News

Sun has reopened
Solaris x86 to free downloads under its Free Solaris Binary
License Program, returning to the status quo that prevailed before
it first tried to abandon the OS earlier this year.

We weren't sure about Sun's wisdom when the company decided to
name its former "Mad Hatter" the Java Desktop System. Now that
we've read about Sun's pending deal with WalMart to put
JDS-powered systems on the shelves, and come across analysts
describing the product as "Java-based" in response to the deal,
we're sure our instinct was correct. Sun's eagerness to push
Linux to the background by covering the product with the Java
brand just means marketplace confusion in exchange for a point
of pride.

SCO suffered a setback when the judge in its case against IBM
told the company to provide evidence IBM
says SCO has been witholding. SCO preferred to spin
the matter as a question of the judge asking SCO's help in
getting things rolling. Looks more like the judge ordered an
abrupt end to SCO's prolonged fishing trip. The company also
fell victim to a
denial of service attack on Wednesday, which it was quick to
blame on "someone from the Linux community." For its part, some
in the Linux community are wondering if SCO was even really under attack.

SGI's xfs
journaling file system has ended up in the 2.4 series of
the Linux kernel despite earlier indications it wouldn't be
included in the core distribution until the 2.6 series. The
primary issue is less the filesystem's ability to work with the
Linux kernel, which it has for some time, but whether an extra
download of the filesystem's source from SGI would be required
to patch the Linux kernel and use it.

Security Roundup:

Just after we went to press last week,
a number of distributors released updates of rsync (which our
readers may remember from a previous
Tip of the Trade. The bug this update patched was serious
enough to be involved in a spate of compromises of high-profile
Linux projects, including the Gentoo distribution and the Savannah
project's servers. If you're running rsync in server mode, this one
warrants a look.

Tips of the Trade:

The Roundup Ranch is home to a small artists colony of a server,
where some creative folks without a lot of bandwidth or terms of
service with their ISP that will allow them to run services. We
enjoy providing the service because it keeps us in the "serving the
end user" game that writing about this stuff keeps us from more than
we might like, and it gives us a chance to see what cutting-edge
types are playing with. We provide a lot of room for
experimentation, provide whatever tools our users need, and keep an
open mind. But when a recent project got out of control, we were
glad to have one of those weapons of last resort that sysadmins
depend on when all else fails: the merciless slay.

What's slay? Think of it as kill's thermonuclear cousin.

The situation was this: Our consumer-grade DSL connection went down
for service at some point in the evening. A collection of clever
programs one of our users wrote to collect newsfeeds and republish
them
on his site continued to run, and run, and run. Even though there
was no Net to connect to, they ran every few minutes, creating a new
process, waiting for a response from a server they couldn't connect
to. By the time we got up the next morning and looked in on
our server, there were so many running processes that we couldn't
run many commands without getting errors because the total allowable
number of
open files was maxing out. We were able to run a
quick ps ax, which told us that the processes were also
running with many different names, which made killall a tough
proposition. We didn't want to have to use it for every program
running, because there were at least a dozen different program names.

With the server slowly collapsing under the weight of all these
programs, though, we had to do something. So we unleashed slay, which
works with a single argument: the login name of the user whose
processes you want to kill. You can add which signal to use, as well,
so for extra pesky processes you can slay -9 username.

The tricky thing about slay is the differences between commands of
the same name on varying systems. In Linux and BSD variants, slay
performs as we described it. Under QNX, it works more like
killall, working by processname instead of username, and it
doesn't turn up at all in a few other Unixes. So before you unleash
it on a user whose processes are running amok, make sure to check the
man page and see just what it does.