See also: last week's Letters page.

Letters to the editor

From:	 "nathan r. hruby" <nhruby@arches.uga.edu>
To:	 letters@lwn.net
Subject: Error About trove
Date:	 Thu, 14 Jun 2001 10:22:41 -0400 (EDT)

In the June 14th edition of LWN, on the "Linux History" page
(http://www.lwn.net/2001/0614/history.php3) you say:

> Trove has not caught on in the way Eric might have liked, with one big
> exception: SourceForge uses it. 

FreshmeatII now uses Trove as well for categorizing its entries.  

-n
-- 
......
nathan hruby - nhruby@arches.uga.edu
computer support specialist
department of drama and theatre
http://www.drama.uga.edu/
......

From:	 "Robert A. Knop Jr." <rknop@pobox.com>
To:	 <letters@lwn.net>
Subject: GnuCash 1.6 & library dependencies
Date:	 Thu, 14 Jun 2001 06:59:35 -0700 (PDT)

I understand the frusturation that you must feel trying to get GnuCash
1.6.0 to work.  Fortunately for me, 1.4 serves my needs quite well, so I
will stick with that for the forseeable future-- which is almost certainly
when the next major revision of the distribution I use comes out.

I had a similar but smaller-scale problem several months ago when I was
trying to install lilypond on a mostly RH6.2-based system.  Lilypond
required a newer version of the guile library-- which was fine, except
that the dependencies in the RPMs were such that a couple of the *other*
programs on the system would *not* work with the new guile packages.  In
order to get the newer guile on my system, I ended up having to rebuild a
number of other RPMs from source RPMs, and keep my rebuilt ones around to
overwrite updates which I was automatically grabbing using scripts I'd
written myself.  I hate to think what would have happened if I was using
just a pre-canned update service, unless it had a way of letting me mark
which things were *not* to be updated.

When I upgraded to RedHat 7.1.  Then, at that point, installing lilypond
1.4 became simple.  (I think I did have to rebuild it from the SRPM, but I
didn't have to rebuild anything else, and the libraries with RH7.1 were
sufficient.)

There are a couple of lessons in this.  The first is, if you wait a little
while, the major distributions will "catch up" with the newer libraries,
and things will settle down and start working.  The second is, when the
applications get "ahead" of the library installation for your system,
most users who don't want to spend the trouble should just stick with the
old version until their distribution catches up.

It would be nice if applications only depended on "longstanding"
versions of libraries (e.g. only Gnome 1.2, not Gnome 1.4).  However, free
software is chaotic, and that's one of its advantages.  There is nobody
keeping everything synchronized, and free software developers are
perfectly free to build things that depend on development versions of
libraries.  Most major applications tend to have *some* version packaged
to work immediately with major distributions, either by the maker of the
distribution, or by the writers of the application.  If a package for your
distribution isn't available from the application writers, often you find
it in the distribution itself, or in some add-on collection (such as
RedHat's Rawhide).  It may not be the latest and greatest version of the
application.  As long as we can wait the six months or so it takes a
distribution to move forward, and don't need to run the latest version of
(say) GnuCash within weeks of its release, things are not quite so dire as
all of that.

This might sound like fodder for Microsoftesque free-software bashing:
"You can't even run the latest version of applications without being a
system developer and capable of updating the libraries yourself!"  On the
other hand, compare the rate of release of typical free software packages
to the rate of release of typical closed-source commerical packages.  Free
software keeps pace very well in terms of users really being able to
use new version of things... it is just that the new version gets aired to
the public a whole lot sooner, as opposed to closed-source commercial
software where R&D departments sit on things waiting for the next release
of Windows.

-Rob Knop
rknop@pobox.com

From:	 Patrick Spinler <spinler.patrick@mayo.edu>
To:	 letters@lwn.net
Subject: An upcoming solution to Gnucash 1.6 dependancies
Date:	 Thu, 14 Jun 2001 10:03:55 -0500


If you don't want to wait until the next vendor release from your
distribution; The Gnucash core team plans a release of Gnucash 1.6 on CD
that will install all it's needed libraries into a private area, thus
allowing use of the new software without destroying your existing
system.

No date has yet been set for this release, however we are told to expect
it "soon".

-- Pat

-- 
      This message does not represent the policies or positions
	     of the Mayo Foundation or its subsidiaries.
  Patrick Spinler			email:	Spinler.Patrick@Mayo.EDU
  Mayo Foundation			phone:	507/284-9485

From:	 "Tom Cato Amundsen" <tca@gnu.org>
To:	 letters@lwn.net
Subject: gnucash 1.6
Date:	 Thu, 14 Jun 2001 17:38:38 +0200

Gnucash is only hard to install if you run the wrong OS.
On debian unstable, I did

apt-get install gnucash

today, and all the correct libs are installed.
-- 
Tom Cato Amundsen <tca@gnu.org>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/

From:	 John Goerzen <jgoerzen@complete.org>
To:	 letters@lwn.net
Subject: Gnucash 1.6.0 is here
Date:	 14 Jun 2001 10:32:18 -0500

LWN:

Thank you for your article on Gnucash.  I maintain the package for
Debian, and wanted to let you know that Debian's sid distribution does
currently have all requisite packages for a Gnucash installation, and
Gnucash 1.6.0 .debs already have been uploaded to Debian and should be
installed in the archive soon.  People looking for an advance copy may
find them here:

gopher://quux.org/11/devel/debian/gnucash

You should be able to install that on any current sid machine and just
have it work.

-- 
John Goerzen <jgoerzen@complete.org>                       www.complete.org
Sr. Software Developer, Progeny Linux Systems, Inc.    www.progenylinux.com
#include <std_disclaimer.h>                     <jgoerzen@progenylinux.com>

From:	 Herbert Thoma <tma@iis.fhg.de>
To:	 letters@lwn.net, GnuCash <gnucash-devel@gnucash.org>
Subject: LWN gnucash article
Date:	 Thu, 14 Jun 2001 17:27:55 +0200

Hi,

in your last front page you claim:
"As of this writing, there is probably not a single distribution which, out of
the box, provides that environment."

SuSE 7.2 comes with everything that is required for GnuCash 1.6.

(OK, I admit, SuSE 7.2 is out for no longer than 1 week ...)

I'm a (not too active) GnuCash developer. And in spite of your
article I still like LWN very much. But I do agree with the mail
Bill Gribble sent to Jonathan Corbet.

Regards,
 Herbert.
-- 
Herbert Thoma
FhG-IIS A, Studio Department
Am Weichselgarten 3, 91058 Erlangen, Germany
Phone: +49-9131-776-323
Fax:   +49-9131-776-399
email: tma@iis.fhg.de
www: http://www.iis.fhg.de/

From:	 dave mallery <dmallery@cia-g.com>
To:	 <letters@lwn.net>
Subject: dependency hell
Date:	 Thu, 14 Jun 2001 12:25:15 -0600 (MDT)

hi

i have been using linux daily since about 1997 and saw my first computer
in about 1965.

the feature on gnucash fingers a really major problem.  a working linux
desktop is a beautiful thing, but the near impossibility of installing
anything major kills it neatly.

i just spent a week trying to get Corel Office  2000 to run on my r/h 7.1
machine.  the initial problem is that it needs glibc2.1 or 2.0, not the
2.2 that ships.  a backward compatibility problem.  just installing the
compatability rpm did not solve it.  the install script shipped with the
product does not work in this environment.  only a well hidden script
pointed to by an e-mail (many day latency) from support would work.
further problems showed up requiring another upgrade for libaps via an rpm
from their site.  at this point, it will 'run' but is highly unstable and
there are no more hints available.

i had come to rely on their wordperfect 8 for a few years.  too bad.  the
reason i don't just go to one of the free apps is that the fonts are few
and they won't read my many hundred wp8 files.  (i have not checked star
yet).

the big fear in the back of my mind is that as i make changes to my 7.1
install, i will either screw something up or unwittingly fork, making my
system 'un-upgradable'! i have the same fear with a system on which i
installed ximian.  once you diverge from the r/h installation (i subscribe
to krud), you may find yourself in un-charted seas.

i am a reasonably experienced user facing a wall of complexity.  this
could rapidly become an insurmountable problem and needs some clever
fixing at the system level.  i'd love to use gnucash.....

dave


-- 
www.ramahcafe.com

Dave Mallery
Ramah Cafe
3270 Hiway 53
PO Box 520
Ramah,  NM  87321

no gates
  no windows...

running GNU/Linux
free at last!

Linux is a trademark of Linus Torvalds

From:	 Joe Van Andel <vanandel@atd.ucar.edu>
To:	 letters@lwn.net
Subject: shared library hell and library version numbers
Date:	 Fri, 15 Jun 2001 12:01:03 -0600

The "gnucash 1.6 and the dependency nightmare" article didn't explain
that some library developers are contributing to the problem by *not*
changing the version number of libraries when incompatable changes are
made.  In theory, if application X uses shared library Y.1.2, it should
work with *any* version of library 1.1.2.  In practice, I find that two
different releases of Redhat (for example) may contain shared libraries
with the same version number, but incompatible contents.   

Clearly, if library developers "played by the rules", I could continue
to use application X with shared library Y.1.2 while using application
'Z' with shared library Y.1.3 .  That is, I wouldn't need to worry (as
much) about breaking existing applications when I upgrade shared
libraries if all library developers would consistently change the
library version suffix when incompatible changes were made.

