Re: LSB Commands and Utilities, Draft proposal
And lo, the chronicles report that Stuart Anderson spake thusly unto the masses:
>
> On Tue, 6 Jul 1999, Julie Haugh wrote:
>
> > As Linux becomes more mainstream (read: as companies start sending
> > money to Red Hat and other Linux distributors and hope to see something
> > they can use and sell to their customers ...) the need for a UNIX98
> > brandable version of Linux is going to grow.
> >
Why? For marketing? All too often I hear about how Linux must be/do this
or be/do that in order to gain acceptance. It must look and act more like
Windows; it must look and act more like Solaris; it must have UNIX98
compliancy, etc. The way I see it, Linux is Linux. If we define Linux by
some proprietary definition of UNIX (UNIX98 being controlled by the Open
Group, AFAIK) then we are moving the control of Linux outside of the
Open/Free Software community. The XFree86 project, unfortunately has no
choice but to accept TOG's definition of X, to remain compatable, but they
have had their own brush-ins with proprietary control of standards.
Linux will be certified UNIX98 if it is in someone's interest to do so.
If a company wants Linux to be UNIX98 then let them fund the effort and
the testing, but don't expect the maintainers of the GNU utilities or the
kernel developers to simply follow in lock-step with the Open Group. UNIX98
features should be adapted only when they are both feasible and desirable.
The motivation should not be corporate acceptance.
Linux is a conglomeration of POSIX, System V, BSD and GNU. I think that
makes it a unique combination worthy to be maintained in its own right. I
think that is what the LSB is for; I don't see the LSB as a transition to
UNIX98 and I don't think anyone else should. I see the LSB as providing the
same service as the UNIX98 standardization has for the "official" UNIX.
Again, if someone wants to undertake the Herculean effort of UNIX98
certification, then they are welcome to. But simply providing the necessary
changes to popular utilities (such as the util-linux package) may not be
enough: your changes must be accepted by the maintainers, unless you want
to fork development efforts. The LSB is supposed to be about defining the
de-facto standards primarily, not guiding the installed base along a different
path.
> > Should we view UNIX98 compliance as a long term objective or hope
> > that the large companies who are infusing cash into Red Hat and others
> > don't happen to notice that Linux is non-compliant?
>
> I agree that UNIX98 is where things should be heading. For the purposes of
> the LSB however, we can't just state that everything must comply with UNIX98
> or else we wouldn't have any compliant implementations. Fixing all of the
> differences will take some time. We can however define the LSB and being
> UNIX98 with a list of differences. This allows us to reference a large
> body of specifications and only document the differences.
>
I disagree here as well. Although I do think there should be a list of
differences where possible, this list should be in addition to the LSB
specification and should only be used for developers/sysops as a reference
to use while transitioning to Linux. This presents alot more work to the
LSB project, but in the end it will make LSB self-sufficient, again not
depending on specifications controlled by other organizations wherever possible.
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.
--
Aaron Gaudio
icy_manipulator @ mindless.com
http://www.rit.edu/~adg1653
--------------
"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
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.
Reply to: