Re: LSB on /.
On Wed, 9 May 2001, Dave Greene wrote:
> "Let's face it, RPM is far from ideal. It has flaws. Different Linux
> distributions implement different features in RPM that essentially, from
> the ISV perspective mean that to support just the commerncial Linux
> distributions requires the same effort as supporting 5 or 6 different Unix
> implementations. The cost and overhead of this is not worth it to many
> large software houses. In other words - we all lose out!
>
> The LSB had to start somewhere. We recognise that we are not going to
> convert all the RPM based Linux distributions to deb. Not yet that is, and
> probably not at any time soon. "
>
> As stated by John H. Terpstra. However, if it's not worth doing right in
> the first place, why bother? Not to insult RPM itself (I personally don't
> like it, but that's my opinion), but, why rush the LSB out the door if
> it's not ready? Other then trying to hurry the LSB out the door at a
> previous point (at this juncture in the road, I believe the debate is
> mute, and I am not trying to start it up, nor continue it), wouldn't it
> have been better to define a new set of API's, and then someone else could
> build it? As it is, I don't see that distributions will be able to
> implement the LSB as it runs out the door.
Dave, at no point did I infer that the LSB Spec is not being done right. I
fully support it. I support the decisions made to recommend RPM for
commercial software developers who want to build and package their
software for use on commercial Linux distributions.
Your points above do beg the question though, "What do you expect the LSB
Specification to achieve?"
As it stands, the LSB is a means to an end. The objective we have is to
allow commercial software houses to build portable binary only packages of
their software for Intel systems running Linux. The secondary purpose of
the LSB Spec is that system adminsitrators will get a more consistent
environment to manage.
> And, I believe that slackware prefers to be uniquie in it's own way.
And no-one criticises Slackware for being who they are. How many
commercial software developers are porting their software to Slackware
though? Why are there not more?
This in no way undermines Slackware though. Slackware has it's followers
and always will - so long as they satisfy the needs of their target
market.
> Personally, after reading some of the Rationales, such as the Further
> Rationale item 1. which states:
>
> "1. We need to develop a single model Linux system. One that can be
> adopted by the various distributions with little difficulty. This is the
> single greatest goal that we must achieve. Anything which interferes with
> this goal should automatically be eliminated."
>
> It sounds more like "Resistence is futile, you will be assimilated". As
> far as I was aware, and the great thing about Linux, is it's diversity
> (though, that has gotten abit out of hand here and there). In Item 4, it's
> stated not to dictate what linux can do now, and let linux go where it
> goes, except some of that will be stiffled by say a new distro xyz (lets
> say I made it) that has implementation of a new thing, but also wants to
> be LSB compliant, it's either install backwards compatability in one form
> or another, or abandon it. Yes, the option to have 2 "items" (I'm using
> items because I have no current examples at the moment) reside together is
> always there and possible, But if 1 system is far superior to another,
> then why even bother with the inferior one. This would be a possible case
> of the LSB not updating fast enough, but, in the public eye, does it
> really matter if xyz distro is not at fault, and has something superior.
>
> These are all just my opinion, and maybe I missed something here, or
> failed to read into something far enough, all comments to me personally
> are welcome, however, as I have seen things unfold from my seat, it seems
> as if the LSB is following the Microsoft legend, in some cases they have
> had good ideas, but with poor implementation, or gestapo like tactics to
> force something that could have possibly been good on it's own merit (no
> examples here, if you have any, I'm interested).
>
> I think the LSB is a great idea, but can be stiffling to some distro's
> (did I mention I use slackware?). One of the things I'm actually curious
> about though, is an example of pre-compiled software that was not
> installable and/or runnable from one distro to another, as in my travels,
> using mostly source, I have not had this problem, nor encountered it
> anywhere.
The issue, just for clarity, is that the LSB Spec is NOT intended to limit
creativity, not to squash innovation, it is intended for commercial Linux
distributions so that they can host commercial binary only software.
I have seen very few problems with source code software packages.
Commercial software vendors will not distribute their code though.
Every major software vendor that has ported to one distribution has had
difficulty running on another. The main problem areas have been in
differences in glibc, kernel configuration, the curses library, add-on
libraries that have differing access pathes, and so on.
Not every system administrator or OEM or VAR has the skills you and I
consider "normal" though. Most of these folks that I have met do not want
to "hack" at a system to get it to work, instead they want to be able to
install needed software and just simply have it work. This does require
standards. Commercial Linux distributions welcome these standards.
I, for one, want to see radical Linux implementations, I delight in
incremental divergence, BUT NOT for commercial deployment. Commercial
users are far more conservative. They need kit-glove assurance that their
deployment platforms are stable and have long-term support.
If we want to see Linux in use as the standard for commercial and
organizational users then we need to have binary software that those users
want available or else the defacto choice will remain MS Windows. It's
simple really - if we want to win the war for the desktop we need to
software that users want. If we want commercial software that can be
deployed on Linux servers - then ditto, we need standards. The LSB Spec
meets this need. However, the LSB will continue to develop the LSB
Specification because we do want technical excellence.
Just my $0.02 worth.
- John H. Terpstra
Reply to: