Re: X and LSB
On Sun, 19 Mar 2000 firstname.lastname@example.org wrote:
> The reality is that many Linux companies are trying to sell Linux
> boxes and Linux distributions into various corporate markets, and have
> been trying to make further inroads into the desktop market, which is
> currently dominated by Windows. The companies that are doing this
> definitely part of the Linux community, but of course they don't
> represent all of the Linux community. Still, I think a lot of people
> would agree that what they are trying to do is a Good Thing (tm).
> It's also a reality that in order to do this, it is important to get
> the support of independent software vendors (ISV's). They want to be
> able to provide binaries that work on "Linux". They don't want to
> test against N different possible distributions; they only want to
> test against one interface. So if we don't provide an LSB, then they
> will likely start shipping products based on the dominant
> distribution, which today is Red Hat.
So, if a distribution wants to be compatible with the majority of ISVs,
they simply make their systems RedHat compatible. We don't need the LSB to
enable vendors to implement a "follow the leader" (de facto) standard, and
indeed this is already happening. And it's not just happening in the realm
of commercial ISVs -- how many open source packages do you know of that
supply downloads of non-RedHat RPMs?
> Now, how important is this depends on how important you perceive the
> impact of commercial software to be. The fact is that today, there
> are certain products for which there are no good free software
> analogues. Oracle is one such example. Another good example is tax
> preparation software like TurboTax. And whether or not you believe
> that there will be good alternatives available in the future, many
> people are not satisfied with the free software available, and will
> want to use the commercial alternatives. (Personally, I will rather
> pay $19 bucks to get Turbotax rather than to spend my own time
> figuring out my taxes by hand, or pay for H&R block to do my taxes for
> me. So sue me for using commercial software.)
I think that concentrating on commercial vendors obscures the real issue.
*All* developers of software for Linux-based platforms, commercial and
open source, have an interest in a packaging/API standard. Think of all
the needless duplication of effort necessary to install or package
binaries for different platforms now.
Demand for open source developers and development resources is on the
increase. A packaging standard allows the elimination of redundant efforts
and allows developers to concentrate more on actually making the software.
Rob makes a valuable point that the LSB will need to be sold/marketed to
the community, and it's necessary not to describe it as an effort that
exists only to serve the needs of commercial vendors. If it cannot be
advanced as a benefit to *all* developers and users, LSB adoption may not
be as widespread as is necessary to make a standard worthwhile.
Will commercial ISVs flock to a Linux standard that's avoided by the open
source developers? Maybe, maybe not. Why take the chance when such a
controversy is totally avoidable? Create (and 'sell') the LSB as something
of value to everyone, and we stand a much better chance of getting it
> I know that there are a number of Slackware users who don't like the
> way most of the other Linux distributions have chosen to do things.
"The best thing about standards is that they give non-conformists
something not to conform to".
If one were in the Red Hat world, one would say the same about Debian, yet
the Debian folk are also very interested in having some common ground.
Community participation in the LSB is open, and if Patrick wants to get
involved I'm sure he wouldn't be turned away. That's his choice.
> Otherwise the ISV's will do the job for us, and simply chose one
> particular distribution, and it will almost certainly be Red Hat. If
> that happens, most other distributions will need to follow Red Hat,
> since not being able to run applications like Oracle will be a
> significant disadvantage in a large number of markets where many of
> these Linux distribution will be competing.
In honesty, this isn't as miserable an option as one might think.
Most distros now are already FHS compliant, and many of them already use
RPM. So two important (and widely, if not universally followed) components
of a standard are already in place.
It's not inconceivable that RPM-based distributions could offer a "Red Hat
compatibility" package that provides all the ISV-relevant facilities of a
specific Red Hat snapshot. As far as file placement goes, if the LSB isn't
going to make recommendations, then the existing FHS does all they need
All that's left is the API, and that can be easily defined by taking a
snapshot of certain libraries -- the way a distribution vendor such as Red
Hat does already. A developer could (I would suggest "should anyway") use
RPM's dependency-checking features to ensure that necessary pre-requisite
components, at the proper release levels, are installed.
My point is that the development of a defacto standard (everyone following
Red Hat's lead), is not really that painful from the developer's
viewpoint, and other distributions could cope with such a standard with
relatively little pain should they choose.
So let's not mince words. The LSB primarily is about control and
authority. The community as a whole wants to shape the evolution of Linux
and not leave the creation of its minimum standard in the hands of any one
sub-group (commercial or not). The members of the LSB represent a broader
cross-section of the community than Red Hat alone does, and believe that
it's in Linux's long-term interest to have its standards defined by an
open community effort.
I believe that this is a Very Good Thing -- which is why I have been
involved with the LSB from the beginning -- but it's not life or death so
far as developers are concerned. And it has little to do with specifically
pandering to the interests of commercial software vendors. They'll find
their way with or without us, so long as they see a market here.
evan leibovitch <email@example.com> starnix inc.
tollfree: 1-87-pro-linux brampton, ontario, canada
http://www.starnix.com professional linux services & products