Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.4.0-test6, which Linus released just moments after LWN was published last week. There is a 2.4.0-test7 prepatch out there, currently in its fourth revision. Linus has picked up a nice new habit: sending out changelogs for his releases; here's the changelog for 2.4.0-test7-pre4.
The current stable kernel release is still 2.2.16. A prepatch (2.2.17pre17) went out on August 15, but there has been no announcement for it, so far.
vger.rutgers.edu is down due to a disk failure as of this writing, and has been for about a day. That means that the linux-kernel mailing list (along with many others) is not currently functioning. For those who are used to the 150-200 message per day linux-kernel stream, things seem awfully quiet and peaceful.
At the Ottawa Linux Symposium David Miller said that the lists were going to move over to a new machine (vger.redhat.com). It may be that he'll take this opportunity to make the move.
Multistream files - again. Every so often, the kernel development list seems compelled to go through a discussion of whether - and how - Linux should support multistream files. This time around it started with a query as to whether Linux had any sort of support for streams along the lines of NTFS. The requester got his answer ("no") fairly quickly, but the discussion went on rather longer than that.
A lot of people like multistream files. They let you do things like attach a thumbnail to an image file, attach "sticky notes" to a document, any many other things. Complex information can be attached to a file which simply stays out of the way for most actual uses. The concept is not without its merits.
Nonetheless, quite a few kernel developers feel that Linux has no business supporting multistream files. Such files certainly twist the normal Unix way of dealing with data. They also present practical problems: how do you make cp copy a multistream file properly; how do you get tar to back it up? Most network protocols (i.e. FTP, HTTP, NFS, etc.) also do not understand multistream files.
Just as the kernel developers were getting going with the ritual trashing of the multistream file idea, Linus joined in with a statement that Linux should support the concept. His reasoning is simple: like it or not, there are several filesystems out there which implement the multistream concept. If Linux is to play well with other systems, it has to support those filesystems. And a proper job needs to be done of it - meaning that multistream files need to be supported well.
A number of ideas were raised on how to implement the multistream concept. At one end of the scale is Pavel Machek's unfortunately named Podfuk utility, which shoves the work into user space. A commonly-raised idea is to make a multistream file appear to be a directory, with each stream looking like a file within that directory. If the file itself is opened, the operation is remapped to a default stream (often known as the "data fork") within the file. There are even schemes for automounting some sort of specialized filesystem on top of multistream files when they are opened.
Those are all just ideas, however. The fact is that Linux is far from any sort of proper multistream file implementation, though a hack for Apple's HFS does exist now. But the door has been opened, and such a thing will probably go in at some point.
The OpenXDSM project launches. XDSM is the "Data Storage Management" API; it is apparently oriented toward hierarchical storage and data migration tasks. The OpenXDSM project, which announced its existence this week, has set out to create an open source XDSM implementation. Thus far they have some support from BigStorage, Inc, a SourceForge page, and not a whole lot more. Obviously, they are looking for interested people to help out.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
August 17, 2000