4 ms·

While not serialized to a database, memory-dump/snapshot based distribution was done with smalltalk and various lisps. Basically dump the gc and the executable

by knome 2y ago

While not serialized to a database, memory-dump/snapshot based distribution was done with smalltalk and various lisps. Basically dump the gc and the executable just reloads it right into RAM. Wasn't the best from what I've read over time. Having an SQL based callstack sounds painfully slow.

acuozzo 2y ago
> Having an SQL based callstack sounds painfully slow. It could be, but this aspect of the idea could also be user-togglable at runtime.
igouy 2y ago
> Wasn't the best from what I've read over time. Because?
- knome 2y ago
  I don't have references, just bits of notion from reading various accounts of things online over the years. Most of the software that was distributed as an image would also run as an image and stop by saving that image down to the disk. This could lead to persistent difficult to debug errors (imagine a random RAM bit flip getting persisted into the image) that couldn't be recreated because they only existed on that one clients machine. Each customer was effectively modifying their versions as they ran and saved and reloaded the software, and the as seller was contracted to make local modifications for them, so the install base would diverge over time. There was no central or single source to rebuild the program from. Turning it off and on again just reloaded the saved bugs.
  - igouy 2y ago
    > just bits of notion from reading various accounts of things online over the years And that casts shade. > Most of the software … would … stop by saving that image down to the disk. Not so. Fat-client apps for corporate DBs. > There was no … source to rebuild the program from. Not so. I'll leave you to read a 1984 manual, page 459: https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... > … just reloaded the saved bugs. Let's pretend that someone had made "bad" changes and saved them in their current image file, and they had not archived their other changes. They would be able to recover all their "good" changes without the "bad" changes because their changes were automatically recorded in a transaction log file. They could replay the "good" changes from the changes log into an original image file, and not replay the "bad" changes.
    - knome 2y ago
      >And that casts shade I was just being clear from my knowledge was secondhand. I hadn't heard about a smalltalk transaction log. That's a great link. I'll grab a local copy and read through it later. I love tech history. Thanks.
      - igouy 2y ago
        fwiw Stef's Free Online Smalltalk Books http://stephane.ducasse.free.fr/FreeBooks.html http://stephane.ducasse.free.fr/FreeBooks.html

by knome 2y ago

acuozzo 2y ago

> Having an SQL based callstack sounds painfully slow. It could be, but this aspect of the idea could also be user-togglable at runtime.

igouy 2y ago

> Wasn't the best from what I've read over time. Because?

knome 2y ago
I don't have references, just bits of notion from reading various accounts of things online over the years. Most of the software that was distributed as an image would also run as an image and stop by saving that image down to the disk. This could lead to persistent difficult to debug errors (imagine a random RAM bit flip getting persisted into the image) that couldn't be recreated because they only existed on that one clients machine. Each customer was effectively modifying their versions as they ran and saved and reloaded the software, and the as seller was contracted to make local modifications for them, so the install base would diverge over time. There was no central or single source to rebuild the program from. Turning it off and on again just reloaded the saved bugs.
- igouy 2y ago
  > just bits of notion from reading various accounts of things online over the years And that casts shade. > Most of the software … would … stop by saving that image down to the disk. Not so. Fat-client apps for corporate DBs. > There was no … source to rebuild the program from. Not so. I'll leave you to read a 1984 manual, page 459: https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... > … just reloaded the saved bugs. Let's pretend that someone had made "bad" changes and saved them in their current image file, and they had not archived their other changes. They would be able to recover all their "good" changes without the "bad" changes because their changes were automatically recorded in a transaction log file. They could replay the "good" changes from the changes log into an original image file, and not replay the "bad" changes.
  - knome 2y ago
    >And that casts shade I was just being clear from my knowledge was secondhand. I hadn't heard about a smalltalk transaction log. That's a great link. I'll grab a local copy and read through it later. I love tech history. Thanks.
    - igouy 2y ago
      fwiw Stef's Free Online Smalltalk Books http://stephane.ducasse.free.fr/FreeBooks.html http://stephane.ducasse.free.fr/FreeBooks.html