I thought when they return to the "future", men in blue outfits were rebuilding the world. Just before the present catches up, they zip into a rift to work on the next future.
UPDATE: I am mixing this up with a similar new twilight zone episode.
Electrical Engineer doing embedded programming since 1976.
I thought when they return to the "future", men in blue outfits were rebuilding the world. Just before the present catches up, they zip into a rift to work on the next future.
UPDATE: I am mixing this up with a similar new twilight zone episode.
Could this be another monopoly violation? According to a recent Bill Gates memo uncovered from http://antitrust.slated.org/
Most of the problems with installing Linux has to do with APCI in the BIOS. Windows always works, why does Linux not? Microsoft is at the heart of the problem. While I was trying to install Linux Mint on my new Compaq Presario F700, I traced some of my problems to the BIOS, nothing new here. But I finally found a concise, technical explanation of why! This web page: HOWTO Fix Common ACPI Problems says:
"The ACPI Specification defines the requirements for the DSDT (and everything else, for that matter) pretty explicitly. Intel's ASL compiler, iasl, used to compile the DSDT to AML from ASL, will throw errors and warnings if the underlying ASL is buggy. Unfortunately, Microsoft's ASL compiler allows many of these errors and warnings to sneak by. As a result, many OEMs write buggy DSDTs, and it turns out that Windows is very forgiving of bugs in the DSDT that get by Microsoft's compiler (not surprisingly).
What this means is that a DSDT that does not conform to the ACPI specification will work under Windows, even though it shouldn't. However, when you try to use it in Linux, where the ACPI developers expect that the DSDT is written to comply with the standard (and the Intel ASL compiler), the buggy sections of the DSDT are unsupported. If you have a buggy DSDT, ACPI may not be aware that certain devices exist. Or, if it is aware, it may not support all of their capabilities. If you have either of these symptoms (missing or incompletely supported functionality in /proc/acpi), then the cause may be a buggy DSDT."
I am wondering if this is not a symptom of a common computer problem that I have seen. With only one implementation in use, two bugs can cancel each other out. OEM's need to stop using M$ complier and start using Intel's, and make M$ fix windows."