Hacker News new | past | comments | ask | show | jobs | submit login

> Most civilians understand that computers have to have some way to "remember" their files, but the fact that computers also need memory that "forgets" if the power goes off makes no sense to them.

Well, of course that makes no sense. It isn't true.

We use volatile memory because we do need low latency, and volatile memory is a cheap way to accomplish that. But the forgetting isn't a feature that we would miss if it went away. It's an antifeature that we work around because volatile memory is cheap.




I agree we would be fine if all memory was nonvolatile, as long as all the other properties like latency were preserved.

In terms of software robustness though, starting from scratch occasionally is a useful thing. Sure, ideally all our software would be correct and would have no way of getting into strange, broken or semi-broken states. In practice, I doubt we'll every get there. Heck, even biology does the same thing: the birth of child is basically a reboot that throws away the parent's accumulated semi-broken state.

We have built systems in software that try to be fully persistent, but they never caught on. I believe that's for a good reason.


It would take serious software changes before that became a benefit. If every unoptimized Electron app (but I repeat myself) were writing its memory leaks straight to permanent storage my computer would never work again.


> If every unoptimized Electron app (but I repeat myself) were writing its memory leaks straight to permanent storage my computer would never work again.

This is a catastrophic misunderstanding. I have no idea how you think a computer works, but if memory leaks are written to permanent storage, that will have no effect on anything. The difference between volatile and non-volatile memory is in whether the data is lost when the system loses power.

A memory leak has nothing at all to do with that question. A leak occurs when software at some level believes that it has released memory while software at another level believes that that memory is still allocated to the first software. If your Electron app leaks a bunch of memory, that memory will be reclaimed (or more literally, "recognized as unused") when the app is closed. That's true regardless of whether the memory in question could persist through a power outage. Leaks don't stay leaked because they touch the hard drive -- touching the hard drive is something memory leaks have done forever! They stay leaked because the software leaking them stays alive.


> The difference between volatile and non-volatile memory is in whether the data is lost when the system loses power.

I'm aware. This is a feature for me - I disable suspend/hibernate/resume functionality. I don't want hiberfile.sys taking up space (irrelevant in this scenario, I guess) and I certainly don't want programs to reopen themselves after a restart, especially if it was a crash. If all storage were nonvolatile, OSes would behave as though resuming from hibernate (S4) all the time.

> that memory will be reclaimed [. . .] when the app is closed.

Again, I'm aware. I'm glad you've never had any sort of crash or freeze that would prevent closing a program, but it does happen.

OSes would need to implement a sort of virtual cold boot to clear the right areas of memory, even after a BSOD or kernel panic. Probably wouldn't be that hard, but it would have to happen.


> Again, I'm aware.

Are you? Because according to your words in this more recent comment, your original comment was meaningless gibberish.

> If all storage were nonvolatile, OSes would behave as though resuming from hibernate (S4) all the time.

That isn't even possible to do. Thus, obviously, it would not be done.


> That isn't even possible to do.

What? Of course it has to have a first boot sometime, but past that S5 would no longer need to exist.


You could still have a restart "from scratch" feature in the OS. But persistent RAM could potentially mean the power dropping for a few seconds means you don't lose your session.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: