Raspberry Pi with bare metal Smalltalk/Squeak is the kernel of this.
A Smalltalk with a boatload of RAM but actually running in a persistent, Virtual Memory environment. Some way to not have to "save" images, but at the same time a way to recover when you fat finger and delete the "Object" class from your image and murder it. Smalltalk will let you do that. You'll regret it, but it'll let you do it.
But other than that, the VM is the file system. Your email inbox is just an array named "inbox", stored in persistent VM, paged to and from disk as necessary. With 64GB of RAM, 4TB of disk, you cache "everything" eventually.
I just don't know how to get the virtual memory part to save stuff to disk properly. Maybe save the VM pages to something like an append only CouchDB style file store, that way it's easy to rollback when you bork something up. Every 6 months you'll need to vacuum the datastore to reclaim dead pages.
> … but at the same time a way to recover when you fat finger and delete the "Object" class from your image and murder it. Smalltalk will let you do that. You'll regret it, but it'll let you do it.
Doesn't Smalltalk let you rollback the changes file to just before you borked something up?
"The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."
1984 Smalltalk-80 The Interactive Programming Environment page 461
To recover in normal Smalltalk, you revert to a known good image, and then roll forward changes from the Changes file, ideally not executing that last bit that killed it in the first place.
I would think this would be challenging a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to.
For this use case, there is no "file system". Just the living image -- and it's big, ostensibly larger than RAM.
So, rather, you'd want something like the write-ahead log in databases, but one that you can roll back through a primitive restart process to a known good point.
This is why I mentioned CouchDB which versions all of its page writes making recovery from catastrophe possible (at a not small cost of garbage collection).
And, I appreciate the difficulty. Imagine simply having a thread tracking a real time clock. Every second a page gets persisted to the disk...tic tic tic. 86000 pages a day, just "sitting idle".
Or does it? Maybe pages never get persisted to disk until snapshot or swapped out. (And since you have stupid amounts of memory, swapping is rare).
> … a world where you have a single, very large, persistent image (at least as naively presented as I have). You have no "known good" image to revert to.
I'm finding it difficult to understand how we would both have a "persistent image" and not have a "known good" image to revert to.
Seems as though deleting Object might well prevent the image being persisted.
A Smalltalk with a boatload of RAM but actually running in a persistent, Virtual Memory environment. Some way to not have to "save" images, but at the same time a way to recover when you fat finger and delete the "Object" class from your image and murder it. Smalltalk will let you do that. You'll regret it, but it'll let you do it.
But other than that, the VM is the file system. Your email inbox is just an array named "inbox", stored in persistent VM, paged to and from disk as necessary. With 64GB of RAM, 4TB of disk, you cache "everything" eventually.
I just don't know how to get the virtual memory part to save stuff to disk properly. Maybe save the VM pages to something like an append only CouchDB style file store, that way it's easy to rollback when you bork something up. Every 6 months you'll need to vacuum the datastore to reclaim dead pages.