What's the big deal, there are often changes, sometimes inconvenient, sometimes breaking changes, requiring a configuration file change or software update. This is true of any operating system update or upgrade.
I think some might suggest that the defaults matter a lot.
> However, it may doesn't throttle well for some users, resulting in huge power usage even when idle, heat from the CPU and also fan noise.
While the crowd that uses OpenBSD might be crafty enough to look up and apply solutions, this happening in any mainstream OS would be unacceptable, since many simply wouldn't know how to change the setting, or wouldn't even be aware that there's a setting to change in the first place.
And what would the consequences be if tens to hundreds of millions of devices out there suddenly started wasting lots of electricity and ran in a mode that could cause the CPUs to fail more quickly?
Here's a nice article on the topic of defaults: https://www.jason.af/defaults-matter/
Last year I tried to run FreeBSD on a HP DL380 G7 (old-ish enterprise server). After install, all the fans were spinning at ludicrous speeds. Funny thing about these HP servers; the fans will spin like this if you put non-HP hardware components in them. I don't have non-HP components, so I never had the fan issue prior to FreeBSD. But because the issue was so common, searching the web kept turning up crazy solutions using resistors and such. I gave up and put Alpine Linux on there instead. Alpine worked great.
Months later, I went back and tried FreeBSD again. This time I had stumbled across a FreeBSD specific fix for the fan: sysctl hw.acpi.cpu.cx_lowest=C3
That was it; a C state setting. I had to learn about C states, powerd and Intel SpeedStep before I could do anything with FreeBSD on that server. No power management. But... we get a mail server?
Yeah, I would say defaults do matter.
OpenBSD expects that its users will look up and apply solutions.
They do not have a goal to be a mainstream OS.
That is fine and all, but consider the following:
- if a solution is needed, that means that there's a problem; why should an update knowingly introduce a problem?
- caring about the environmental impact/load on the hardware isn't mutually exclusive with being knowledgeable and able to apply solutions; shouldn't the more conservative/environmentally friendly option be the default setting?> As the usual "automatic" frequency scheduling mode is no longer available, I wrote a simple utility to manage the frequency when the system is plugged to the wall, I took the opportunity to improve it, giving better performance than the previous automatic mode, but also giving more battery life when using on a laptop on battery.
if the above worked (I'm not a openbsd user really) then why would the author need to create the utility that created this post?
It seems one advantage is that it offers more control and settings for those who want it. E.g. options for:
-d downstepfrequency sets the steps removed every cycle when decaying, default to 100
-i inertia sets the number of cycles after which the frequency will decay, 0 is the default
-m maxfrequency sets the maximum frequency the CPU can reach in percent, 100% is default
-l minfrequency sets the minimum frequency the CPU must be lowered to, 0% is default
-r threshold sets the CPU usage in % that will trigger the frequency increase, 30% is the default
-s stepfrequency sets the percent of frequency added every cycle when increasing, 10% is default
-t timefreq sets the milliseconds between each poll, 300 is the default
-T maxtemperature sets the temperature threshold under which the maximum frequency will be temporary lowered until the CPU cools down