See also: last week's Back page page.

Linux links of the week

SourcePower.org is the web page for what appears to be an attempt to create a free software advocacy organization. Some sort of combination of Linux International and the Open Source Initiative, but with a bit more of an activist bent.

Section Editor: Jon Corbet

Letters to the editor

To: editor@lwn.net
Subject: Re: Not quite open source
Date: Fri, 26 Mar 1999 19:01:48 +1100
From: Peter Miller <pmiller@acay.com.au>


In your feature ``not quite open source''
(http://lwn.net/1999/features/BitKeeper.phtml) you say "Larry McVoy is
out to change the way cooperative software development is done, and he
may just pull it off."

But it's not a one-horse race.  In an article recently posted to
linux-kernel, I propose that Aegis
(http://www.canb.auug.org.au/~millerp/aegis/) be used instead.  See
http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_99/3960.html
for details.

Regards
Peter Miller   E-Mail: millerp@canb.auug.org.au
/\/\*          WWW:    http://www.canb.auug.org.au/~millerp/
Disclaimer:  The views expressed here are personal and do not necessarily
        reflect the view of my employer or the views of my colleagues.

Date: Tue, 30 Mar 1999 11:12:47 -0700
From: "Dr. Glenn Butcher" <gbutcher@cos.colotechu.edu>
To: editor@lwn.net
Subject: Re: What Linux Needs Next

Mr Atkinson has identified a true need for Linux to move into the
mainstream, but he's whacking on the wrong nail.  The configuration
files can stay where they are if we start using configuration tools that
hide their locations.  I've been using webmin for a couple of months
now, and it provides excellent facilities for developing and including
modules for any software requiring configuration.  I plan on developing
webmin modules for all the Linux software I develop.  Abstraction can
occur at many levels; the "market" will eventually gravitate to one or
the other for integrated configuration...

Glenn Butcher

Date: Fri, 26 Mar 1999 18:28:23 -0600
From: Dub Dublin <dub@pswtech.com>
To: editor@lwn.net
Subject: Registry isn't inherently evil


In reading the many responses to Tom Atkinson's letter suggesting that
Linux needs a configuration database (CDB), I noticed that many people
are opposed to the idea of a MS Registry-type thing without exactly
knowing (or at least cogently stating) why.

At the risk of being accused of defending Microsoft, I'd like to point
out that it's important to draw a distinction between the concept of a
fast database to store and index critical OS and application
configuration information and Microsoft's specific implementation of
the concept.

I argue that the Registry/CDB *as a concept* is a good and valid idea.
I also argue that the rat bag of incompatible and inconsistent
Registry entries has failed for *exactly the SAME reason* that the rat
bag of incompatible and inconsistent Unix config files has failed:
lack of any agreement on how to use the things!

In principle, the Registry concept has a lot going for it: it's fast,
compact, easily accessible (well, sort of), highly optimized by some
programmer other than the one calling it, etc.  The problem is that
Microsoft never adequately specified how it was to be used (and, of
course, no one else could, either.)  As a result, many applications
use configuration parameters that *should* (in a good architecture) be
keys under, say HKEY_CURRENT_USER, but are actually implemented as
keys under HKEY_LOCAL_MACHINE or something similar.  It's this sort of
ambiguity over what the registry is intended for and how it should be
used that has left it in the sorry state it's in today.  Every
application developer does that which is right in his own eyes, with
little regard to what might happen if, say, the application is served
rather than local, or used by multiple users
simultaneously. (ref. Proverbs 12:15 <g>) It's this sort of
short-sightedness that can make things like running a "test" version
of an application on an NT machine that also has a "production"
version loaded a very challenging excercise - even though this is
pretty trivial in Unix..

As for stability, it's true that a CDB represents a critical single
point of failure, but then so do filesystem FATs - and we don't seem
to mind that much anymore.  If properly implemented, CDBs would have
reliability features such as journalling, integrity checking,
etc. that would allow graceful reconstruction of a munged CDB. Again,
the Windows registry falls short of the mark, but a poor
implementation should not damn the entire concept.

We need to set aside the anti-registry bias and seriously look at what
forms a CDB might take, and what value it might have to the community
at large.  ***More importantly, much of the key tree needs to be well
mapped out in advance so that there are predictable and reasonable
locations and formats for OS and application data.***

At the risk of starting a flame war, this is one place where infinite
malleability and extensibility may be suboptimal.  Such constructs
tend to become the only ones used by lazy programmers, leading to a
tragedy of the commons in which there is a standard format which
(thanks to an extensiblity hook) has unused standard entries and
beaucoup proprietary data.  Witness IGES type 102(?) "copious data",
the SNMP "enterprise MIB" tree, HL-7 extensions, etc.  Ultimately,
these just produce a legion of proprietary formats shoehorned into an
awkward "standard" wrapper, resulting in what is arguably the worst of
both worlds.  (Interestingly, XML may provide a very useful mix of
exensibility and self-explanation, even though it's very malleable.)

As an interesting aside, I think it is exactly the "pre-thunk"
attributes that have made the Macintosh implementation of this
(essentially a CDB in the resource fork of every file) arguably the
most successful implementation of the function to date.  In spite of a
relatively clunky file-by-file storage structure, the keys and value
formats are well known and understood, and can be shared and used
freely without worry.  The value to the user/programmer comes from the
consistency, predictablity and organization, not from ease of access,
or even speed.

I look forward to a time when Linux has a powerful, flexible, and
*predictable* mechanism for holding OS and application config
information.  The exact implementation mechanism is much less
important than how well-thought-out it is in other respects.
(Personally, I'd prefer some sort of persistent object store, since it
maps well to the real world and inheritance would be handy, but it
really doesn't matter...)

Dub Dublin
dub@psw.com

From: Alex Shnitman <alexsh@hectic.net>
Date: Sun, 28 Mar 1999 17:45:25 +0300 (IDT)
To: editor@lwn.net
Subject: Re: What Linux needs next

Hello,

Last week a lot of people wrote in with responses to Tom Atkinson's
article that suggested a central binary "registry" for storing all the 
configuration data of all the programs.

Most of them compare the idea to Windows' registry, and reject it on
that basis. They miss one thing. Don't ever confuse the idea with the
implementation. You are right that the registry, in the way it's
implemented in Windows, is a nightmare. But that doesn't mean that the
idea sucks, it only means that the implementation sucks. Perhaps it
isn't a good idea to store all the entries in one file (that can
easily get corrupted). And perhaps there needs to be a better
structure for the registry, one that is designed very carefully to be
easy to clean (or rather hard to get bloated in the first place), and
that doesn't acquire slack over time. But don't discard the idea on
the basis of one if its implementations.

Having said that, I do agree that strictly a *binary* database isn't a
good idea. In my opinion the approach taken by KDE and GNOME is the
best. The configuration remains in text, but there's a unified API for
accessing it. Thus, it's still script-processable, and yet GUI-
manageable and consolidated. The configuration of each program is
stored in its own file, so it's not easy for the database to get
corrupted. You see - we don't have to invent anything new. Perhaps
more programs should be written with the KDE or GNOME libraries, even
if they don't use Qt/GTK or are not even graphical. Then again there's 
the KDE/GNOME conflict, but reducing the configuration to *two*
databases is certainly better than what we have now.


-- 
Alex Shnitman                            | http://www.debian.org
alexsh@hectic.net, alexsh@linux.org.il   +-----------------------  
http://alexsh.hectic.net    UIN 188956    PGP key on web page
       E1 F2 7B 6C A0 31 80 28  63 B8 02 BA 65 C7 8B BA

From: "Greg Owen {gowen}" <gowen@xis.xerox.com>
To: <editor@lwn.net>
Subject: Re: replacing flat text config files with a database
Date: Thu, 25 Mar 1999 10:55:18 -0500

Art Cancro writes:
>   The configuration database that Mr. Atkinson proposes is,
>essentially, the Windows Registry.  Anyone who has had even minimal
>experience with the administration of Windows systems knows that
>it's quite easy for the registry to become corrupted, or (perhaps
>even worse) loaded up with defunct settings for programs which are
>no longer installed on the system.

   The fact that Microsoft did it poorly should not be taken as an
indicator that it can't be done right.  Isn't that the Linux motto?
;>

   What Mr. Atkinson proposes, in short, is replacing a flat-file
database, with all its parsing and lookup headaches, with a reasonable
database backend.  I think the advantages in speed, performance, and
reliability are potentially quite large.  The largest obstacle is not
in building a good system, but in making various packages that have
been using crappy config files for 20 years compatible with the new
system.

   Such a system, built from the ground up, could target the problems
of the Windows Registry and learn from Microsoft's mistakes:

1) Redundancy, redundancy, redundancy.  Build the system to beat
corruption.  Microsoft didn't do it, but nobody said it can't be done!

2) Cleaning.  The RPM system manages to do a reasonably good job of
protecting the filesystem from cruft, and if the system is a database,
it is perfectly designed for keeping the associated information
required to clean up.

