Bryan J. Smith wrote:
> On Sat, 2005-09-10 at 10:28 -0400, Edward Diener wrote:
>
>>I was thinking that somebody, given the error I reported on this post, might
>>know why it occurred. I understand that installers are not perfect but they
>>should give error messages that might tell one what went wrong.
>
>
> Sometimes they literally can't.
>
> Anything to do with storage is one area where there are _countless_
> variations, combinations and other details that are just too broad,
> compounding and other issues.
What I meant were two things.
First I received an error message box that told me nothing about what my problem
was. I am a programmer myself and find such error messages to be, almost always,
just lazy programming with little regard for the end user. The days when
something wrong happens in code and the error message is essentially "something
wrong happened" should have been over decades ago, so I find it pretty
disappointing it persists, especially in OS code because OS code is crucial.
Second, even with the vague error message I received I would think that some
CentOS developer might tell me what the possibilities are that generate this
message. Then it would be easier for me to find a workaround rather than having
to spend some time experimenting on installation options to get the OS
installed, and not even knowing if there was a way for me to succeed.
>
> Furthermore, it takes a _deep_ understanding of how 16-bit BIOS Int13h
> Disk Services work, and how disk geometry, disk numbering/ ordering/
> mapping, Linux device/ driver/ initrd and other things differ. It
> literally took me _years_ to come up to speed on those things, and I
> _still_ only know how to solve maybe 75% of all issues.
>
> And that's me, a human. An installer, no way.
Actually an installation program must know these things as far as I am
concerned. If the idea is "we have a great OS but our installer is not nearly as
good", how does one expect an OS to attract users if the installer can not even
install properly, or at least tell the end-user why it failed for the end-user's
particular hardware.
>
>
>>No it is an older Via chipset, the KT333 northbridge and the VT8233A
>>southbridge, using an AMD processor. The mobo is an Abit AT7. I have had this
>>machine run SimpleMEPIS and FC3. I was able to upgrade to the latest 3.3.1
>>version of SimpleMEPIS. I failed completely to get FC4 to install due to the
>>fact that my video adapter's ( Matrox 650 ) support using VESA went bad between
>>FC3 and FC4,
>
>
> I can't remember if I said so here, but even Alan Cox said he's not
> installing Fedora Core 4, and sticking with Fedora Core 3. But this is
> nothing new, some Red Hat Linux (now Fedora Core) releases are too new
> in their adoptions. But it was a little easier to know with Red Hat
> Linux (".0") -- although I've starting calling it the "reverse Star
> Trek."
>
> The even are bad, the odd are good. Funny that it's Kinda opposite of
> most kernel/project revisions.
From what I got investigating messages for FC4 installation black screens and
white screens, the failure to support various video cards which worked
flawlessly in FC3 was discovered soon after the FC4 release, and the reasons for
this failure were well-known ( buggy Gnu C++ 4.0 code ). So why not just fix it
and post an updated set of ISOs ? Not doing so just gives a release a bad name
from the start.
>
>
>>and now have experienced this problem with CentOS. It is disappointing
>>to see Linux get worse, rather than better, as new distros are
>>created in dealing with hardware.
>
>
> Installers are _not_ Linux.
> Installers are _not_ distros.
Installers are the first thing one sees when using an OS. If the installer fails
the user is not going to think much of the OS. If one is concerned on promoting
an OS, the installer needs to be first-rate.
>
> In fact, the main problem isn't Linux, but the increase in "superstore-
> designed hardware." And that means cheap, poorly tested, Windows
> version _specific_ drivers, and absolutely _no_ public specifications.
Do Linux developers study Windows drivers in order to create Linux device driver
code ? I can understand that the public specs can be bad and I can understand,
in an unfortunate way, that the hardware companies have been sold on the idea
that only Microsoft should be able to create software fot their hardware. In the
latter case I sympathize with Linux device driver developers. I would not mind
if an OS says that it can not support certain hardware in any way due to the
lack of information by the hardware vendor, but I did not find any such
information for CentOS ( or FC4 when I failed to install it ).
Thanks for your help and I am glad I got CentOS working.