RedHat

[Charles Steinkuehler]

Jason Clinton wrote:
> My two biggest problems with RedHat RPMS (and there are many) are that
> 
> 1. RedHat's update software never works correctly. If an RPM failed to 
> download in the midst of an upgrade I often found myself stranded or if 
> I had installed _anything_ of my own choosing (such as the latest 
> Mozilla) it broke all of their automagical utilities so that I could 
> never again use their update software. Further, never once in weeks of 
> trying was I able to get any of the included RPM graphical utilities to 
> work -- usually because the mirrors were down or had upgraded to the 
> latest and greatest RedHat and dropped support for my version.

I've never had problems with the RedHat update software, and in fact, I 
like it so much I pay them for privliged access to the update servers.

I'm just entering the RedHat desktop world, but I've been doing RH 
servers for years, and one of the things I actually *LIKE* is they stay 
a bit behind the curve with regards to the "latest and greatest".  I 
have only had RedHat automatic updates break things a couple times, and 
even then I can't fault RH that much:  The problem was when upgrading 
from PHP3.x to PHP4.x, when lots of system defaults and paths changed, 
breaking some pre-installed PHP3 code (note: the PHP code was stuff I 
installed, so the RH tools had no knowledge of it).  A few config tweaks 
to find the new perl DB libraries, and all was well again.

We'll see if I have more "dependency hell" or whatever you want to call 
it with the desktop system than I did with the servers, but so far 
everything is working as expected.  I've compiled and installed mplayer, 
and upgraded (then down-graded, then gone sideways, then finally 
upgraded again, switching between RedHat's "official" RPM, a patched 
version of 1.1.0, and the recently released 1.2.0 versions) rdesktop (an 
X client for 'doze terminal services).  All without issue.

> 2. If I wanted to install something of my own choosing (like qstat, a 
> Quake3 game browser) then I had to either find official RPMS (which 
> didn't exist) or install dependencies from tar.gz that overwrote 
> versions that other 'RedHat customized programs' depended on or replaced 
> RedHat's custom version of the library with something that wasn't 
> compatible thereby killing something as important as Kudzu.

:)  Half the time I simply remove the Kudzu RPM, since I don't want it 
doing any hardware checks/updates on my servers.  I do that manually if 
I add/remove cards.

> If I had a nickel for every time I tanked a RedHat system SIMPLY because 
> I wanted to install the latest version of software instead of waiting 
> for RedHat to get around to it in five or six months -- well, I'd start 
> a Linux business. That's what I'd do.

So where can we download your disto?

> This rant omits the following other problems that erk me: it's VERY 
> difficult to install a vanilla kernel due to the number of 
> 'optimizations' RedHat has made to their included kernel (if they're 
> that great, why aren't they in the vanilla kernel), RedHat's distro is 
> such a clunky behemoth that any newbie that has any incling to tinker 
> with it has to go buy a few $50 books (money and time I don't have) to 
> understand how it works, and last but not least, they've made it so 
> freaking user friendly that when it doesn't work the way it's supposed 
> to (Kudzu) it's damn near impossible to go and make the modification 
> yourself -- oh sure, you can make the changes to your conf files but you 
> wont be able to run any of the automatic stuff again!

Please.  I'm sorry, but to me you are simply whining because you don't 
know how to maintain a RedHat system.  RedHat is not Debian.  Redhat is 
not Gentoo.  RedHat is not Mandrake, or Suse, or even Caldera.  *EVERY* 
one of these disto's does things like low-level init scripts, hardware 
configuration, etc. a bit differently.  To RedHat's credit, most of the 
steps required to tweak their system are documented in the official 
Reference and Customization guides, if you care to read them.  Oh, and 
they're available online, if you don't want to spend the $30 from RH to 
get the dead-tree version:
http://www.redhat.com/docs/manuals/linux/

And you're just plain wrong about using a generic kernel.  I *HAD* to 
use a generic kernel to get my fancy new A7N8X with the 8xAGP NForce2 
chipset working with RH8.  I grabbed a generic 2.4.20 tarball from 
kernel.org, the latest 21-pre and ac patches, and setup a source tree. 
A make menuconfig followed by make dep bzImage modules install 
modules_install, and I was running a new kernel, complete with DMA 
support for my recent chipset.  I have also installed generic kernels on 
various RH7.x systems, and never had any problems.

-- 
Charles Steinkuehler
charles at steinkuehler.net