
Show HN: Turbo Boost Disable for macOS - nicebill8
https://github.com/bradleymackey/turbo-boost-disable
======
aequitas
I know it's not protocol to talk down Show HN submissions. But this is just a
shell script loading a core component of TBS [0] during login without password
prompts: by saving your password in a plain text file.

I can agree that password prompts at login are not the best user experience
but security is there for a reason.

Maybe TBS should implement this using the privileged helper pattern [1] which
allow a small daemon with root permissions to perform actions for a userland
application through a secure RPC channel.

[0] [https://github.com/rugarciap/Turbo-Boost-
Switcher](https://github.com/rugarciap/Turbo-Boost-Switcher)

[1]
[https://developer.apple.com/library/archive/documentation/Se...](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/AccessControl.html)

[2]
[https://developer.apple.com/documentation/servicemanagement/...](https://developer.apple.com/documentation/servicemanagement/1431078-smjobbless?language=objc)

~~~
stefan_
Well, it also loads a random kernel extension that is only there as a binary
blob that the author didn't make.

------
jphoward
This is not at all meant to be a criticism, but more a question: is taking a
20% performance hit, as the author writes, really worth it for a theoretical
improvement in the lifespan of some integrated circuits? Are ICs actually how
modern laptops break?

What do you think the odds are in him realising this benefit? Assuming he bins
the laptop after, say, 5 years? (he's rich enough to buy a £1.3k minimum
laptop, assuming it wasn't second hand)

It relies on several assumptions: 1) His laptop dies before he bins it in 5
years' time 2) It died becuase of an integrated circuit (the reason he cites)
- in my experience old computers tend to die of things like exploded
motherboard capacitors rather than ICs. Maybe the death of these are
accelerated by turbo boost, too? 3) The integrated circuit's death was
hastened by a meaningful amount (several months at least; a dodgy thing dying
a couple of days/weeks later doesn't save you from buying a new laptop).

Is taking a 20% performance hit on your laptop really worth this? I'm
interested. I can't imagine it would be for the vast majority of people.

~~~
zozbot234
Generally the packaging fails well before the integrated circuits themselves
do. Thermal stress is hell on SMD and BGA solder joints, and you can't reach
~100C temperatures routinely without quite a bit of thermal stress.

But 100C is also pretty much Tjunction temperature anyway, which means
reaching that temp _will_ in fact cause physical wear and tear on the IC. The
wear and tear would probably decay exponentially as you drop away from the
Tjunction limit, but that still means you _don 't_ want to get too close to it
in general.

------
floatingatoll
Relevant quote for those wondering how it’s done:

> _This is just a shell wrapper around a kext to disable Turbo Boost on 64-bit
> macOS, taken directly from TBS._

> _We have to use the direct TBS kext because for some reason, their kext can
> run on macOS, but we cannot sign our own version to work on macOS. They must
> have signed it with an Apple key or something? Anyway, to get around having
> to use the crappy Turbo-Boost Switcher GUI, we take the core kext, which is
> directly enabled /disabled with the shell scripts in this repo._

The kext in question is from this app:

[https://www.rugarciap.com/turbo-boost-switcher-for-
os-x/](https://www.rugarciap.com/turbo-boost-switcher-for-os-x/)

The benefits of disabling Turbo Boost can be studied more closely at this
prior post about Turbo Boost (28 days ago, 6 dupes, 0 comments):

[https://marco.org/2020/01/13/macos-low-power-mode-
redux](https://marco.org/2020/01/13/macos-low-power-mode-redux)

-62% power draw (Watts), +59% build duration (seconds), -28% heat levels (Celsius)

------
aaronharnly
Looks neat! Shouldn't there be a better way to get the required permissions
than asking the user to put their login password in a plaintext file?

~~~
nicebill8
There's likely a way to get root without having to read the password each
time, this is just what I managed to hack together. If anyone has any
ideas/suggestions I would be happy to fix this ASAP!

~~~
georgebarnett
Allow the script to run under sudo without a password.

~~~
smaccona
Looks like the author already addressed this - the README now has instructions
on configuring /etc/sudoers to run the script without requiring the user’s
password. See [https://github.com/bradleymackey/turbo-boost-
disable/issues/...](https://github.com/bradleymackey/turbo-boost-
disable/issues/1) although [https://github.com/bradleymackey/turbo-boost-
disable/issues/...](https://github.com/bradleymackey/turbo-boost-
disable/issues/2) points out another security hole with that approach.

------
robin_reala
There are some hints that a “Pro Mode” might be coming in macOS[1] that
unlocks power in exchange for fan noise, etc. I wonder if that could be
extended into a “battery saver” node like iOS has that does effectively the
opposite?

[1] [https://9to5mac.com/2020/01/13/macos-beta-hints-at-future-
pr...](https://9to5mac.com/2020/01/13/macos-beta-hints-at-future-pro-mode-to-
boost-performance-on-portable-macs/)

~~~
nicebill8
I hope something like this comes soon. Until then, I'll keep my Turbo Boost
disabled!

------
tibbetts
I’m not an OSX expert, but it seems like you should be able to make a compiled
binary to do this and then give it setuid permissions, avoiding the need for a
password. At least that is how I would do it on other unixes.

------
wizzzzzy
Out of curiosity, can you not get some of these benefits by simply running
your fan more / at lower temperatures and instead sacrifice a bit of noise
instead of the performance?

