On Sun, 2005-09-11 at 13:40 -0400, Edward Diener wrote:
My thought does not involve having to know the exact sequence of events at any level when an error occurs but rather having that error recognized at the earliest possible time and propagating that error to the code which can put out an intelligent, even very technical if necessary, message to end-user. That message would then give the end-user at least a fighting chance of either understanding what went wrong, or reporting the message so that a developer of the install could explain it to the end-user.
You're thinking like an application/installer developer, not an OS/installer developer. They are _worlds_ of difference.
Remember why the OS exists, to provide a _standard_set_ of interfaces to applications. That means there are "known, standardized interfaces" when you install an application, or when an application is running.
When the OS installer itself is running, you have _no_ standardization in hardware. The OS _provides_ the standardization for the hardware. So until that OS is setup -- the installer can do little to provide why something failed.
I grant that OS code, especially in an installer, is almost certainly far more complicated than any application code. Still there are techniques for reporting errors from the point in which they are discovered. The modern way is exception handling, but even if one uses the older error code technique, the error should translate into a more narrow possibility thatn the vague and generalized message which I received.
Again, you're _still_ thinking like an application/installer developer. Monolithic kernel device drivers do _not_ have exception handling, they can_not_ call some "user-space system function" to throw an exception -- they throw far more "low-level" interrupts. There are no "rich exception handling features" for them to use.
Otherwise device drivers would be slow and bloated. We're talking the kernel program and OS itself -- not some selection of programs that can take advantage of the exception facilities of a pre-emptive OS. In other words, there is no "pre-emptive OS" for the OS itself. ;->
So the common way to "find out what's wrong" in a kernel is to run a _separate_ "host system" (be it a 2nd, physical system, or run the "target" as a virtual system on the "host").
Is there a Bugzilla data base for CentOS ? If so I sure do not see it anywhere off of the home page at http://www.centos.org/.
CentOS is a 100% 1:1 rebuild of Red Hat Enterprise Linux. File them at Red Hat. You do _not_ need to pay Red Hat one dime.
I agree with all you say above. My argument is not that any OS must install on my computer, or anyone elses computer, but that if it does not the end-user should be given a decent indication why not. Even though OS code is generally more complicated than application code I see no difference in its ability to give intelligent error messages, or even error message numbers which translate to an intelligent reason.
And I'm telling you it's impossible.
As someone who has built numerous embedded systems -- the "system-level" developer standpoint is 100% different than the "application-level" (or even library-level) developer standpoint. Again, in a nutshell, there is no "pre-emptive OS" to service the OS itself.
Which is why, in the embedded world, we use failsafe firmwares with a failsafe mode, a "host" platform for remote debugging, etc... In the commodity PC world -- if the OS/installer screws up, it's very, very difficult to get anything useable like application exception handling.
I was spoiled by FC3 which installed and worked nearly flawlessly on my machine.
Stick with Fedora Core 3. Alan Cox just came out the other day on how many issues have been introduced on Fedora Core 4 by various changes, and why he's staying with Fedora Core 3.
My History ...
I did _not_ upgrade to Red Hat Linux 5.0, waited for Red Hat Linux 5.2. I did _not_ upgrade to Red Hat Linux 6.0, waited for Red Hat Linux 6.1. I did _not_ upgrade to Red Hat Linux 7.0, waited for Red Hat Linux 7.2. I did _not_ upgrade to Red Hat Linux 8.0, waited for Red Hat Linux 9. I did _not_ upgrade to Fedora Core 2, waited for Fedora Core 3. I am _not_ upgrading to Fedora Core 4, waiting for Fedora Core 5.
You make a good point but it is annoying that what worked on a previous release could not even install on the next one. C'est la vie.
Because things changed _radically_. Anytime you do that, you introduce issues. But if Red Hat didn't adopt GLibC 2.0 (RHL5.0), GCC 2.96/3 (RHL7.0),
Frankly, I continue to blame this on Red Hat. I have point-by-point recommended why they need to go back to the revisioning so people _know_ when there is a ".0" release when there is a ".1+" revision.
Last year I covered this _in_depth_ (through Fedora Core 3): http://www.geocities.com/thebs413/RH-Distribution-FAQ-3.html
My question was a reply to your statement of "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." You seemed to be implying that poor Windows version _specific_ drivers was one of the reasons why Linux has trouble creating device drivers for hardware. So I asked the above as if to say that I find it hard to believe that Linux depends on disassembling Windows driver code in order to get at the internal hardware specs for a device.
Yes, that's _exactly_ it in many, many cases!
Furthermore, a lot of "superstore hardware" is now 99.9% software. And you can't grow those software subsystems overnight. There are major 3rd parties who sell software RAID, software modem, software audio, software MAC (network), etc... software that make a _killing_ because hardware vendors license it, and change a few things.
Eventually Linux creates replacement, unified subsystems, but it's not always easy to figure out how to get them to interface to the specific and endless variants of hardware out there. E.g., there might be literally 1,000 products with 1,000 _different_ Windows drivers, all from the same codebase (but slightly different), and if the _single_ Linux driver can support 300 of those variants, that's a "good driver."
Not to mention the fact that when a new piece of "superstore hardware" comes out, the Windows drivers have been written for it _prior_ to release. Linux drivers writers typically have to wait until the hardware is on the shelf before they can start. Hence the lag time.
This is _not_ going to get better. It's one of the falicies in the Linux world. Only sheer volume matters, and that's most server hardware (non-superstore) have good Linux drivers, because Linux is about 30+% of new server shipments from OEMs.
I do not doubt the difficulty but I have done some very difficult programming myself so I do not doubt the solution also.
Have you done kernel-level and device-driver development? It's not about "difficult programming." It's about system-level development.
E.g., have you written a boot-loader?
Thanks for pointing this out to me. Microsoft does have a very good record in supporting hardware devices,
Not Microsoft, but hardware vendors. Microsoft does _not_ write device drivers. If they did, Windows would have 1/100th the driver support of Linux.
and their install programs are very solid.
I completely _disagree_. Especially for those of us who _only_ supported Windows NT 3.5, 3.51 and 4.0 when Windows 95 and 98 were popular.
Hardware is developed for specific Windows releases. If you have hardware that is not supported by your Windows version, you can find all sorts of issues.
And the installer can get into a self-rebooting loop that it _never_ exits. With Linux installers, I have a known quantity that I can control. Windows installers are a _joke_.
If Linux is to compete against Windows
Linux does _not_ compete against Windows. Windows is a distribution avenue for Microsoft. Linux is an open solution for companies that want to avoid such.
it must take the same attitude
What attitude? Microsoft's attitude? That we (like Microsoft) expect vendor to write device drivers? If so, then there will be _few_ device drivers for Linux.
that it needs to be as good, or at least needs to be more informative when an error occurs.
You can't give a hardware detection error in an installer if the installer doesn't know how to detect the hardware. And the only way an installer knows what the heck a piece of hardware does is if there is a driver telling it so! It's a chicken-egg issue.
So no, that's not it at all. What Linux needs is vendors to create driver disks and include them with their products -- even if only for select Linux distributions (just RHEL/RHD and NLD will do). But they won't. That's the problem.
It has *0* to do with the installer.
E.g., the installer doesn't know what to do with an unsupported storage device. There is _no_ reference information on what type of storage device it is. It can't tell you, "this is brand X model Y" other than what the PCI ID or other strings tell it -- hence the problem.
I am now on CentOS 4.1 so I will leave bleeding edge Fedora behind. I did not appreciate the Fedora 4 answers I got when I brought up the video card problem on their forums so I will go for greater stability instead.
It's probably because of your poor assumptions like above. No offense, but that's probably it.
I never wanted to be bleeding edge but Fedora 3 worked so easily I thought that Fedora 4 would easy to setup and use. I was wrong about that.
Fedora Core 2 was "bleeding edge." Fedora Core 3 was an evolutionary revision after Fedora Core 2.
Fedora Core 4 is "bleeding edge." Fedora Core 5 will be an evolutionary revision after Fedora Core 4.
The same was true prior, especially with Red Hat Linux. Everytime Red Hat changes things, it takes 1-2 revisions to get all the bugs worked out. Red Hat tends to "push the envelope."
In fact, Windows XP (NT5.1) is just an evolutionary revision from Windows 2000 (NT5.0), which was an evolutionary revision from Windows NT 4.0.
And Windows 98 (MSDOS7.1) was an evolutionary revision from Windows 95 (MSDOS7.0/7.1) which was an evolutionary revision from MS-DOS 6.x / Windows 3.x -- something Caldera proved in court, to complete technical emulation (removing MSDOS7.0 from Windows 95) against Microsoft (i.e., so Windows 95 was illegal product bundling of DOS/Windows into one).
You're assumptions are based on other assumptions that just aren't true.
Microsoft doesn't write drivers, and doesn't even develop much of the installer/upgrader. And Microsoft works with superstore vendors so anytime you upgrade just 1 -- applications, OS, PC or peripherals -- you are forced to upgrade _all_ of the other 3 if they are more than 2-3 years "out-of-date."
In Linux, once a "core/base" hardware driver is developed, it is perpetual for many, many products of the same "core/base". Although the superstore vendors regularly introduce new variants that differ slightly, so it's always an issue, and not all are supported (just the most popular/known).