Hi,
As the original designer of power-profiles-daemon, I haven’t had the chance to reply before to this thread. I was already asked whether switching to tuned with a compatibility was a good idea when this same proposal was made for F40, and now again.
First, tuned already existed when power-profiles-daemon was designed, and the reason why tuned was not used instead of creating a new API was documented in power-profiles-daemon’s README:
Since then, nothing much has changed on tuned’s side that would make it more suited for this task.
First, and as an easy problem to spot, the boot time might very well be impacted by this change. I’ll let others measure its impact on boot up, but I’m sure this problem will show up on systems with slower “disks”.
Second, and most importantly, tuned does a lot. It can be a good thing, if you’re trying to tune a server for a single use case and can verify that it doesn’t corrupt your data for example. It’s not so great when you’re trying to create a product, and not offer too many foot-guns for users to lose their data, and increase their power draw when they meant to reduce it.
It’s great that tuned has this compatibility layer, as that means that folks will be able to test things more easily before figuring out how to upstream them.
But it’s only by upstreaming changes (as Mario, de facto one of the power-profiles-daemon maintainers mentioned above) to where they need to live, into systemd’s rules, into the upstream kernel, that you would be creating a product.
Replacing power-profiles-daemon with tuned in Fedora Workstation would replacing a product with a bag of bits.
/Bastien, not the power-profiles-daemon maintainer