See also: last week's Letters page.

Letters to the editor

From:	 Garry Knight <garryknight@bigfoot.com>
To:	 letters@lwn.net
Subject: Linux's birthday
Date:	 Thu, 23 Aug 2001 14:11:27 +0100

Dear Sirs

I see from your front page on Thursday 23 August that there's some 
controversy over exactly when Linux's first birthday will be. You quote 
August 25 and October 5 as possible candidates.

On page 87 of Linus's autobiography, "Just for Fun", Linus himself says:
  "There's a protocol for numbering releases. It's psychological. When you 
think a version is truly ready to be released, you number it version 1.0. 
But before that, you number the earlier versions to indicate how much work 
you need to accomplish before getting to 1.0. With that in mind, the 
operating system I posted to the ftp site was numbered version 0.01. That 
tells everybody it's not ready for much.
  "And yes, I remember the date: September 17, 1991."

Could this be a better candidate for a birthday?

-- 
Garry Knight
garryknight@bigfoot.com  ICQ: 126351135
Linux registered user 182025

From:	 "Robert A. Knop Jr." <rknop@pobox.com>
To:	 <letters@lwn.net>
Subject: Sad about Source Forge Enterprise Edition
Date:	 Fri, 24 Aug 2001 10:26:34 -0500 (CDT)

Before I say this, I must say that I don't fault VA Linux.

However, seeing them going to selling proprietary extentions to an open
source project makes me sad.  Not because I think that VA Linux has sold
out or anything-- but because it's yet one more nail in the coffin of what
I had hoped would be the software model of the future.  That model was
much like FSF's: software would be free, and users (large and small)
who wanted it would pay for maintainance and support.

The argument always went something like, what if we're a large company,
and we want to buy a lot of hardware and have it just work?  The answer
was, buy your hardware from somebody like VA Linux, and then buy a support
ocntract for all the software.  If you find that the support you're
getting is unsatisfactory, the software is free, so you can find another
company (say, Red Hat) to support your software installation.  You're not
locked into mandatory support contracts forever more from one single
monopoly.  Or, if you're a smaller site, find an outfit with a smaller
plan, or hire a Linux Geek who will both support your installation as well
as contribute back to the efforts of free software programmers (and,
thusly, be enough in the community to draw on the de facto software
support that comes from it).

Alas, VA Linux, like Red Hat, was a sort of poster child for this.  They
were a hardware vendor who sold hardware with (at least mostly) free
software.  But now that model is gone, and to survive, they feel that they
have to go selling and supporting proprietary software.

As long as VA Linux does continue to support and contribute to the Open
Source community as they do now, with things like Sourceforge and keeping
Eric Raymond on staff, I won't fault them or bear ill will towards them.
But their selling of proprietary extentions to the Sourceforge software
does seem to be one more strike agains those of us who still want to think
that the Free Software/Open Source model of software development is one
that can work and that ultimately will be the best for everybody.

-Rob

From:	 David.Kastrup@neuroinformatik.ruhr-uni-bochum.de
To:	 letters@lwn.net
Subject: Stallman and things
Date:	 23 Aug 2001 11:59:39 +0200


The problem of Stallman is that of many a great revolutionary: once
the idea they have so painfully nurtured and fostered and kindled has
finally caught on and is spreading like a wild fire, they cannot
simply leave it to itself and restrain the urge to control what needed
their care for a long time.  Sort of a children and parent problem.

Stallman is no fool, but a bit out of touch with reality.  Apply the
proper grain of salt when listening to him.  He has deserved it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@neuroinformatik.ruhr-uni-bochum.de

From:	 Kapil Hari Paranjape <kapil@imsc.ernet.in>
To:	 letters@lwn.net
Subject: Freedom zero and all that
Date:	 Sat, 25 Aug 2001 12:41:23 +0530

Dear LWN,

