See also: last week's Back page page.

Linux links of the week

Another approach has been taken by Advogato, which has been up and running since last November. Advogato carries a certain number of free software and freedom-related stories; it also hosts diaries for its readers. A look at the site on any given day will show new diary entries from a number of well-known Linux personalities. There is also an interesting "certification" mechanism which establishes a reputation value for each member.

Section Editor: Jon Corbet

Letters to the editor

Date: Tue, 9 May 2000 20:18:39 +0200
From: Ragnar Hojland Espinosa <ragnar@macula.net>
To: lwn@lwn.net
Subject: http://www.lwn.net/2000/0504/


   Kerberos protocol - sort of. You can only get the information in the 
   form of a self-extracting executable file, which puts up an    
   intimidating "click wrap" license first. It seems that the Kerberos 

That's not true.  You just have to open the file with winzip and, oh lookie,
a pdf :)

-- 
____/|  Ragnar Højland     Freedom - Linux - OpenGL      Fingerprint  94C4B
\ o.O|                                                   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for      104B78C56 B72F0822
   U     chaos and madness await thee at its end."       hkp://keys.pgp.com

Handle via comment channels only.

Date: Fri, 5 May 2000 13:26:51 -0400
From: "Jay R. Ashworth" <jra@baylink.com>
To: letters@sptimes.com
CC: trigaux@sptimes.com, asp@baylink.com, letters@lwn.net
Subject: LoveBug worm

I'm quite disappointed to see that none of today's coverage of this
topic points out that the reason this worm spread so far so fast is
that -- as it always has -- Microsoft has chosen to favor convenience
over security in the default configurations of most of its operating
system and applications software.

In many cases, poor Outlook users didn't even *have to open* the
attachment, Outlook would be "helpful" and do it for them.

This is not the first time this has happened... but it's also not the
first time the *general* press has failed to make it clear that the
fault lies as much with Microsoft as it does anywhere else.

The technical press seems to do a slightly better job of getting it
right, although they're not perfect either.

In any event, until people (by which I mean the highly paid network
administration staffs of Fortne 500 companies just as much as
individual PC owners) start to think security -- or switch from
Microsoft software to better designed programs (like Eudora and
Netscape Messenger) and operating systems (like Linux and the Mac OS),
this sort of thing will continue to occur... and people will continue
to find out the hard way that stupidity is supposed to be expensive.

Cheers,
-- jra

-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     
The Suncoast Freenet
Tampa Bay, Florida     http://baylink.pitas.com                +1 888 806 1654

Date: Thu, 4 May 2000 14:47:11 -0700
From: Nathan Myers <ncm@nospam.cantrip.org>
To: editor@lwn.net
Cc: bad@kitenet.net
Subject: Tucows download stats


In this week's LWN, while discussing Tucows download statistics, 
Liz observes:

  The really startling note from the three months worth of data, 
  still a small sampling, is the lead that the two RPM-based 
  distributions have on the rest of the pack. It will be an 
  interesting trend to watch. 

Considering that Corel and Stormix are basically Debian plus
some add-ons, it's worth looking at the statistics with the 
three combined.

February
Linux-Mandrake     46%
Red Hat            27%
Debian+            18%
SuSE                3%
Slackware           3%
Caldera             3%

March
Debian+            36%
Linux-Mandrake     31%
Red Hat            14%
Caldera             6%
SuSE                5%
FreeBSD             4%
Slackware           1%

April
Red Hat            31%
Debian+            29%
Linux-Mandrake     29%
Caldera             4%
FreeBSD             3%
SuSE                3%
Slackware           2%
Yellow Dog Linux    1%

Here we have the Debian/Apt-packaged family easily keeping up with the 
more heavily-promoted commercial distributions.  March is interesting 
in that Debian downloads far exceed Mandrake's much-hyped popularity.

Perhaps once Potato is out, Debian will just take over the world; 
then all those people working on proprietary distros can go home and 
do something productive instead. :-)

Nathan Myers
ncm@nospam.cantrip.org

Date: Thu, 4 May 2000 15:37:24 +0100 (BST)
From: Dunstan Vavasour <dunstan@grenville.co.uk>
To: letters@lwn.net
Subject: Kernel Releases, Feature Creep, etc.


The process Sun use for developing OS releases (so a fairly reliable
source told me) is to have two development teams, each producing alternate
releases. So the team which had just released Solaris 2.4 immediately
started work on the new stuff to go in Solaris 2.6, while the other team
worked on Solaris 2.5. Then when Solaris 2.5 was released, that team then
merged in the new features which were already included in the upcoming
2.6, and moved on to develop Solaris 2.7.

By contrast, when the feature freeze comes down on a Linux development
kernel tree, it means that excluded features won't be in a production
kernel until perhaps two years down the road. If, on the other hand, the
new development kernel started when the "near production" kernel hit
feature freeze then it would take off the pressure to cram features under
the wire. All that then leaves is the need for people to work on the
latter stages of the kernel development rather than the more exciting
earlier stages, but I would guess that the "near release" kernel would be
more widely used and deployed, giving it the usage and testing which is
needed at that stage, while the early stage kernel might attract more
developers where more effort is needed. When the 2.4 (say) kernel is
released then the 2.7 development kernel would start, either with the 2.4
code base, and the new stuff in the 2.5 kernel being merged in, or it
would take the current 2.5 kernel (unstable) and add features while the
2.5 kernel is stabilised for release as 2.6. Clearly the two development
teams would need to share bug fixes, but they could work with a large
degree of autonomy without being a code fork.

The need to talk like this shows just how important the Linux kernel now
is.

Dunstan Vavasour
dvavasour@iee.org

