LSB Commands and Utilities, Draft proposal

[Stuart Anderson]

On Tue, 6 Jul 1999, Aaron Gaudio wrote:

> 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.

I agree with this order of preference.

> 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.

It can't happen any more. X.org is now in charge of the standards and sample
implementation. TOG won't be able to try that again.

> Similarly, since LSB does not have an official representation (AFAIK) in
> the Open Group, relying on the Open Group to provide Linux standards is
> dangerous.

Metro Link, Inc. is a member of X.org, XFree86 is also on good terms with
X.org, so I see the LSB as having 2 channels now.

> 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.

Right. This is why I describe this as UNIX98 with some differences (and
omissions). STREAMS is in UNIX98, but it definitely is not in the LSB.

> 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.

There are copyright & Intellectual Property issues that prevent us from
wholesale copying of other standards. In some ways, it would be easier to
do it that way.

> 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.

If someone will step up to writing a complete, high quality specification for
it, then we can include it. At the moment, there are a lot of specification
that are either incomplete, or non-existant.

> 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.

The LSB does have a representative participating in the group that is working
on the successor to UNIX98.


                                Stuart

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
http://www.metrolink.com/