There is some irony in the fact that Microsoft has been plagued by the
same issue with Dynamically Linked Libraries (DLLs).  One source of
instabililty in Microsoft Windows applications is that installing one
application can break existing applications, because the "new"
application installs its own version of DLLs that aren't compatible with
the DLLs needed by an existing application.  Microsoft's solution for
Windows 2000 is (so-called) "enhanced sharing" of DLLs.  Rather than
applications being allowed to over-write the system DLLs provided by
Microsoft, each application must install its own "private" copies of
DLLs, which are stored with the application, rather than in the
"shared", system directories.  As a result, at runtime, your system
might have 3 different verions of XYZ.dll loaded into memory.

As much as I dislike statically linking applications, unless library
developers do a more consistent job with shared library version
numbering, static linking may be necessary to improve application
stability.


-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu

From:	 Ketil Malde <ketil@ii.uib.no>
To:	 letters@lwn.net
Subject: Executable stack and security
Date:	 14 Jun 2001 09:00:30 +0200


While one may argue that disabling execution of the stack doesn't
really fix the problem, I don't agree with labelling it "security
through obscurity".

STO is about maintaining security by hoping nobody finds out about
your weaknesses.   Non-exec stack makes exploits more difficult, it's 
making the weakness a bit less weak.

Calling this patch STO is, IMHO, a political statement, though
from LWN it's probably unintentional.  The real argument against it, I
think, is that those lazy, worthless bastards[*] maintaining libc and
other code may not bother to fix their buffer overruns any more. 

