Btw, tar(1) on MacOS shows the file currently being processed when you hit Ctrl-T (i.e. when it receives SIGINFO).
And talking about signals, dd(1) can show the amount of data it has processed as well as the throughput. The signal depends on the implementation(e.g. SIGINFO for MacOS, SIGUSR1 for GNU).
> they do not actually give the user access to general purpose computing in the sense that the users can control exactly what computations the device is going to execute
What prevents the creation of an App that allows one to do exactly that?
You can in fact side load it. There are no restrictions on apps loaded via adb. The 24H restriction period on side loading only applies to apps retrieved by other means.
Oh wow, you can sideload it? Amazing. All grandma has to do is install Android Studio, enable developer mode, tap the build number seven times, flip on USB debugging, plug into a laptop, accept an RSA key fingerprint, and pop open a terminal. You know, the way normal people install apps.
>> they do not actually give the user access to general purpose computing in the sense that the users can control exactly what computations the device is going to execute
i don't think we were talking about grandma use case
Paused game does not equal paused process. It means the gameplay clock has paused.
The rendering loop continues to run. The GUI is immediate mode and is still rendered. In some games visual effects continue to be rendered. If it’s a networked game the network code will continue to run.
A paused game is not like a paused video where there is no processing going on. A paused game still has all the rendering usually going on (unless the developers got time to implement something custom), audio still needs to continue, the only thing actually paused in the game logic and gameplay elements.
Given this the game needs to slow down and lock its frame rate while paused and in menus otherwise it will run at full speed and burn a lot of CPU & GPU time. Though I would say this is not usually an issue because it gets fixed pretty quickly during development.
Now more work can be done by the developers to make the paused state this efficient, but it is all a matter of priorities, and in all cases the developers would rather spend their time making the gameplay better and fixing crash bugs. If the player wants their game to run more efficiently then they should reduce the processing demands by limiting the frame rate and lowering quality settings.
Obviously not every game is doing that level of styling, but often a lot of stuff might still be happening when a game is "paused" for various reasons e.g. aesthetics, or handling input for pause menus, which usually offer you the ability to change all the games settings, e.g. video resolution, volume levels, etc. and also provide you with audio/visual feedback when you make choices, which requires keeping the audio engine running as well as rendering to the screen @ 60 fps.
And talking about signals, dd(1) can show the amount of data it has processed as well as the throughput. The signal depends on the implementation(e.g. SIGINFO for MacOS, SIGUSR1 for GNU).