LSB Commands and Utilities, Draft proposal

Aaron Gaudio icy_manipulator at
Tue Jul 6 08:29:09 PDT 1999

And lo, the chronicles report that Stuart Anderson spake thusly unto the masses:
> On Tue, 6 Jul 1999, Aaron Gaudio wrote:
> > The XFree86 project, unfortunately has no choice but to accept TOG's
> > definition of X, to remain compatable, 
> This can also be viewed as they are fortunate enough to have a stable
> standard on which to build. The X Window System specification have been
> around for a long time before TOGs involvment.

I agree that any standard is better than no standard. But an open standard
(by which I mean, anyone can participate in its creation and maintanance
without spending lots of $$$ to join) is better than a non-open one. The
problem I was alluding to was the fact that TOG can effectively cut off
XFree86 by changing the standards and not providing a sample implementation
under a license at least as free as XFree86's own, which almost happened.
Similarly, since LSB does not have an official representation (AFAIK) in
the Open Group, relying on the Open Group to provide Linux standards is

> > I see the LSB as providing the same service as the UNIX98 standardization
> > has for the "official" UNIX.
> Yes, but there is one important difference. UNIX98 has had many many man years
> of effort put towards writing the specification. 

Agreed, and I wouldn't find fault with the LSB borrowing where possible and
feasible from the UNIX98 standard, however it can only reasonably do this
where the features borrowed are applicable today. For instance, the LSB
shouldn't include pax simply because it is part of UNIX98; it should include
pax if and when pax comes into wide usage in Linux distributions. There are
two types of standards: those which define and those which codify. I am
under the impression that the LSB was created to codify as much as possible
and define only when absolutely necessary. Technology which is driven by
defining standards becomes stagnant and obsolete (look as X itself, or 
PEX), whereas technology which is allowed to ebb and flow and is only pruned
and codified into a standard once it is proven tends to develop and evolve
much quicker (for example, HTML).

> > I should be able to read the LSB specification in its entirety without having
> > to obtain and refer to a copy of the UNIX98 specification.
> Refering to other standards is a matter of convenience and practicallity.
> Writing a complete specification will take years, by which time the window
> of opportunity will have passed. Referencing standards such as UNIX98 is
> necessary if we are going to have something against which implementations
> can be measured in a reasonable time frame.
> We are sensitive to the fact that Linux is not someone else's UNIX. We are
> documenting how it is done now, and not mandating that things be changed.
> At the same time, by looking at the differences, we are discovering some
> that can be eliminate by making small changes that won't adversly affect
> the way things currently work. For things that aren't implemented, then using
> UNIX98 again can be a convenience as the feature can be implemented to that
> spec instead of having to figure out what to implement from scratch.

I understand your concerns here and agree with you, with the following
caveat: that relying on references to UNIX98 (rather than simply borrowing
ideas or specifications and planting them into LSB) should be seen as
a necessary evil and be minimized as much as possible. As the LSB develops,
effort should be put into removing such references as part of the official
LSB specification and filling them in with actual specification. For instance,
it may be beneficial to rely on the UNIX98 specification for 'tar' (assuming
there is such a specification, this is all speaking hypothetically anyways)
for the time being, but it should be a goal to replace that with an actual
specification for the GNU (or whatever) version of tar.

The relationship between the LSB and UNIX98 should be one of roomates, not
spouses. Roomates live with one another because it is expedient to do so,
but they will eventually part and go their own ways when possible and 
desirable (perhaps catching up with one another every now and then), as should
the LSB and UNIX98, IMHO.


Aaron Gaudio
icy_manipulator @
"The fool finds ignorance all around him. The wise man finds ignorance within."
Use of any of my email addresses is subject to the terms found at By using any of my addresses, you
agree to be bound by the terms therein.

More information about the lsb-discuss mailing list