3) Fix the obscurity problem.  For example, each key has an associated
help entry that describes what it does and what forms of values it
takes, and have it do some sort of checking on the entry to see if it
complies.  That, to me, represents an improvement over reading
flat-file examples and 5 man page entries, then searching the web to
see an example of someone else's syntax.

4) I don't know what the Registry does for layers of permission, but
that's something that should be thought about too.

    Is there a mailing list appropriate for discussing this idea?  Is
anyone else interested in doing the thought experiment of picturing
how such a system could be designed?  Let's spend some thought on it
and see what we come up with.

--
        gowen -- Greg Owen -- gowen@xis.xerox.com -- gowen@scansoft.com

        Please note my new gowen@scansoft.com address which will
        become my default address in March, and which works now.

From: nride@us.ibm.com
To: editor@lwn.net
Date: Thu, 25 Mar 1999 12:12:48 -0700
Subject: Re: What Linux Needs Next



I, like many others, feel that a single binary "registry" would not be
the way to go with Linux. I've seen the effect of such things on other
systems (Windows and OS/2) and they generally hide information from
the user that should be easily accessable.

I also agree with many of the other people who wrote on this topic
that a single unififed format for the various files in /etc would be a
great idea.  Not only is it difficult to remeber the various formats
(The only thing that seems to stay constant is that # starts a
comment) but a lot of programmers are wasting a lot of time writing
parsers for their servers.

