Specially in the FLOSS world, I think most programs are actually doing rather nice, since during the powertop era there was some push for people to "pay their taxes". Nowadays it seems that people no longer care as much, but we still have a nice headstart.
I guess that might be a part of the problem: the root cause is often somewhere else than in the (traditional, non-javascript) application that you're running on your desktop. Although I imagine browsers would do something to avoid unnecessary resource use when a page is not active, it's harder to entirely prevent it without potential side effects when the "data" of your program can essentially be an application of its own running within your platform. To make applications behave well on idle, you'd have to involve web developers, and their priorities are ultimately dictated by their bosses and clients, too.
Other than that, I wholeheartedly agree that it would be better to not have code that consumes unnecessary resources in the first place than it would be to try preventing it downstream.
The only other applications that I regularly find using multiple percent of CPU time when not in active use are Thunderbird and Steam. I have no idea what's going on with Thunderbird or why it's doing that. Some other applications may have some unnecessary background activity as well, and it might be nice not to have that, but it's usually not particularly heavy. The powertop era you mention may have helped with that.
However, the framework with kernel signals (which this uses AFAIK SIGSTOP (17) / SIGCONT (19)) is there on Unix systems, if not a bit rigorous.
For example, say I have an e-mail client on a laptop and one on my smartphone. On my laptop, I don't need to know at night that if I receive an e-mail I need a notification LED or even refresh e-mail. It can do that once I restart the laptop. However, on my smartphone, I might be waiting for an important e-mail or I might want to receive an important SMS or say an AMBER alert. My point being, there are different gradations of importance which depend on factors. The interesting part is learning about these patterns. With ML? Or by asking the user? I believe something like macOS and Android already do this with DND mode.
In fact, the entire complain is because suspending background processes _is_ annoying, and may even lead to data loss.
To put it in another way:
> forcing by default to segfault on every memory access outside of process bounds which is a real annoyance.
Is forcing to segfault a real annoyance ? Can you show me an example of where it is an annoyance ? Do you prefer to let processes continue accessing obviously undefined memory and/or corrupting the memory of other processes or the system ?
On the other hand, suspending a process on idle is an annoyance:
* If it was a service, you've just caused a Denial of Service attack.
* If it was a timer/cron/alarm of some sort, you've just caused it to miss important events -- the user will arrive late to their meeting.
* If it is a client, it suddenly stopped talking to its server, with unknown consequences.
* If it was even a simple editor that is just saving the user document as a background task, you've lost user data.
That said, you are right about having some reservations about automatically suspending applications. However, it would be nice to have the option. I would like to opt-in to something like this on a case-by-case basis.
Which XSuspender provides via its configuration file.
Well, if you're an Amiga programmer you may depend on being able to walk through system memory or memory belonging to other processes. System calls into Amiga EXEC are made by offsets from a base pointer in absolute memory space (it was 4 in old-school AmigaOS). I swear, there are people in the Amiga community who actually believe virtual memory is a short-lived fad, and we will all realize the error of our ways once the Amiga comes again in glory. Or there were ten years ago... I think that hope for Amiga as a viable platform in the current year has dried up by now even among the diehards.
> On the other hand, suspending a process on idle is an annoyance:
No one was talking about blindly suspending processes on idle. XSuspender's job is to suspend X clients, i.e., interactive programs, that aren't being interacted with. And you have fine-grained control over which clients it actually suspends so it doesn't stop your xclock.
I used to do a lot of 16-bit Windows programming, and there was an awful lot of "tax paying". You had to free window, device context, brush, etc. handles as soon as you were finished using them, otherwise you'd blow your GDI heap and other applications would crash -- or worse. When I switched to Win32 and later Unix it was nice to not have to worry about the resources, including memory and window handles, from a crashed app being cleaned up by the system. It's not a license to code sloppily, but it's one less thing to have to think about should something go wrong.
I don't see why power management can't be the same. I don't see why Android can't for instance snapshot the heap of a backgrounded app without a running service attached, and then restore the heap from the snapshot when the app is resumed instead of making the developer save and restore application state by hand onPause() and onResume().
Oh, and "paying your taxes" is doubtless a reference to USA income taxes, where you have to submit a detailed record of your earnings and deductions to the IRS each year, despite the IRS already having this information. In countries with sensible tax codes, the tax service automatically deducts taxes from your paycheck and in most cases only a simple confirmation that the amount deducted is correct is necessary. So there's not actually much need for "paying your taxes" even when it comes to actually paying your taxes.