LSB Commands and Utilities, Draft proposal
anderson at metrolink.com
Tue Jul 6 08:43:36 PDT 1999
On Tue, 6 Jul 1999, Frank LaMonica wrote:
> FL-> I think the differences do have to be resolved, and that is where
> we should be putting our efforts. ISV's don't want a list of
> differences, that want an assurance of similarity.
If all distributions have the same differences relative to a baseline, then
they are similar.
> > My experience as an ISV is that the largest existing market share has been
> > incompatible with itself each release. This just makes it a bunch of
> > smaller shares with a common name.
> FL-> I think we all agree that incompatibility has been an issue, but we
> can't "unrelease" distributions or versions that have been released in
> the past. Your statement is irrelevant regarding the past performance
> of any single distribution vendor, that doesn't alter the fact that it
> is still a big mistake to ignore existing market share. That just
> highlights the focus of where the work should be directed. The issue is
> the future; the LSB group must work with the Linux distribution vendors
> BEFORE they release their next version to try to move toward the goal of
> total compatibility. If there is a lack of cooperation, then the focus
> of the LSB's work should be to find out why and to gain the necessary
The future is our goal. We know that we can't go back and fix things that
have already been done. We have been working very closely with the
distributions for just this reason. We are now working on issues that will
affect the releases that will be coming out early next year (subject to each
vendors own schedules). I think that we have excellent cooperation among
many of the distributions.
> > If Linux is close to UNIX98 (I didn't say matches exactly) then ISVs will
> > find it easier to port their apps from other flavors of Unix.
> FL-> many apps are not coming from Unix, and those that are, are coming
> from specific "flavors" of Unix. I'm not disagreeing with your goal -
> conformance to a larger standard with the advantage of years of prior
> work is definitely worthwhile. My only point is the order and priority
> of the tasks.
In order for the LSB to be of any real value, we must be able to test what
it specifies, so that we can verify conformance/compliance. In order to
create tests to do this, a certain methodology has to be followed. Part of
this methodology is to draw assertions from some written specification and
code tests for each assertion. We have two choices for obtaining the written
specification, we either write it from scratch, or we adapt something that
exists. There aren't a lot of very complete written specifications for
things that make up Linux, so adapting an existing standard seems to be the
most efficient route. We have choosen UNIX98 as the base specification to
reference as it is very complete, and is the closest to what we would want
to write from scratch if we had the resources to do so. This is a very formal
process that is based on the processes of previous standards bodys.
Market share is not a part of this process. If it was, all of the Internet
standards would be controlled by Microsoft instead of the IETF.
We will use market share as a data point when we have to make a choice between
two proposed solutions, but we should not simply say "go do what the market
leader does". That is the Microsoft approach.
There are multiple threads at work in the LSB. Some of them are addressing
the various glaring incompatabilities that you are referencing, and others
are working on the groundwork for being able to prove compatability. These
are going on at the same time.
Stuart R. Anderson anderson at metrolink.com
Metro Link Incorporated South Carolina Office
4711 North Powerline Road 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.938.0283 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
More information about the lsb-discuss