5 ms·

ACPI is standardized via a specification. It's quite easy for non windows operating systems to support ACPI. I can't say the same for device tree as that requir

ACPI is standardized via a specification. It's quite easy for non windows operating systems to support ACPI. I can't say the same for device tree as that requires reading Linux source.

turminal 3y ago
That specification is a monster. "quite easy to support" is not a good description of the situation.
- surajrmal 3y ago
  By comparison it is easier. The alternative is that you need to read even an order of magnitude more lines of GPL source code in the Linux kernel to write your OS, which may not be an option.
trelane 3y ago
Lots of things are available in a specification. HTML, for instance. Just being an open specification is insufficient when there's a superdominant implementation. At that point, that implementation is the specification. In HTML, it was Internet Explorer for a long time, now it's Chrome/Chromium. In ACPI, it's Windows. In fact, Linux pretends to be Windows because anything else is a shipwreck graveyard of disappointment and untested code. https://askubuntu.com/questions/28848/what-does-the-kernel-boot-parameter-set-acpi-osi-linux-do https://askubuntu.com/questions/28848/what-does-the-kernel-b... Also, see the whole necessity of patching your DSDT (Windows users: "The what?" Linux users: nodding sadly) https://wiki.archlinux.org/title/DSDT https://wiki.archlinux.org/title/DSDT Modern computers are sufficiently complicated that they really only support one OS. And of course, those are almost entirely Windows computers. Buy a computer with Linux preinstalled, with support, if you want to avoid having to care about things like this (or having a computer that never works quite right (e.g. doesn't reliably suspend or the fans are running wrong)).
- PaulHoule 3y ago
  The situation with HTML was worse in 2000 than it is today. Early on Netscape introduced its own non-standard behavior for broken HTML (tags not properly closed.) Somewhere between 30-60% of HTML was broken so any competitive browser had to (i) render broken HTML and (ii) render broken HTML in the same undocumented way as Netscape! Microsoft figured this out with IE but it was one barrier in the way to alternative browsers. This undocumented behavior was finally documented in the HTML 5 spec. Now you might say the "whole stack" has the Chrome problem in that Chrome has some features that (some) other browsers don't have such as https://caniuse.com/css-cascade-scope https://caniuse.com/css-cascade-scope https://caniuse.com/view-transitions https://caniuse.com/view-transitions https://caniuse.com/css-text-wrap-balance https://caniuse.com/css-text-wrap-balance but a lot of those features are in the "cherry on top" category and there is a fairly healthy process of documenting how they work and the features proliferating to other browsers except when Apple doesn't want them to. (Gotta keep developers in that app store.)
  - trelane 3y ago
    It's not a perfect parallel. For instance, the tooling used to create HTML isn't almost universally provided by one vendor (Microsoft), and then run by the same vendor (still Microsoft.) It's also not like the CEO of that company we ever caught speculating on how to lock out competitors using that same technology. (OK, that's true of both HTML and ACPI)
  - pjmlp 3y ago
    Only because Web has effectively turned into ChromeOS with one vendor left standing.
crabbone 3y ago
The lack of support usually comes from the other side: the h/w vendors aren't testing with anything but Windows. I'm yet to see a Linux laptop where ACPI wasn't broken at least for one device (the most likely suspects are the components that aren't typically used in servers, s.a. webcams or wifi modems).
keep_reading 3y ago
My understanding from ~10 years ago is: There is a specification Windows ACPI implementation is buggy Hardware manufacturers implement Microsoft's implementation bug for bug Everyone has to reverse engineer Microsoft's implementation because the standard isn't enough
- _ea1k 3y ago
  I feel like that outcome is inevitable. All implementations have bugs, and developers implement for reality rather than for a spec. Inevitably it leads to drift and the need to retain things that weren't right to begin with. See also, the referer header. :)
  - lmm 3y ago
    > I feel like that outcome is inevitable. All implementations have bugs, and developers implement for reality rather than for a spec. It depends. If the spec is clear then developers will generally implement the spec. If the spec is a mess then it becomes easier to just do what works on the popular implementations. Things like spec conformance suites, or even just writing up the spec well, can move the needle.
- rasz 3y ago
  From my 20 year memory it was other way around: There is a specification. Taiwanese hardware OEMs suck at programming, make mistakes. Windows ACPI implementation is build to detect and work around those bugs. Think Win 3.x version of SimCity 2000 read after free bug and Microsoft hardcoding workaround in Windows 95 https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... >Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95. Everyone else stumbles on those badly implemented ACPI Tables which seemingly work just fine in Windows land.

