X and LSB

[Evan Leibovitch]

On Thu, 16 Mar 2000, Robert W. Current Jr. Ph.D. wrote:

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

Doubtful, since the goal as Dan stated it is *exactly* the mandate
I recall when the LSB began.

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

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.

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.

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.

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

I guess you could complain that LI, being a vendor-heavy organization, had
no right to give a mandate to LSB. But it's been my experience that the 
result has been a significant community good.

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

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

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

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.

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

-- 
evan leibovitch <evan at starnix.com>                            starnix inc.
tollfree: 1-87-pro-linux                         brampton, ontario, canada
http://www.starnix.com              professional linux services & products