NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/linux/8397

Internet Message Format | 1992-08-16 | 5.6 KB

Path: sparky!uunet!cis.ohio-state.edu!ucbvax!bloom-beacon!bloom-picayune.mit.edu!daemon
From: [e-mail] (Theodore Ts'o)
Newsgroups: comp.os.linux
Subject: Re: Linux Standards (was: Stabilizing Linux)
Message-ID: <[e-mail]>
Date: 16 Aug 92 22:17:36 GMT
Sender: [e-mail] (Mr Background)
Reply-To: [e-mail] (Theodore Ts'o)
Organization: The Internet
Lines: 92


   From: [e-mail] (Daniel AMP Carosone)
   Date: Sun, 16 Aug 1992 00:47:18 GMT

   Even ignoring the factions and parties building releases, it is an
   excellent idea to have a standards document to which releases must
   conform rather than a release to which the standard must conform.

I disagree.  Most usuable standards in the world come about by adopting
an already working implementation and declaring it to be a standard.
Most unworkable standards in the world happen because they were designed
by a committee, which typically consist of pompous people who just sit
around a table, and who are not, generally, the people who would
actually be doing the implementation.

If you want an example of this, just look at the Internet --- the
Internet "standards" were first done by having working implementations,
which were then annointed as the standard.  In contrast, you have the
OSI standards --- which were designed by committee without having any
implementation experience --- and what you end up with is a disaster.

   I have not been following the discussions on the Linux Standards list, I
   wonder if the current efforts there are this ambitious? This is surely
   the best place to direct followup conversation on this matter.

There hasn't been any discussions on the Linux Standards list, in quite
a while.  We just couldn't come to a consensus.  One big problem is that
since *anybody* can join the list, anyone can start blabbing off with
half-*ssed ideas that really won't work --- and it takes an awful lot of
to respond to each of them explaining why the idea is stupid or won't
work, or is completely non-standard compared to every single other Unix
system in the world.  And we were only trying to discuss something as
simple as what to name the devices in /dev!  I saw a bunch of proposals
on that mailing list, for example, about hiearchical directories in /dev
(i.e., /dev/tty/*, /dev/pty/*), and the authors seemed blithely unaware
of much havoc that would wreck amongst unsuspecting programs.  At the
time, I was spending all of my time at a *real* standards meeting (the
Internet Engineering Task Force), so I simply did not have the time and
energy to respond.  And, it turns out, neither did anyone else, as the
list went dead shortly thereafter.

There are two advantages that a "real" standards body (such as the IETF,
or ANSI, or ISO) has over something that we put together.  First of all,
each of those organizations have authority based upon some charter.  Who
would charter a "Linux Standards Committee"?  What would give that group
authority?  Aside from sounding pretentious as all hell, there is
certainly no way you could enforce the statement "You are not allowed to
use the name Linux unless you follow thus-and-so".

The second advantage that a "real" standards body as over something we
put together is that there is a real cost to attend a standards meeting,
even if it's only the travel expenses to the location in question.  This
tends to weed out the duffers and the casual attendees.  While it is
true that this may filter out some brilliant, poor graduate student ---
it also filters out the raving Usenet flamers as well.  You either need
to be rich enough to attend one of these meetings, or your company has
to think well enough about you to let you attend.  While this mode of
operations has its drawbacks, it has its clear advantages, and
unfortunately it's one that could not apply to us.

However, without this, you have to face the fact that you will have a
non-trivial amount of people with relatively little Unix system
experience that will be constantly spouting off and you either have to
outright ignore them --- which doesn't tend to go over well if you want
to at least have the pretense of democracy --- or you have to spend a
lot of time and energy teaching them why they are broken.


The advantage of having multiple releases is that even IF one of
"self-appointed release engineers" is totally losing and is brain
damaged ---- and it turns out to be rarely true, since the people doing
the work tend to be much more reasonable than the airchair quarterbacks
--- that's O.K., none of them is the standard.  The rest of the world
can just ignore that release once it is determined that the person has
used a completely hairbrained filesystem structure, for example.  And,
if a significant minority *want* that hairbrained strucutre, they can
use that release; it's their freedom of choice.

On the other hand, even if we did annoint a single standards document as
The Only Way To Do Linux ---- and this is assuming that (1) we had the
authority to do this and (2) we could actually come to a consensus ---
there is a significant chance that the standard may be broken, in which
case everybody loses.  How could this happen, if we had come to a
consensus, I hear you ask?  Because all it takes is a vocal minority to
continually push their *bad* ideas, and what will happen is that the
reasonable people will, after a while, give up and go away in disgust.
At the very least, I would be very resentful of the fact that I had to
spend all of my time fighting bad ideas instead of doing something
useful, like doing some Linux development.  I'd rather the bad ideas die
in the marketplace.

                        - Ted