begin Philipp Thomas's quote: | You're comparing apples with oranges. OpenGL in itself is standard | and software 3D (mesasoft) works flawlessly (albeit slow as | molasses). It's the *implementation*, more specifically the support | for *hardware acceleration* as implemented in the drivers that | sometimes leaves a lot to wish for. ah, yes, implementation. sort of like the implementation of acpi, no? | >there is an ohmygod message saying that this might not be a good | > idea. | | Experience tells us to do that, yes. experience suggests that you need to come up with a probe for acpi that meets the standard to which your module is written, leave it out by default, or -- horrors! -- let the user decide at install time, perhaps including some of the problems that can arise either way in the docs and/or on screen. | >but acpi, which is at least in a state of flux, and which the vast | >majority of users and would-be users know nothing about, | | google for ACPI and you'll be astonished what you find. same with sanskrit. means nothing. the problem is that the nature of acpi failures as exhibited in suse 8.2 is not the kind of thing that would lead anybody to google for acpi -- even if they could, which they can't, in that one of the symptoms is disabling the network card. | >and which the documentation describes only as a power management | > standard | | Ah yes, you'd call http://sdb.suse.de/en/sdb/html/81_acpi.html and | http://www.suse.de/en/private/products/suse_linux/i386/acpi.html no | documentation? no, i'd call them sawdust: "acpi=off -- This parameter disables the whole ACPI system. This may prove very useful, for example, if your computer does not support ACPI or if you think the ACPI implementation might cause some problems." seldom do so many words mean so little. what acpi=off means is obvious; the kind of thing that would cause a user to think it's a good idea is not, and here there is no help. and that's if you're *looking* for acpi, meaning that you have already solved the problem. what's needed is an entry in the database for "the goddammed network card that worked before 8.2 doesn't now," with the answer: "turn off acpi with the boot parameter acpi=off." | >thereby giving no clue that it can, say, fubar your network card, | >is enabled unless action is taken to disable it. | | It doesn't fubar your nic, the ACPI BIOS just doesn't assign | interrupts correctly -> broken BIOS implementation. or broken acpi implementation. i do not know and, frankly, i do not care. it was working. after suse 8.2 installation it was no longer working. and it would still not be working but for the fortuitous presence of another machine which didn't have suse 8.2 on it, and someone on this list more interested in solving the problem than in affixing blame. whose fault it is is an interesting subject of debate, but the fact is that somebody trying suse for the first time, having it disable some hardware, and finding out from tech support that it isn't a supported issue is not going to be interested in that discussion. that person will be going to a different distribution or back to windows, saying "suse sucks" or "linux sucks" respectively. | To me this all sounds as if you're on some kind of a holy crusade | and I'd ask you to please carry it somewhere else or discuss in a | sensible way. Thank you. and to me it sounds as if you're blowing smoke in the fashion of the old microsoft support joke the punchline of which was "incompatible mouse pad." if expecting a modern linux distribution to install and run on a common and modern machine with a minimum of fuss is a holy crusade, then i'm on one. if your position is that this cannot be expected and that if it doesn't come to pass it's everybody's fault except suse's, then i'd be very interested in knowing that, too. -- dep http://www.linuxandmain.com -- outside the box, barely within the envelope, and no animated paperclip anywhere.