Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.1.119; this kernel has been out for almost a week. A series of 2.1.120 pre-patches has appeared, a full kernel release will likely happen soon. Linux 2.1 remains in feature freeze, of course, with only bug fixes going in. Many of those are being generated, with quite a few bugs yet to go. 2.2 is not quite around the corner yet.
Version 7 of the 2.0.36 stable kernel pre-patch has been announced. Alan Cox's announcement describes the changes. This may be the last before the 2.0.36 release, so now is the time to gripe if something is not working.
There have been some complaints that the 3c59x driver in 2.1.120pre does not work. If you are seeing this problem, David Miller would like to hear from you. He needs to know which cards are showing problems so that he can work on a fix.
Users of the 2.1 kernel NFS daemon should be aware that it suffers from a number of security problems. These are being worked on, now that Alan Cox has called them out, and should be history by the time 2.2 comes out. H.J. Lu has, meanwhile, released a new version of knfsd with more fixes in it. There have been some reports of compilation failures with this release, though. Another may be forthcoming early next week.
Version 3 of Rik van Riel's "out of memory killer" patch is available. This patch enables the system to kill carefully-chosen processes in desperate memory shortage situations. Rik says this version "might even work" and declares it ready for beta testing. The intent is to get the bugs ironed out so that this change can go into the 2.2 kernel. Here is the patch for 2.1.118; give it a try and let Rik know how it works.
Rik also posted a summary of 2.1 memory management issues in response to a request. Check it out if you're interested.
William Henning wrote to let us know that he has added results for a Deschutes P-II to his kernel compilation benchmark article.
Version 0.51 of the RAID driver has been released. This release incorporates a lot of changes, see the announcementfor more info. This is an alpha release, and comes with a suitable set of warnings.
Much discussion this week centered around possible implementations of "forked" files for Linux. Forked files, as implemented in MacOS, NT, and other systems, allow the storage of metadata in parallel with the normal contents of disk files. Uses for this capability include storing an icon with an executable file, or "attaching" applications to individual files to allow reasonable things to happen when a file icon is invoked by a user. In other words, much of the perceived need for this capability comes from the graphical desktop arena.
There are a number of advocates for a kernel-based implementation of forked files. Reasons behind this approach include efficiency, maximizing transparency of access to forked files, minimizing changes to user space libraries, and keeping users from reaching "around" the fork implementation and corrupting things. An outspoken member of this camp is Hans Reiser, who sees his "reiserfs" file system development as an ideal vehicle for this sort of capability.
In opposition are those who feel that forks should be implemented in user space. Reasoning on this side says that kernel bloat will be minimized, normal Unix file semantics will not be messed with, and that it is easier and more flexible to implement these capabilities as a user space library. The need to retain Unix file semantics is important: otherwise tools like tar or cp break, network protocols like NFS, FTP, and HTTP become unable to cope with forked files, and applications (like KDE) which run on multiple systems can not use the new capabilities without becoming system dependent.
There is also a crowd that claims that forked files are useless and unneeded, no matter what the implementation is.
A feature like forked files would not go in before kernel 2.3, certainly, if it goes into the kernel at all. So the various parties have some time to argue about it.
September 3, 1998