Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is, of course, 2.4.0-test1. Alan Cox continues to develop the "ac" series, with the current version (as of this writing) being 2.4.0-test1-ac18. At times, the interval between "ac" releases seems to be less than the time required to download and compile one of them - a lot is going on.
The "ac" kernels certainly qualify as development kernels, however. Most people who tried ac13 regretted it, as a buffer problem caused a lot of crashing and file system checking time. ac16 didn't compile for many. On the other hand, your editor is finding life reasonably comfortable, if not on the bleeding edge, with ac17.
A new 2.4 jobs list was posted on June 13.
The current stable kernel release is 2.2.16; this release came out just as last week's LWN hit the web. Since then, Alan Cox has made the release notes available, as well as a thank-you note to the people who helped find and fix the security holes that 2.2.16 fixed.
Since that release, a few problems - including some security issues - have come up with the 2.2.16 release. As a result, a 2.2.16 errata patch has been released - something that has almost never been seen with Linux kernel releases. If you have upgraded to 2.2.16, you almost certainly want to apply the errata patch.
The 2.2.17 release appears to be on the fast track as a consequence of the above-mentioned problems. There is a 2.2.17pre1 patch available now, which contains the 2.2.16 errata and some other stuff. It will likely become official after a relatively small number of revisions if all goes well. Since the emphasis is on getting the bugfixes out quickly, the larger NFS updates look like they will have to wait yet again; maybe in 2.2.18...
Are the 2.2.16 security fixes in the 2.4.0-test1 series too? This fairly obvious question came up this week. Alan's terse answer is that "some of them" are in there. Alan points out that there has not been a real security audit of the 2.4.0-test1 releases yet; expect a surprise or two to be lurking there.
RMS wants easier floppy access. Richard Stallman jumped into the kernel list with this request to make access to floppies easier ("like MSDOS"). The need to explicitly mount floppies (or use mtools) was held up as one of the things blocking adoption of Linux by Windows users. Mr. Stallman might even be right. Whenever somebody wants to depict Linux as difficult to use, it's standard practice to dig up some sort of ugly mount command.
The most common answer to this problem seems to be supermount - a special filesystem which detects media insertion and removal and tries to keep everything straight. Supermount is included with the Linux-Mandrake distribution, and probably with others as well.
Supermount, unfortunately, also suffers from a lack of attention. According to MandrakeSoft's Jeff Garzik, getting supermount ported to the 2.2 kernel required some incentive via a project on Cosource.com; work has been done on a 2.3/2.4 port, but it is currently stalled. There is also evidently a need for an audit by a serious filesystem hacker to deal with some questionable practices and race conditions.
It is hard to imagine that supermount could be made ready for inclusion into 2.4.0 at this point, though surprises are always possible. But it would be nice if adding supermount separately were an option.
Linux Kernel Auditing Project. An announcement has gone out for the Linux Kernal Audit Project - a group that wants to go through and proactively seek out (and fix) security problems in the Linux kernel. They have a mailing list set up for those who would like to participate.
Symbolic link behavior has changed in recent kernels. If a symbolic link points to a nonexistent file (a "broken link"), an attempt to create the file via the symbolic name will now fail. In other words,
ln -s no-such-file link touch linkwill fail with a "no such file or directory" error with recent 2.4.0-test1 kernels. With old kernels, instead, no-such-file would be created. A few applications have been broken by this change, leading to complaints.
According to Alexander Viro, this change was deliberate (the old behavior was "taken out and shot"). The problem, evidently, is that the old behavior is very hard to implement in the kernel without a bunch of race conditions. Unfortunately, it seems that the POSIX standard says that the file creation should work in this case (except when the O_EXCL flag is used, which is not the usual mode). So Linux has just moved out of compliance in this regard.
The kernel generally tries to adhere to POSIX except in cases where it really makes no sense. So it is likely that somebody will eventually apply the needed brainpower to reimplement the old semantics in a safer manner.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
June 15, 2000