See also: last week's Letters page.

Letters to the editor

From:	 Paul Komarek <komarek@andrew.cmu.edu>
To:	 letters@lwn.net
Subject: Gartner and Linux
Date:	 Thu, 25 Oct 2001 01:19:12 -0400

I suppose that Gartner's tone probably depends on who is paying it for the
research.  I don't care to say anything about facts, if "facts" even exist
in modern computing.  The only times I've read nice things about GNU/Linux
from Gartner, the article was on ZDNet.  Maybe ZDNet is mining Gartner for
pro-GNU/Linux research, hoping to attract more page views. Just like when
Jesse Berst trolls for page views.  ;^)

-Paul Komarek

From:	 Eric Smith <eric@brouhaha.com>
To:	 letters@lwn.net
Subject: booting Emacs 21 directly
Date:	 25 Oct 2001 18:09:20 -0000

Gentlemen,

In your 25-October-2001 issue, you wrote "the rumor that one can now boot
directly into emacs from LILO or GRUB, and thus avoid the need for an
operating system entirely, proves to be unfounded."

Although I'm no longer doing it, in the late 1980s I routinely used emacs
as my login shell.  I found it to be quite practical on text-only
terminals, and could bring up a "normal" shell in an emacs buffer when
needed.

Sincerely,
Eric Smith

From:	 tom poe <tompoe@renonevada.net>
To:	 lwn@lwn.net
Subject: Alan's Going Too Far?
Date:	 Thu, 25 Oct 2001 20:34:01 -0700

Hello:  This from your front page of this week:

"Even so, one might be forgiven for wondering if Alan is taking things a 
little too far here. Censored changelogs will attract a bit of attention, but 
are unlikely to really change much. Besides, as readers of NTK know, the 
U.K.'s laws are not much better than those in the U.S. with regard to things 
like "circumvention devices." "

Much more appropriate, I think, would have you say, " Folks, get ready, 
because IT's COMING!.  AND, this is what IT looks like!"

What we need, I think, is an Open Source Summit, right now.  Linus, Alan, 
Larry Wall, whoever is heading BugTraq, and others to meet, discuss, and 
announce a period of time, a day, a week, a month, when everyone puts on 
their DMCA/SSSCA/EuroCopyright, hats and gives the world community a "TASTE" 
of the future!  I think Alan is RIGHT ON.  I'll betcha our friend, Eric 
Raymond, would think this is about the right time for something similar to be 
staged.  I agree wholeheartedly with Alan, and those who have had to make 
life-decisions as a result of legislative idiocy.  You saw the kind of crap 
M$ puts out with its XP, along with its double-digit patch, this week.  
Imagine how sloppy it will be, as he gains even more of a foothold in the 
future.  Everyone with a computer will be lined up to work one-on-one to 
bring their dossiers up-to-date before they'll be able to use their 
computers.  Weird.  Idiotic, and I have to stop, now.   Tom

From:	 Rip Linton <ripl@yahoo.com>
To:	 letters@lwn.net
Subject: DMCA Issues
Date:	 Thu, 25 Oct 2001 06:55:56 -0500

From your front page on Oct. 25, 2001:

"In the long run, if the Powers That Be are determined to
prevent the discussion of security vulnerabilities, they
will seek a way to block the exchange of the code as well."

As one who has read all 94 pages of the DMCA, I must be
missing something. No one has yet provided a reference to
the DMCA that supports the thought that discussion of
security vulnerabilities violates the DMCA. While I do not
like the DMCA, I think that this political statement, by
Allen Cox, can only hurt efforts to get Linux into the
mainstream.

The DMCA does not stop us from documenting bugs or security
problems. It only prevents us from publishing code that
bypasses the security of an "effective" security device.

That means that we can discuss the problems and faults of
something like CSS all we want. We just can not publish, in
any form, a program that bypasses CSS.

That, also, means that we can discuss the problems and
faults of the Adobe software. We can not publish, in any
form, a program that bypasses the copy protection built in
to the software.

In all of the DMCA cases, programs to bypass the security
features were published. The DeCSS issues revolved
around the release and publication of DeCSS code not the
discussion of the faults in the CSS software. Sklyarov was
arrested for a program that was offered for sale, not for
documenting or discussing the flaws in Adobe's software
protection.

In my opinion, DMCA would not come in to play with an open
source program exploit that only affected that software.
However, if Allen Cox feels that it does, all he has to do
is avoid publishing the code, in any form, that takes
advantage of that exploit.

From: "Andy Elvey" 
To: letters@lwn.net
Subject: Comments on the DMCA
Date: Fri, 26 Oct 2001 20:09:47 +1300

Hi al! !  

 I've just been reading your latest column - a **great** read , as always ! 

 I've been mulling over the DMCA and its possible impacts.  One of the
 things that got me thinking was your (very good) comment that the
 Stanford Checker people haven't (yet) got around to censoring their
 bug reports.

  I think there is an area that seems to have been *very much*
  overlooked by many people.  That is , the area of *safety* as it
  applies to software.   I think it would be quite possible for a
  software bug to have effects not only on security, but on **safety**
  as well.

    If a programmer discovers a serious bug that not only compromises
    *security* , but also *safety* as well (think nuclear power
    plants) , what does he now do (given the DMCA and all that ) ?
    And lets face it - **who now decides**  whether a bug is a
    security issue, a safety issue , or both?   I suggest that a
    programmer is in the best position to judge that , but the DMCA
    and similar laws seem to put the lawyers in the "deciding seat" ,
    as it were.   Mmmm .... not a great move, really ........ :-/ 

 I wonder if there will now be (at some time in the future)  a
 disaster which could have been prevented if the programmer had felt
 free to reveal a particular software bug ( **and** its fix ! ) .
 Who knows ?

  Anyway - just my two cents worth !  

  ( oh - btw - I would like my email address to be anti-spammed !  Thanks ! )