-kzm

PS: Yeah, and cut the Desktop page some slack, will you?  LWN *needs*
desktop coverage, and I think it will sort itself out.  I guess
(looking at the survey) we're a bunch of dweebs who'd like more of the
hard tech stuff -- personally, I like the way the kernel page is done;
first the current news, then a more in-depth look at some technical
details.  How about some technical stuff about KParts, CORBA, XFree86
4, etc?

[*] Actually, I'm being ironic.  I think they'll continue to fix bugs,
regardless of stack executability.
-- 
If I haven't seen further, it is by standing in the footprints of giants

From:	 Eric Smith <eric@brouhaha.com>
To:	 letters@lwn.net
Subject: Non-executable segments are NOT an obscurity defense
Date:	 14 Jun 2001 21:39:41 -0000

Gentlemen,

In your 14-Jun-2001 issue, you write "non-executable segments is
arguably an obscurity defense, because attacks exploiting overflow
vulnerabilities that are stopped by non-executable segments can always
be re-worked to be "return into libc" style attacks that bypass the
non-executable segment by pointing directly at code in the code segment."

That's like saying that putting a lock on my front door is an "obscurity
defense" because an attacker can still pick the lock.  The failure to
solve 100% of the problem and eliminate related attacks does not make
it an "obscurity defense".