What I suggest (And will try to work on in my copious spare time
*snort*) is a migration to XML format. Intead of /etc/sendmail.cf,
you'd have /etc/sendmail.xml. There are lots of tools available now to
do parsing of XML data and the language is ideal for this sort of
thing. In addition if it's done correctly, system configuration for
the average user should be as simple as pointing mozilla at /etc. You
could also write a file that each server could register in to which
would contain the server name, some info about it, and the name of its
config file.

If we really wanted to get clever about this we could write a tool
that would import a DTD or schema and output a C header file with
structures that you could read directly into. You could then use some
library routines to import your data as needed.

I'm trying to get a push on to start work on this but I don't
currently have a central location from which to coordinate something
like this.  Perhaps someone else would like to start a project page?
I'm planning on working over my weekends and nights and hope to start
by moving the init file format to xml. It would be nice to have a
central dumping ground for patches though.

--
----------
Bruce Ide           nride@uswest.net

Date: Tue, 30 Mar 1999 10:53:18 -0600
From: Craig Goodrich <craig@airnet.net>
To: bruce@perens.com
Subject: ESR's Leadership ...

[ref http://perens.com/Articles/Evangelist.html ]

Bruce,

I agree with your editorial's conclusion that it would be more
healthy for the open software movement to have several prominent
speakers to act as ambassadors to the curious alien culture on
Planet Suit, rather than placing that burden on any one person. 

The difficulty, though, is that basically what we refer to as
the "movement" or the "community" really _has_ no leader, at
least not in the sense that the commercial (much less political)
world uses the term. We're a spontaneous order, and when we call
ourselves followers of ESR or RMS, that's simply a shorthand way
of characterizing our own individual philosophical orientation
vis-a-vis some of the licensing and advocacy issues currently
being debated within the community. (At least, that's what it
means among the grownups who express themselves in the mailing
lists, newsgroups, and such fora as Slashdot.) 

It's not as though the community itself elected anyone by
anything like a formal (or even informal) process. What happened
was that ESR wrote a very perceptive and original paper -- "C &
B" -- contrasting two different approaches to the technical
probem of software development, _both approaches being within
the "open software" tradition_, and pointing out the practical
advantages in productivity, reliability, etc. of the bazaar
method. Hackers for a commercial software company found the
paper, decided it was relevant to their company's current
problems, invited ESR to speak at Netscape, and the rest is
history. 

If anyone appointed ESR spokesman, it wasn't the hacker
community at large, nor ESR himself. It was just what happened,
and the press, wondering what it was all about, gravitated
towards ESR since he was the most visible source of information.
And this became self-reinforcing: press coverage leads to more
press coverage as the name becomes better-known. 

So ESR was faced more and more with a choice between a) pulling
a Marlene Dietrich and retiring quietly to his machine in
Pennsylvania, or b) accepting an expense- paid week in some
fascinating place in exchange for talking to suits. (I know the
choice I would have made, and I'm pretty much burned out
already....) 

Basically, I think, if ESR really wants to step out of this
role, all he would have to do is start saying "Sorry, I can't
make it, but you might want to contact Fred or Bruce or ...."
when invited to speak. And he probably will eventually, when in
his personal judgment the conditions are right -- although it's
doubtful, at least to me, whether this position can actually be
passed on by primogeniture or apostolic succession; only time
will tell. 

But in the meantime, would-be bureau speakers don't have to
convince the hacker community of their talents (except possibly
Eric). We could unanimously vote somebody Supreme High Long
Integer and it wouldn't make much difference to the audience ESR
is reaching. The ones to convince are the press and the suits. 

Craig
==============
Craig Goodrich
Rural Village Systems
somewhere in the woods near Huntsville, Alabama

Politics for the Thinking Redneck  -- http://airnet.net/craig/g4c
Linux miscellany                   -- http://airnet.net/craig/linux

-------------

Though my heart be left of centre, I have always known that the
only economic system that works is a market economy, in which
everything belongs to someone--which means that someone is
responsible for everything. It is a system in which complete
independence and plurality of economic entities exist within a
legal framework, and its workings are guided chiefly by the laws
of the marketplace. This is the only natural economy, the only
kind that makes sense, the only one that can lead to prosperity,
because it is the only one that reflects the nature of life
itself.
				-- Vaclav Havel 
				  _Summer Meditations_