Re: X and LSB

[Daniel Quinlan <quinlan@transmeta.com>]

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

>> The goal of the LSB is to guarantee that third-party applications can
>> run on any LSB-compliant Linux distribution.  

> This is a major stance your taking, and I think you may regret it.  By
> saying the LSB is in place to service only ISVs and the like, the LSB will
> essentially be seen by the Linux community as "A orginization trying to
> impose standards so that commercial software vendors can exploit Linux.
> The LSB has no basis in defining standards for Linux, but rather is an
> orginization that serves as mediator between the Big 3 Distributions and
> commercial software vendors."

Third-parties is anyone that isn't the local sysadmin or a distribution.
That includes both commercial software vendors, independent developers,
etc.  That's anyone that packages software for use on more than one
distribution.  Yes, that includes commercial software vendors, but they
aren't our enemy.

We also have participation from a lot more than "the big 3"
distributions (whichever those are).  Debian (a non-commercial
non-profit distribution) is one of groups participating and large chunks
of the draft LSB standard are almost straight out of the Debian policy
manual.  We also have non-x86 based distributions as members, at the
last LSB meeting, etc.

>> Calling the inclusion of X "big and bloated" or talking about whether
>> or not a server is configured to include X is disingenuous.

> Well, that's something I can accept in consept, that it's just some core
> libraries.  But, it sort of makes the point meaningless, doesn't it?
> Require X libraries, but not any form of X itself? 

Nope.  You only need the X libraries to run the application.  Set the
display to run on some machine running an X server (an X terminal is a
good example) and the application will work.

> Well..  That's potentially short sighted as well.  In the evolution of
> software, continuing to hang on to legacy compliance will always decrease
> productivity, and increase bloat.
>
> If that was not the case, then there would be no issue when a new glibc
> came out... because it would encompass all of the old glibc.  But, that is
> not the case.  The fact remains, the libraries can co-exist, but do not
> (for good reason) always include identical and increased functionality
> of the older versions.

The library symbol versioning provided by glibc 2.1 helps alleviate the
potential for bloat.  It is not necessary to include entire copies of
libraries to provide backward-compatibility.  Are you aware of this
feature?

Dan