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

Text File | 1992-08-15 | 7.1 KB | 129 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!decwrl!world!dsb
From: [e-mail] (David Boyce)
Subject: Re: Stabilizing Linux
Message-ID: <[e-mail]>
Organization: The World Public Access UNIX, Brookline, MA
References: <[e-mail]>
Date: Sat, 15 Aug 1992 23:47:53 GMT
Lines: 118

In article <[e-mail]> [e-mail] (Lars Wirzenius) writes:
>What I propose is this (getting to the point already, are we?):
>We'll let the kernel evolve towards what we want 1.0 to be, at
>least featurewise.  After we reach a point where all the features
>we want are present, we freeze that version of the kernel as 0.99,
>and refuse to put in new features (unless they are essential).
>
>After the kernel has been tested thoroughly, for a few weeks or
>so, and all the major bugs have been fixed, we release it as 1.0.
>Then we consider this as the baseline, and create one official
>release that is easy to install, easy to administer, contains
>everything necessary and a lot of unnecessary but probably widely
>useful things and package everything neatly.
>
>This package is what should be called Linux, not just the kernel.
>Compare with, say, SVR4: it is not just a kernel, but a whole
>bunch of software.  Also the whole package is given its own
>version number, instead of using the kernel's version number as is
>currently done.
>
>The whole package will then be put into all the major Linux ftp
>sites, and those sites are cleaned up so that there are no old
>releases that confuse people.  This is then announced and
>advertised as the official released version of Linux which should
>be used by everybody but hackers and others who like to have
>problems.  It is also advertised to remain that way for at least a
>few months...

    Two prolific threads lately have been this "Stabilizing Linux"
series and the discussions of the coming commercial CDROM/floppy releases.
It seems to me that there's a natural way to put them together:
    The upshot of Lars' article seems to be that "we need to create
a stable, reliable Linux 1.0 version" and thus that we (using the term
loosely, I haven't contributed much) should go through the usual
integrate/test/document/release process that most commercial software
goes through. While I agree with most of Lar's article and the followups,
my disagreement with the above is rooted in the fact that commercial
software developers go through the painful release process because
they have paying customers, who are understandably upset when bugs or
incompatibilities show up or when promised features don't. But linux
per se has no paying customers, just users.
    Now, at the same time we're reading that there are for-profit
organizations getting ready to issue CDROM or floppy editions
of linux as soon as it stabilizes. While I'm not one of those
people that has a problem with this (I understand the GNU concept
etc.) I do have trouble understanding why the companies that propose
to have paying linux customers shouldn't be the ones to do the
integration and testing.
    So this is my proposal: instead of doing the integration and testing
for (the entire system) Linux 1.0, we should spend the intervening time
between now and (kernel) 1.0 discussing and developing a document
in the spirit of SVID or POSIX*, i.e. something which says
"you can't call your product Linux unless it conforms to the
following specifications". This wouldn't need to be a big thing,
just an invocation of the appropriate POSIX etc. specs where
applicable, a description of filesystem layout and utility
features ("... the utility suite is that provided by FSF,
with the exception of the following which are in the BSD
distribution, and such-and-such special cases...").
    Note that this document doesn't concern itself with versions;
it simply says that the following files will exist  in the following
places with the following modes and will exhibit the following behavior....
Once we've issued release 1.0 of that document and Linus has
blessed version 1.0 of his kernel, we can sit back and wait for
the CDROM company(s) to put together a package that satisfies
this Linux Interface Document (LID). If the makers of mcc-interim,
MJ, etc. can do this without a spec in their spare time, I assume
it can be done commercially without too much trouble, given the spec.
    Actually, this document or something like it is probably already
being worked on by the linux-standards people.
    And then as soon as the CDROM is issued, the people at one of the
big linux ftp sites can acquire one (taking donations as appropriate,
I'm sure they'd be gladly given) and mount it
for ftp access (it will be freely distributable, after all).
Other sites can do the same or mirror it, and voila! there is
a stable Linux 1.0 available for ftp by the core linux community,
and hackers can go on issuing a release a day if they like.
And we'll let the for-profit issuers decide when releases 1.1, 2.0,
etc. are required. They can pick fixes from the stream and issue
them as floppy updates to their customers or make whole new releases.
As a customer, the ftp site(s) would get these updates and make
them available for ftp.
    I don't think this would be an undue burden on linux sellers.
Anybody selling software has to test it first; they owe that to
their customers. And they'll probably decide to rebuild all the binaries
with the released version of gcc, just for the sake of sanity.
At least, that's what every commercial system vendor I've ever
worked for does. So given that they'll probably go through
a build/integrate/test/release process anyway, why not piggyback
off them? Let them do what they hope to be paid for and let
the linux developers go on being the geese that lay golden eggs.
    Also, we need to recognize that whatever version is issued on
floppy/CDROM is going to become a de facto standard, just by the nature
of things. This is why I think that rather than issuing a standard
release and then hoping it's what gets shipped on CDROM, we should
issue only a document and wait for it to be instantiated in CD.

    Anyway, this seems, to me at least, to solve everyone's problems:
the hackers can go on hacking and acquiring new software as quickly
as they can ftp it, the "users" buy the CDROM or floppies. The
"Keep Linux FREE!!!!!" contingent will sleep better at night knowing
those commercial vendors are doing some work for their money,
the vendors get exclusive access to the non-internet community,
and those who have ftp access get the best of both worlds
by being able to ftp the CDROM bits for "free". And those of
us on c.o.l who have opinions galore but lack either the time
or the talent to contribute anything else, can get to work
on wrangling over the LID.

To summarize: issuing releases is an incredible drag. Especially
the ones after the first. The problems are caused by the requirements
of paying customers. Thus, I think the burden is best left to
those who have said customers. Let them also take charge of when new
releases are required, release nomenclature, packaging, etc.
Since Linux is freely distributable, we can "steal" their work
right backs for our purposes.
--
David Boyce    [e-mail]    617-576-1540