4 ms·

I have never used bedrock linux in anger, but it fascinates me. I'm glad it finally made it to the front page. Edit: I've been fiddling with NixOS and reading

I have never used bedrock linux in anger, but it fascinates me. I'm glad it finally made it to the front page. Edit: I've been fiddling with NixOS and reading up on pros/cons vs scripting everything and having a good repo with all the necessary stuff. It seems like Bedrock could provide a good foundation for making it safe and easy to rollback with said scripts, or maybe even divide the scrip up into pre Bedrock and post bedrock with easy rollback capabilities.

boomboomsubban 6y ago
>I have never used bedrock linux in anger, But you have used it in joy? Or what does this mean? And as for rollback capabilities, wouldn't snapshots just work far easier than any of your other ideas? Not only can you easily rollback, everything about the failure is still accessible.
- deleted 6y ago
  [deleted]
- AlexCoventry 6y ago
  It comes from the expression "fired in anger," which meant using a weapon in the heat of battle, i.e., that the weapon was battle tested.
  - boomboomsubban 6y ago
    Ahh, I thought they harbored some ill will towards the project. Thanks.
  - andrewem 6y ago
    I’ve seen people (entirely in computing contexts) say “used in anger” but never knew the derivation. See eg https://en.m.wiktionary.org/wiki/fire_in_anger#Verb https://en.m.wiktionary.org/wiki/fire_in_anger#Verb
soraminazuki 6y ago
Rollbacks are only going to work reliably if packages are immutable, isolated, and its dependencies deterministic. I don't see Bedrock Linux as a particularly better target for supporting rollbacks compared to other distros as it doesn't satisfy any of those properties. Not saying that it's a bad thing, but it just doesn't seem what Bedrock Linux is designed to be good at.
- swsieber 6y ago
  Ah, when I say rollbacks, I mean when you go to upgrade, you duplicate the strata (OS install), and the do everything in the new strata. Then if anything went wrong, delete the new strata and switch back to the one you branched from.
  - soraminazuki 6y ago
    In that case, I wonder how much effort does Bedrock Linux put into isolating runtime state from individual stratas.
    - ParadigmComplex 6y ago
      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.

boomboomsubban 6y ago

>I have never used bedrock linux in anger, But you have used it in joy? Or what does this mean? And as for rollback capabilities, wouldn't snapshots just work far easier than any of your other ideas? Not only can you easily rollback, everything about the failure is still accessible.

deleted 6y ago
[deleted]
AlexCoventry 6y ago
It comes from the expression "fired in anger," which meant using a weapon in the heat of battle, i.e., that the weapon was battle tested.
- boomboomsubban 6y ago
  Ahh, I thought they harbored some ill will towards the project. Thanks.
- andrewem 6y ago
  I’ve seen people (entirely in computing contexts) say “used in anger” but never knew the derivation. See eg https://en.m.wiktionary.org/wiki/fire_in_anger#Verb https://en.m.wiktionary.org/wiki/fire_in_anger#Verb

soraminazuki 6y ago

Rollbacks are only going to work reliably if packages are immutable, isolated, and its dependencies deterministic. I don't see Bedrock Linux as a particularly better target for supporting rollbacks compared to other distros as it doesn't satisfy any of those properties. Not saying that it's a bad thing, but it just doesn't seem what Bedrock Linux is designed to be good at.

swsieber 6y ago
Ah, when I say rollbacks, I mean when you go to upgrade, you duplicate the strata (OS install), and the do everything in the new strata. Then if anything went wrong, delete the new strata and switch back to the one you branched from.
- soraminazuki 6y ago
  In that case, I wonder how much effort does Bedrock Linux put into isolating runtime state from individual stratas.
  - ParadigmComplex 6y ago
    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.