I'm not the only one who thinks this. Linus Torvalds wants it to die as well.

Here is the problem. Like systemd, it's trying to solve too many problems in a low level system. Systemd wants to solve all of the problems in a single init process instead of.. letting a multi-process system of specialized programs solve there specific area.

ACPI is like systemd on steroids. It's original job was to communicate power information from the motherboard to the OS. Now it's responsible for mapping out all the hardware on the mother board and relaying power information.

Wow. That sounds useful. So what's the problem? It does some of those things ass backwards.
For the simple power state info like telling you if your laptop is plugged in, it...

• Sends an interupt signal to the cpu which relays that to the kernel
• The kernel then needs to stop everything and let some firmware program on another chip process some code written in AML (ACPI Machine Language).
• This code will now break
• Then your computer freezes

In a sane world you'd recognize that you have a pretty low value signal here driving a pretty surface level consequence.. changing a charge icon on your display.

It's not worth the complexity and the risk to do it this way, hoping that all existing operating systems and boards and firmware copies will always do this dance without breaking.

Better is to just make the physical positive wire on the charge port a GPIO pin. And then write the voltage difference between it and ground to /sys/gpio/powerpin. And then any high level script that wants to drive an icon can poll the file. Or if scripts want to be event oriented, some deamon can poll the file and then send out events when it changes. Completely high level, none to little firmware. Low level systems do a default low context job they can reliably do. Every part is modular and can be fixed or replaced without compiling a kernel.

In Linux fashion if something isn't working you are supposed to be able to replace it or develop a quick alternative. You should be able to say "fuck this thing, I'm doing something else," always. Always and quickly.

But because ACPI also manages device detection, you can't decide to replace it with something smarter, more organized, and more principled.

Now, I've only covered half the cancer. ACPI is a plague created by microsoft and toshiba that permanently poxed x86 (intel spec). So then maybe one should swith to or at least value the prospect of using ARM or RISC-V to escape the insanity.

The problem is standards spread. ARM and RISC-V used to use exactly the GPIO solution I described. These were embedded systems used in industrial processes. They were used by engineers instead of sys-admins. Reading a sensor directly and driving some code from it is reasonable to those people. But when ARM and RISC-V started to get some real compute power attached to them, they looked attractive for server use. Servers run linux. Linux is tightly integrated with ACPI (it doesn't want to be by any choice). And so ARM and RISC-V had to adopt ACPI.

It's a cancer that just will not end.

---

So to recap. Microsoft demanded Intel adopt a standard they drafted. Intel said yes. Linux needed to support Intel. ARM and RISC-V needed to support Linux. The lesson is, if you can learn to say no to Microsoft early, you can stop a cascade of bullshit.