19 ms·

It depends on exactly what you mean. While you may not have intended it to be, this question is more philosophical than technical. Extended conversations I've

It depends on exactly what you mean. While you may not have intended it to be, this question is more philosophical than technical. Extended conversations I've had on this topic eventually drift toward subjects like the Ship of Theseus [0] and essential vs accidental properties [1]. For the sake of conversation, lets say your preferred distro is Fedora. If you replace Fedora's web browser with one from Arch, are you still running Fedora? What if you replace the kernel with one from another distro? And the init? Are you still running Fedora if you swap out every single file that is unique to Fedora? Bedrock does not currently support being "uninstalled"; it has to be formatted over, like traditional distros. This is for two reasons: (1) I currently have no way of ensuring any one slice of the system is functionally complete such that removing the rest of the system would leave something bootable. (2) I don't want to advertise support for something active Bedrock users do not themselves regularly exercise, and by its very definition active Bedrock users won't uninstall Bedrock. In theory with enough effort Bedrock could be made uninstal-able, but I don't plan on investing effort there. If a user is interested in testing Bedrock out, I recommend using a VM or spare machine. In every other workflow I can think of, Bedrock can functionally mimic being an alternative packaging system on top of whatever it supports. You can get most of your system - including the install process - from some distro, then use Bedrock to get features from other distros in a way that "feels" like it is "on top" of your original distro. Whether it is "on top" is a matter of semantics rather than practice. With the next major release (0.8) I plan on supporting running Bedrock in something akin to a container. This would let users uninstall it and be less ambiguously "on top" of a traditional distro, but come at the expense of not integrating with the host environment. [0] https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus [1] https://plato.stanford.edu/entries/essential-accidental/ https://plato.stanford.edu/entries/essential-accidental/

akvadrako 6y ago
I mean something akin to a container but still integrated the way flatpak is; I don't want it to touch my base system, except for a few symlinks, being able to selectively expose directories to specific roots, allowing roots to call commands in other roots and things like exposing dbus endpoints. I currently run a number of different chrooted installs of other distros using bubblewrap to selectively expose directories and flatpak-spawn in bash wrappers to run commands in other roots. It works okay but I have looked at bedrock as a possible improvement, however I don't want to use it as my distro.
- ParadigmComplex 6y ago
  Bedrock Linux is a system to integrate things from different distros. The desire to use it while avoiding integration with a "base system" seems mutually exclusive to me. I think one of us is failing to model the other properly. Can you elaborate on: - Why your existing bubblewrap/flatpak-spawn/bash-wrapper works only okay, and why Bedrock might be a possible improvement? From where I'm sitting the limitation with the system you've described is that it does not integrate well with the rest of the system; however, you explicitly don't want it to. - Why you don't want to use Bedrock Linux as your distro? On the one hand, this might just be a matter of definition; if you define Bedrock as something other than a distro, would it then meet your needs? It certainly isn't a distro in the traditional sense; Bedrock's documentation refers to it as a "meta distribution" for this reason [0]. On the other hand, if it's due to some concrete failing on Bedrock's part - it certainly isn't perfect - it's not clear to me how using as an alternative packaging system independent of your distro would alleviate that failing. [0] https://bedrocklinux.org/faq.html#what-is-meta https://bedrocklinux.org/faq.html#what-is-meta
  - akvadrako 6y ago
    > Why your existing bubblewrap/flatpak-spawn/bash-wrapper works only okay, and why Bedrock might be a possible improvement? One thing is managing all the /bin links and taking care of all the directory mappings that are needed. Say env-A calls gcc which is installed in env-B: First, env-A needs a wrapper for all gcc packaged binaries - and those wrappers need to ensure the current directory stays the current directory, /bin and /lib become merges of env-A/env-B, etc. It gets hairy and I'm not sure what's even needed - I haven't done something this complex. I think I read bedrock has fuse for managing links which seems like the level of complexity that's needed. Also managing fonts is something I haven't looked at. And I'm sure there are more things. - Why you don't want to use Bedrock Linux as your distro? Because it makes things more complex. I expect things will break and reasoning about security will be more difficult. My ideal setup is a base system which is fairly minimal, but handles boot, init and kernels for sure. And then isolated packages on top (docker, flatpak, nix, homebrew, distro-chroots) which do integrate with each other when needed.

akvadrako 6y ago

I mean something akin to a container but still integrated the way flatpak is; I don't want it to touch my base system, except for a few symlinks, being able to selectively expose directories to specific roots, allowing roots to call commands in other roots and things like exposing dbus endpoints. I currently run a number of different chrooted installs of other distros using bubblewrap to selectively expose directories and flatpak-spawn in bash wrappers to run commands in other roots. It works okay but I have looked at bedrock as a possible improvement, however I don't want to use it as my distro.

ParadigmComplex 6y ago
Bedrock Linux is a system to integrate things from different distros. The desire to use it while avoiding integration with a "base system" seems mutually exclusive to me. I think one of us is failing to model the other properly. Can you elaborate on: - Why your existing bubblewrap/flatpak-spawn/bash-wrapper works only okay, and why Bedrock might be a possible improvement? From where I'm sitting the limitation with the system you've described is that it does not integrate well with the rest of the system; however, you explicitly don't want it to. - Why you don't want to use Bedrock Linux as your distro? On the one hand, this might just be a matter of definition; if you define Bedrock as something other than a distro, would it then meet your needs? It certainly isn't a distro in the traditional sense; Bedrock's documentation refers to it as a "meta distribution" for this reason [0]. On the other hand, if it's due to some concrete failing on Bedrock's part - it certainly isn't perfect - it's not clear to me how using as an alternative packaging system independent of your distro would alleviate that failing. [0] https://bedrocklinux.org/faq.html#what-is-meta https://bedrocklinux.org/faq.html#what-is-meta
- akvadrako 6y ago
  > Why your existing bubblewrap/flatpak-spawn/bash-wrapper works only okay, and why Bedrock might be a possible improvement? One thing is managing all the /bin links and taking care of all the directory mappings that are needed. Say env-A calls gcc which is installed in env-B: First, env-A needs a wrapper for all gcc packaged binaries - and those wrappers need to ensure the current directory stays the current directory, /bin and /lib become merges of env-A/env-B, etc. It gets hairy and I'm not sure what's even needed - I haven't done something this complex. I think I read bedrock has fuse for managing links which seems like the level of complexity that's needed. Also managing fonts is something I haven't looked at. And I'm sure there are more things. - Why you don't want to use Bedrock Linux as your distro? Because it makes things more complex. I expect things will break and reasoning about security will be more difficult. My ideal setup is a base system which is fairly minimal, but handles boot, init and kernels for sure. And then isolated packages on top (docker, flatpak, nix, homebrew, distro-chroots) which do integrate with each other when needed.