I read with interest your editorial this week ("Let's beat up on
Richard Stallman") and the articles by O'Reilly and the others.
Of course this has led to another series of postings in various
fora and the debate will rage on. Here is my 2 paise worth.

1. RMS < FSF < GNU < GPL. But we are often guilty of equating them. In
   particular, each time RMS makes a statement that people object to
   they use it as an excuse to beat up on the FSF and sometimes the GPL
   as well. Of course, RMS himself is guilty of over-reaching on some
   of these inequalities...

2. The GPL is about the user's freedom. What O'Reilly (and open
   source) is talking about is the developer's freedom. But the
   distinction between users and developers is a grayscale and not black
   and white. We all start as (l)users and (should) try to attain some
   sort of mastery. The GPL says that every developer *must* help a user
   in this by letting the user (a) use the program (b) study and adapt
   it (c) get friends involved in this ativity (d) carry on the work of
   developers that came before by helping others too.

3. If developers grant themselves the "freedom"/"power" to stop
   helping users in this way *or* users grant themselves the right to
   expect "readymade" fixes from developers forever, it is only a
   matter of time before the division is created and made permanent.

Unfortunately, O'Reilly's "freedom zero" is easily distorted into a
freedom for developers such as in (3). The response from RMS/BMK also
too easily interpreted to mean a user's "right to expect" as in (3).

A cliche (actually the title of an Indian soap opera) may help!

   	"Sans bhi kabhi bahu thi"
   		(A mother-in-law was also a daughter-in-law once).

Kapil Paranjape.

From:	 Michael Alan Dorman <mdorman@debian.org>
To:	 letters@lwn.net
Subject: Thanks for cutting through the rhetoric!
Date:	 23 Aug 2001 07:27:05 -0700

Your "Should we be talking about freedom?" section on the Main Page of
this week's issue is something that I would hope many people will read
and remember and refer back to.

Although I'm personally happy I work on "Debian GNU/Linux" rather than
"Debian Linux"---I got started using GNU software before I started
using Linux (heck before Linux existed), and I *do* think the GNU part
is really important---it's a point on which reasonable people may
disagree.

The value of freedom, however, is one thing which I would hope people
would recognize is essential and Richard Stallman is our conscience on
this matter, with all that implies: an inability to compromise, a
tendency to nag, and hundreds of other annoyances that one must,
nevertheless, tolerate because he is also our benchmark---you may not
share his values, but you always have a fixed, absolute point from
which to navigate.

I will, however, spare you with my jeremiad against Eric Raymond,
including my analysis of why his response to Stallman and Kuhn is
obviously slanted against them, and why I don't think Eric Raymond
really cares deeply about any freedom other than that of gun
ownership. :-)

Mike.
-- 
"One does not write satire anymore; one merely tries to stay half a
step ahead of reality." -- Jon Carroll

From:	 Stuart Thayer <thayer@scfn.thpl.lib.fl.us>
To:	 letters@lwn.net
Subject: Eric Raymond
Date:	 Thu, 23 Aug 2001 13:14:16 -0400

Folks:

	I think Eric Raymond's missive to Stallman and Riley bends
backwards too far to be fair. Fairness is, most would agree,
a noble thing. But he seems naive, at least for the sake of
making his point, about American politics.

	There is a far greater chance of outlawing open source than
outlawing proprietary software, so the power play isn't as
equal as it may seem.

	U.S. politics is based on bribery. We don't call it that,
of course; we call them campaign contributions. Even our
illustrious Supreme Court tries to bamboozle us by calling
them free speech, thus protected by the First Amendment. The
U.S. may be the only country in the world where bribery
enjoys constitutional protection.

	Owners of proprietary software, with their profits, are
thus in a far better position to bribe U.S. lawmakers to
make free software illegal than developers of free software,
with few profits, are to persuade, cajole, jawbone, or
otherwise plead -- with no monetary incentive -- lawmakers
into making proprietary software illegal.

	I'll leave it to you to decide which poses the greater danger.

