Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.3.12. There is a 2.3.13 pre-patch available. In this patch, Linus has changed the way driver initialization is done, eliminating the need for the big pile of ugly #ifdef's in init/main.c. This is a far-reaching change, requiring tweaks in lots of drivers. There is nothing complicated about these tweaks, but there are a lot of them, so it could be a little while before this change works it way through all the code. See Linus's announcement for a bit more information.
Linus has also proclaimed that a 2.3 feature freeze will probably happen in about two weeks. He is clearly serious about trying to get a 2.4 out in the fall. While there is little disagreement that 2.2 was too long in coming, one could well wonder if 2.4 isn't being a little rushed. By some accounts, 2.2 hasn't really stabilized yet (though it works great for most people); by the time it does, it may already be obsolete.
Looking forward to 2.4, Joseph Pranevich has put out the first version of The Wonderful World of Linux 2.4, which describes the changes that will appear in that release.
The current stable release remains 2.2.10. Alan Cox has been passing around a set of 2.2.11 pre-patches, but Alan has been somewhat scarce in recent weeks and progress on that front has been slow.
If there are any Sparc users who are considering trying 2.3, our advice is to wait. Some of the memory management changes in 2.3 broke badly on the Sparc, with the result that the 2.3 kernels do not build. Work is underway to fix that, but it's going to take a little while yet. Unless you're willing to help out with the work, the best thing to do is to hold off for a few more releases.
Your backup is unsafe, but don't worry too much, it's just a Windows partition. So starts this note from Robert de Bath. Here's the problem: those who have dealt with the Windows "VFAT" file system know that there can actually be two names for a file. The file system supports long file names almost like a real operating system, but, underneath it all, there is a DOS 8.3 ("short") filename that really identifies the file. Thus "Program Files" becomes "Progra~1".
The Linux VFAT file system only makes the long file name visible to the user, on the reasonable assumption that it is the one they want to see. Usually all works just fine. But imagine that you back up this file system, then restore it at some future time. All of the long file names will go back the way they were before, but Linux has to generate new 8.3 names to go with them. Those 8.3 names will usually be the same ones that were there before, but not always.
Changing 8.3 names would not necessarily be a problem, if it weren't for certain programs (i.e. Office) which actually depend on them. Long and short file names also tend to get mixed up in the Windows registry, leading to serious havoc if they do not continue to match up together. Since there is no reason why a rational person would use VFAT if they were not working with windows software, this is a real issue.
Solutions to this one will not come easily. The Unix worldview is just not prepared to deal with two weirdly linked names for the same file in this manner. The most common idea was to turn the long file name into a link (either hard or soft) to the 8.3 file name, and present both in a directory listing. Since VFAT does not support links, this usage would be unambiguous, and seems like an easy way out.
But only until one really thinks about the problem. The short and long names are tied much more tightly than Unix links; who expects that, when you rename one link to a file, that the other would change too? Since directories, too, have long names, the use of hard links is out of the question; hard links to directories are a quick path to trouble in almost any Unix-like system. Even with symbolic links, trying to make everything actually work right would be slightly less fun than, say, being tied over an anthill.
So it's not clear that this problem will get solved. And one could indeed ask how important that is; it seems that almost all backup programs that run under Windows have the same problem. VFAT, in the end, is a piece of ugliness that is exceptional even in the Windows context; there is only so much that can be done to make it work right.
A few notes on SCHED_IDLE, the proposed new scheduler class (discussed in last week's issue) which would run low-priority cranker jobs only when nothing else wants to run:
Other patches and updates released this week include:
Section Editor: Jon Corbet
August 5, 1999