X and LSB

[Robert W. Current]

Evan Leibovitch wrote:
> I think you're making way too large a leap from "third-party applications"
> to "commercial software vendors". A standard benefits anyone producing
> software that's intended to be installed without recompiling on every
> target system. Having a stable development target may make production less
> expensive for a software vendor, but it also significantly reduces the
> pain-in-the-ass factor for open source projects that want to concentrate
> their efforts on coding rather than packaging.

Yes.  Agreed.  I'm suggesting that the justification needs to be spelled
out so that this doesn't become a standard complaint.

> We now have an environment in which even RPM files aren't portable between
> rpm-using distributions. The need to work around this and other similar
> problems is a major resource-suck which is totally avoidable. And time not
> spent on making redundant packages is time spent making the software
> itself better.

Sure, that's building a "base."  A good thing.

> Will commercial software producers benefit from a well-accepted LSB
> definition? You betcha. But so will producers of free software. And the
> biggest winners would be the end user community who will have a much
> easier time of finding, installing and administering their apps.

Yes, absolutely true.
 
> > 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."
> 
> As someone who was there when the LSB was formed, I'd *really* like to
> know where the above definition comes from. The LSB was one vote short of
> unanimous consent when first presented by Bruce Perens to a board meeting
> of Linux International -- indeed, the one abstaining vote came from one of
> what you'd probably consider "the big three".

Depends on who you ask.  And, BTW, I put that in quotes because it's not
something I would say, it's something that has been said to be the the
biggest fear of the LSB back when the FM forum on it was going.

I remember who abstained quite well.  And, I remember it was because of
that abstention that the LSB got community support.  At that time, the
vendor in question was scaring the community by it's rapid growth, and
it was feared that if they threw their hat into the LSB ring, they would
push themselves as being the de facto standard.

If you think back to that time, there was another "big" distribution
lead by someone who flat out tried to blow the LSB out of the water
solely because he feared that the one "abstaining vote" was going to
have the only say in the matter.  I personally spent three days trying
to carefully compose emails to this person in order to convince him that
would not be the case.  I tried to explain that his involvement alone
would could serve to insure that would not be the case.  He was still
willing to be public about the fact that the LSB should never exist, it
was a sham, and it was never going to amount to anything other than
making one distribution the de facto standard.

I am bringing these issues up here not because I believe that the LSB is
fundamentally flawed, but because I feel that the LSB needs to think
back on how the community can view standards and deals among "for
profit" companies through shaded glasses.  It's important to have well
thought out answers for these situations before they are asked.  (Which
Evan is doing very well here.  I am going to play devils advocate when I
see this stuff happen, and I was hoping for the last two days to see a
solid response like the one Evan just sent ;-)
 
> > 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.
> 
> So much for the Debian involvement, I guess, or even the participation of
> folks like you and me. Maybe I've just heard one too many conspiracy
> theories for my own good, but this one makes no more sense to me than most
> of them. Look no further than the very top -- is Dan representing either a
> Linux distributor or ISV?

To continue to play out this discussion (which should be done, I'd like
to make it clear that this is outside the point of X layers or /usr/bin
bloat), Debian is one of the big distributions that primarily serves the
desktop market, commercial or not.  Debian does not serve the roll of
speaking for the smaller nitch Linux distributions.  And the smaller
nitch distributions should never be written off as "outside the norm"
because they are the ones responsible for the ability of the Linux
community to claim scalability, and broad functionality and diversity
that something like MS Windows can never deliver.
 
> The LSB will sink or swim based on the level of respect it achieves within
> the community -- but remember that this community now extends far beyond
> Linux's original developers. And, yes, even those nasty commercial
> developers are part of the community...

But remember as well that a great influx of Linux users moved to Linux
to get away from commercial products.  ;-)  User backlash is a worse
wrath than commercial reluctance.  Without a user base, commercial
interests will fade.
 
