I'm a bit of a novice when it comes to operating system implementation, so I'm not sure if this is a naive question, but how big of a priority is this for an OS written in Rust? By default, Rust statically links everything besides things written in C/C++ (e.g. libc), so would static linking be sufficient for an OS designed to implement everything in Rust?
You get the best of both worlds?
The problem, though, is that all the libraries are duplicated on disk. Flatpak and snaps get around this by recognizing when there is a shared dependency and only downloading it once. But if you "bake in" all your dependecies into a single executable file, that would cause pretty significant inflation for program sizes.
This may be less of an issue now as disk space gets cheaper and cheaper, but it still feels like a step in the wrong direction.
If you edit a file, it could do a copy-on-write, to ensure you're not inadvertently changing a different file.
If you want something that's higher level, there are tools like git annex that do this.
[1] https://www.usenix.org/legacy/events/fast02/quinlan/quinlan_...
It’s better than having static libraries that you cannot fix without recompiling from source.
The problem with this is DLL hell. You need a central repository of images for mapping, but that leads to conflicts. Possibly a good opportunity for CAS?
If things don't work, I notice and fix it. If things aren't secure, I don't notice, get hacked, and my files get ransomed back to me.
Or alternatively, like LD_PRELOAD, just have an env variable; LD_DONT_PRELOAD. Though that would make it more complicated.
On the other hand if they crash or contain memory corruption bugs, the host process suffers as well.
Rust is apparently capable of producing shared libraries: https://doc.rust-lang.org/cargo/reference/manifest.html#buil...