[TriLUG] Fw: WinXP vs RH 7.2

Marc Johnson marc_johnson27591 at hotmail.com
Thu Nov 1 13:26:26 EST 2001


> > As for his woes installing RH7.2 ... been there, done that. I've had no 
>end
> > of crappy installs just like what he describes - frozen systems, CDs 
>that
> > won't boot, installations that dump core, you name it. Currently I'm in
> > love with my Mandrake 8.0 system. Why? Because it was an install that
> > worked the first time I tried it. Thought I'd died and gone to heaven.
>
>Wait a minute...you said earlier that you hadn't tried 7.2...

True; but I've experienced similar problems with other distributions though. 
This is just more of the same. I've given up on Red Hat because of these 
kinds of problems. This is not a new "feature".

> > I think the author's complaints were valid and well taken. In the case 
>of
> > RH7.2, he raises a couple of points that I harp on all the time (just 
>ask
> > anyone who knows me for the bloody bore I can be on the subject <g>) 
>about
> > software in general: IF YOU KNOW YOU HAVE A PROBLEM, DON'T APOLOGIZE,
> > ***FIX IT***, and THE INSTALLATION IS THE USER'S INTRODUCTION TO YOUR
> > PRODUCT. HAS NO ONE EVER TOLD YOU ABOUT 'FIRST IMPRESSIONS'?!
>
>What problem would you like fixed?  You make it seem like the Red Hat
>installer doesn't work at all.  If that's true, then I'm trying to figure 
>out
>how so many users got Red Hat Linux onto their systems.

It works on some systems, not on the columnist's. And, as the followup 
article points out, he's not running some obscure off-the-wall 
configuration, it's an off-the-shelf Dell system. I recall that in the 
original article he discovered that there were some known problems ... and 
my response is: then FIX them. If you know your software can't work with 
certain hardware configurations, either work around the problem, or come up 
with a more elegant and friendly solution than locking up or dumping core.

>If the problems you are talking about are related to faulty hardware, how
>would you propose to fix the problem via software?

If the defective hardware can be detected, then do so, and either work 
around the defect, or report, in clear language, exactly what the problem 
is.

The main problem, part of rant #2 of mine, is that installation software 
seems, across the board, to be an afterthought. A recent case in point: I 
downloaded and attempted to install JBuilder on my Linux system. The 
installation failed, with an error message that made it quite clear that I 
had somehow gotten a defective file, and maybe I should try doing a *binary* 
download next time; meanwhile, DON'T USE THIS FILE!!.

Turned out, after doing some digging around, that this was not the case at 
all (which I didn't believe anyway; I got this message after ungzipping and 
untarring the binary I had downloaded .. if the file was defective, I don't 
think I'd have gotten that far). It turns out that the file was attempting 
to uncompress the VM it contained, and couldn't find the uncompress utility 
... which is frequently NOT installed on Linux machines (Borland even says 
so on their web site where I found the description of this problem). 
Solution: make the uncompress utility available. I did, and it installed 
just fine after that.

But: this problem, according to the Borland web site, has existed for TWO 
major releases of the product. It is NOT rocket science to tell the 
difference between "I ran the command and it failed miserably; I think the 
file is defective" and "I ran the command and it failed because the command 
is not available". But did they fix it? Nooooooo.
When Red Hat, or any other vendor rolls out a distribution with similar 
vulnerabilities in its installer, that is inexcusable IMNSHO. If you know of 
a 'gotcha' that can f*ck up the installation, and you just let it slide, 
that makes the user wonder what the quality of the rest of the software is 
like.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp




More information about the TriLUG mailing list