I'm likely equipped to answer your question if you elaborate a bit on what you mean by runtime state. Could you provide concrete examples of things you are curious about?
The general pattern, in case it covers what you are looking for:
- By default, files/filepaths are isolated, similar to chroots/containers. Features the Bedrock Linux development team haven't taken time to work on yet usually work as they would in their native distro, but are not integrated with the rest of the system. This notably includes most things that package managers touch to keep them from fighting each other.
- Bedrock actively integrates a supported list of files/filepaths which are needed to ensure features from different distros interact transparently. The specifics here vary depending on the given feature. Over time, the Bedrock team expands the list of files/filepaths that do something to integrate across strata as solutions are found to do so without introducing conflicts.
- Bedrock purposefully eschews isolating things like processes and network namespaces. Running `htop` shows all processes from all distros. In the worst case scenario, the user can only get the given feature from one distro at a time. The most notable example here is systemd, which requires being run as PID 1; the lack of PID namespacing means a Bedrock system only has one PID 1 at a time. Switching between different distro inits usually requires a reboot.
- A stratum can be "disabled," which both kills all of the associated process and removes the runtime integration with other strata. Once this is done, it can be copied (backed up) or removed safely. The stratum providing PID 1 cannot be disabled, as Linux is not designed to run without a PID 1; to remove the PID 1-providing stratum, a user must first reboot and select another init. The `bedrock` stratum cannot be disabled, mostly because the Bedrock developers didn't put time and effort into supporting that workflow.
I was referring to files created by various software at runtime, usually in /var. I'm assuming that rollbacks for a package management system would want to only roll back package-provided files and have the rest left alone.
Ah, I now see what you mean. With the exceptions of /var/lib/dbus/machine-id and /var/run, which need to be shared for certain bits of software to communicate properly, /var is currently isolated by default. If a website is hosted at /var/www or e-mail contents stored at /var/spool/mail, a naive implementation of the rollback system swsieber described would roll back the website and e-mail as well. Bedrock can be easily configured to make such directories shared across the system and exempted from such a rollback system; hopefully any user who attempts such a workflow would catch this issue and change Bedrock configuration accordingly. I should probably investigate making such configuration default.
The general pattern, in case it covers what you are looking for:
- By default, files/filepaths are isolated, similar to chroots/containers. Features the Bedrock Linux development team haven't taken time to work on yet usually work as they would in their native distro, but are not integrated with the rest of the system. This notably includes most things that package managers touch to keep them from fighting each other.
- Bedrock actively integrates a supported list of files/filepaths which are needed to ensure features from different distros interact transparently. The specifics here vary depending on the given feature. Over time, the Bedrock team expands the list of files/filepaths that do something to integrate across strata as solutions are found to do so without introducing conflicts.
- Bedrock purposefully eschews isolating things like processes and network namespaces. Running `htop` shows all processes from all distros. In the worst case scenario, the user can only get the given feature from one distro at a time. The most notable example here is systemd, which requires being run as PID 1; the lack of PID namespacing means a Bedrock system only has one PID 1 at a time. Switching between different distro inits usually requires a reboot.
- A stratum can be "disabled," which both kills all of the associated process and removes the runtime integration with other strata. Once this is done, it can be copied (backed up) or removed safely. The stratum providing PID 1 cannot be disabled, as Linux is not designed to run without a PID 1; to remove the PID 1-providing stratum, a user must first reboot and select another init. The `bedrock` stratum cannot be disabled, mostly because the Bedrock developers didn't put time and effort into supporting that workflow.