From:	 David Gibson <david@gibson.dropbear.id.au>
To:	 lwn@lwn.net
Subject: Flerbage
Date:	 Wed, 29 Aug 2001 13:08:46 +1000
Cc:	 esr@thyrsus.com, rms@gnu.org

The FSF's use of the word "freedom" might be confusing, but Eric
Raymond's flerbage argument is certainly a straw man.

Eric postulates that a law banning proprietary software has been
passed.  Thus, he argues he could now be thrown in jail for offering
people software under the same proprietary license as he did before
the ban, which would indeed seriously diminish his flerbage.  But why
on earth would anyone pass a law making it a jailable offence to offer
a proprietary license, when all that is necessary to effectively "ban"
proprietary licenses is to modify copyright law so that they are
unenforceable[1].  Essentially Eric's argument assumes that it is
possible to offer proprietary licenses, whereas the point of banning
them would be to make it impossible, rather than to punish people
merely for making the attempt.

So let us suppose instead that proprietary software was "banned" in
this much more sensible way.  Now, in such a world, I could go and
offer software under a proprietary license to whomever I pleased.  Of
course, whoever I did offer it to is quite likely to either a) laugh
in my face, or b) take the software and then do whatever they please
with it, since they know I can't enforce my license restrictions.
Still, I'm not going to be dragged off to prison for it.  So, while
this state of affairs might be unfortunate for me if I was planning to
live off license sales, it hasn't affected my flerbage.

Note that in the above I haven't actually touched on the issue of
whether banning proprietary licenses would be a good idea or not. 
That's a much more subtle issue, and one that can't be decided on
matters of flerbage alone.

[1] Strictly there are two things which would have to be done - first
make explicitly restrictive licenses unenforceable and second remove
the built-in restrictions imposed by copyright [2].

[2] Before anyone points out that this would probably also make the
GPL unenforceable, that's strictly true, but irrelevant.  A ban on
proprietary licensing would give many of the rights (e.g. unrestricted
duplication and modification) that the GPL grants automatically and
while someone could promulgate binaries but not sources to a formerly
GPLed program, there would be little incentive to do so.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

From:	 zooko@zooko.com
To:	 lwn@lwn.net
Subject: /dev/random silliness
Date:	 Thu, 23 Aug 2001 09:32:03 -0700


Folks:

The vast majority (perhaps all) of the people who use /dev/random to the
exclusion of /dev/urandom in their crypto applications are doing so out of
ignorance, and are not making their application any safer for their users.


Assume that the random pool has been initialized with 160 bits which no
attacker can guess.  (That assumption is the hard part, but if it is wrong then
/dev/random can fail just as easily as /dev/urandom can.  Note that this
implies that /dev/urandom *must* block or otherwise signal an exception if this
precondition is not met.)

Now for an attacker to guess the output of /dev/urandom he must accomplish one
of the following:

1. perform roughly 2^160 work (i.e. guess-and-check for all possible initial
   states)
