If the computer has non volatile memory then how do you turn it off and on again to fix the bugs in software? Hope we don't have to say rest in peace to this beautiful piece of troubleshooting procedure
If, today, your disk is corrupt, you tell your OS to boot in single-user mode and run fsck. If that doesn’t work, you fall back a level and reformat a disk.
I don’t see why a device where all storage is directly addressable would be different.
As a result, in the existing system, if the video driver gets corrupt and messes up kernel memory, there is a very high probability that all the files are intact and system will be fully usable once I reboot. Maybe the single file that I was working on will be damaged. Compare this to fully persistent memory system, which has a high chance of being unusable afterward.
For example, memory protection mechanisms can be used to protect boot code from tampering, a level above that the core OS used for ‘just above reinstall’ recovery can use a different protection regime, the OS proper allows user modifications after sudo, but otherwise is protected from user processes, etc.
Actually, even without disk space being memory mapped I think the MMU (and robust disk drivers) are what gives you that high probability of the file system staying intact when a process goes rogue. It used to be fairly common to lose a disk because some runaway process trashed the in-memory cache of essential on-disk data structures, and the OS than (blissfully unaware of the damage) flushed the incorrect data to disk.
What you really want is some sort of generic "document" abstraction. So that user app can specify intent (read or write or update) and a document name, and system will enforce it. This way if your photo app gets damaged, the "blast radius" is limited only to the "documents" which are being edited now, which will hopefully be very close to zero. Hm.. I wonder what this sounds like? :)
(also: I used MS-DOS (with no memory protection, but with SMARTDRV disk cache) a lot, and crashed it a lot, often by my own code. The disk corruption was not that frequent at all. And in the worst case, you could often recover most of the data with NDD. The viruses and disk failures were far more common causes of data loss)