Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.
SQLite doesn't have system-versioned / temporal tables, but a quick search turns up a fairly straightforward approach. Instead of overwriting existing rows, always write new rows with timestamps. https://www.ohnekontur.de/2024/02/19/unlocking-time-harnessi...
I'm thinking now of the hoops you have to jump through to edit a package.json file to update your dependencies, and thinking yeah, what if you could do: "UPDATE dependencies SET version='1.2' where name='madlib';"
A single SQLite ‘connection’ can be ATTACHed to multiple database files (which appear as separate prefixed schemata, but you can do things like joins across them) and it seems to work properly if some are read-only and some are not!
the question of how you reset to a known-working state if it mutates itself
I have this problem on my computers already, because configuration files and other program data is spewn across all kinds of directories and files all over the place.
The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that has been excreted by the software on my systems just so that I can keep the data that I actually want to keep.
Whereas to pick up all of my data that I do care about and copy only that and nothing extra to another place, is extremely time consuming to the point that it’s not realistically doable :(
Of course, cramming absolutely everything including user documents into the program won’t solve that either.
My ideal system would separate data that was written because of me (non-default config values, bookmarks, etc) from documents etc made by me, from garbage that the program wants to write that I absolutely do not care about and do not want to know about.
Look, I try to avoid bringing up nix in unrelated conversations. But.
The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that has been excreted by the software on my systems just so that I can keep the data that I actually want to keep.
NixOS solves this.
My ideal system would separate data that was written because of me (non-default config values, bookmarks, etc) from documents etc made by me, from garbage that the program wants to write that I absolutely do not care about and do not want to know about.
While way too restrictive, I believe android actually has the correct idea here, having separate data folders per app. The problem is that you can't really touch this per app data folders - even backup is a special operation only doable by the OS (or you root the phone).
Spamming my home folder on the other hand is criminal..
afaik Plan9 already solved this issue - you had 'layers' of filesystems, not unlike Docker images/OverlayFS, with each process getting its own view of the filesystem. The last layer was non-persistent scratch. Of course you'd still need to reconcile writes to things like config files, which would be used by multiple processes, but the general approach is sound imo.
Makes sense to me. Also for production, I would have the app change its name by adding a datetime to the filename, indicating when it was last synchronized.
This is a very appealing idea, I too hope it gets 1000% more attention and adoption.
There are applications where you want to run multiple instances but also want to have them use shared state, e.g. for their preferences (editable via their UI).
Or think of an editor or something like Excel. You probably don’t want the files you edit to all be stored in the binary and require separate export/import functions for sharing, or for editing using alternative applications.
And in the end, that goes for pretty much all data. The applications are the tools you use to view or modify the data, but the data remains independent.
local appConfig[myUniqueArgv0] = { .. some config data .. }
Seems viable to me. I have no problem with different apps having access to each instance' unique app configuration - could be handy for a lot of things. "Copy system config", "Reset to config <blah>", etc.
Comments
What if I'm running multiple instances of the same binary?
As another comment points out down in the thread, that's already a problem today with programs storing their config and data in a fixed location.
On the other hand, sqlite supports concurrency and ACID transactions, so it might actually be better at handling concurrent access to shared state
Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.
SQLite doesn't have system-versioned / temporal tables, but a quick search turns up a fairly straightforward approach. Instead of overwriting existing rows, always write new rows with timestamps. https://www.ohnekontur.de/2024/02/19/unlocking-time-harnessi...
I'm thinking now of the hoops you have to jump through to edit a package.json file to update your dependencies, and thinking yeah, what if you could do: "UPDATE dependencies SET version='1.2' where name='madlib';"
So something like `npm i madlib@1.2` then?
A single SQLite ‘connection’ can be ATTACHed to multiple database files (which appear as separate prefixed schemata, but you can do things like joins across them) and it seems to work properly if some are read-only and some are not!
I have this problem on my computers already, because configuration files and other program data is spewn across all kinds of directories and files all over the place.
The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that has been excreted by the software on my systems just so that I can keep the data that I actually want to keep.
Whereas to pick up all of my data that I do care about and copy only that and nothing extra to another place, is extremely time consuming to the point that it’s not realistically doable :(
Of course, cramming absolutely everything including user documents into the program won’t solve that either.
My ideal system would separate data that was written because of me (non-default config values, bookmarks, etc) from documents etc made by me, from garbage that the program wants to write that I absolutely do not care about and do not want to know about.
Look, I try to avoid bringing up nix in unrelated conversations. But.
NixOS solves this.
And NixOS with https://github.com/nix-community/impermanence does this, forcefully. Actually normal nix might solve it depending on how far you want to go.
Again, I wouldn't usually try to evangelize it, but you have described your ideal system, and it exists.
While way too restrictive, I believe android actually has the correct idea here, having separate data folders per app. The problem is that you can't really touch this per app data folders - even backup is a special operation only doable by the OS (or you root the phone).
Spamming my home folder on the other hand is criminal..
afaik Plan9 already solved this issue - you had 'layers' of filesystems, not unlike Docker images/OverlayFS, with each process getting its own view of the filesystem. The last layer was non-persistent scratch. Of course you'd still need to reconcile writes to things like config files, which would be used by multiple processes, but the general approach is sound imo.
$ cp /original/binary.app /new/binary.app && /new/binary.app
Makes sense to me. Also for production, I would have the app change its name by adding a datetime to the filename, indicating when it was last synchronized.
This is a very appealing idea, I too hope it gets 1000% more attention and adoption.
There are applications where you want to run multiple instances but also want to have them use shared state, e.g. for their preferences (editable via their UI).
Or think of an editor or something like Excel. You probably don’t want the files you edit to all be stored in the binary and require separate export/import functions for sharing, or for editing using alternative applications.
And in the end, that goes for pretty much all data. The applications are the tools you use to view or modify the data, but the data remains independent.
On phones we do all use the model that the data is part of the app.