2. exploit a flaw in the cryptographic underpinings of the /dev/*randoms (e.g.
   SHA1)
3. penetrate the computer and read the state of the random pool
4. exploit a flaw in the code that implements the /dev/*randoms


In practice, some combination of these might enable an attack, although
obviously #1 will never happen, as long as the attacker is confined to using
conventional (Turing machine) computers.


Now my point is that /dev/random can fall to an attack like this just as easily
as /dev/urandom can!  In fact, the added complexity of implementing the
/dev/random behavior makes #4 *more* likely for /dev/random than for
/dev/urandom.

Not to mention that /dev/random's specification *requires* the applications
that use it to become susceptible to a DoS attack by sucking down the "entropy
estimate" count.


Here's the real kicker: with the exception of a true One Time Pad, any
application that uses /dev/*random is going to also use some cryptographic
primitives like a block cipher, stream cipher, secure hash, public key
cryptosystem etc., now each of *those* primitives themselves are susceptible to
a massive, impossible brute-force attack (attack #1, above), just like
/dev/urandom is!

Therefore, there is absolutely no improvement in using /dev/random over
/dev/urandom, and then feeding the results into a block cipher which is itself
susceptible to an impossible (e.g. 2^128) brute force attack.


The bottom line is: if you are not implementing a true One Time Pad that
utilizes no cryptographic primitives -- it uses only XOR -- then you shouldn't
be using /dev/random.  To do so opens you up to a DoS attack, and makes the
security of your app depend on more complex code, but gives you no real-world
improvement in security.


Regards,

Zooko

From:	 Leandro =?ISO-8859-15?Q?Guimar=E3es?= Faria Corsetti Dutra
	 <leandrod@mac.com>
To:	 letters@lwn.net
Subject: Kernel /dev/random entropy only adds to security worries
Date:	 Thu, 23 Aug 2001 16:03:00 -0300

> Once again, nobody has ever gotten close to demonstrating an attack of
> this nature, but if security people didn't worry they would have little to
> do.

	It seems to me that it wasn't intentional, but this sentences sound to me like 
the author meant that security people had to worry about very improbable 
events in order to get occupied.  It sure can be construed like that, and 
that's certainly not true, as bad security practices almost everywhere already 
give them surely plenty of labor.



-- 
  _
/ \ Leandro Guimarães Faria Corsetti Dutra           +55 (11) 246 96 07
\ / http://homepage.mac.com./leandrod/     BRASIL    +55 (43) 322 89 71
  X  http://tutoriald.sourceforge.net./     mailto:lgcdutra@terra.com.br
/ \ Campanha fita ASCII, contra correio HTML    mailto:leandrod@mac.com

From:	 "Tom Poe" <tompoe@source.net>
To:	 <letters@lwn.net>
Subject: RH and Proprietary Software Comment
Date:	 Thu, 23 Aug 2001 22:14:41 -0700

Hello:  You mention the issue of proprietary software being written
specifically for RH, this week.  You mentioned that there might be some
straying from LSB by RH, which then would have the market move away from
other distributions in order to have access to proprietary software written
for Linux.

My comment is, that such a path is going to be followed, only if the
software is critical to a business.  If it's not critical, CFO's are going
to have to have some other compelling reason to become vendor inmates once
again, don't you think?

Further, it's my humble opinion, that RH has already crossed the line into
proprietaryville.  I can't help but feel they look like a duck, smell like a
duck, talk like a duck, walk like a duck, and are a proprietary product at
this point.  Maybe it's time they're called a duck/proprietary product, and
need to be recategorized by Open Source folks, or whatever.  Tom

From:	 Robert Bihlmeyer <robbe@orcus.priv.at>
To:	 letters@lwn.net
Subject: Debian and proprietary software
Date:	 24 Aug 2001 14:16:35 +0200

> However, if a business chooses to run Debian and also chooses to use
> a proprietary software product shouldn't this combination just work?

Why should it? While Debian states that it supports its users even
when they're running proprietory software, no claims are made that no
work on the users's part will be required. Making proprietory software
easy to run on Debian is certainly not a primary goal of the project.

Debian developers and users may of course choose to make this their
goal, and support it independently.

> Should that business be forced to use a different distribution just
> because it is tied to a third party product? This is a mode of
> operation more reminiscent of certain proprietary operating systems
> than of Linux.

Oh, come on! What is Debian doing to /force/ its users to a different
distribution? Certainly, some of them may be faced with the choice
between easily installable proprietory software on the one hand, and
whatever advantages one sees in Debian over, say, redhat.

Debian is simply omitting a feature that many Debian users can do
without, not actively prohibiting others from using it the way they
like.

Is redhat /forcing/ Sparc owner to Debian for not providing an
appropriate port of their distro?

Perhaps, what you really want to see is a distribution with the same
technical featureset as Debian, but a different social agenda. Fine by
me, but please let's make this a new distribution, not a future
Debian.

> World domination [...]

... is more reminiscent of certain proprietary operation system
vendors, no?

-- 
Robbe

From:	 Leon Brooks <leon@cclinic.com.au>
To:	 letters@lwn.net
Subject: Simple example of Unix flexibility
Date:	 Sun, 26 Aug 2001 13:47:16 +0800

Many LWN readers will not need to delve into the guts of their 
systems to do what they want done, and may miss most of the goodness 
in their systems. Many similarly inclined non-LWN-readers may wonder 
what all the fuss is about with Linux, and with Unix and general, and 
why geeks get so hyped over it.

I ran across a little example just now which shows how useful the 
flexibility of the Unix every-program-is-a-tool attitude can be.

The problem: I have an ISO image of some Open Source software CDs in 
files on a hard disk, and I want to get them out and burn some copies 
onto CD-R media.

The partition that the ISOs are in is ReiserFS format instead of 
the traditional Linux ext2. Windows users can think in terms of a 
Win2k partition instead of NT-4.0-level NTFS. the tools I have to 
achieve this with are an unlimited supply of Windows 9X boxes, one 
Mandrake Linux 8.0 box [ohso] which can read ReiserFS but can't be 
shut down to have a hard disk installed, and one RedHat Linux 7.1 box 
[archenland] which can't read ReiserFS and also can't be shut down to 
be taught how, but does have a CD burner. All on the same LAN.

The solution, step by step (follow the bouncing ball):

  *  Plug the offending hard disk and a Linux Router Project (LRP)
     floppy into a random Windows 98 box [aravis].

  *  Boot aravis under Linux. LRP can't read ReiserFS either.

  *  From ohso, "ssh -x aravis 'cat /dev/hda5' >hda5.image" to copy
     the 2GB partition across the LAN from the LRP box.

  *  "mkdir 1; mount -t reiserfs hda5.image 1" to make a temporary
     directory and attach the local copy of the partition to it.

  *  "scp 1/*.iso archenland:" to copy the ISO images to the box
     with the burner.

  *  From archenland, "cdrecord dev=0,4,0 -eject -speed=6 first.iso"
     (and repeat for each ISO).

If that had been a Windows-based problem, I would have had to go out 
and find a working machine that had an OS capable of reading the hard 
disk, and a CD burner. Else just cry into my peppermint tea (I'm a 
weird Aussie, I don't like beer). Did I mention that this is on a 
Sunday and in the middle of the Australian outback, 1400km from the 
city?

A couple of things worth noting: I can burn those CDs in a machine 
several hundred meters away, securely and with no special software, 
and have a computer illiterate feed CD-R blanks for me as required; 
archenland is UW SCSI so can safely burn about 12-14 CDs at once; 
authors of newer Gnome and KDE packages tend to make them 
specialised rather than flexible - please don't; Microsoft have 
finally remembered that mounting is useful, and have implemented it 
for XP; Does anyone have a useful standalone version of NT, 2000, or 
XP that fits on one floppy?

For those interested in LRP, I took the EigerStein2BETA image from 
http://lrp.steinkuehler.net/, wrote an IDE-enabled kernel on it, 
added modules for all of the network cards used here, lost the DHCP, 
DNS and web packages, added sshd, made a key and lost keygen, added 
hdsupp. Hand-edited syslinux.cfg then used lrcfg to "backup" all 
packages and reboot to test. If anyone wants to host a copy of the 
finished product, just ask.

This LRP floppy is used for recovering vital stuff from dead Windows 
boxes before reGhosting, and for quick network solutions (random box 
+ extra LAN card + floppy == instant router, add another floppy for a 
proper webserver or the like). More powerful LRP-like bootable CDs 
are also available for machines that actually have CD drives.

We hope that you enjoyed the show.