begin Philipp Thomas's quote:
| dep [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.