Especially those highly critical apps absolutely depend on the the ability to recover via reboot at any moment. There could be random hardware glitches, or software crashes -- and the fix is to discard the RAM, very carefully verify the stored persistent data, and re-create the state from it.
Famously, during the moon landing, the computer had an error and crashed, multiple times [1]. The landing was still a success because while the navigation state was explicitly saved, everything other state was reset. Good thing the designers did not use persistent memory!
Religions are very different around the world. Though my gods do not forbid anybody to 'very carefully verify the stored persistent data, and re-create the state from it' even if persistent data is stored in... persistent memory.
Well, just kidding, I'm agnostic, there's no such thing as my gods. ;)
Key point is code that 'very carefully verifies'. Forced RAM nullification on reboot does not help per se.
And there's no need to reboot in any case. If you feel you're busted, in persistent env you still can clear all state and recreate it from some other state.
It's just very traditional to think of files, not RAM as storage.
Memory mapped files, btw, are quarter a step to Phantom.
Back in the days of core memory I remember restarting a machine after the power had gone out. No need to reboot (unless power had gone out while the monitory ("kernel") was running) -- only the running process, with its semiconductor registers, would die. Everything else was persistent.
The original Multics design did not make a distinction between memory pages on disk and in RAM. Files were just a way to describe a collection of memory pages, wherever they might be.
Comments
Especially those highly critical apps absolutely depend on the the ability to recover via reboot at any moment. There could be random hardware glitches, or software crashes -- and the fix is to discard the RAM, very carefully verify the stored persistent data, and re-create the state from it.
Famously, during the moon landing, the computer had an error and crashed, multiple times [1]. The landing was still a success because while the navigation state was explicitly saved, everything other state was reset. Good thing the designers did not use persistent memory!
[1] https://www.wired.com/story/apollo-11-mission-out-of-control...
Religions are very different around the world. Though my gods do not forbid anybody to 'very carefully verify the stored persistent data, and re-create the state from it' even if persistent data is stored in... persistent memory.
Well, just kidding, I'm agnostic, there's no such thing as my gods. ;)
Key point is code that 'very carefully verifies'. Forced RAM nullification on reboot does not help per se.
And there's no need to reboot in any case. If you feel you're busted, in persistent env you still can clear all state and recreate it from some other state.
It's just very traditional to think of files, not RAM as storage.
Memory mapped files, btw, are quarter a step to Phantom.
Back in the days of core memory I remember restarting a machine after the power had gone out. No need to reboot (unless power had gone out while the monitory ("kernel") was running) -- only the running process, with its semiconductor registers, would die. Everything else was persistent.
The original Multics design did not make a distinction between memory pages on disk and in RAM. Files were just a way to describe a collection of memory pages, wherever they might be.