Every single ACPI vs Device Tree argument needs to start with the observation that I can boot a modern Linux kernel on an arbitrary x86 board from 1998 and it will probably suspend and resume correctly, and I can't do that with an arbitrary Arm board from 2026
@mjg59 if you're going to subtweet my LWN comment then at least you should've read it. But feel free to buy a Qualcomm SoC, it should just work after all since it's ACPI, right?
@CounterPillow Not meaningfully

@mjg59 Ah, so they're just doing ACPI wrong! No true Scotsman would fail to boot.

Thank you for your kind directions from your armchair, here's your Reddit-V Gold. Now I can finally stop writing drivers, since ACPI means I will no longer need those after all.

@CounterPillow as someone who's spent a shitload of time working on ACPI issues and who's deployed DT-based devices (including on x86!) and who's worked on hardware support for both consumer and enterprise distros, I will politely suggest that I have broader expertise in this domain than you
@CounterPillow if your goal is to ship an integrated platform with the OS tightly tied to the hardware, device tree makes complete sense. But that's not the problem ACPI is trying to solve - there's overlap, but fundamentally they're different and most people talking about this issue refuse to acknowledge that