Re: Submitted for your approval: White paper draft
On Tue, 4 Apr 2000, Nicholas Petreley wrote:
> The goal of Linux Standard Base (LSB) is to develop and promote
> standards that will increase compatibility among Linux offerings and
> enable software applications to run on any compliant Linux system.
It's absolutely necessary to add the term "vendor-neutral" here.
One could easily suggest that Linux ISVs already have had a "standard"
with which to work -- the Red Hat way of doing things. If LSB fails to
deliver -- and indeed what's happening by those who can't wait -- without
a mutually-agreed standard, ISVs (and many free-software developers too)
are simply targeting Red Hat and letting other distros figure out how to
cope with being Red Hat compatible.
In other words, the Linux world will eventually have a standard with LSB
or without it. What LSB is trying to do is develop one that's independent
of any specific distro packager.
> In addition, LSB will help coordinate efforts to recruit software
> vendors to port and write products for Linux.
Pardon? Since when is LSB taking a co-ordinating an ISV advocacy role? I
don't recall that being determnined, ever. It certainly wasn't part of the
original endorsement by LI.
It's enough for LSB to create the spec. There are plenty of other groups
that can flog it to the public once created.
> Customers need to be able to purchase the Linux distribution that best
> suits their needs without fear that their applications will have
> compatibility problems on that distribution. LSB assures a customer
> that their choice of application has been tested against LSB standards
> and should run properly on any LSB compliant distribution.
Might want a different term from "customers". The point has already been
made, and is quite valid, that the LSB is to benefit not only commercial
distributions and applications, but also open source ones as well.
Is someone who downloads an LSB-compliant distro and loads free-software
LSB-compliant apps onto it a "customer"?
> Developers and independent software vendors (ISV) alike need LSB
> because it is in their best interest to count on their applications to
> run on as many Linux platforms as possible. Developers reach the
> broadest possible audience without having to form political alliances
> with every possible Linux provider.
I'd avoid the term "political alliance" because it's not necessary.
I was recently involved in a development project that shipped (on the same
CD) separate RPMs for Red Hat and Caldera. No alliances with either vendor
were relevant
I'd change "form political alliances" to "create separate packages".
.
> The Linux Standard Base will include a written specification, a test
> suite to measure compliance, and a sample implementation of an
> LSB-compliant base distribution of Linux as a starting point for
> others to use if they wish. The sample implementation is also a
> useful development and testing tool for developers and ISVs.
> The goal of LSB is to assure cross-distribution and backward
> compatibility of Linux applications without impeding innovation in
> Linux. Shared libraries are at the root of many application
> compatibility issues, especially when libraries are not subjected to
> strict version control or when application writers don't know which
> version of a library to use.
I'd suggest that the problem isn't the library so much as the API inside
it. If FreeBSD achieves an LSB-compliant environment (totally possible) it
could do so maintaining the same API but not using glibc at all. So I'd
suggest that, in the big picture, LSB is specifying an API, not libraries.
A specific version of glibc will no doubt be the reference implementation
of that API, but it (glibc) is not the standard per-se.
Or is it?
> LSB recognizes that some LSB compliant Linux applications can and will
> be started when the Linux system boots. For this reason, LSB defines
> a standard procedure for the placement and contents of initialization
> files and scripts. This standard allows a database vendor to install
> the proper database initialization scripts with the assurance that
> other initial services upon which it may depend are already started.
> The standard also prevents things like circular dependencies, which
> would cause system initialization to go into a never-ending loop.
Is the intent to make an exact definition of what-goes-where, or to make a
consistent interface to apps installers for installing init scripts?
Remember the the FHS currently allows both Debian and Red Hat startup
script placements, which are somewhat different from each other.
> LSB compliant systems support the POSIX.1-1990 standard plus glibc
> extensions.
Every system that supports POSIX has extensions. "plus glibc extensions"
means nothing, and deals with the implementation rather than the spec
itself.
> Executable and Linking Format (ELF) is the de-facto standard
> executable object file format used with Linux. LSB reaffirms the use
> of this standard and tests for it. The ELF specification is available
> in pdf format at the URL
> http://www.linuxbase.org/spec/refspecs/elf.pdf.
Is merely specifying ELF enough? UnixWare, FreeBSD, SolarisX86, and
(Intel-based) Linux all use ELF, but aren't binary compatible. System call
numbers, error numbers, etc also need to be detailed to complete the spec
of the binary format.
> What isn't covered by the LSB is equally as important as what is
> covered. Linux customers, ISVs, developers and Linux distribution
> vendors will not only benefit by the standardization issues that the
> LSB addresses, but in some cases they reap even more benefits because
> there are things LSB specifically will not address.
This is clumsy. I think it's enough to say that LSB, like Linux, is
designed to minimize bloat, and to not standardize more than is necessary
to assist the deployment of applications. The LSB does not want to stifle
innovation and specialization, and recognizes the fine line between
standardization and stagnation.
I don't think it's useful to list what LSB does not do. That list would be
too long ;-). Down thr road some of this may be covered in a FAQ, but you
don't need to add it here.
Anyway, that's enough for now.
--
evan leibovitch <evan@starnix.com> starnix inc.
tollfree: 1-87-pro-linux brampton, ontario, canada
http://www.starnix.com professional linux services & products
Reply to: