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-test12. The -test13 prepatch is up to 2.4.0-test13-pre3. In addition to the major makefile thrashup, it contains a large cleanup for shared memory handling and a number of other fixes.
Those who are interested in reasoning behind the makefile changes can take a quick look at this note from Linus which we fished out from among the extensive spam on the kbuild list.
Alan Cox has put out 2.4.0-test13-pre3ac2 which contains a number of pending fixes. It is, says Alan, "for the adventurous."
The current stable kernel release is 2.2.18. Work continues on 2.2.19, with the current prepatch being 2.2.19pre2. The bulk of the effort currently is oriented toward integrating Andrea Arcangeli's virtual memory work.
2.2.18 breaks the emu10k1 (SB Live!) driver, at least if it's compiled directly into the kernel. The fix, for those not wanting to wait for 2.2.19, is to apply this small patch.
The Linux Quality Database Project. Michael D. Crawford has announced a new bug tracking project for the Linux kernel. His plan is to put together a database-backed web site where users can report kernel bugs, search for bugs relating to their hardware, and track when and how things get fixed.
The idea certainly has merit. There is currently no formal mechanism for tracking kernel bugs other than the extensive database in Alan Cox's head (and the "TODO" lists that are kept at the end of development cycles). The "AC" database appears to be comprehensive, but access is difficult for most Linux users, and making backups has proved difficult. A development project as fundamental as the kernel really should have a better scheme for keeping track of things.
Of course, this sort of thing has been tried before. The real problem is not the development work in making the system function; that is relatively straightforward. But if the kernel developers do not actually make use of the resulting system, its database is worthless. Kernel hackers tend to be busy people, they are uninclined to spend time maintaining some database somewhere. Linus, in particular, has been unenthusiastic in the past.
So this project has some challenges in front of it. Success will require paying as much attention to the human side of the equation as to the technical side, if not more. If it works, the rewards will be worth it.
On the public nature of the linux-kernel list. The linux-kernel list has long been a place where people have said what they thought, without a great deal of concern over who might be watching. They do so, in fact, to the tune of about 200 messages per day. LWN includes messages from this list, but we have always made a point of passing over the more inflammatory stuff. After all, very little is accomplished by reproducing flamewars.
Increasingly, however, linux-kernel is being watched by people who have little real interest in the kernel itself. Journalists see the list as a way to tune into what's going on with Linux, and not all of them will resist the opportunity to engage in a little sensationalism.
Example: we would not have normally included Linus's opinion on Red Hat 7 here. Excerpts from that posting, however, showed up on Linuxgram as "Linus Savages Red Hat 7.0". There is little new to be said about the choice of compiler in that release (which LWN covered at the beginning of October); the only point was that Linus was speaking strongly, as is his way at times.
This particular episode doesn't mean much. The real point is that Linux kernel development, at least as it is expressed on linux-kernel, is an increasingly public process. The open nature of the process is a good thing, of course, but a spotlight that is too bright could prove to be worrisome. The development process will be hurt if developers no longer feel that they can speak freely to each other. It would be a shame if communications among the developers were to be repressed, or if it were to move to closed, invitation-only mailing lists.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
December 21, 2000