"the machine must present a single address space which can be considered non-volatile" That doesn't solve the problem, or it is at least an oversimplification.

"the machine must present a single address space which can be considered non-volatile" That doesn't solve the problem, or it is at least an oversimplification. How do you ensure that you are only writing out valid states, and not some state that is temporarily invalid (i.e. in the middle of some operation)? I'm sure there's an answer for that, but that seems like totally the wrong direction. That's what a DBMS is for, and/or a modern filesystem with DBMS-like features. I think that DBMSs and the fancy features in new filesystems are underused by applications. Perhaps that could be improved through greater standardization of the way to access basic ACID guarantees. Or, perhaps OSes should have these things more built-in and the lower-level APIs that are tricky to get right should be more obscure. In any case, an oversimplified notion of persistence does not improve matters. Virtual memory just seems like the wrong place to solve these problems. How do you do a "rollback" of some operation when it's a direct modification of the in-memory state? (Note that a rollback is not the same as going back in time -- a rollback surgically undoes a single operation without affecting concurrent operations). If nothing else, a program bug can do a lot more damage (sometimes subtle and not detected for a while) within its own address space than it can to data already held by a separate program (like a DBMS or the kernel's filesystem) with its own consistency guarantees. I think one of the most common software engineering mistakes is to not understand the role of a DBMS in application development, or to drastically oversimplify it (usually leading to a bad reinvention of the DBMS). The reality is that most applications would be greatly simplified by using a full DBMS (typed data, etc.), and almost all applications would be greatly simplified by relying on ACID guarantees.