Linux in the news
All in one big page
See also: last week's Kernel page.
Substitute editor's introduction. Watching the linux-kernel mailing lists is a task left to those with an interest in which bits fly across an ether, not whether or not those bits look green or blue (as we desktop nerds prefer). So when Jon asked me to fill in for him on the Kernel page this week I felt a tang of distaste. Wondering whether BIG_BUF_OVERFLOW_MASSIVE_CRASH_HELP is supposed to be an unsigned long or int in the scheduler is tantamount to a master chef asking me if a teaspoon or two of salt belongs in the Quiche. Me, a man who spends most of his fine dining at McDonald's and The New Emperor's Chinese All You Can Eat Buffet and spends weekends popping excessive amounts of salt tablets after rather exhausting rounds of Putt-Putt golf. I stand emphatically and pronounce "Make it an unsigned long" and walk away proud to know that I will never know if it made a difference or not. It had no color. It wasn't important.
Unfortunately, on this page, for those millions of loyal readers of Jon's weekly summaries and analysis - and for those who know it really did have color - it does matter. And so I'll taste the Quiche (and check which bits have been twiddled) once again. Bleck.
The current development kernel release is 2.4.0-test12. Linus posted 2.4.0-test12, the latest in the pre-2.4.0 series, on Monday. The first prepatch for 2.4.0-test13 is out; it is a small patch consisting entirely of makefile changes.
The current stable kernel release is 2.2.18. Alan Cox has posted the release notes for the 2.2.18 kernel release. The major thrust for the i386 line has been support for processors running in excess of 2GHz, support for the CyrixIII processor and also basic support for the Pentium IV. A slew of memory leaks were also cleaned up, including some in the popular bttv driver (the primary driver used for PC-based TV cards). That driver was also updated to allow subwindow clipping.
Looking forward to 2.2.19, Alan Cox has indicated that he will look at incorporating some virtual memory fixes. Evidently the (much improved) 2.4 VM has impressed him, but he plans to make 2.2 be even faster. Linus took the challenge: "You and me. Mano a mano." It should be fun...
Disk corruption problems found? Andre Hedrick, maintainer of the IDE subsystem, has evidently found the cause of occasional disk corruption reports. It appears there is a "feature" in the IDE DMA implementation that stops a DMA operation if there is a delay of one microsecond or more. The current crop of large drives may be more inclined toward this sort of delay, and may be behind some of the current complaints.
Fixing the problem may take some work; Andre has three possible alternatives. The third one, however, is "give up and go to bed," which may not appeal to all users...
Pentium 4 and Linux Distributions. An article posted on C|Net News.com (from an original posting on LinuxGram) noted that support for Intel Pentium 4 processors was not being included in most current Linux distributions, with Red Hat and TurboLinux being the exceptions. The problem wasn't with Intel, however - that company had provided the appropriate CPUID information to the major distributors some time back. Instead, the distributors had decided, for one reason or another, not to include support for that processor.
Caldera's [vice president of engineering Darren] Davis basically agreed with [Intel's P4 spokesman George] Alfs' characterization, noting that "Intel gave us all the (Pentium 4) information we needed."
Interestingly enough, the release notes for the 2.2.18 release from Alan Cox included this bit of information about the Pentium IV:
Unfortunately Intel chose to ignore all precedent in model numbering via cpuid and report a family of '15'. This sudden jump broke assumptions in the kernel tree without any warning. Intel have failed to provide good reasons for their change. We have chosen to continue to report the Pentium IV as a '686' class processor. The full family data is provided via cpuinfo.
This sort of makes you wonder just who had the information, who actually wanted the information and why, if it really was available, it really wasn't used.
Not long after noting the C|Net News.com article on the LWN.net Daily Page, we received the following note from a SuSE employee:
SuSE provides an updated installation floppy image at
It was unclear whether News.com had contacted SuSE (or any other distributions) to clarify the issue.
Rule Set Based Access Control (RSBAC). On Monday, Amon Ott posted the announcement of the release of version 1.1.0 of the Rule Set Based Access Control (RSBAC). RSBAC is an open source security extension for current Linux kernels. It is based on the Generalized Framework for Access Control (GFAC) by Abrams and LaPadula and provides a flexible system of access control based on several modules. Essentially, RSBAC interposes a central decision maker between an application and the system calls it makes; rules may be applied to any system call which determine whether the call is actually allowed to execute or not.
In the current RSBAC version (1.1.0), eight modules are included:
kORBit - the Linux kernel CORBA ORB. Here is one of the more interesting kernel patches we have seen go by for a while: kORBit is a CORBA object request broker (ORB) which runs in the Linux kernel. It allows kernel extensions to be written as CORBA objects. Possible applications, from the announcement, include:
Other patches and updates released this week include:
Section Editor: Michael J. Hammel
December 14, 2000