ACPI is standardized via a specification. It's quite easy for non windows operating systems to support ACPI. I can't say the same for device tree as that requires reading Linux source.

turminal 3y ago

That specification is a monster. "quite easy to support" is not a good description of the situation.

surajrmal 3y ago
By comparison it is easier. The alternative is that you need to read even an order of magnitude more lines of GPL source code in the Linux kernel to write your OS, which may not be an option.

trelane 3y ago

Lots of things are available in a specification. HTML, for instance. Just being an open specification is insufficient when there's a superdominant implementation. At that point, that implementation is the specification. In HTML, it was Internet Explorer for a long time, now it's Chrome/Chromium. In ACPI, it's Windows. In fact, Linux pretends to be Windows because anything else is a shipwreck graveyard of disappointment and untested code. https://askubuntu.com/questions/28848/what-does-the-kernel-boot-parameter-set-acpi-osi-linux-do https://askubuntu.com/questions/28848/what-does-the-kernel-b... Also, see the whole necessity of patching your DSDT (Windows users: "The what?" Linux users: nodding sadly) https://wiki.archlinux.org/title/DSDT https://wiki.archlinux.org/title/DSDT Modern computers are sufficiently complicated that they really only support one OS. And of course, those are almost entirely Windows computers. Buy a computer with Linux preinstalled, with support, if you want to avoid having to care about things like this (or having a computer that never works quite right (e.g. doesn't reliably suspend or the fans are running wrong)).

PaulHoule 3y ago
The situation with HTML was worse in 2000 than it is today. Early on Netscape introduced its own non-standard behavior for broken HTML (tags not properly closed.) Somewhere between 30-60% of HTML was broken so any competitive browser had to (i) render broken HTML and (ii) render broken HTML in the same undocumented way as Netscape! Microsoft figured this out with IE but it was one barrier in the way to alternative browsers. This undocumented behavior was finally documented in the HTML 5 spec. Now you might say the "whole stack" has the Chrome problem in that Chrome has some features that (some) other browsers don't have such as https://caniuse.com/css-cascade-scope https://caniuse.com/css-cascade-scope https://caniuse.com/view-transitions https://caniuse.com/view-transitions https://caniuse.com/css-text-wrap-balance https://caniuse.com/css-text-wrap-balance but a lot of those features are in the "cherry on top" category and there is a fairly healthy process of documenting how they work and the features proliferating to other browsers except when Apple doesn't want them to. (Gotta keep developers in that app store.)
- trelane 3y ago
  It's not a perfect parallel. For instance, the tooling used to create HTML isn't almost universally provided by one vendor (Microsoft), and then run by the same vendor (still Microsoft.) It's also not like the CEO of that company we ever caught speculating on how to lock out competitors using that same technology. (OK, that's true of both HTML and ACPI)
- pjmlp 3y ago
  Only because Web has effectively turned into ChromeOS with one vendor left standing.

crabbone 3y ago

The lack of support usually comes from the other side: the h/w vendors aren't testing with anything but Windows. I'm yet to see a Linux laptop where ACPI wasn't broken at least for one device (the most likely suspects are the components that aren't typically used in servers, s.a. webcams or wifi modems).

keep_reading 3y ago

My understanding from ~10 years ago is: There is a specification Windows ACPI implementation is buggy Hardware manufacturers implement Microsoft's implementation bug for bug Everyone has to reverse engineer Microsoft's implementation because the standard isn't enough

_ea1k 3y ago
I feel like that outcome is inevitable. All implementations have bugs, and developers implement for reality rather than for a spec. Inevitably it leads to drift and the need to retain things that weren't right to begin with. See also, the referer header. :)
- lmm 3y ago
  > I feel like that outcome is inevitable. All implementations have bugs, and developers implement for reality rather than for a spec. It depends. If the spec is clear then developers will generally implement the spec. If the spec is a mess then it becomes easier to just do what works on the popular implementations. Things like spec conformance suites, or even just writing up the spec well, can move the needle.
rasz 3y ago
From my 20 year memory it was other way around: There is a specification. Taiwanese hardware OEMs suck at programming, make mistakes. Windows ACPI implementation is build to detect and work around those bugs. Think Win 3.x version of SimCity 2000 read after free bug and Microsoft hardcoding workaround in Windows 95 https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... >Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95. Everyone else stumbles on those badly implemented ACPI Tables which seemingly work just fine in Windows land.