begin Philipp Thomas's quote: | dep <dep@linuxandmain.com> [Wed, 30 Apr 2003 19:48:08 -0400]: | >okay, granted. and if the purpose of the exercise is assigning | > blame, the job is done. | | You seem to be skilled in alienating people, don't you? Why do you | think that aggressively pushing your point will make the discussion | any better? that is very much *not* my purpose. indeed, we have the same goal, making linux and in this case suse linux (which in my view is the best of the commercial distributions, which is why i run it), a pleasant experience, especially during installation, where many potential converts can be turned away (as witness OS/2, where problems in the installation of 2.0 and 3.0 could never be overcome, even though they were experienced by a minority of users and would-be users). the problem is that companies get very defensive, which is counter-productive. when an install goes bad, on a machine that was working just fine with something else, then "well, there's something wrong with your hardware" is simply not going to satisfy anybody. it's insulting and it's demonstrably wrong, in that the machine was working before. it leads to broader judgments of the company making the statement. the strongest true statement that can be made, especially in an evolving standard such as acpi, is "the way we do it and the way your motherboard does it are incompatible." | Quite frankly, no. It should stay on by default but with better | blacklists and whitelists to turn it (or at least parts) off/on | where needed. That's why | http://www.suse.de/en/private/products/suse_linux/i386/acpi.html | has this at the end: | | In order to be able to expand the blacklist (as well as the | whitelist) for the kernel, we need to know on which systems the | problems occur. Therefore, please send an e-mail message to | acpi@suse.de. Tell us which kernel parameter(s) worked on your | system. (Please include the output of the diagnosis tools | acpidmp and dmidecode in your message. These tools are available at | ftp.suse.com/pub/people/ak/diag.) but see, there are a couple of problems here. first, the failure modes are such that very few would guess that acpi is the culprit. second, even if it were correctly identified, getting online to do any of this is problematic, because among the victims is the network card. third, the people who it is hoped will be aided by a very simple install are also the ones least likely to be able to diagnose all of this, and the ones least able to find the above and to carry out what it says. there are a lot of clones in the world, and a lot of people who haven't the foggiest notion of what motherboard they have, and so on. in short, the above makes a lot of assumptions that i don't think are justified. the install process could be made much better by allowing some user intervention. it has been noted that there is "safe mode," which translates to "what will it cripple on my machine?" mode. that's because a whole big batch of stuff is disabled in one fell swoop. wouldn't it be better if "manual install" were the more traditional, actual, *manual* install, in which things can be turned off or on as per the user's actual hardware (for instance, an incompatible acpi does not mean that ide dma doesn't work), perhaps with advice, as one gets with enabling opengl support. a simple line which says that the implementation of acpi varies widely; if there is a problem with network cards and other peripherals, this should be switched off, which can be done [here] following the install? and the same thing for hardware detection? this would involve one additional screen, and maybe two pages of documentation. it would force nothing on the user; indeed, most users, who do not choose manual install, would never see it. but it would make the whole process much, much better for those who are victims of the associated "bugginess," no matter whose fault that bugginess is, and would leave users with the sense that the install procedure is well thought out and considerate. i cannot understand why this is thought a bad thing. | Like other things thought up inside Intel, ACPI is extremely | ambitious and so complicated (the kernel needs a complete | interpreter just for ACPI) that many failed to follow the rules | correctly. perhaps you are right. but perhaps, and based on my having followed development for awhile, linux acpi support is not entirely mature, even as the standard itself appears to be evolving. so, again, assigning blame seems to be both premature and, anyway, ultimately pointless if the object is being able to install and use suse linux on one's machine. the user is less concerned with why it doesn't work than with making it work. and the above will no doubt be cast off as a rant, which to me is simply a symptom of the problem. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.