Distro comparison

[invalid at pizzashack.org (Derek Martin)]

On Wed, Oct 22, 2003 at 08:51:35PM -0400, David Kramer wrote:
> On Wednesday 22 October 2003 11:09, josephc at etards.net wrote:
> > On Wed, 22 Oct 2003, Derek Martin wrote:
> > > I think David's issue (and mine, if I'm correct) is that if the system
> > > still works, you shouldn't ever have to install a new version of the
> > > OS.  In practice, this just doesn't work out.  Eventually, there comes
> > > a time when you need to upgrade some piece of software, and to do so
> > > would cause a cascading dependency nightmare.
> 
> No, that's not my problem.  My problem is that there is no technical
> reason for Red Hat 7.3 to be incompatible with KDE 3.1.*, yet
> neither Red Hat or KDE provide that upgrade path for political
> reasons.  

I think you're mis-attributing the reasoning there.  Red Hat doesn't
support upgrading KDE to 3.1 because that's not what comes with Red
Hat 7.3, and supporting two different releases of the same software on
one platform is a support nightmare.  They don't just do this with
KDE, they do it with EVERYTHING.  If you want a newer version of some
package than what they provide (excepting patch-level updates for bug
fixes, etc.), you'll generally have to install it yourself.  And you
can bet Red Hat won't support it.

As for KDE not supporting it, why would they?  It's not their role to
manage the upgrade paths of the OS vendors...

> I should be able to run my 7.3 system and upgrade whatever parts are
> still compatible with my kernel.  

Well, you still can.  Just remove all of the KDE packages, and remove
all of the supporting libraries, and re-install the new ones.  It IS
possible.  Enjoy...

> If there was an incompatibility due to a kernel change causing
> binary incompatibiliy, I fully expect to have to upgrade my OS.

In the real world, it just doesn't work that way.  When you are
talking about a monumental software package like KDE, which has many,
many other library dependencies, it is not practically feasible for an
OS company to provide that sort of upgrade path.  A few may do it
anyway, if their customers demand it of them...  But it's expensive,
and those companies tend to find themselves in financial difficulty.
One individual case of this will certainly not break the bank, but a
company who tries to do this consistently with say, KDE, Gnome, X,
etc. etc. will soon find they do not have the resources.  Where does
it stop?

By and large, for this reason, the Linux distributors don't support
multiple releases of a software package on any given release.

I think you're expecting way too much here.

> > I'm afraid you're thinking "Windows Terms" where software that requires
> > Win2K or XP just won't run on 3.1 or 95. With Linux and most other
> > Unixes, there is little if any software that requires RedHat 8 or later
> > (the exception being RPM's, but those can be easily recompiled).

I never got this message it seems, so I'll reply to this point here.

Practically speaking, this is simply false.  For example, the latest
releases of VLC Client (a DVD player software) and I think GNU Cash
will not compile on RH7 out of the box.  Even if I'm wrong about GNU
Cash, there are LOTS of programs out there which require much more
recent versions of supporting libraries than what comes with Red Hat
7.x.  Sure, it is technically possible, if you are willing to spend
the weeks worth of time identifying exactly which versions of what
libraries they require, and installing them all from sources, and
screwing up your package management system.  But it is FAR easier,
faster, and hence more practical to simply upgrade your OS.  And if
you're paying for support, the latter is your only option, since the
former will make your system unsupported and unsupportable by the
vendor.

> Not true for binaries.  Remember that up until recently a major version 
> change in Red Hat usually meant a change in the binary format, and 
> certainly meant a different set of gcc libraries.

And this is also an excellent point.
 
> > support out of the box. Source compatibility is hardly eve broken.
> 
> True, but when you try to use RPM's source compatibility is not enough.

Indeed.  Again, the main problem is not source compatibility, but the
presence (or not) of required support libraries of the correct
versions.  Installing/upgrading one or two or five may not be a
problem, but if it's fifty...

And there are other problems too.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.
Replying to it will result in undeliverable mail.
Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20031023/8f7ff259/attachment.sig>