It never fails. Right when you need your notebook to perform and be trouble free the most. It could be a meeting. A client demonstration. Or you could be in a panic trying to remotely fix some server that’s down.
And that’s when it starts.
The fans spin up. The computer slows to a crawl. And your attention is diverted from the thing you need to be focused on to the thing you should never have to think about: a background process.
Some installer, updater, indexer, antivirus check, disk check, or other ridiculous piece of software decides that now is the time to shove the peddle to the metal and finish an irrelevant background task. TrustedInstaller.exe, svchost.exe, SearchIndexer.exe, and yes, even on Macs, mdsworker.
This post is directed at every single software engineer involved with projects that have background tasks. Especially the people behind Microsoft’s infuriating software updaters and that stubborn Google Chrome updater.
If it’s faceless then I do not care how long it takes to complete. Period.
- Your task should not run if the CPU is already under a medium to high load. That means I’m working.
- You should not use more than about 20-30% of a CPU core. Not without my explicit permission.
- Your task should generally not run when on battery power unless the user has authorized it to do so.
- If your task is running and there is a spike in CPU usage from another process, pause your task until the CPU returns to near idle.
- Always have an easy to find option for me to change the scheduling or turn off your background task.
In Your Face Apps
If it has a face then I care how long it takes to complete, but that’s no excuse to be a lazy coder.
- Your task needs to have a pause and/or delay until later feature.
- An updater should not prevent me from using the old version unless and until it is ready to swap in the new version, and that should take seconds. After which my work space (i.e. open windows) should be fully restored.
- Pay attention to code efficiency. That means processor efficiency, energy efficiency, and memory footprint.
I’m writing this while the Microsoft Office updater slams my fans to 6200 RPM and my CPU to 96C. There is absolutely no excuse for a file downloader to consume nearly all the resources of a dual core, 2.7 GHz i7 processor. Even checking file signatures and decompressing data should not be this intensive. I would likely fire someone for such grossly inefficient code, yet this seems to be the norm across Microsoft’s latest OSes and products.
I’ve lost track of how many times I’ve forcibly shutdown some stupid background process and ripped its guts off a computer. You can imagine my fury when a few weeks later I find the same ridiculous thing back in the same place doing the same thing. (I’m looking at both the developers of the Chrome updater and the developers of the GitHub desktop tool’s background app.)
In the 1990’s the big issue was updating consumer OSes with memory protection so that applications could not crash one another. I think the next big issue should be modifying consumer OSes so that end users have a clear idea of what’s running on their computers and why. And so that they can explicitly set limits on the resources used by their applications, limits managed and imposed by the OS itself. I’m focusing on CPU resources in this article, but this should extend to network and data access. Should anyone in the Linux, macOS, or Windows communities decide to pursue such improvements, here’s a wish list:
- Cryptic background process names should not be allowed. Show a list of clear names and vendors with short descriptions and code sign verifications. An average user should immediately understand what a task is for and therefore what it needs. And they should be assured it’s not malware posing as legitimate software.
- All…and I do mean all…scheduled and background tasks need to be presented to the end user via a single UI, and the end user needs to have full control. No hidden startup areas in the OS. (Windows is a terrible offender of this, but even on macOS you can get a process to launch outside of the areas a user might check.)
- The user needs to be able to set explicit limits on CPU use, memory use, scheduling, data access, and network use. CPU use should include power use limitations. Again, this needs to be enforced by the OS. Right now none of the major OSes have a good way to manage CPU time. They’re preemptive, but a process can still elevate its priority to the point of freezing the machine. Most programs won’t go so far as to elevate their priority and risk freezing the machine…I could work on this blog post while the MS Office updater tried to fry an egg on my CPU…but they will consume everything they can regardless of your battery or your other work.
- Network access that is not in response to an explicit user request needs to be visible to the user. This means all code which checks for updates or phones home. And the user should be able to block it without ill effect. Of course we can’t expect this on Windows botnet any time soon, but Apple would only strengthen their reputation by making this part of their app guidelines.
Governments, corporations, and engineers are becoming increasingly arrogant in how they treat user data, time, and resources. It needs to end. Let’s hope OS vendors…Apple and the Linux community at least…give us aggressive tools at the OS level to stop some of this nonsense.