> Defining an environment in which a basic X programming interface is
> standardized but the X display itself isn't required, is a reasonable
> middle ground between too much and two little. It's totally conceivable
> that one may want an X app running on an LSB-compliant system which itself
> is running without an X server -- its display could even be a non-Linux
> system. Defining the X API gives the app writer a clear and stable target
> for a run-time platform, regardless where or on what the actual X display
> takes place. X itself defines that part of the standard well enough.
> 
> > Setting the LSB up as anything other than a basic standards orginization
> > for the Linux community itself will cause a huge fallout in support.
> 
> Perhaps, but I may disagree with your definition of the community. I
> believe that the community that is intended to be served by the LSB
> *can* accept its definition of a standard that includes the X API. Even
> people who don't use X apps can understand the benefit of having a
> standard base Linux GUI API. I mean, it's not like LSB is doing anything
> really fun such as mandating KDE or GNOME...

Outline a structure for KDE and Gnome to build on and spec with is an
issue Alan was discussing.  My suggestion is that X be laid out as a
sample implementation of how something can easily fit onto the base, and
how the LSB "base" itself works to make that easier and more standard
across the distributions.

And, some of the work on that has already been done ;-)  I'm just saying
move X onto the the top of a base layer.  This will provide a model for
checking a standard dependency (Is X there and functional?  LSB says it
should be in location X, and tests for it with the X test suite, so if
LSB says X is there, then I can count on it being there).

I have no doubt the community can benefit from LSB, but acceptance is
not nearly as guaranteed as the fact it may be beneficial.

> Maybe there's a significant number of people who will get themselves tied
> up in knots if LSB defines a bare minimum GUI programming interface. I
> just don't see it.
> 
> > No one wants to see the standards revolve around only the parties who
> > are making money off them (even if it is completely indirectly).
> 
> Let's not turn this into a class struggle. Commercial developers will
> certainly benefit from a useful standard, but so will non-commercial
> developers as well as end users.

I wish it was that easy.  My intent is to point out that to many, it
will be a matter of a class struggle.  Address that now, and it won't be
a problem.  But if the LSB defines it's usefulness in terms of ISVs, the
term ISV will imply "commercial" to many, and impose the class struggle
mentality.

So, yes, define it in terms of benefiting software providers.  Even drop
the term "third party" software providers.  Define it to clearly include
GNU, BSD, or completely commercial software providers.  Be careful of
the wording.  It will matter.
 
> The fact that something will benefit commercial interests is not in itself
> a valid reason to reject it. You haven't demonstrated any harm, only that
> you're wary of some of the benecficiaries. And that's not enough.

I don't think it should be rejected.  I am saying it should be defended
well if it is to be considered for a standard.  Obviously, I am starting
to find people ready to do that, and that's what I was looking for. 
That should be the case with everything the LSB standardizes.

The issue of moving X out of "the base" is different.  X isn't a basic
component of Linux, it is an incredibly useful piece of software that
can be used on a Linux system.  So, it should be treated as such.

> > I don't think I will accept the argument that "they" want it as a
> > reason for adapting it as a standard.
> 
> On its own, agreed. But you have yet to demonstrate the connection between
> "an X API should be in the LSB standard" and "LSB only serves the
> interests of large distros and commercial software vendors" -- let alone
> why such a connection has relevance to the quality of the standard that
> LSB produces. I'm neither an ISV nor distro maker (of any size), and I
> want the X API there. It just makes sense.

Many people want an X API there.  I don't deny that.  I never have.  I
am saying that an X API isn't a "base" issue, it's a standardization
issue.  But, in terms of how the fundamental structure of a system
should be built, X sits on a layer above the OS.  That makes a strong
case for outlining the structure of the standard to reflect X is a layer
above the OS itself.

By no means would I suggest X not be addressed in some way.  The goal of
the LSB is to address how software can have a logical structure to sit
on the OS, and how using this logical structure, it will be a little
easier for others to run their software on the OS.

X is an excellent case for defining how something should work on a Linux
system.  My point is that X isn't part of Linux, it's something that
works well in Linux.  There is a definite separation between something
that big that works in Linux, and something that should be considered a
standard base component of Linux.


Cheers to Evan, :-)  

Rob C.