See also: last week's Letters page.

Letters to the editor

From:	 Eduardo Sanchez <suppressed>
To:	 lwn@lwn.net
Subject: About "Free Software and racism"
Date:	 Thu, 21 Feb 2002 10:27:33 -0500

Dear Mr. Corbet:

In the LWN Weekly Edition Front Page of this week you wrote:

<begin quote>
Should open source licensing prohibit racist uses of the software? The Open 
Source Definition is explicit on that point: 

 The license must not restrict anyone from making use of the program in a 
specific field of endeavor. For example, it may not restrict the program from 
being used in a business, or from being used for genetic research. 

 ...or from being used in appalling, hate-promoting games. 

Software developers are already coming under attack for writing code that is 
seen to promote (or simply fails to prevent) copyright infringement. The last 
thing we need is to be told that we must not allow our software to be used to 
promote racism. It's a small step from there to no end of other restrictions. 
The fight against racism is important and deserves our support, but that 
fight can not be won through the sacrifice of other rights. 
<end quote>

You perhaps might find the words of Theo De Raadt back in the IPFilter 
license controversy useful:

http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/ipf/Attic/ipf.c

To quote it:

"But software which OpenBSD uses and redistributes must be free to all (be 
they people or companies), for any purpose they wish to use it, including
modification, use, peeing on, or even integration into baby mulching
machines or atomic bombs to be dropped on Australia."

Best regards,

Eduardo Sánchez

From:	 Dylan Griffiths <Dylan_G@bigfoot.com>
To:	 letters@lwn.net
Subject: Inflamatory hate speech on http://www.adl.org/videogames/default.asp
Date:	 Thu, 21 Feb 2002 17:12:18 -0600
Cc:	 nicor@ADL.ORG

	Your site is quoted as stating, "Making Ethnic Cleansing was fairly simple. 
Its designers were able to use a powerful, freely available open-source 
game program or engine that 'drives' the program by providing the basic 
operating instructions to the computer. The designers then simply plug in 
their message of hate."
	You imply that open-source or free-software is somehow to blame for 
allowing those games to be created.  In the same breathe, you say, "In 
addition, the 'comedy' section of the Web site of the racist, ... as well 
as downloadable racist games. Among these are Aryan 3, Shoot the Blacks, 
NSDoom (NS is short for National Socialist), and WPDoom  (WP stands for 
White Power)."
	Should we all write about how John Carmack is evil for making the Doom 
game?  Anyone who makes up the appropriate WAD file can, after all, use 
the Doom engine to "drive the message of hate."  The same applies to any 
game I can think of: imagine a scenario for RailRoad Tycoon 2 where you 
make the trains to haul jewish people to death camps by 1943, thus 
changing the outcome of WW2?
	It seems like you want to gloss over this ability which humans have to do 
what they want, when they want, with any tools available.  The way to 
restrict such things when they don't benefit society is through laws, or 
through careful social structuring.  Do you make car companies write out 
that KKK members are not allowed to drive cars?  No, you merely add laws 
about being discriminatory and mean to other people.  Laws are how you 
keep a large society organized and fair.
-- 
     www.kuro5hin.org -- technology and culture, from the trenches.
                          -=-=-=-=-=-
Those that give up liberty to obtain safety deserve neither.
  -- Benjamin Franklin
   http://www.zdnet.com/zdnn/stories/news/0,4586,2812463,00.html
   http://slashdot.org/article.pl?sid=01/09/16/1647231
                          -=-=-=-=-=-

From:	 Leandro Faria Corsetti Dutra <leandrod@mac.com>
To:	 letters@lwn.net
Subject: Debian's usntable -- what about testing?
Date:	 Thu, 21 Feb 2002 11:55:01 +0100

	It seems you failed to mention at your main page that if stable is 
too old and unstable can break at times, testing usually is some 15 
days only behind unstable but uses these 15 days to avoid any 
short-term critical issues... so that's what people should be using 
if they want something newer than stable but still not as risky as 
unstable.


-- 
 _
/ \ Leandro Guimarães Faria Corsetti Dutra        +41 (21) 216 15 93
\ / http://homepage.mac.com./leandrod/        fax +41 (21) 216 19 04
 X  http://tutoriald.sourceforge.net./      Orange Communications CH
