3 ms·

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 be

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

e2le 5y ago
Some kind of overlayfs type solution? With a non-writeable "default" lower state and a writeable upper state where the changes occur, removing the upper state would effectively reset the system.
- clintonwoo 5y ago
  Fair call, sounds like an immutable OS like CoreOS where updating it requires a reboot. That's possibly all that's required!
  - a9h74j 5y ago
    IMHO something was lost when hard drives no longer had their own write-protect switch (remembering back to DEC rack-mount spinning drives).
Someone 5y ago
The same way you do it now. Most computers already have non-volatile memory, typically a tiny bit for such things as boot parameters and an enormous amount in the form of disk storage. 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.
- theamk 5y ago
  But the disk does not get corrupt frequently because (1) user apps cannot write to it directly, they have to use a restrictive API, (2) each write operation is limited to a single logical part, and cannot affect other parts and (3) disk structure is designed to be recoverable. 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.
  - Someone 5y ago
    I expect OSes to be compartimentalized similarly. There’s no way to manage a system with 2^trillions of states otherwise. 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.
    - theamk 5y ago
      Having the per-app compartments, recovery partition, or sudo-only memory is not going to help you if your text editor crashes, and loses all your documents. Or if photo app crashes and loses all the photos you ever had. 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)
IshKebab 5y ago
Same way you fix errors with persistent caches. You clear them.

e2le 5y ago

Some kind of overlayfs type solution? With a non-writeable "default" lower state and a writeable upper state where the changes occur, removing the upper state would effectively reset the system.

clintonwoo 5y ago
Fair call, sounds like an immutable OS like CoreOS where updating it requires a reboot. That's possibly all that's required!
- a9h74j 5y ago
  IMHO something was lost when hard drives no longer had their own write-protect switch (remembering back to DEC rack-mount spinning drives).

Someone 5y ago

The same way you do it now. Most computers already have non-volatile memory, typically a tiny bit for such things as boot parameters and an enormous amount in the form of disk storage. 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.

theamk 5y ago
But the disk does not get corrupt frequently because (1) user apps cannot write to it directly, they have to use a restrictive API, (2) each write operation is limited to a single logical part, and cannot affect other parts and (3) disk structure is designed to be recoverable. 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.
- Someone 5y ago
  I expect OSes to be compartimentalized similarly. There’s no way to manage a system with 2^trillions of states otherwise. 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.
  - theamk 5y ago
    Having the per-app compartments, recovery partition, or sudo-only memory is not going to help you if your text editor crashes, and loses all your documents. Or if photo app crashes and loses all the photos you ever had. 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)

IshKebab 5y ago

Same way you fix errors with persistent caches. You clear them.