Date: Thu, 04 May 2000 00:31:45 -0700
From: David Clatfelter <dclatfel@pacbell.net>
Subject: Where is the 2.4 kernel?
To: letters@lwn.net

In your May 4th edition, you noted a number of articles which
have begun to ask the question - Where is the 2.4 kernel?

Let me state first that while I am not a developer, I think I
agree with most Open Source developers, that software is like
fine wine - it should never ship before its time.

But what I find most humorous is that these authors have chosen
to question the release schedule of the kernel.  I mean, how many
of them will be consciously aware of the benefits of 2.4?  Is it
just me, or is it somewhat absurd to compare the release of 2.4 to
something like the release of Win2K?  Why aren't these authors
clamoring about the release date of KDE 2.0 or the next version of
GNOME?  That seems like the more apt comparison, but nobody ever
seems to make it.  

Anyway, thanks for letting me voice my opinion.

David Clatfelter

Date: Thu, 4 May 2000 10:31:35 -0400 (EDT)
From: Clemmitt Sigler <siglercm@alphamb2.phys.vt.edu>
To: letters@lwn.net
Subject: Open Source software release schedule.

Hi Jonathan and Elizabeth,

The solution to the problem of Open Source release "delays" that you
addressed on last week's front page seems really simple to me.  But
given the nature of Open Source hacking, it may be hard to achieve.

In the case of the Linux kernel, when 2.4 comes out Linus and Alan and
other kernel "fathers" need to sit down on IRC or in person and decide
just one thing:  Which new features should be included in the 2.5
development kernel series.  This needs to be planned _before_ hacking
on 2.5 starts.

The list of features to be included should be short, high priority,
high feature win, and achievable.  Then comes the hard part -- having
the discipline to stick with it.  Some modifications to the list are
to be expected, but inclusion of totally new features not planned should
be forbidden.

We know the nature of Open Source hacking is to code what you love as much
as what needs to be done.  This makes such discipline hard, and might even
lead to the dreaded "code fork" if someone gets extremely frustrated that
his/her pet project won't be included in the kernel.  So it seems to me to
be a choice between the current long development cycle, or
losing/redirecting hacker interest in the Linux kernel.  It would be nice
if there was a common ground somewhere in between these two extremes, but
this can't be easy to find.

					Clemmitt Sigler

From: nride@us.ibm.com
To: letters@lwn.net
Date: Fri, 5 May 2000 13:32:29 -0600
Subject: 2.4 -- What's the big deal?



No one who matters made any promises and as always the kernel will get done
when it gets done. Open source development isn't in the death march that
commercial shops are in and if commercial acceptance of Linux is going to
require us to get into that mode, I'd as soon give the various companies
the finger. We're not shipping a piece of software with 64 thousand bugs in
it, here. We have our reputations to think about, after all. If you need a
newer kernel, the dev kernels have been relatively stable (I'm running one
at home right now.)

I fail to see what the big deal is, or who finds it a big deal. I assume
some crack smoking marketroid. The marketroids always choose (usually
unreasonable) deadlines over quality. Well I got news for you, one of the
biggest reasons to use Linux is because of its quality -- the number one
reason people quote for using it over windows is that it never crashes. I
know that the important people (The Kernel Developers) are smart enough to
know that this is a non-issue and pay it the attention that it truly
deserves. I wish the rest of the Linux media would follow suit.

--
Bruce Ide                               nride@us.ibm.com
IBM PSC Software Developer

Date: Thu, 4 May 2000 14:42:20 -0400
To: letters@lwn.net
Subject: Software testing in the Open Source world
From: Zygo Blaxell <zblaxell@genki.hungrycats.org>


> In 20 years of development, having worked for 7 different
> companies ranging in size from a 5 man startup to the behemoth that is
> Samsung, this is the first time I've seen software released to the world with
> no formalized testing applied.

I wish I could read the rest of this
article, but the web server is returning error messages to me at the
moment.

In 8 years of development, having worked for 6 different companies ranging
in size from a 5 man startup to a behemoth that I won't name, only one of
those companies released software to the world _with_ formalized testing
applied, and that company's policy was to ship the revision of the product
with the lowest number of known severe defects when the release date
arrived.  The same company also had no plans to correct the software after
shipment even when the problems were severe, corrections were available,
their application to existing systems in the field was feasible, and
ongoing support was paid for by the customer--an inconvenience which
usually outweighed the small quality benefit from the pre-release testing
in practice.

Your mileage may vary, I guess.

This perception be the result of different semantics surrounding the word
"formalized."  All of the companies maintained some level of defect
tracking, ranging in complexity from stacks of paper with handwritten
bug reports to a customized cross-platform client-server database
application, and in all cases at least one employee spent part of
their time documenting defects as they were found.  To me, this is not
"formalized testing"--it's "informal testing" at best, and IMHO
it's a stretch of the meaning of the words to even call the behavior
of some of these companies "testing" at all.

Contrast with e.g. CVS, EGCS, Perl, or Tcl, all of which have significant
formalized (and mostly automated) test suites.  In particular the CVS and
EGCS projects publish their test results on mailing lists where anyone who
wants to know can see exactly how well the developers are doing.

Also contrast with the Linux kernel and the Debian distribution.
Formalized testing definitely does occur on subsets of these projects,
as sophisticated end users and even a few developers run their own test
suites and benchmarks on each new revision, although the code coverage
is by no means complete.

To say that no testing exists in open-source software at all is a gross
overstatement.


Opinions expressed are my own, I don't speak for my employer, and all that.
Encrypted email preferred.  Go ahead, you know you want to.  ;-)
OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D