Punishing Greedy Apps

When a machine bogs down, the app in front of you will often suggest the fix: close your other applications. So you quit a few tabs, shut the music player, kill the thing syncing in the background, and maybe it helps a little.

Here is what you never find out: whether the app that asked you to do that was the actual problem.

It might have been spending its memory on something it genuinely needed. It might also have been leaking, caching the same image forty times, holding a thread spinning on a poll loop, or shipping its entire UI as a web page rendered in a browser engine it bundled for itself. You cannot tell the difference. The app is the only one talking, and it has every reason to point at someone else. It owns the explanation, and you have no second opinion.

Waste is an externality

Software bloat is an externality.

When an application wastes your CPU and memory and battery, the cost is real, but it does not land on the people who wrote it. It lands on you, and on every other program sharing the machine. The developer who shipped the wasteful build pays nothing. Their laptop is fine. Their telemetry says the app “works.” The damage spreads thin across millions of users who each feel a slightly worse computer and have no way to trace the slowness back to its source.

This is the classic shape of pollution. A factory dumps into the river because the river is free and cleanup is not, not out of cartoon evil. Bloat is the same: free to the producer, expensive to everyone downstream. So we get more of it every year, and we have learned to blame ourselves, dutifully closing tabs at the request of the heaviest program running.

Existing systems are not stupid. They give you a task manager, where you can see processes and their CPU and memory. That is real, useful information. The trouble is what it cannot tell you, and why.

Why the task manager cannot save you

Try to answer a simple question with the tools you have: is this app’s memory use reasonable for what it is doing?

You cannot. The task manager shows a number. It does not show a fair number to compare against, or how much of that number is waste versus need. Worse, a lot of real work hides: a chunk of what an app costs you runs inside shared system processes on the app’s behalf, attributed to the system instead of the app. You see a fat opaque service eating CPU and have no idea which of your programs asked it to.

Clean attribution is genuinely hard, and this is not laziness on the OS authors’ part. When ten applications call into one shared service that does work for all of them out of a single process, honestly splitting the bill back out to the ten callers is a real engineering problem nobody fully solved. The crude attribution you see is the honest output of a system never built to track who asked for what, and why. The causal chain was never recorded, so it cannot be replayed.

So the app keeps its monopoly on the explanation by default, because no neutral party is positioned to contradict it.

The thing worth poking at

I offer this as a possibility, not a verdict. I do not think the problem is solved, and I am not sure it is solvable in the part that matters most. But there is a thread worth pulling.

What if the operating system could answer “what is this app actually spending” itself, honestly, on a surface the app cannot fake?

This is thinkable in Cathedral for a structural reason: resources are capabilities. You do not get to touch the CPU, allocate memory, write the disk, or wake the device just because you happen to be running. You hold a budget for each, the way you hold any other authority, and the OS enforces it. CPU share, a memory working-set ceiling, a storage-write budget, the right to run in the background at all: each is a held grant, not an ambient power.

If resource use runs through that model, accounting is not a profiler bolted on afterward. Every running instance is a billable entity, and the system can always answer “what is this spending,” because the spending happened through grants the OS handed out and watches. The design also records a causal event graph: why each syscall happened and which authority permitted it, not merely that it happened. That is the missing piece behind “an opaque system process is eating CPU and I cannot tell who asked.” If the work was done on behalf of a caller, the chain points back to the caller instead of stopping at the proximate process.

Measured this way, attribution stops being detective work and becomes a query. The app loses its monopoly on the explanation, because the OS has a competing one the app did not get to write.

That is the appealing part. Now the hard part.

Measuring honestly is the easy half

Suppose you can measure perfectly. You still have not fixed anything; you have only built the precondition. Knowing the true cost is worthless unless something acts on it, and every mechanism for acting on it has a sharp edge.

Hard caps punish the user. The obvious move is to cap the offender: ten percent of the CPU and no more. But a hard ceiling bites even when the machine is idle. If nothing else wants the CPU, why throttle the app? You have made your own computer slower to teach a program a lesson. A cap that fires on a quiet machine is spite aimed at yourself.

Manual tuning is busywork nobody does. Fine, make it adjustable, per-app budgets the user sets. We know how this ends, because today’s settings panels already offer a version of it and essentially nobody opens them. People do not want to be the resource manager for their own laptop. Any fix that depends on lovingly tuning sliders is not a fix.

Comparing across apps is genuinely fuzzy. Say the OS just shows honest numbers and lets you judge. A photo editor legitimately needs far more memory than a text editor; a video call more CPU than a notepad. There is no clean universal scale of “too much,” because the right amount depends entirely on what the program is for. A naive comparison misleads, making heavy-but-honest apps look like villains and light-but-lazy ones look virtuous.

The moment you pick a metric, you invite Goodhart’s law. As soon as a number means something, apps optimize the number instead of the thing it stood for. Target “low memory” and an app thrashes to disk, technically using less RAM while making everything slower. Target “fast boot” and apps lazy-load everything, scoring a quick launch and then stuttering the first time you ask them to do real work. Every simple score is a target, and every target gets gamed.

Social pressure needs reach you do not have yet. Maybe the answer is not technical. Publish the numbers, rank the apps, let users shame the gluttons. But a leaderboard only bites if the platform has enough users that landing badly on it costs the developer something real. A new OS has no such reach on day one, so the pressure is hollow exactly when you need it most. And like any score, it is gameable.

Where the line actually is

The one distinction I keep landing on, and the part I am most confident about:

Background and idle waste is plausibly containable. Foreground active-use waste is not, at least not by the OS.

When an app is not in front of you, suspending it costs you nothing. You are not looking at it or waiting on it. If it was quietly burning battery on work it did not need, clamping it down is pure upside, and the design already has the lever: running in the background is itself a budgeted capability the power and network policy has to admit. That is a real fix for a real category of waste, and it asks nothing of the user.

Foreground waste is the hard wall. When you are staring at the app and using it, you want it to have the machine, fast and responsive right now. The OS cannot throttle the thing you are actively using without hurting the experience you are trying to have, so it has almost no leverage in the exact moment the waste hurts most. The only real pressure on foreground bloat is users noticing the app is slow and walking away. That is a market force, not a kernel feature, and no amount of honest accounting summons it.

So honest measurement helps most where the OS can already act, and least where you most wish it could.

Where this leaves us

I do not have a clean ending, and pretending to would be dishonest about a problem this open.

What is reachable: the precondition. Trustworthy, per-instance, app-can’t-spoof attribution of resource cost looks genuinely more tractable when resources are capabilities and the system records why work happened. That alone would be a real shift, because today the app is the only voice in the room, and a credible second opinion changes the conversation. “Close your other apps” hits differently when the OS can quietly note that you have one app and it is the heavy one.

What is missing: the incentive layer on top. Caps punish, tuning rots, comparisons mislead, scores get gamed, shaming needs reach you have to earn first, and the foreground case may have no technical answer at all. Measuring honestly does not make anyone act honestly. It just removes the excuse that nobody could tell.

That is a thread worth pulling even without knowing where it ends. Break the monopoly on the explanation, contain the waste you can contain without hurting the user, and be honest that the rest is unsolved. I would rather build the honest surface and admit the open question than ship one more confident dashboard that the app gets to write the numbers for.