At some point the time to resume is going to make no difference if you still need to load and start a kernel and loading state into RAM is just as fast as loadi

At some point the time to resume is going to make no difference if you still need to load and start a kernel and loading state into RAM is just as fast as loading the OS (which is generally what you get with an immutable OS -- you don't have to spend time on dynamic stuff like loading/probing as much as you would normally). For most operating systems, time tends to be spent in two areas: 1. What-ifs, to mitigate hardware changes, software changes and environmental changes 2. Actually loading and starting the stuff you need That second part can be pretty fast and optimised, and if you eliminate the first part, what you'd do when resuming tends to be the same as loading/starting, but you're going to get bottlenecked by storage-to-RAM if you need to restore the entire memory at once. At that point, if loading/starting programs is fast enough, you might as well do just that. As a bonus, you now get to use events and parallel processing which can give you significant performance gains. But, if we go back a bunch of years and make it a bit more generic (not just focus on Linux); there was indeed a very long time where having a pre-loaded image (essentially the entire machine state) was the fastest you could get since the time spent on individual tasks was so much slower than it is now. The biggest difficulty was making sure that a restored state was stacked on top of pre-initialised hardware. In a way, this is still how many IPL processes for mainframes still work; the entire system is brought out of reset and initialised using a separate system, which then dumps the OS on top of an already-running system.