[talldayo]

Probably not, Intel does a pretty decent job regulating power consumption as long as you don't modify the power profiles or fuck with ACPI. Distributions or third-party nagware might ruin the battery, but that goes for any laptop that's required to install Teams or McAfee.

Loading up powertop on my i7 6600u reports an idle draw of 5.5w with my browser open playing music. I think that's pretty damn good, for an old-ish laptop with mitigations enabled on Linux.

[mschuster91]

> Probably not, Intel does a pretty decent job regulating power consumption as long as you don't modify the power profiles or fuck with ACPI.

That assumes the motherboard vendor implemented ACPI properly, and most don't, you're often lucky to have something that is able to keep Windows alive enough to pass certifications. Linux, xBSD or macOS compatibility? Forget it unless you're talking servers with support contracts making it actually worth the effort for manufacturers.

[StillBored]

Sure, there are ACPI bugs, they hit windows too. But to claim there are "works on windows but not linux" bugs everywhere is bogus. If it works in windows, it should work in linux too, that is the point of a platform power interface like ACPI. When one actually tries to look at why the battery life is worse in linux, or the machine doesn't resume properly, overwhelmingly what one finds are linux bugs. Bugs, like the distro won't ship accelerated video codec's, or hibernate is broken due to the kernel refusing to support it with secure boot on, or the wifi or GPU drivers have bugs in their suspend/resume paths, or even simpler things like there isn't a clear project/owner responsible for detecting seat activity and making power related decisions. Sure the freedesktop/dbus/systemd interfaces are there, but often a WM of distro will replace one of those components and create another set of bugs. Never mind desktop Linux still doesn't have the concept of a foreground/background application split so even if it wants to do scheduling hints indicating that a minimized chat application shouldn't be consuming 100% of a cpu when in the background no such standardized component exists unless one is running android. Systemd rightly gets a lot of shit, but it has standardized parts of this functionality, like for example how an application requests a screen inhibit. Nevermind it takes 2-3 years from the point a machine gets released before all the driver tweaks/etc land upstream, and trickle down to your average users machine.

Bottom line, linux on laptops only really works because of ACPI, if you were wondering what the laptop space looks like without it, I might suggest grabbing a couple random arm laptops/chromebooks and giving them a spin.

[PaulHoule]

I don't trust anything in power management to work right on Windows (or Linux.) It is way better than it was in 2000 when I was working with a businessguy who had a Windows laptop that needed several hard reboots a day.

Right now I am listening to music on this computer while I work on another computer. When the screen turns off on this computer the headphones get switched to headset (telecommunications) mode and the music quality goes down... On a desktop computer where saving power is not a big issue and I certainly don't want worse audio just because the screen powered off.

It's been a long term issue that USB devices will not work properly if USB power management is enabled and that's scary when some of those devices are mass storage devices that could corrupt data.

As a single vendor, I trust Apple better to get things like this right, but I don't particularly like MacOS.

[ac29]

> Linux, xBSD or macOS compatibility? Forget it unless you're talking servers

I think you'd have a pretty hard time finding an x86 system that couldnt run Linux these days. If you gave me a random x86 machine from the past decade, I'd actually feel more confident installing Linux than Windows.

[PaulHoule]

My understanding is that ACPI handling code is more complex than any OS pre-1990...

[talldayo]

They don't call it "advanced" for nothin'.

FWIW the alternative these days is probably running a 32-bit RTOS on your battery hardware which isn't much simpler.