Re: X and LSB

["Robert W. Current Jr. Ph.D." <current@hel-inc.com>]

On 16 Mar 2000, Daniel Quinlan wrote:

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

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

I am not trying to flame here.  And I am definately not going to tell you
where to guide the LSB if it's already been decided that only ISVs with
deep pockets and Linux distributions with the highest sales figures will
be calling the shots.

Setting the LSB up as anything other than a basic standards orginization
for the Linux community itself will cause a huge fallout in support.  No
one wants to see the standards revolve around only the parties who are
making money off them (even if it is completely indirectly).

So... I don't know, that's just plain scary to me.


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

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?  

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

I never have argued the work that has been done.  I feel it's been done
fairly well.  But, how far down the road are you looking at this project?
By not seperating things into managable hunks, if one of the few people
who know the inside scoop drops out, there will be almost no one in the
community able or willing to step up and take on the job.

> In addition, we are not targetting ultra-small embedded systems or
> special cases.

Yes, you are targeting "special cases."  Specifically, commercial ISVs and
the biggest of the big Linux distributions.  You just made that point
yourself.

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

I totally agree with this.  Although I know my last letter was written in
haste, I understand that it's the "functionality" that the LSB defines,
not the actual kernel version number, nor any app version number.

This is exactly why the "test suite" is a brillant idea, and I fully
support it.

My point was, that since it's LSB version level compliance that your
after, the issue isn't complicated by changing libraries or kernels.  And
therefore, the arguement that "levels" are too much added complexity
because of constantly moving versions is muted.

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

As it should be.  Idenitfying compliance based on what the specs of todays
standard hardware and useage of Linux is (in anyones opinion) is the type
of short sighted thinking I am objecting to.

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

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.

For this reason, it would make much more sence to say that LSB v. 2.0 does
NOT imply that the system is LSB v. 1.0 compliant.  This would allow for
evolution.  And, there is no reason why a distribution can't just say "We
have included everything nessessary to run software that requires LSB v.
1.0 and LSB v. 2.0"

If you don't allow a new version of LSB to be free from the requirements
of the old version, as you get to version 5 or 6 you will find that your
unnessessarly bloated with outdated standards, and may actually find
conflicts.  (What if FHS changes even minorly?  Then LSB v. 2 would have
to specify that the path include both the old location and the new
location for a file?  Which, would then violate FHS, not comply to it.)

You have to think these things through, and not just listen to what ISVs
and the big distributions want.  What they say they want is totally
diffrent in some cases from what they actually need.  They need a standard
they can work with.  The might say "we want X, we want backwards
compatability" etc... But it's the job of the LSB to apply the logic to
the issue of standardizing things, not to bend over for the people with 
deep pockets who are making unrealistic requests.

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

Again, I strongly disagree.  And, without provoking an argument, I would
very much like to see a specific list of who these software vendors and
distributions are that are asking this of the LSB.

I consider Samsung a contender in the Linux market, they have fingers in
places all over that would greatly benifit from a Linux standard.  I doubt
that they are demanding any such thing to help them market Yopy.  Is
Cobalt saying they need X for thier cube and Raq systems?

I don't think the Linux Router Project would ever be asking that any part
of X be included in a standard base set.  But, I could easily see where
they could accuse the LSB of being bloat to cater to commercial interests
like Cisco, who would like to prevent Linux from scaling them right out of
thier mindshare of the market.

The case for the community to rebel against a LSB that only wants to cater
to the commercial ISVs.  And there will be infighting if the LSB only
listens to the 3 or 4 distributions that sell a lot of "workstation"
disks.  I don't think anyone really wants to see that happen.  I sure
don't want to see it.  And therefore, I don't think I will accept the
argument that "they" want it as a reason for adapting it as a standard.