If I put a lock on my front door, but the lock was designed to open
without a key if someone whistles nearby, that *might* qualify as an 
"obscurity defense."

Note that obscurity isn't inherently bad.  It is *depending* on
obscurity of widely-distributed information that is bad, because you
can't expect that the attacker doesn't have the necessary obscure
information.

Some amount of obscurity is almost always necessary for security.  For
instance, having a password is an "obscurity defense," because you're
counting on the attacker not knowing this obscure knowledge.  However,
a password is a very small bit of knowledge that is ideally only known
to one person.

On the other hand, if a password system in a widely distributed piece of
software had a fixed "back door" password coded into it, and we expected
no one to find that, it would be a blatant case of "obscurity defense",
because the knowledge could be (somewhat) easily obtained by anyone.

Eric Smith

From:	 Christian Hellon <xian@lisardcage.fsnet.co.uk>
To:	 letters@lwn.net
Subject: On the Desktop just hit the mark
Date:	 Thu, 14 Jun 2001 12:40:20 +0100 (GMT+01:00)

I've watched the furore over the On the Desktop section for the last few
weeks, and privately agreed with those who felt that the style wasn't really
in keeping with the rest of LWN. However, I decided to wait and see; it's
natural that an established author, accustomed to writing and achieving
success in his own style, would take a while to find the "groove" that
successfully combined that with the house style of the magazine he's just
joined.

It looks like I was right to wait a while before passing judgement. This
week's column is spot on, continuing the trend of the last couple of weeks. A
belated welcome to the team, Mr Hammel, and I look forward to reading On the
Desktop for a good few years to come.
-- 

the desk lisard is at reply@lisardcage.fsnet.co.uk

"i don't know why i'm crying, am i suspended in gaffa?"



____________________________________________________________
Freeserve - get your free ISP service including web-mail at:
www.freeserve.co.uk

From:	 "Alex Bennee" <Alex_Bennee@hotmail.com>
To:	 lwn@lwn.net
Subject: On having plug in protocol stacks in the Linux Kernel
Date:	 Fri, 15 Jun 2001 10:38:42 +0100



Dear LWN,

I thought I would just point out why having this pluggable interface structure
would be useful. I'm in the process of trying to convince my development area
(we do embedded comms) to move from our existing RTOS's (where we suffer badly
from vendor lock-in) to a linux kernel. However as is common in the comms world
we do use 3rd party stacks to bring our time to market down. While the eventual
hope would be to move away from such expensive 3rd party stacks pragmatism must
be the order of the day. By the way the stacks we use are about 50/50 split
between pure source or binary only.

Of course anybody could "fork" the kernel or provide a patch for the standard
kernel to add in such a feature but it would be a bit more of a pain to manage.
Most proprietary OS's provide standard interfaces for 3rd party stacks to
plug-in.  I think the kernel will suffer in the embedded world if such
interfaces can't be kept in an open central way. I prefer a more pragmatic
approach which allows for proprietary plugins but is not dogmatic about avoiding
the possibility of non "free" software working with the kernel. Also I think
"crippling" a generic patch to only work with source-level linking is a rather
pointless exercise.

Regards,

Alex.

From:	 "Robert A. Knop Jr." <rknop@panisse.lbl.gov>
To:	 <letters@lwn.net>
Subject: FUD "forking" resopnse
Date:	 Fri, 15 Jun 2001 14:00:07 -0700 (PDT)

A common piece of FUD about Linux and free software is that because it's
not controlled by any one central authority, it may (and will and indeed
been known in the past to) fork, causing confusion and balkanization for
its users.  The plethora of Linux distributions available is often cited
as an example; it is difficult for anybody to support Linux, the argument
goes, because you don't know exactly which flavor of Linux your users are
using.

One might make the analogy to news sources.  Go to the supermarket and
look around.  You are likely to find a number of different mainstream news
sources: Time, Newsweek, the local newspaper, etc.  You will also find the
National Enquirer, the Weekly World News, and other, er, less mainstream
sources of news.  Freedom of the Press means that anybody who wants to and
can afford to can put out a newspaper.  But, horrors!  Without a central
authority controlling the news that gets to individuals, how are we to
know which news source to listen to?  How are we to make heads or tails
out of the reports in certain "news" sources that seem to contradict
everything in other news sources?

