Re: X and LSB
On 20 Mar 2000, Jochem Huhmann wrote:
> But I'm wondering why most admins consider mixing all distribution
> packages in /usr as very bad idea (hey, a nice idea for a slashdot
> poll ;-)
Personally I don't know of any admins that have a problem with this. I
certainly don't.
> In an ideal world I should be able to unmount /opt and mount another
> partition on /opt to switch from one distributed set of software
> ("distribution") to another without reinstalling the whole system.
Ever use SCO OpenServer? I guess not. Hint: they put _everything_ in
/opt. It doesn't work out well, as demonstrated by the mass exodus of
their users to Linux and BSD. I unfortunately have two very small
OpenServer 5.0.5 boxes in addtion to my "real" systems. It's a shame to
see nice HP Netserver boxes get wasted on that lame operating system, and
I have a secret plan to replace SCO with Linux, and run the app under
iBCS. But anyway, I diverge.
> I'm getting the impression that LSB does not mean "Linux Standard
> Base" but "Standard Base to ease the selling of CD sets and commercial
> applications". If LSB is just a thing between distributors and ISVs,
> it will be a standard for distributors and ISVs but not for Linux.
I think many people misinterpret the name "Linux Standard Base" to imply
that the LSB is seeking to define what is "Linux". The LSB simply seeks
to allow application vendors to make some safe assumptions as to what
libraries and resources a Linux system should have. It's not setting out
to define what applications are present, but what an application can
expect to find (in a runtime environment).
Again, I see many people arguing over what should be in a distribution
from an application perspective. They are mistaken. What the LSB is
about is defining what should be in a distribution from a library
(runtime) perspective.
As a hacker on a few small projects, I see a great need for this. I
personally couldn't care where Netscape resides on a system -- I care
about what libraries are going to be present, and what versions.
> The LSB has to say something about this and if it doesn't do that,
> pointing at the FHS-discussions is meaningless. Example: KDE is a
> large package but if a distributor decides KDE to be "part of the
> system" and install it in /usr instead of /opt the FHS doesn't help at
> all since it isn't additional software then. The FHS can say where the
> system and where additional software should go to, but the LSB has to
> say where the system ends and additional software begins. That's the
> point I'm trying to make.
Why? If kde-libs and gnome-libs are in the library search path, why do we
care _where_ they are? We're talking specifications, not implementations.
Note that IIRC neither KDE nor Gnome are going to be in LSB 1.0.
Jeffrey.
o-----------------------------------o
| Jeffrey Watts |
| watts@jayhawks.net o-------------------------------------------o
| Systems Programmer | "Anyone who says you can have a lot of |
| Network Systems Management | widely dispersed people hack away on a |
| Sprint Communications | complicated piece of code and avoid |
o----------------------------| total anarchy has never managed a |
| software project." |
| -- Andrew Tanenbaum |
| Regarding Linux - USENET, 1992 |
o-------------------------------------------o
Reply to: