mike wrote:
> On Monday 09 July 2001 20:51, David Rankin wrote:
>
> > The "cup is half-full" side to the "Lack of Standards" argument is the
> > "Rapid Progress" being made and "Healthy Competition Coupled with
> > Enginuity" within Linux development community. To call this a "Lack of
> > Standards" is at best a misunderstanding of the open source concept and a
> > worst a calculated "issue" spin doctored by our dear friends at M$.
> >
> > Gotta Go, my 2 yr. old needs some daddy time...
> >
> > --
> > David C. Rankin, J.D., P.E.
> > ASEL -- Instrument
> > Nacogdoches, Texas
> > N31 34.7 W094 42.6
> > 355 MSL
>
> That has got to be the silliest thing I have ever heard. Yes, it does take
> discipline to grow and remain organized. This is not a "Linux Community"
> issue, this is departing from the Linux community. Perhaps you are too young
> to remember the UNIX wars. I have been programming UNIX since 1982, and
> frankly I spit on M$. Branching off so that users are stuck with your way
> your doing things is very M$. It is natural when a strong advocate of Linux,
> like myself, sees this kind of devisivness to become disturbed.
>
> Get something else to massage your ego, join the revolution. Linux is about
> freedom, an escape from tyrany.
>
> Suffer the little children to come unto me, and forbid them not, for such is
> the new kingdom.
>
> mg
Easy Flicker,
Let's look at this from another direction. First the issues you raise about a
lack of interoperability amoung the distributions and backwards
compatibility/dependency problems are valid and frustrating. The challenge is to
determine how to eliminate as much of the problems as possible without squelching
the benefitial competition amoung the distributions. The issue may be something
that needs to be dealt with on a release and/or version basis - and thus
standards are required.
A great example of the backwards compatibility/dependency problem issue is the
LM7.2 - LM8.0 transition. The release of many new-upgraded core components in
8.0, including X, rpm, reiserf, to name a few presented new challenges. The
question is how to anticipate and convey known release compatibility/dependency
problems to users before the new release is -- well released. Many of the issues
cannot be anticipated until the new version receives a litmus test by a broad
range of users. To some extent these issues will always be present. I think as
much advance warning about what is known about compatibility/dependency issues
being made available before the configure/make/make install or rpm -Uvh happens
will lessen squawks to the list.
Second issue, software incompatibility amoung distributions. On this list,
several months ago there was a discussion about defining what "core components"
or "packages" of a Linux distribution are and trying to set a "standard" that
could be agreed upon between the distributions and relied upon by people
developing for Linux open source. Last I recall, the discussion stale mated due
to the vast difference in what packages get installed depending upon whether a
workstation, server, custom or expert installation was selected by default. A
second hurdle (not impossibility) to get over would be coordinating amoung the
distributions to get agreement for a uniform release or identification of just
exactly which standard Linux was being released at any given time.
My suggestion would be to define what, say a "Linux2001-1" standard would be.
This would be a standard of core compatible packages that all distributions could
agree would be the core set of a release for a given period of time until the
"Linux2001-2" standard had been approved by "some body politic" yet to be
established. The standard should be broad enough to eliminate a majority of
present incompatibilities. The individual distros would be free to tack on
whatever else they felt like including without affecting the uniformity of the
core distribution.
So if a standard core for Linux is the solution, What are the core packages?
Kernel - sure. Windows managers - sure, Networking - (getting grey), but sure.
Hardware support - should be sure. (A release deadline for inclusion might force
manufactures get their Linux support done (or actually do Linux support) or miss
out on a growing market) I know I don't know enough about Linux to answer the
question about what is and what isn't the standard core for Linux.
Will this work? -- I have no idea. It's simply one approach to addressing the
cross distribution incompatibility issue you raised and a suggestion for a
"standard" to prevent further fragmentation of what Linux is. There are probably
a number of different approaches to this problem that would be better and more
workable that what I have suggested. This is only my suggestion. Let's see what
everyone else has to say on the issue -- and perhaps -- just perhaps, we may
blindly stumble onto a workable set of "standards" that eliminates these issues
and, in doing so, makes Linux a better OS for us all.
Sorry I ruffled you feathers. Lively civil discourse is a good thing.
--
David C. Rankin, J.D., P.E.
ASEL -- Instrument
Nacogdoches, Texas
N31 34.7 W094 42.6
355 MSL
