The 2.7 Kernel: Back To The Future For Linux

Anonymous Coward writes "Now that the Linux 2.6 kernel has been released and is being worked into distributions, many in the open-source community are turning their attention to the next development and test kernel, known as the 2.7 tree. To get an early glimpse at some of the thinking going into the next kernel, key vendors that aid in shaping the Linux kernel helped eWEEK last week put together a long-range wish list for 2.7."

Comments

List? How many items did anyone else see in it?

[Eberlin]

I saw something about clustering support. Not much of a list. There's gotta be more than that. "Focusing on the desktop" does not make a list...it's too vague. Any specifics?

Then again, I suppose you're not going to get very specific on an e-week article.

Don't get me wrong. I'm all excited about 2.6 making the distros and then hearing about what awesome stuff they'll have on 2.7 -- but this article really just leaves me hanging.

So roll your own kernel

[Mr. Underbridge]

Does it strike anyone else as strange that everyone keeps dreaming up more stuff to throw into the kernel? What happened to the unix philosophy of small, independent programs that do one thing well?

That's still the idea. When they say "putting new stuff in the kernel," they really mean "new options that you *can* compile into the kernel." Don't like Ham radio support in your kernel? Don't compile it in. Same for multiprocessor support, or virtualization support, or whatever the hell they throw in that you happen not to want.

That's the beauty. Now - you *are* compiling your own kernels, right? Cuz if you blindly use whatever default kernel RedHat or whoever throws at you, that's not so good maybe. ;)

The article is mostly content free.

[winkydink]

I've read and re-read the article. Other than a couple of vague references, there is no list there at all.

Why It's Done That Way.

[HopeOS]

This may come off as overly aggressive, and for that I apologize in advance, but people who haven't adminstrated *nix boxes in large-scale deployments often fail to recognize that there's a delibrate method behind the file system.

Each one of those directories has a very distinct purpose; it didn't happen that way by accident. The difference between /bin, /usr/bin, and /usr/local/bin may seem trivial to you as a user, but from an administrative vantage point, they are very important.

In single user mode with an ailing system, the most you may successfully get booted is the root partition. You have at your disposal only /bin, /sbin, and /lib. That means that all tools necessary for fixing the system must be there including all kernel modules and shared libraries. It must also be possible for this device to be completely read-only, possibly even residing in firmware. Installing an application in /bin while its companion libraries are on /usr/lib would be folly since the /usr partition may be completely inaccessible. You may notice that some distributions install a stripped-down, statically-linked version of vi in /bin and a full-featured, shared-library version in /usr/bin. Now you know why.

Once booted and all the necessary kernel modules are loaded from /lib, the remaining partitions can be mounted. On a single-user machine, the /usr directory may be on the same partition as root. Often times it has its own partition. But for large-scale deployments, the entire /usr partition may be on a network share. It may also be on a CDROM. Installing software to /usr may be impossible or require a site-wide change. Secondly, it won't do to have software trying to write data to this partition, so programs and data are always separated. All data goes to /var which is normally a machine-specific mount. Also, a diskless machine may mount /var on a ram disk.

To address software installed on individual machines, we use the /usr/local directory. If /usr is read-only, /usr/local is mounted to a separate writeable volume. All software not packaged by the distributor or site administrator belongs in /usr/local if it's machine-wide and in the user's home directory if not. Other conventions exist, including the use of /opt, but that's a site policy issue.

So that's that. Given any package, it is a simple matter to determine if its executables go to /bin, /usr/bin, or /usr/local/bin. Libraries go to the equivalent lib directory. Header files to the equivalent include directory. Manual pages to man. Cross-application data to share. All application data goes to /var including log files and databases. All temporary files go to /tmp. If you follow these rules, there's no end to the configurations you can create. Violate any single rule and you have a machine that cannot be recovered, applications that cannot be shared site-wide, machine-wide, or between users, and data that cannot be conveniently backed up. Sorta like Windows.

You specifically address the issue of plug-ins, but even having an application located at /usr/software/netscape won't help if the installer is looking for /usr/software/mozilla. This class of problem has been solved many times over with package configuration files and scripts. The responsibility is mainly that of the distribution maintainers to facilitate this. If it's not happening for your distro, get satisfaction, or move to a distro that cares.

That said, the browser plug-in issue annoys me, too.

-Hope

Cluster File System

[dotwaffle]

There used to be a cluster fs for windows called Mango - but that's now obsolete thanks to Win2003, which clusters. But Linux can't access that as far as I know. So there is a middleman - Coda. Coda is a clustered file system for use with WinNt/Win95/Linux and is already in the kernel as far as I know. Just clearing up the hole that appears to be at the bottom of the article (really... it's been in since 2.4!)