From:	 Matthew Miller <mattdm@mattdm.org>
To:	 matt@bluelinux.org
Subject: Common Linux Installer and Anaconda
Date:	 Thu, 25 Oct 2001 01:04:42 -0400
Cc:	 lwn@lwn.net

Hi! I read the bit about your Common Linux Installer Group project on LWN
with some interest. I'm the lead developer of Boston University Linux, which
is a Red Hat Linux-derived distribution. Our installer is a customized
version of Anaconda. I couldn't load the <http://clig.bluelinux.org/> page
from your original announcement, but I did read your response the LWN's
initial criticisms, and I have a few comments on those.

First, going through and changing Red Hat-specific messages and paths is
actually not as difficult as you make it seem -- took me about half an hour,
and that's including changing some of the help text. Second, and more
importantly, Anaconda actually *does* have a strong separation of
functionality and display. This is how they implement both text and X-based
install modes. Since the whole thing is written in object-oriented Python,
it already is very modular in design.

It's definitely easy to make changes like the "default-to-following-
dependencies" idea you suggest -- that's exactly the sort of change we make
for BU Linux. And, since the code is modular, I don't think it would be
unreasonably difficult to make even drastic changes like supporting
packaging systems other than RPM.

Anaconda is a proven package with a lot of testing in the real world, doing
a task which is difficult to get right in every case. There's a lot of very
different machines out there! Note the vast improvement between the 6.1
installer -- the first Anaconda -- and that of 7.2, or even 7.1. A Common
Linux Installer can take advantage of this and not have to re-invent the
wheel.

I strongly urge you to take a fresh look at this. I'd be very interested in
working on community project based on Anaconda.

-- 
Matthew Miller           mattdm@mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>

From:	 Rainer Weikusat <weikusat@mail.uni-mainz.de>
To:	 letters@lwn.net
Subject: I am getting really tired of this
Date:	 27 Oct 2001 09:30:55 +0200

@@ -520,6 +532,8 @@
        bprm->dumpable = 0;
        if (current->euid == current->uid && current->egid == current->gid)
                bprm->dumpable = !bprm->priv_change;
+       else
+               current->dumpable = 0;
        name = bprm->filename;
        for (i=0; (ch = *(name++)) != '\0';) {
                if (ch == '/')
@@ -533,8 +547,10 @@
        flush_thread();
 
        if (bprm->e_uid != current->euid || bprm->e_gid != current->egid ||
-           permission(bprm->dentry->d_inode, MAY_READ))
+           permission(bprm->dentry->d_inode, MAY_READ)) {
                bprm->dumpable = 0;
+               current->dumpable = 0;
+       }
 
        current->self_exec_id++;
 
@@ -552,12 +568,11 @@
 }


That's the one (minus architecture specific changes) of them.
Am I the only person capable of reading patches that's left in the
world?

-- 
near
                        distant

From:	 David.Kastrup@t-online.de (David Kastrup)
To:	 letters@lwn.net
Subject: Regarding: Open Source programmers stink at error handling
Date:	 26 Oct 2001 09:59:45 +0200
Cc:	 nicholas.petreley@linuxworld.com


Let me tell you that Open Source *users* stink at error reporting.  I
have recently published a LaTeX editing environment for Emacs
(<URL:http://preview-latex.sourceforge.net>)  and have taken pains to
ensure that
a) error reporting instructions are in READMEs and other relevant
files.
b) an error reporting command is available which collects most of the
useful data a user tends to forget, and makes out a bug report to a
special bug reporting address.  This command is described in all the
instructions.
c) when internal runs of GhostScript fail, you get a button in your
document making all relevant error messages display so that you can
cut and paste those for a report.

Only after I had this infrastructure in place did I make the first
release.

Result?  Almost no usable error reports, particularly when taking into
account the download numbers.  I got more when things just
mysteriously and silently failed so that people could get absolutely
no handle on why this happened.  If people now report errors at all,
they usually send one uninformative Email to my personal Email account
(which is harder to come by in the documentation than the error
reporting instructions).  I never got reports at all about how and
when and which versions of GhostScript fail once the error reporting
interface was in place: people obviously use the feature to debug
their problems away (usually by upgrading GhostScript, I assume)
without telling me.  I get more bugs "reported" (which I subsequently
fix) by snide remarks on Usenet Groups of the "I tried that but
that-and-that did not work as expected" kind than by actual bug
reports.  Mostly of the "I did not consider a bug report because I
figured out that the software is buggy, anyway" variety.  What sort of
a reason is that?

It seems that Open Source users are too accustomed to either living
with bugs or fixing them themselves without telling anybody as to
stoop to reporting any problem.

Either the problem is minor, then they ignore or circumvent it and
make snide remarks on Usenet groups, or it is major, then they don't
use the software at all.  Reporting a bug seems to be an option you
cannot make acceptible.  Not even when you auto-generate an Email
where only few lines needed adding.

Is this remnant from the times where using software was usually the
same as having illegally acquired it and where you feared a bug report
would send you to jail?

Make my day: install my software and report a bug...  And consider
reporting a bug whenever you encounter one in any piece of Open Source
software.

Make it a boy scout motto: one good bug report a week.  People
complain all the time about buggy software.  Make it a habit to
complain where you are supposed to.

Thank you,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de