[nSLUG] (2) Bloat & Notice of Upgrades

George White aa056 at chebucto.ns.ca
Fri Sep 17 22:23:26 ADT 2004


Quoting Peter Cordes <peter at cordes.ca>:

> On Thu, Sep 09, 2004 at 12:35:34PM -0300, Donald Teed wrote:
> > I don't care about hooting for my favorite distro.  I think
> > taking on a distro like one's favorite hockey team makes little
> > sense.  Pretty much any distro will have its strengths for
> > particular purposes, environments, and personal preferences.
> > Likewise I don't think one should "shoehorn in" their
> > personal favorite for a server in a commercial setting.
> 
>  That might be overly generous.  Doesn't it make more sense as an admin to
> know one distro very well, and so be able to make it do whatever you want?
> (That's the other extreme, and it's probably going too far in the other
> direction.  I'm just saying that the size of the niche for some distros is
> pretty small.)  If you pick the "wrong" distro, maybe you'd be reduced to
> compiling your own versions of things in /usr/local?  I don't have any
> experience with commercial support, so it seems to me that Debian and Gentoo
> are all anyone would ever need.  Except that Suse had an AMD64 port
> first...  Hmm, I'm starting to see your point that sometimes using another
> distro might make sense.  Still, I've been using Debian's not-yet-released
> AMD64 port instead of switching to Suse or something, and it's pretty good
> so far.

In many fields there are large systems that were developed in a particular
environment.  This means you either face the problems and uncertainties of
trying to get it working on your favorite distro or you get the distro
used by the developers.  The biggest headache in trying to use a different
distro is figuring out which version has compatible library versions.  Some
these packages are real monsters with many executables written in multiple
languages over a span of years, so even if you get the distro the authors
currently have, you find that you need libraries from previous releases to
get it running.

> > It used to piss me off to see hugh dev packages installed during
> > Redhat updates where it used to be merely the user libraries.
> > One cannot entirely escape some system bloat over
> > time.  I've noticed updated packages in Gentoo that have a few
> > new dependancies over time.  Like anywhere else, there is
> > more integration, more additional features, etc.  Often
> > it isn't a question of whether you need the feature, but that
> > the application will misbehave if one tried to utilize
> > something that had no underlying software support.
> 
>  Debian has the same "problem".  Newer versions of packages are often
> compiled with more optional features enabled, and so they depend on more
> libraries...  I've never seen upgrades pull in unneeded dev packages, and
> debfoster and/or aptitude do a good job of noticing when packages aren't
> needed anymore, and were only there to satisfy deps.

I find many bugs have fixes in the current sources but may not have been
backported to the distro your production machine is running, so you end
up installing the current version of some package in /usr/local, and then
fighting with configure on the next package you install.  Pretty soon I'm
going to have to run each package in a different virtual machine that has
been tweaked to match whatever the package developer actually uses.  


!DSPAM:414b8e1388948823980603!




More information about the nSLUG mailing list