Linux in the news
All in one big page
See also: last week's Letters page.
Letters to the editor should be sent to firstname.lastname@example.org. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
November 22, 2001
From: Rahul Siddharthan <email@example.com> To: firstname.lastname@example.org Date: Thu, 15 Nov 2001 11:06:54 +0100 Dear LWN, This is with reference to your editorial this week (Nov 15), where you talk about the problem of a long stabilisation period for the 2.4 kernel and a lack of a development branch, and suggest the Debian model where releases happen more slowly but are more stable, while the unstable branch continues. It seems to me that the BSDs, all of them, have got this right. They make stable releases frequently (much more rapidly than Debian), while continuing work on the development branch. Although I started with using linux and still read lwn regularly, I now use FreeBSD almost exclusively; it seems quite competitive with linux for new features, hardware support, etc while being extremely stable and, reportedly, often having much better performance even today. (It's hard to tell on a desktop machine, though.) While the release date of FreeBSD 5.0 was pushed far into the future because of its ambitious agenda, new features get backported to the 4.x branch regularly, after first being thoroughly tested in the 5.x branch. I'm not a developer myself, but the evidence suggests that this system works (and works very well). Though FreeBSD's first (dot-zero) stable releases are often marked for early adopters, 4.0 in fact was already good enough for general production use, which is more than can be said even for linux 2.4.9 (or for 2.2.x for x<7 or so). In fact, one usually comes to no harm when syncing one's sources to just about any point on the -stable branch. It's even more impressive when you consider that the BSDs maintain the entire base userland -- libraries, utilities, and all -- apart from the kernel. Surely such a system could work for linux too? Perhaps the major factor here is the cvs-based approach of the BSDs, which Linus dislikes so much. Rahul
From: email@example.com To: firstname.lastname@example.org Subject: The 2.5 kernel is coming Date: Wed, 14 Nov 2001 21:37:23 -0800 > Many kernel developers have had no target for new code in a year. A kernel should not be a dumping ground for every feature that an undergraduate might consider. The job of a kernel is to provide some simple layers of abstraction over the underlying hardware and get out of the way. A kernel should be a pencil, not a word processor. > The 2.4 kernel has been a very long time in stabilizing. Which is not surprising considering the huge amount of SMP and NUMA big iron feature and algorithm complexity that has been applied over the past two years. Plus a new VM. neal nuckolls email@example.com
From: firstname.lastname@example.org To: email@example.com Subject: Microsoft's "threat" Date: Thu, 15 Nov 2001 09:10:53 +0100 (MET) In his (as usual) very good article, Bruce Schneier wonders: > What [Culp] did was to rail against the publication of vulnerabilities, > and ask researchers to keep details under their hats. Otherwise, he > threatened, "vendors will have no choice but to find other ways to > protect their customers," whatever that means. I cannot help but think that the most obvious "other way" is to actually fix the bugs. Some threat. -kzm
From: Mark Bainter <firstname.lastname@example.org> To: email@example.com Subject: Re: bug reporting in noncommercial software Date: Thu, 15 Nov 2001 10:18:32 -0600 I would have to agree with Seth's assessment of the situation. It takes someone really dedicated to take the time and write a usefull bug report. I don't think any automated system can replace that. But, I do agree that an automated system could help to eliminate a lot of the smaller bugs that often go unnoticed because it isn't worth the time and effort to report it. I would propose an alternate solution however. Instead of having a standard system for doing bug reporting, (i.e. one app that handles it for all apps) I would suggest having the standard be some permutation of the applications name + bug. For example vimbug, or etermbug. These would be provided by the application writers to gather relevant data about the system and compose an email message for the reporting person to then puruse, edit, and submit along with a description of the problem. The reason I suggest this instead is that each app is different. Vim doesn't generally need to know what version of window manager you are running, or even which one you are running. Eterm doesn't care what version of modutils you are using. Let the developers decide what information is most usefull and have it gather all that background data, so all the user has to do is make sure they are ok with the information being submitted, and add in the actual description of the problem. --