X and LSB

[Daniel Quinlan <quinlan@transmeta.com>]

Robert W. Current Jr. Ph.D. <current@hel-inc.com> writes:

> Again, I say, X is not an essential part of Linux.  That in itself
> is the enough reason to say it should not be part of "a standard
> base."

A lot of stuff is not essential to run Linux.  That doesn't mean that
common applications won't need those things.

The goal of the LSB is to guarantee that third-party applications can
run on any LSB-compliant Linux distribution.  Since a large number of
third-party applications use X libraries, they need to be included.
We are continuing to survey applications to see what facilities are
being used, how often, and which could be practically excluded.  X is
not one of them.

The alternatives to putting X in LSB 1.0 are to put X in an optional
layer or to have applications ship with X libraries.  Both
alternatives were rejected by the distributions, software vendors, and
developers who have participated.  The people who will implement the
LSB don't want to have to worry about layers of the LSB.  It's enough
that we'll have to worry about future versions of the LSB (which will
only add features, not remove them).

This does not prevent people from shipping software without X.  You
don't have to use every feature in the LSB to have an LSB-compliant
application.

This does not mean you have to configure X on any machines, it does
not mean you have to include any X servers, applications,
documentation, or fonts.  We're talking about the core X libraries.
Calling the inclusion of X "big and bloated" or talking about whether
or not a server is configured to include X is disingenuous.

Also, including X in the specification does not add much work to the
spec.  Stuart has already pointed this out.

In addition, we are not targetting ultra-small embedded systems or
special cases.  We are targetting the common cases: servers, desktops,
workstations, etc.  (However, even small devices like thin clients and
notebooks still include X.)

> Again, this will have to be carefully addressed from the point of
> vocabulary, because "Level 2 compliance" will only be part of a
> moving target spec, that will likely also need to include "versions"
> as libs and kernels update.

The kernel is not defined by the LSB.  The goal is to have all of the
functionality used by LSB applications is presented through glibc or
another library, an application, etc.  That way, changes can happen in
the kernel without affecting LSB applications.

Another goal is to have LSB applications continue to run 5 or 10 years
from now.  That can't happen if the specification is a moving target.
Yes, there will be an LSB 2.0 and it will include more than LSB 1.0
did and LSB 2.0 applications won't run on LSB 1.0 systems, but LSB 1.0
applications *will* run on LSB 2.0 systems.

Philip Rackus <philipr@corel.com> writes:

> If everyone agrees that eventually the goal of the LSB is to define
> different level of standards, how much extra time would it take to define a
> base spec (without X) called ..say LSB 1.0, and the spec including X called
> LSB 1.1 ?  In this scenario 1.0 would basically be a subset of the 1.1 - so
> a distribution that is 1.1 certified would by default be 1.0 certified as
> well.
 
I think it's fair to say that it would talk us longer to finish if we
took that approach.

One final note: after we're done the LSB, we *could* issue a "micro-LSB"
standard which could drop X windows.  It's not a very high priority for
any software vendors or distributios, though.

Dan