[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

LSB Directions (very very long...was Re: Thread deficiencies



Alan Cox wrote:
> 
> > No question that POSIX.4 is heap of stinking shit.  The problem is that
> > it's a *standardized* heap of stinking shit, and application writers
> > want to be able to cleanly port their programs from other Unices to
> > Linux.
> 
> No argument. And thats why we should support it, and yes the libraries will
> have to do a chunk of gunge work to emulate the flaws in it.

Stop.

Is our goal in creating the LSB spec to determine the future direction
of Linux?

I realize that what we currently have isn't very clean, elegant or
optimal. But should we be dealing with such design issues at this point
in time for every item in the spec? Wouldn't that be better handled in
the linux-kernel mailing list or some other forum that deals with the
particular component in question?

It seems that we lack a well-defined selection criteria for what should
and shouldn't be in the spec as well what issues should and shouldn't be
dealt with. There are several goals that may be in conflict as well, and
we should prioritize them in order to create our selection criteria and
meet our goal of releasing the spec in a timely manner (eg, for the
LinuxExpo in February).

According to the LSB web site (http://www.linuxbase.org), our mission
statement reads:
"The goal of the Linux Standard Base (LSB) is to develop and promote a
set of standards that will increase compatibility among Linux
distributions and enable software applications to run on any compliant
Linux system. In addition, the LSB will help coordinate efforts to
recruit software vendors to port and write products for Linux.".

In reviewing the mission statement, I enumerated and am hereby
presenting a small list of goals I perceive being sought by the LSB,
their rationale, and the means of testing whether we are meeting that
goal or not (please edit and add additional goals as you see fit). I
reserved comments on the merits of these goals until later, but here are
the ones I noted:

1. Select the components/features/API of a model Linux system so
application developers know what the target system will include, what
the behavior will be, and how to package it so that it can be installed,
executed, and removed from the system.

Rationale: A single Linux model allows an ISV to know in advance how a
conforming linux system will behave to (a) minimize issues in porting
code from another platform, and (b) allow a package to perform the same
way regardless of the linux distribution.

Test Criteria: Are proposed components/features/API being selected? Are
proposed components/features/API being rejected?

2. Develop the documentation for the components/features/API of the LSB
as well as their respective behaviors.

Rationale: The LSB spec must be presented to distribution implementors
and ISVs in a format other than source code.

Test Criteria: Is each component/feature/API documented clearly,
completely and accurately?

3. Advance the state of the art in Linux by incorporating desired
components/features/APIs into the LSB spec.

Rationale: The world is a moving target, and we have competitors outside
the Linux arena. To provide a compelling reason for the adoption of
Linux we should take advantage of new ideas and technologies as well as
target new markets and industries.

Test Criteria: Is there a component/feature/API which would provide a
clear improvement over the existing Linux environment?

4. Advance the development of applicatons for Linux by providing
improved compatability with existing standards or platforms.

Rationale: By providing ISVs with an execution environment which is
compatible with an existing standard or platform we garner a greater
number of applications or software solutions, providing users with
greater incentive to adopt Linux and abandon their current platform.

Test Criteria: Are there existing standards or platforms and does the
model Linux system match their behavior?

Given these goals, and please add/modify goals as needed, I'd like to
suggest the following draft for the selection criteria for determining
what should be included into the LSB spec, in decreasing order of importance:

1. Whatever currently exists in the Linux world in source code form and
is redistributable via a GPL-like or BSD-like license.

2. Whatever is currently being actively developed in the Linux world
which will conform to another existing standard and be available in
source code form within six to twelve months after the finalization of
the LSB spec and is redistributable via a GPL-like or BSD-like license.

3. Whatever is currently being actively developed in the Linux world
which will advance the state of the art and be available in source code
form within six to twelve months after the finalization of the LSB spec
and is redistributable via a GPL-like or BSD-like license.

My reasonings for the selection criteria and my views on the goals are
as follows:

1. We need to develop a single model Linux system. One that can be
adopted by the various distributions with little difficulty. This is the
single greatest goal that we must achieve. Anything which interferes
with this goal should automatically be eliminated.

2. We have to work with what we have. While we may have the skills
necessary to develop the code to fulfill whatever wish list and
whiz-bang feature we might desire, we most certainly will not have the
extra time needed to do it in a timely manner after finalizing the spec.
Therefore we should restrict the list of components/features/APIs
considered for inclusion in the LSB spec to whatever we currently have.

3. We are not required to conform to any standard except our own. This
includes the POSIX stuff. Yes, it would be nice to meet any or all other
standards, but it isn't possible for LSB 1.0 to meet it at this time and
there's no sense in pretending that it will. ISVs are more concerned
with having multiple Linux distributions and the lack of a well-defined
standard than in the existence of yet-another *NIX-like platform for
which to target. We are not the standards body for POSIX. There is
already a group for that. We are the __Linux__ Standards Base
Organization. We are not a rubber-stamp for anyone else. If we meet
POSIX, terrific. If not, let's just accept it for now. Hopefully the
maintainers of the appropriate Linux portion will target POSIX in the future.

4. There's a lot of cool stuff that can be done to Linux. Let's leave it
to be done. Let's not dictate that now. We can't tell how Linux will
evolve over the next five years. Our job is to make a single Linux model
for ISVs to target NOW, not worry about how the new jaw-enabled joystick
will be supported. I came up with several really cool and excellent
ideas at the NY meeting that got shot down by the group for a very good
reason: THERE'S NO IMPLEMENTATION! No one else can see for themselves
how it would work out! If someone believes in their idea, they'll
implement it and let it face the scrutiny of the rest of the community.
The bazaar development model allows several similar projects to develop
simultaneously, competing for resources, ideas, attention, etc. based on
their merits. Some make it. Some don't. Let some dreamer show us the
possibilities. When he does we can either say, "Cool! We want that to be
standard.", or "Yawn...Next!"

5. We need to eliminate from the spec prospects those items that are
inferior to those of a like nature, or group their functions into a
minimum requirements spec for its package. For example, there are
multiple formats for distributing packages, multiple X window managers,
multiple shells, etc. While it isn't always beneficial to lock users
into a single system (eg, KDE vs. GNOME, or bash vs. csh), we should
specify the minimum requirements and capabilities of such a system so
that the interfaces and behavior are well-defined.

> > Independent Software Vendors, so sorry, unlike every other Unix system
> > on the planet, you have to use clone() and not the standardized POSIX
> > interfaces.  Now go away and stop bothering us?  The problem is, they
> > may do exactly that.
> 
> We need to standardise clone(). We don't need to standardise on clone() but
> not posix.4. Standardising clone "temporarily" as the IBM guy suggests is
> not sane. Clone is a real working API. If you want to use clone its there
> it works. If you want to use pthreads then clone is a piece of specification
> you don't care about. Removing it in future is the error.
> 
> > Do we say that we "almost but not quite" implement POSIX.4, and then
> > list all of the ways that we don't quite match the spec?  That won't
> > make us a lot of friends in the application developer world (who will
> > ask why can't we support all of POSIX.4), but it's at least honest.

Returning to this topic, let me say that given the current state of
affairs WRT to threads in Linux, we should standardize on clone(). If in
the future we have something better we can adopt it then and render
clone() obsolete. But for now, there is nothing as clearly defined. And
given that pthreads doesn't conform to POSIX.4 we should keep it out of
the spec lest we confuse those developers who would try to use it and
then have to discover by trial and error all the little anomalies
between Linux pthreads and POSIX.4 pthreads. It's better from a
psychological standpoint to have a completely different interface rather
than one almost alike.

Ciao!

Al Guerra


Reply to: