See also: last week's Letters page.

Letters to the editor

From:	 Rahul Siddharthan <rsidd@online.fr>
To:	 letters@lwn.net
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:	 nn@broadcom.com
To:	 lwn@lwn.net
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
nn@techie.com

From:	 ketil@ii.uib.no
To:	 letters@lwn.net
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 <mark-spamx@firinn.org>
To:	 letters@lwn.net
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.  

--