[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RedHat Compatibility

Hash: SHA1

On Wed, 15 Aug 2001, Nick Phillips wrote:

> Excuse me, but you're talking bollocks. As far as most companies, most
> executives, and most people who we'd really prefer didn't matter (but iff
> we care about getting lots of people to use our system, do) are concerned,
> Linux == RedHat. As far as pragmatism (with which we should occasionally
> concern ourselves, but certainly not to the exclusion of idealism) is
> concerned, Standard Linux == RedHat.

That may be right; however, what I meant to say was that although I agree
that this can be a problem, his suggested solution was not the right
one. A standard is on its way, which will (hopefully) deal with this
problem (and all problems like this one that could arise in the
future). But adhering to the wobbling-ship-"standard" that RedHat is, is
not the way to solve it.
If you want to get yourself a lot of work and create a package
"libstdc++-rh" or something likewise, be my guest. Oh, and be complete --
there's lots of other libraries that've been written in C++ and linked
against this one. You'll have a lot of work porting them. But as I
said: if you think it's necessary, please do so.

> Sad, but true. You can't avoid it by not liking it and calling it evil
> (I'll not go overboard on the misuse of the word "evil", as I'm guessing
> that english isn't your first language).

It isn't, that's correct.

> Yes, it will be nice if and when LSB means that we can all be mutually
> binary-compatible. As you yourself said, that ain't now. In the meantime,
> being Redhat-compatible is the best way to make sure that proprietary
> linux software will work on your OS. When it has arrived, if Redhat is
> LSB-binary-compatible, then any other OS that is LSB-binary-compatible
> will automatically be RedHat-binary-compatible. Does that make LSB
> compliance "evil"? (you imply, no doubt unintentionally, that it does).

There's a difference between a well thought out standard that's
implemented in different distributions and a de facto standard that has
been invented and implemented in a seemingly ad-hoc way. RedHat can be
quite braindead sometimes. I should know, I've used it for three years
prior to using Debian.
(And yes, Debian can be braindead sometimes too, but that's a different

I don't feel like supporting all different kinds of libraries. Plus, if a
company provides only binaries of programs written in c++, it's that
company's fault. Not ours. Sad, but true.

> If, when the LSB is "out there", RedHat decide to be "not-quite-LSB-compliant",
> then people releasing proprietary software will ignore LSB, in all probability.
> They'd be fools not to, as that's how they get to sell to as much of their
> potential customer base as possible.
> Iff we care about enabling people to use as much proprietary software as
> possible,

Officially, we care about them, but not that much that we give up
everything else. Debian Social Contract, point 4:

"Our priorities are Our Users and Free Software".

If some library is being upgraded and no longer binary compatible with
older versions of the library, it's usually still possible with Debian to
install the older library so that you can run that library. There's a
difference between that and an ABI that changes with virtually every
compiler revision (OK, that's a bit exaggerated, but you get the idea)

> If you mean to say "I don't give a flying f*** about compatibility with
> RedHat because I don't care whether Debian gets used 'in the enterprise'
> or not", then say so. If you mean "I'd like to be RedHat-binary-compatible
> so that lots of people can get lots of use from Debian, but I'm only going
> to do it on my terms" then say so. If you mean "excuse me, but you're
> assuming that Debian cares about being usable with commercial software,
> and it doesn't" then say so...

I don't really care about the "Commercial viability" of any Free Software
product. In this particular case, if someone wants a RedHat library
installed, he can use alien, ftp, and install it. Most of the time, this
should work (albeit a bit uggly).

I'm just getting sick of all those posts saying "You need to do provide
this obscure little library, else 'the enterprise' won't be able to use
your Free Software program". Usually they're from someone that's used to
commercial support that promises things like "you'll be able to use this
program for whatever reason you want". Usually they can't keep up with it.
It's still possible to install this particular proprietary program on
Debian; you'll just need to do a bit more work, and not ask someone else
to do it for you.

> just don't slag someone off and say that
> they're doing some great evil for stating what, from their viewpoint, is
> perfectly sensible and correct. It's *rude*.

It's perfectly sensible to install that particular RedHat library on your
system if you need it. If you don't know how to do that, there are
companies providing help and support that should be able to help you out.

It's not perfectly sensible to ask any distribution to provide any random
collection of libraries so that any random proprietary program can run on
it. Especially not when compared to RedHat, but that's just IMHO ;-)

> > You could just as well require us to
> > be Windows binary compatible; after all, Most boxen in the world run
> > Windows, you know.
> Iff we care about enabling our users to run as much proprietary windows-based
> software as possible, then yes. Maybe we do, maybe we don't -- we do have
> Wine and DOSemu, after all.

So, those people that need to run Windows or DOS software from Debian are
able to do so. Great. Still, Debian isn't Windows binary compatible. See?


Anyhow. I hope you get my point; this'll be my last post on the issue.

BTW: apologies to anyone who thinks RH is great; it probably serves its
purpose somewhere to someone, but it didn't do that to me.

- -- 
wouter dot verhelst at advalvas dot be

"Human knowledge belongs to the world"
  -- from the movie "Antitrust"
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.75-6


Reply to: