Lets Get Clear About the Mission and Goals of the LSB
Please read attachment below or visit
We must stay within our scope and not deviate into ramblings that are
not coordinated with our overall mission and therefore simply irrelevant
to our ongoing discussion. This is just a friendly reminder to stay on
* LSB Mission *
Here are a set of goals which are more specific than our overall mission
statement on the home page. They are a work in progress and should not
be considered official. We invite feedback; please send it to us at
* Goals *
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 Independent Software Vendor
(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
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 operating systems advance
both inside and outside the Linux arena. To provide a compelling reason
for the adoption of Linux and the LSB we should take advantage of new
ideas and technologies, including those aimed at different problems than
Linux has tackled in the past.
Test Criteria: Is there a component/feature/API which would provide a
clear improvement over the existing Linux environment?
4. Advance the development of applications 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?
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
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
within six to twelve months after the finalization of the LSB spec and
is redistributable via a GPL-like or BSD-like license.
The focus is on x86 but we want to minimize x86 dependencies and make it
feasible to write non-x86 annexes if things like constants and
structure layouts need to vary.
My reasonings for the selection criteria and my views on the goals are
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.
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
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. People 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,
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.