On Sun, 2005-09-11 at 07:06 -0400, Edward Diener wrote:
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.
As both a programmer and (wanna-be ;-) kernel developer, debugging at the OS level is far more complex than end-user programs. In an OS installer, with all the variables, it's damn near impossible to figure out the exact sequence of events. So it's most likely you are getting an error code/message that seems rather useless, but it's the only "common denominator" the installer can come up with.
We're not talking an application installer on a known, good, usable OS that is already installed. We are talking the OS itself, which is far, far, far more involved -- because the entire system is _not_ yet in a usable state.
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.
Again, see my comment above. Bugzilla reports are the best means to find out more.
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.
Again, you're asking for the _impossible_ -- even on Windows. There is the terminology barrier, the plethora of combinations that could have caused the error, etc... Installer issues are almost _never_ understood until they are repeated and documented in a bugzilla report -- and since hardware is _always_ changing, it's a "moving target."
Which is why any "sane" professional recommends that end-users _always_ get their OS "pre-installed." By pre-installed I mean either OEM, by a LUG (with users more familiar with the installer in use), etc...
Because not even experts who wrote the installer itself and have extensive kernel development experience can always figure out the massive set of combinations that _could_ be thrown at an installer. Which is why many installer type issues (like the kernel 2.6 / buggy BIOS geometry / NT 255/63 head/sector issue) were _not_ discovered until _after_ the installer was released. Not everyone can test every single hardware combination out there.
Again, this is very, very, _very_different_ than installing an application. When installing an application, most everyone has the same set of libraries, binaries, etc..., or they can easily bring the system to that same state as everyone else. Again, remember the purpose of an OS -- to take radically different hardware and capabilities and present them for applications in a single set of common interfaces. So, again, don't compare OS installers to applications or even application installers.
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 ).
Again, is it _not_uncommon_ for Red Hat to use the "bleeding edge" code every 2-3 releases of their community release (Red Hat Linux, now Fedora core).
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.
Because who says one GNU C++ 4.0.x revision will fix them all? So then the Fedora team keeps spinning out revision of the installer and corresponding CD after revision after revision. Red Hat learned early on in Red Hat Linux that it cannot support respinning installers/CDs. In fact, I know of _no_ major vendor (including Microsoft) that respins new installers every few weeks -- only every 6-24 months.
Again, these releases are no different than the "bad name" releases of Red Hat Linux 5.0, Red Hat Linux 7.0, Fedora Core 2. Right now I've adopted the "reverse Star Trek" attitude on Fedora -- the even are bad, the odd are good. On the evens, Red Hat changes things in Fedora Core majorily (like old RHL ".0" releases). On the odds, Red Hat changes things minorly.
I'm looking forward to Fedora Core 5, just like I did Fedora Core 3.
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.
Impossible. See above commentary.
Do Linux developers study Windows drivers in order to create Linux device driver code ?
No offense, but are you really a developer? You're talking disassembly. You're talking machine code-level into assembler and "headache" level reverse engineering, and possible legal issues.
And lastly, you're talking about _software_ based hardware. You can't just "send codes X, Y and Z to a printer, scanner, etc..." but you have to build the entire _support_ code that the vendor probably licensed from a 3rd party before customizing. Sometimes Linux comes up with replacement "subsystems" for Windows equivalents, but getting them to work with proprietary hardware is a long, painful process.
But some do it. And it takes 6+ months. Which means half-way through the product lifecycle of a "superstore product" (~12 months), once the Linux driver is finally written (if at all), the "superstore vendor" has already introduced a replacement product for the next revision of Windows, or whatever "technology" is being pushed.
There are so many things here -- I can't even begin.
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.
The logic is 180 degrees. Microsoft does _not_ create software for their hardware. In fact, if Microsoft had to write their own drivers, Windows would have about 1/100th of the drivers available in the stock Linux kernel. Microsoft would _die_overnight_ if vendors stopped producing Windows drivers for their hardware.
In fact, the reason why people upgrade Windows/applications is because hardware vendors force them too, and vice-versa. It's the "superstore model" which is come over from the decade-long, MS-driven OEM model. Hence why Microsoft has a stake in Best Buy (which really began it in the late '90s).
Hardware vendors support Microsoft because that addresses 90% of consumers, nearly 100% of consumers who shop at the superstore. That's where their profit model is.
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.
Again, I think your issues have more to do with going with a "bleeding- edge" Fedora Core adoption, just like others who used to try the latest Red Hat Linux prior.