3 ms·

Reminds me of the discussions on hn when Intel Optane wasn't quite dead yet. Those always seemed to end with the conclusion that if separation between volatile

by usrusr 3y ago

Reminds me of the discussions on hn when Intel Optane wasn't quite dead yet. Those always seemed to end with the conclusion that if separation between volatile and persistent memory had not been forced on us by technological reality, it would be a concept we'd better have invented at some point.

catskul2 3y ago
Think you can find any of those discussions? I'd be curious to read/browse.
- usrusr 3y ago
  This is the one that was featured in my memory: https://news.ycombinator.com/item?id=32314814 https://news.ycombinator.com/item?id=32314814 But the most recent one is also interesting: https://news.ycombinator.com/item?id=38527437 https://news.ycombinator.com/item?id=38527437
082349872349872 3y ago
I was tangentially involved with an orthogonally persistent OS, and we indeed had had to reinvent a distinct journalling channel and special optionally-volatile storage, for DBMS-style applications.
- kragen 3y ago
  other reasons to need optionally-volatile storage include secure encryption key generation (reusing randomness often fatally compromises it) and device drivers (if you restore the internal state of your device driver from a checkpoint, but not the state of the device, you will probably crash the system the next time the driver tries to frob the device) despite this, virtual machine checkpoints in qemu work well enough for many purposes
cmrdporcupine 3y ago
I am not sure about this? Volatile memory is at this time merely an outgrowth of the uptime of the system. Back when people routinely turned their machines "off and on again", it became part of that convention. But now uptime can be measured in years, and even personal laptops can enter and exit suspended state for weeks on end without clearing volatile memory. What we have developed in software systems to accommodate this on long running processes is garbage collection. If the volatile/non-volatile distinction had never developed, all that would have happened is that R&D into garbage collection would have been more intense, and earlier. In fact Lisp had garbage collection from day 1. Systems like Smalltalk were also built from the ground up on an image-based model where all reachable state was persistent. In other words: transient data does not necessitate volatile memory. It necessitates garbage collection, though. (And likely also a distinction in programming between "performant" memory areas and non-performant, assuming our NV storage is the latter.) In a way, programmers having to deal with their garbage upfront and not relying on "have you tried turning it off and on again?" could have created better software engineering practices earlier? Maybe?
- 48864w6ui 3y ago
  Back in the days when minicomputers (which required a walk to the air-conditioned machine room to reboot) and microcomputers (which had a case or keyboard switch) coexisted, the former were way less flaky than the latter.

by usrusr 3y ago

catskul2 3y ago

Think you can find any of those discussions? I'd be curious to read/browse.

usrusr 3y ago
This is the one that was featured in my memory: https://news.ycombinator.com/item?id=32314814 https://news.ycombinator.com/item?id=32314814 But the most recent one is also interesting: https://news.ycombinator.com/item?id=38527437 https://news.ycombinator.com/item?id=38527437

082349872349872 3y ago

I was tangentially involved with an orthogonally persistent OS, and we indeed had had to reinvent a distinct journalling channel and special optionally-volatile storage, for DBMS-style applications.

kragen 3y ago
other reasons to need optionally-volatile storage include secure encryption key generation (reusing randomness often fatally compromises it) and device drivers (if you restore the internal state of your device driver from a checkpoint, but not the state of the device, you will probably crash the system the next time the driver tries to frob the device) despite this, virtual machine checkpoints in qemu work well enough for many purposes

cmrdporcupine 3y ago

I am not sure about this? Volatile memory is at this time merely an outgrowth of the uptime of the system. Back when people routinely turned their machines "off and on again", it became part of that convention. But now uptime can be measured in years, and even personal laptops can enter and exit suspended state for weeks on end without clearing volatile memory. What we have developed in software systems to accommodate this on long running processes is garbage collection. If the volatile/non-volatile distinction had never developed, all that would have happened is that R&D into garbage collection would have been more intense, and earlier. In fact Lisp had garbage collection from day 1. Systems like Smalltalk were also built from the ground up on an image-based model where all reachable state was persistent. In other words: transient data does not necessitate volatile memory. It necessitates garbage collection, though. (And likely also a distinction in programming between "performant" memory areas and non-performant, assuming our NV storage is the latter.) In a way, programmers having to deal with their garbage upfront and not relying on "have you tried turning it off and on again?" could have created better software engineering practices earlier? Maybe?

48864w6ui 3y ago
Back in the days when minicomputers (which required a walk to the air-conditioned machine room to reboot) and microcomputers (which had a case or keyboard switch) coexisted, the former were way less flaky than the latter.