5 ms·

The problem is mainly with bugs (often intentional) in the ACPI implementations of hardware vendors. While they almost always provide hacky windows drivers, the

by lucian1900 15y ago

The problem is mainly with bugs (often intentional) in the ACPI implementations of hardware vendors. While they almost always provide hacky windows drivers, they almost never provide linux patches, or even enough info for correct blacklists.

thedeuce 15y ago
The problem is when people often buy said hardware from companies that don't give a shit about <random desktop OS here>. Money talks, but mostly in large quantities.
eropple 15y ago
That's a problem of a failure to code to what is, not to what one thinks it should be. As I've said before when this comes up--Windows is, for better or for worse, the de facto standard. Alternative operating systems (and Linux is very, very alternative, in this sort of use scenario) that don't recognize and acknowledge the de facto standard's effective supplanting of the de jure standard are Doing It Wrong. edit: Swapped my jures and factoes. Shouldn't post while writing code...
- aristidb 15y ago
  Did you mean "de facto" when you wrote "de jure", and vice versa? Windows is the de facto standard, and ACPI is the de jure standard; you wrote the opposite.
  - eropple 15y ago
    Er, yes. My bad, was writing a unit test at the same time. ;)
chrisjsmith 15y ago
No the problem is that ACPI is a poor piece of design to abstract what is effectively a stinking great turd of an architecture. You just simply don't get these problems on non-x86 systems. (I speak from experience with MIPS, ARM and SPARC btw).
- wmf 15y ago
  On non-x86 you get different problems, such as the kernel needing special-case initialization code for every phone model ever made.
  - chrisjsmith 15y ago
    That's a fair point. The main problem with that is that most vendors want platform lock in so they implement their own verified loaders (if it's for a phone). If we had OpenBoot on ARM, things would rock.

5 ms·

The problem is mainly with bugs (often intentional) in the ACPI implementations of hardware vendors. While they almost always provide hacky windows drivers, the

by lucian1900 15y ago

thedeuce 15y ago
The problem is when people often buy said hardware from companies that don't give a shit about <random desktop OS here>. Money talks, but mostly in large quantities.
eropple 15y ago
That's a problem of a failure to code to what is, not to what one thinks it should be. As I've said before when this comes up--Windows is, for better or for worse, the de facto standard. Alternative operating systems (and Linux is very, very alternative, in this sort of use scenario) that don't recognize and acknowledge the de facto standard's effective supplanting of the de jure standard are Doing It Wrong. edit: Swapped my jures and factoes. Shouldn't post while writing code...
- aristidb 15y ago
  Did you mean "de facto" when you wrote "de jure", and vice versa? Windows is the de facto standard, and ACPI is the de jure standard; you wrote the opposite.
  - eropple 15y ago
    Er, yes. My bad, was writing a unit test at the same time. ;)
chrisjsmith 15y ago
No the problem is that ACPI is a poor piece of design to abstract what is effectively a stinking great turd of an architecture. You just simply don't get these problems on non-x86 systems. (I speak from experience with MIPS, ARM and SPARC btw).
- wmf 15y ago
  On non-x86 you get different problems, such as the kernel needing special-case initialization code for every phone model ever made.
  - chrisjsmith 15y ago
    That's a fair point. The main problem with that is that most vendors want platform lock in so they implement their own verified loaders (if it's for a phone). If we had OpenBoot on ARM, things would rock.