[sedatk]

> They don't know what is running and what isn't

And they shouldn't. That's the idea Windows 10 tries to convey. Windows Store apps already stay in the background even after you close them. You shouldn't care which app is running or not. Clicking its icon would bring it up and that's the only thing the user needs to know.

iOS and Android already work that way.

[JohnFen]

> You shouldn't care which app is running or not.

I know that there is a strong culture that believes this, but this sort of thing drives me nuts. There are very good reasons why you you would both want to actually close programs and know what programs are running and what are not.

> Windows Store apps already stay in the background even after you close them.

This is one of the many reasons why I don't use Windows Store apps.

[derefr]

> There are very good reasons why you you would both want to actually close programs

Other way around: modern OSes don't want to make it look like programs aren't running when they really are (which has been possible ever since installable background services were created); modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.

[iforgotpassword]

And it's insanely idiotic. In the mobile world we have this due to a vastly different UX, and traditionally very limited resources. Remember the first iPhone didn't allow more than one app running. Today phones have fast CPUs and plenty of RAM, it's mostly about not draining the battery. None of these constraints apply to the desktop. Even on laptops power consumption is much less of a concern, unless you have some program going berserk spinning on 100% CPU.

So trying to bring this same concept to the desktop is insanely idiotic. Microsoft failed miserably by making Windows 8 a phone OS and then bringing it to the desktop with minimal changes. Windows 10 improved so much by actually focusing on the desktop again. Including such no-brainers as allowing store apps to run windowed. I'm not a Windows user anymore myself, but none of my friends who still have it as their daily driver like or use apps.

[JohnFen]

> modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.

I thought they were suspending them, not closing them. Those are very, very different things.

In any case, pretending that applications aren't closed when they are is no better.

[derefr]

What is “suspending”? Like what https://github.com/maaziz/cryopid does? No OS uses such a technique for production process management. (Well, I guess you could say that Genode does if you consider VMs to be processes.) Processes are too non-self-sufficient for this to work with full generality. (For example, what would a process do if it “freezes” in the middle of executing within a shared library’s code section, and then an OS update is applied, replacing that library on disk? The “defrost” process would presumably re-run the dynamic loader, putting the new version of the library into memory; but now the defrosted thread’s PC points into the middle of an instruction. Oops!) CrypPID-like techniques only work in controlled environments, like if you’ve got a machine serving solely as a Docker container host and you want to “pause” containers.

On the other hand, if by “suspending” you mean “the OS asks the program to persist its running state to disk, which it can easily do because it’s using GUI-control and scene-graph frameworks that know how to serialize out their current state”—and then, when it has done this, the OS considers the process “clean” (like a clean page of disk cache) and therefore discardable—then yes, the OS is suspending processes.

Keep in mind that you need to add a flag to your application’s OS-readable metadata (the application manifest in Windows; the Info.plist in macOS/iOS) opting into this behaviour, signalling that your process is okay with being shut down at any time when it’s in the OS-visible “clean” state, and isn’t, say, a host for an RPC server that other applications are expecting to have a stable connection to.

[grawprog]

>iOS and Android already work that way.

And honestly, it's annoying as hell sometimes. You never know when the system's going to kill an app or not. Sometimes you think something might stay in the background for a bit then it doesn't, other times you think you've killed something and it's still running, or it's started itself again. Manual memory management options keep getting stripped back in subsequent android versions. I get the idea behind why android works like this, but the lack of control bothers me.

[Sohcahtoa82]

The difference is that iOS and Android will kill apps as it sees fit. People come to expect that and know that reopening their reddit reader after a few hours, it might not be at the same state they left it.

On a desktop, this is different. You have to explicitly close programs. Because of this, it becomes important to know what's running and what isn't.

[zozbot234]

> The difference is that iOS and Android will kill apps as it sees fit.

Only because iOS and Android are wasting RAM (the former to a lesser extent, but iOS devices also have less RAM to begin with!) and running with zero swap space. (And the latter point in turn is due to the abysmal, bottom-of-the-barrel quality of phone eMMC storage.) This is not progress, it's just the OOM reaper being overactive for lack of a better option.

[bsder]

> and running with zero swap space. (And the latter point in turn is due to the abysmal, bottom-of-the-barrel quality of phone eMMC storage.) This is not progress, it's just the OOM reaper being overactive for lack of a better option.

And all this grief could be avoided by Linux actually allocating memory when its supposed to as opposed to just saying "Sure!" and then sometime later killing completely random programs when someone actually attempts to use memory they requested.

[hombre_fatal]

I wish I had more control over the mobile experience though. For example, my run-tracker apps will get closed and stop tracking me if I open too many apps during my run while leaving Spotify, Youtube, and my podcast apps open.

I'd like to be able to somehow pin the run-tracker as top priority. Sucks to realize after a run or bike ride that it stopped recording 20min into it.

[Asooka]

Your run tracker should have a proper background service to make that not happen, or a persistent notification widget. If it is still happening, look around your power saving options to exempt it from being killed due to "excessive power usage" when in the background.

[sedatk]

Windows Store apps follow the same semantics. When you close them, they are not unloaded from the memory and they restore their state at the startup even if you kill them. The "green leaves" next to the process name in Task Manager means that the app is suspended, but not killed, despite that it isn't open anymore.