1%/h is just 0.5W (for a 50Wh battery) which isn't a lot, but fail to bring a component or two to shutdown or sufficiently low power state and you'll observe exactly this behaviour. Of course some drain is going to be almost inevitable just to keep memory contents sufficiently refreshed, but with proper power-saving states memory can go appreciably below 0.5W.

It's not a single oversight, it's a massive project that needs to be carried out throughout an operating system. Linux's usual advantage of decentralization and wide distro variety with massive customization potential is a disadvantage here. To have a power-efficient system you need all of the software to be working toward the same goal. One bad actor process can completely hose the system's power efficiency.

How so? You need each thing to do its part, but that decentralizes perfectly well because it isn't actually integration at all, it's just a hundred different pieces each doing it right.

And open source has the further advantage that you're not beholden to the maintainer. If Framework notices that piece #37 is wasting power, they have the code and can fix it themselves. If the upstream isn't completely asleep at the switch they'll accept the patch, and even if they are you can still ship it on your own device.

Where this can get messed up is in one of two ways. The first is if something is not open source and then the vendor fails to fix it but also fails to supply anyone else with the capacity to fix it. But this isn't a problem with integration, it's a problem with filthy knuckleheads not keeping their heads on straight and calls for some new competitors to show them how to do it.

The second is something like an actual trade off, e.g. if you want the machine to be able to wake via network packet or pressing a key on the keyboard then you'd need the network controller or USB controller to stay in a low power state instead of being dead off. And then that might cost you half a watt, but you're paying it in order to get something, and then somebody has to decide if Linux users would typically want a default where that feature works or one where the battery can last a month in standby, since it's one or the other.

And that actually happens in real life. Most of the projects care to begin with because they use their own stuff and don't want to ruin their own battery life or have a competitive disadvantage over the alternative. Then other third parties that find business value in having it work pay someone to clean up the odd stragglers when one of them didn't do it or have the resources to do it themselves.

The main problem is when some vendor both doesn't do it and is hostile to anyone else doing it.

Sure, they try not to ruin the battery life, but who is investing the amount of engineering resources into Linux battery life that Apple invests into macOS's? No one, of course, because the ROI of doing that for Apple is much higher than doing the same for Linux. Linux's open nature means that going for SotA battery life does not yield a competitive advantage, so no one does it.

If you or your company wants to work 80 hour weeks to improve power efficiency on Linux, you can submit patches to all the different projects where nobody else is doing the work.

In other words, centralize the battery life project. Who is doing that?

ChromeOS.

The answer is rather that everyone is doing it. Then most people care about it a little so they do a little, but because it's most people that adds up to being the majority of what needs to be done. A smaller number care about it a lot but all that's left is for them to shave off the rough edges.

> Linux's open nature means that going for SotA battery life does not yield a competitive advantage, so no one does it.

How does it not yield a competitive advantage? If you're Framework, Dell, System76, Canonical, Red Hat, etc., you want people to use your product instead of buying a Mac or some competitor's Windows laptop.

> In other words, centralize the battery life project.

I don't understand how this is centralization.

Suppose Intel does the work to make good open source drivers and make sure their hardware has low idle power consumption, Red Hat does the work to make systemd behave in a way which is power inefficient in the hardware-independent ways, etc. Then Framework does an analysis of where power is going on their systems and finds that Intel and Red Hat did a good job but there's a bug in the third party network controller driver preventing it from going to sleep, so they fix the bug.

Where is the centralization? The work is being done by all different companies who aren't even necessarily interacting with each other. Some of the bugs in third party software are fixed by hobbyists or other vendors. Then Framework is left with a limited amount of work to do and they do it.

The problem comes when they go to do that analysis and find that the thing using more power than it should is a piece of hardware that the vendor both failed to document and failed to provide source code for the firmware, so that no one else can fix it when they don't. In other words, it's caused by a thing that isn't open source.

These are important things, but they do not matter for power consumption in sleep, when the CPU is not executing instructions.