UpFront

Wichert Akkerman has been trying for some time to add a Debian package build target to the kernel sources to complement the RPM target. His initial effort in October 2003 suffered the fate of bad timing, falling smack in the middle of the 2.6-test series, which had started in July and led to a 2.6.0 announcement in December 2003. Wichert got some work done on the patch at that time and apparently has been maintaining it privately until June 2004, when he tried again to submit it. This time, with the kernel still in some amount of flux at a recent 2.6.6 release (at the time of this writing 2.6.7 also has come out), Wichert's patch got a much better reception, and it looks as though a .deb target will be accepted into the kernel without much fuss.

For a long time, Mel Gorman has maintained on-line documentation of the 2.4 and 2.6 Virtual Memory Subsystem. After Linus Torvalds' surprise move to replace the subsystem en masse in the early 2.4 releases, documentation was scarce or nonexistent. Mel worked like a dog to describe its inner workings and to offer them on-line as a free resource, and his work eventually was picked up by Prentice-Hall for inclusion in the Bruce Perens Open Source Series. The book, called Understanding the Linux Virtual Memory Manager, is a down-and-dirty examination of one of the most difficult aspects of the Linux kernel.

The relationship between the kernel and the C compiler is one of constant controversy. When a kernel release won't compile, often it is not entirely clear whether the problem is with the C code in the kernel or with the compiler's attempt to convert that C code into machine language opcodes. Lately, Linus Torvalds and others have begun to speculate that future versions of Linux, perhaps in the 2.8 or 3.0 series, would require a GCC version beyond 3.3. Linus cited bad handling of aliasing in earlier GCC versions, but the compiler people are likely to have their own views on what is broken in their code and what isn't. In any case, it's not unusual for the kernel to require a tool upgrade, but every time it happens, the break in compatibility opens the floodgates for requiring other tool upgrades. The flip side is that it is generally preferable to require no tool upgrades at all, so the user has as easy a time as possible upgrading the kernel when they want to.

Greg Kroah-Hartman has taken official responsibility for being the sysfs maintainer. He was forced out into the open by Christian Gmeiner, who had been trying to identify the sysfs maintainer to answer a coding question. Before then, no one was listed in the MAINTAINERS file, but Greg has said he'll submit a patch at some point to update that with his own contact information. The sysfs project has advanced quite far in the 2.5 and 2.6 time frame, and is now the preferred method to interface with the running kernel. Of course, some folks still use /proc and other mechanisms, but they gently are corrected and have been gradually (and sometimes quickly) coming around to the new ideas. sysfs has established itself quite successfully over the past couple of years.

Write support for Microsoft's NT filesystem (NTFS) is not exactly a holy grail of computing but, nevertheless, it has been a persistent itch that some programmers have felt a technical need or personal compulsion to scratch. Anton Altaparmakov is one of these and recently has announced a step in the “write” direction for NTFS: the ability to overwrite files that already are resident on the filesystem. Along with this, the NTFS driver also performs some housekeeping chores that previously had to be done by hand to prevent corruption. Clearly, NTFS is not yet ready for hard-core use and still is best for users needing to copy data out of their old disks, but it seems a time will one day come when full-on NTFS support will be available in Linux.

The PC9800 sub-architecture is slated to be dropped from the 2.6 tree. The hardware is obsolete, which is not necessarily grounds for removing a feature from the kernel. But, in addition to that, the PC9800 code is unmaintained, which certainly is grounds for removing a feature. Linus Torvalds has made it abundantly clear that it doesn't matter even if there are users clamoring for a feature; if code is broken and no one will fix it, out it goes. Of course, thanks to the proprietary BitKeeper revision control system, it is easier now to put the code back into the kernel once a maintainer is found. And, among other justifications for putting unmaintained code on the chopping block is that it does get the attention of people who might then choose to maintain it.

Another bit of code that may end up being dropped from the 2.6 tree is the venerable UMSDOS feature. Back in the old days, UMSDOS was used to install Linux within an existing MS-DOS partition, so folks could experiment with it without repartitioning their drives. Nowadays, UMSDOS is not used as much, but its historical value is significant, so much so that Linus Torvalds, Andrew Morton and the other kernel maintainers might be happy to leave it in the kernel for posterity's sake. Unfortunately, however, UMSDOS is currently broken in 2.6, which greatly reduces the chances that it will be kept around. Without a maintainer to nurse it back to health, the tool that introduced many folks to Linux in the early days may become only a memory.

It is wrong to say that demand creates supply. It is the other way around.

—Henry Ford, www.jyu.fi/library/elkok/isbn9513911675.pdf

Invention is the mother of necessity.

—Thorstein Veblen, www.quotationspage.com/subjects/invention

Well now home entertainment was my baby's wish So I hopped into town for a satellite dish I tied it to the top of my Japanese car I came home and I pointed it out into the stars A message came back from the great beyond There's fifty-seven channels and nothin' on.

—Bruce Springsteen

If we believe we “own” the customer we will quickly die.

—Juha Toivari, EVP, Head of Authentication and Certificate Services, Nordea Bank, IDman conference speech, London, July 2004

The technology that preserved the balance of our history—between uses of our culture that were free and uses of our culture that were only upon permission—has been undone. The consequence is that we are less and less a free culture, more and more a permission culture.

Lawrence Lessig, Free Culture, blogspace.com/freeculture/Introduction

Understanding the open-source process can generate new perspectives on very old and essential problems of social cooperation. And it can provide an early perspective on some of the institutional, political, and economic consequences for human societies of the telecommunications and Internet revolutions.

Steven Weber, The Success of Open Source, www.hup.harvard.edu/pdf/WEBSUC.pdf

Cynicism about new technologies shouldn't blind us to the way the business is changing. New ways of organizing emerge periodically—and can be of huge significance. Open source may well be among them.

—Matthew Lynn, Bloomberg.net, quote.bloomberg.com/apps/news?pid=10000039&refer=columnist_lynn&sid=aqq4dVXwLQ8Y