Re: LSB on /.
I must say, that I am generally impressed at the lack of flames, but
rather explanation of everyone's positions.
On Wed, 9 May 2001, John H Terpstra wrote:
>
> 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?"
My expectation was for the LSB to define the minimum set of standards so
that software can be developed on a more cross-distribution level, as I
have read thru the specification some what, I've seen definitions for
functions and data types. IMHO would it not be better to build an LSB
tool that is an interface to what is already available, have developers
write for that interface? Now that I think about it, maybe that's not such
a great idea then.
>
> 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?
At this current time, I think that's half the problem. It's a matter of
perception. Why is it ported to a specific distro rather then to linux in
general? There has not been software that was written for say RedHat that
I could not run on slackware. Oracle, as an example, which
also"supports" certain distro's runs perfectly well on slackware. Which,
is why I asked for an example of software that did not run on one distro,
but ran on another. It may be that there is something being written
somewhere that is under development and does this.
>
> 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 see now that the main point is "commercial Linux distributions", and not
Linux in general (I must have missed that some where actually).
>
> I have seen very few problems with source code software packages.
> Commercial software vendors will not distribute their code though.
I'm guilty of using mostly source code software, as was probably observed,
Except for things like Oracle and WordPerfect.
>
> 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.
Actually, in my limited dealings with commercial software installs on
slackware that was ment for another distrobution (RedHat Oracle, Oracle in
General, CodeWarrior for SuSE, CodeWarrior for RedHat (honestly, I could
not tell the difference between the two at all, both worked fine on my
slackware box's), and a few others that seem only written for one distro,
but work fine on others), the main problems I've encountered is more of
hard coded binary locations of expected binaries, rather then just
executing them and hoping they are in the path, or just checking possible
locations in general, an example is having to create symbolic links for
binaries that Oracle needed.
>
> 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 should have read this paragraph before I wrote the comment above. To be
honest and frank, I wouldn't hire anyone who didn't have the skills I
consider "normal" to maintain a box, nor write software for one, unless
someone was on hand as a consultant to show them what was expected, or how
things should work.
> > 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.
Actually, personally I don't care about the desktop war so much, for me
it's all in the server. But, on the desktop front, most games work pretty
well on any distro, but I will admit, some do require a little work to get
it to work on any distro. What exactly do desktop users in an
organization need? An office suite (I can't stand Star Office, but it
should suffice, WordPerfect is rather nice, but probably doesn't do what
is needed for every one)? What else is needed? All I ever really see, is
just papers being shuffled around, maybe a Power Point presentation here
and there, but in general that's about it.
And, In general, Isn't there a support team that does installs on desktops
in most enterprise enviroments, rather then the user at the workstation? I
find maintainability is easier that way, plus one can ensure what is
actually on the workstations.
What I want to know, is where is my Visio replacement software for linux,
Dia is nice, but doesn't have everything people above me would like to
see.
Just my 2 cents added to your 2 cents, to my previous 2 cents, so, we now
have $0.06 worth of money, care to do lunch? :-)
>
> Just my $0.02 worth.
>
> - John H. Terpstra
>
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
>
Reply to: