[nSLUG] (2) Bloat & Notice of Upgrades

Donald Teed dteed at artistic.ca
Thu Sep 9 12:35:34 ADT 2004


On Thu, 9 Sep 2004, David Potter wrote:

> Thanks everyone... I'm a little surprised that while it was mentioned a 
> couple of times, SuSe really didn't get as much airplay as I expected... and 
> Fedora didn't get trashed... ;-)

I don't think we have many Suse users around.  Personally I don't
like a distro that has only commercial support and no user community
on the web (at least no English ones that I could find).

As for Redhat/Fedora getting trashed, consider it pre-trashed.

I added a token reminder of how beta the community version
of Redhat's stuff is.  If they shipped RH 8 with a mod perl
that couldn't print "Hello World", and it is obvious
on the mod perl web site that it shouldn't be used with
Apache 2, it is a hint of how little QA went into the distro.
This was never fixed in a RH update.  My attempts to
compile in my own perl, mod perl and Apache in
the weird RH environment were a disaster. I used Debian
for that project instead.  My brief experience
with RH9 has been thankfully bloated out of my mind but
I recall something just as busted as this happened there.

Redhat tells Fedora users to expect to be beta testers
(they don't use that term, but everything they say describes
this situation).

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.

I think many of us will prefer to work with what we know well.
I've seen this with some Slackware users, and I liken it
to small engine repair.  They like something that is
possible to know where every thing is and what each file
does, and they can tweak it in seconds.  They get
very comfortable with that environment and anything
else seems strange and almost "wrong".

There are advantages to working with the distro you know
really well, but it shouldn't be done at the cost of not
suiting the purpose well.  The other option is to bite
the bullet, evaluate other distros and learn another flavour well.

> One of the things I liked about Redhat was the 'timely' notice of security 
> upgrades and the relatively easy upgrade path using (what was then) up2date.

In theory, all of the distros discussed have this.

> One of the other things I'm curious about is my ability to restrict 'up-grade 
> bloat' I still haven't determined for sure whether Fedora is adding a bunch 
> of extra packages when I do an 'upgrade' from a previous install. In earlier 
> days RedHat always wanted to try and install sendmail, for example.

I'd expect the same as usual.  One of the nice things about Gentoo
is the ability to select every little thing (except perhaps python
and the C compiler) during the install.  You get to chose one of
several system logging daemons, cron daemon, mail server, imap
server, file system types, etc.  I don't think this is any more
time consuming that drilling through the huge default package
lists from Redhat and others.

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.

> So far my investigations of Fedora have me still agreeing with Jeff and 
> others in 'the devil you know' theory.

I have not heard any more detail on the type of
business environment and how tolerant it is of downtime.
With no response on that angle, I assume this isn't important.

--Donald


!DSPAM:41407849120281522397243!




More information about the nSLUG mailing list