/ \ Campanha fita ASCII, contra correio HTML      +41 (21) 644 23 01

From:	 "Bruce R. Lewis" <brlewis@ALUM.MIT.EDU>
To:	 letters@lwn.net
Subject: Debian "testing" deserves more than parenthetical note
Date:	 Thu, 21 Feb 2002 11:31:19 -0500 (EST)

Most desktop users should run Debian's "testing" package.  It's only
about 10 days behind "unstable", so people who want latest-and-greatest
packages won't be disappointed.  The "stable" distribution is suitable
for high-availability servers and that minority of users not interested
in recent development.  The vast majority would be better off with
"testing".

Details of how "testing" works can be found at the following page:

http://people.debian.org/~jules/testingfaq.html

-- 
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

From:	 pekka@rinne.as
To:	 lwn@lwn.net
Subject: Debian story
Date:	 21 Feb 2002 09:12:51 -0000

Hi

You are forgetting something in Debian story in Febryary 21 issue of lwn.
That is the testing distribution of debian. You only mention stable and
unstable! Actually, testing may be the most widely used version of debian
at the moment! It is between stable and unstable. And it is getting close
to be released as stable.

Updates to testing are not that frequent as in unstable. Testing also includes
recent KDE and gnome, too.

Please, learn more about debian before writing such a foolish story!

Quality of this debian story is not too good...

Br

Pekka Rinne

From:	 Nicolas Pitre <nico@cam.org>
To:	 editor@lwn.net
Subject: CML2
Date:	 Thu, 21 Feb 2002 13:56:50 -0500 (EST)
Cc:	 esr@thyrsus.com


On the Feb 21st 2002 kernel page we can read:

   Then, there are those who criticize the CML2 work because it is a
   single, large patch. The kernel way of doing things, it is said, is to
   evolve the code in small, simple steps that everybody can scrutinize
   and see are correct.

   But must all kernel development be done in baby steps? It's hard to
   imagine introducing ALSA in tiny pieces. Andrea Arcangeli's VM rewrite
   went in as one big chunk - in a stable series at that. Netfilter was
   not introduced as a set of incremental patches. CML2 represents a
   change in both configuration and implementation languages; how does
   one make that kind of change gradually? The evolutionary approach to
   development clearly makes sense much of the time, and it may yet be
   the best way to fixing the configuration subsystem. But there are
   times when exceptions need to be made.

All exceptions reported above always provided a transition mechanism.  
Netfilter has compatibility module for the ipchains interface and even the 
ancient ipfwadm interface.  ALSA has a compatibility module for the OSS 
interface.  The VM replacement didn't affect many people in terms of 
interfaces to work with so besides the instability issues there were very 
few people which had to deal with the change.

What Eric is aiming for is a straight sudden replacement for an interface
which affects both many users and developers at the same time.  This is a
change of a magnitude never encountered so far.

If, for example, Eric makes his new configuration engine be able to read
both CML1 and CML2 syntax, he could submit _only_ the configuration tools
alone at first (which would already solve the parsing inconsistency problems
with the current tools), and when people are satisfied with them then CML1
files could be replaced with CML2 gradually.  It wouldn't need to deal with
every obscur CML1 corner cases, just like the Netfilter interface for
ipchains isn't 100% accurate either.  But even then Eric is not showing any
interest in making any compromise on that level.

By not doing so, Eric only risk to see his work be obsoleted by some other
replacement solutions which might be way more primitive than CML2 at first
but which will evolve gradually just like most kernel developers are
expecting it.  If such is the future, only Eric will lose at the end but
that would still be a sad situation.


Nicolas

From:	 Ted Clark <tclark@bgea.org>
To:	 lwn@lwn.net
Subject: Rawhide
Date:	 Thu, 21 Feb 2002 11:59:24 -0600

>From LWN.net Weekly Edition for February 21, 2002:
> Red Hat still makes "Rawhide" available, though they do not make it easy to find.