Obviously, this isn't a problem; indeed most people in the USA recognize
that freedom of the press is one of the most important foundations of our
society.  Some people believe the Weekly World News, but most people
recognize it as a source of entertainment.  Based on track record, we
learn which news sources to trust.  What's more, each individual can
figure out for himself which news source is the one that is best for him.
The plethora of distributions, the "forking" of news sources isn't a
problem, it's an opportunity.  And, of course, the only way to "cure" this
"forking" would be to elimiate freedom of the press.

The analogies to free software are clear.  There are lots of
distributions; there are only a few major distributions.  People will pick
the ones that work best for them.  If code forks, people at large will
figure out, and the information will get out, as to which branch(es) of
the code are the ones to trust, and are the ones to pay attention to.
It's just not a problem, any more than having lots of fun newspapers in
the checkout line at the supermarket is a problem.

-Rob Knop
rknop@pobox.com

From:	 "Richard Corfield" <rjc1008@hotmail.com>
To:	 letters@lwn.net
Subject: MS documents about Linux
Date:	 Mon, 18 Jun 2001 10:51:53 -0000

I must admit, as a cancer patient, that I see nothing in common between 
Linux and cancer.

I remember one thing I was told in my graduate training for a well known 
large computer company. You should never blatantly attack the competition as 
Microsoft are doing now. You can sell the benefits of your product, but to 
just insult the competition is seen as highly unprofessional and just gives 
a bad image. Hopefuly people are seeing through Microsoft's "in the 
interests of America" approach and seeing these attacks for what they are.

The text of the "Linux in retail" document is laughable. Here it resulted in 
explosions of giggles. I wonder sometimes if someone could write a similar 
document about Microsoft, but the argument about "being professional" comes 
in, so perhaps better not. I imagine also that Microsoft's laywers would 
have a field day with it.

Microsoft are sounding like the baby throwing the rattle out of the pram 
because it can't get what it wants. Lets hope that is how the computing 
public will see these blind attacks and think about discovering for 
themselves the real differences between Microsoft and Linux.

- Richard

If Linux is cancer, then I suppose Windows is like chemotherapy. I'm finding 
that chemo has the nastier side-effects. Now who wants chemo for something 
non-malignant like Linux?

From:	 Anders Holtsberg <anders.holtsberg@decuma.com>
To:	 lwn@lwn.net
Subject: About your article.
Date:	 Wed, 20 Jun 2001 12:53:34 +0200

In the article  
http://www.linuxweeklynews.com/
you cite a Microsoft document:

  Imagine how confusing it would be if Microsoft
  released 188 versions of Windows and multiple
  versions of the GUI, each with a slightly different
  functionality? Wouldn't that be confusing? Wouldn't
  it be extremely difficult to run an enterprise solution
  with confidence about your future and return on
  investment in Microsoft products? That is the exact
  scenario that Linux is presently in by having so
  many distributions. 

Your answer was:

  You read it here: choice is bad. 

I have another answer: What about Microsoft's number of versions?
We run a network where we develop stuff for the chinese market.
We have for example one machine with chinese Win2000. Does it
work? No. Our company standard swedish MS-Word won't even run
on it because it generates internal temporary file names with
swedish characters in them and the chinese Win2000 refuses to 
accept it. Result: Microsoft Win2000 programs don't work on
Microsoft Win2000 operating system. If Microsoft claims they 
cause no problems since they don't produce a bewildering number
of different operating system versions, then they are lying. 

Anders Holtsberg

ps. by the way: in the project I am heading we use Linux, Bash,
Noweb, GCC, Icon, Gawk and Octave as core tools as well as 
Windows and Visual C++.


-- 
_______________________________________________________________
   Anders Holtsberg                  Decuma AB
   tel +46 709 596305                Ideon Växthuset
   anders.holtsberg@decuma.se        S-223 70 Lund, Sweden