Nor do they make it easy to install or maintain.  There haven't been
boot images available for weeks (months?), and the only way I've been
able to get Rawhide installed at all is to do a fresh install of Red Hat
7.2, apply all errata updates, and then do a forced update (rpm with
--nodeps --force) of gcc, glibc, and binutils, followed by a forced
update of everything else.  Needless to say my RPM database is in a
state of great uncertainty.  I can't complain, since I'm not paying for
this service, but perhaps its time that I tried Debian unstable!

TedC

From:	 "Robert A. Knop Jr." <rknop@pobox.com>
To:	 letters@lwn.net
Subject: Cruft has become our life
Date:	 Wed, 27 Feb 2002 08:13:47 -0600

As ashamed as I am to say it, I admit that I use Gnome; I like lots of
the little fiddly bells and whistles, such as the panel which can hide,
things in the panel (mailcheck applets, gdict, weather monitors, clocks,
icon managers).  Indeed, the panel alone makes things much neater than
the old way of doing things with icons scattered across different
viewports (or virtual screens).

But the configuration... it's all become such a mess.  I find myself
missing the "good old days" when all I had to understand was a .bashrc
or a .cshrc, a .login, a .Xresources, and a .fvwmrc file.  (And perhaps
a .emacs file, and one or two others.)  I could edit them by hand, and
copy the text files to other accounts when I wanted to clone the
configuration.  Things tended to work, or not-- but if they didn't, it
was just that one program or utility that didn't work, and other things
kept working.  Emacs (or vi) was my master configuration editor.  It was
the Unix way: many small independent utilities an intelligent user could
patch together with pipes as necessary, rather than a gigantic
interconnected mess of programs that all must talk to each other and all
must be into each others configuration information.

Now?  Gnome likes to present itself as a gigantic monolithic UberGUI.
The number of dot files in the home directory is out of hand.  There are
many dot directories, with whole hierarchies of stateful information.
Many of these are not designed to be edited by hand, but only with each
individual application's graphical configuration editor, which tends to
be much more inconvenient to use repeatedly (despite a much easier
learning curve).

The worst part is when they all start to interact in mysterious ways.
What brought forth this latest rant was a problem I was having with
Mozilla (and all Mozilla-derived browsers, including Galeon).  It would
show inlined PNG images just fine, but if I tried to view a standalone
PNG image off the web, I'd get a blank white page.  I couldn't find any
bug reports on this on the web.  What's more, another account I had on a
different computer did not have the problem.  This computer had all the
same versions of the RPMs for Mozilla, libpng, gnome, and anything else
I could think of that might be related.

I couldn't find anything in the mess of configuration information
Mozilla's graphical preferences editor gives you, so I tried blowing
away my .mozilla configuration directory and starting that over from
scratch.  (I did save and restore the bookmarks, but nothing else.)  It
didn't help.  This surprised me.

How did I solve the problem?  I moved *all* files out of my home
directory, and then only moved back the ones I understood.  The entire
.gnome directory tree I got rid of, and any number of others.  Then I
spent an hour or so going through and rerunning all those visually
appealing but intrinsically inefficient graphical configuration programs
to get my Gnome setup back the way I wanted it.

It works.  Mozilla is now fine with stand-alone PNG files.  What was it
that I removed that fixed the problem?  I have no idea.  There was so
much there, interacting in ways that I no longer can keep track of.

I've heard horror stories about the Windows registry.  Perhaps this is
the way we're heading?  It will only get worse, as I read all of the
glowing predictions developers post about gconf and *daemons* that keep
track of your configuration, and oh my word.  This is presented as the
solution to the mess that I started this letter complaining about, but
to me it sounds like taking things further in the direction that's
created what I see as the mess in the first place.

It sounds to me that the only way out of the cruft is going to be to,
every so often, as old versions of configuration information accumulate,
delete your entire home dirctory, saving backups only of your own
documents and files.  Start over building your account and configuration
information.  Slow, evidently a waste of time, but a necessary step in
this current world of crufty beautiful programs that do a lot for you
and want to keep all sorts of interconnected configuration information.

Perhaps I should just go back to my roots and run FVWM, and get away
from the Gnome/KDE/GUI madness.  Alas, I want to have my cake and eat it
to; I want the features that come along with the configuration cruft.
Even doing that may not solve the problem, since web browsers now must
interact with helper applications and mime types and mailcaps....

-Rob