25 ms·

Bedrock Linux – a meta Linux distribution

203 points by rhencke 6y ago

swsieber 6y ago
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.
myWindoonn 6y ago
It's pretty cool that this can host other distros, but is that the only advantage over NixOS? I don't know if I would enjoy crossing distro boundaries constantly just for a small handful of desired packages, and I'm not sure what other use cases this might have. Does anybody have experience deploying Bedrock in production? What are some pros and cons?
- karlmdavis 6y ago
  I’m considering proposing this just to watch my security friends’ heads explode.
- ParadigmComplex 6y ago
  > It's pretty cool that this can host other distros, but is that the only advantage over NixOS? The ability to transparently get features from other distros is Bedrock Linux's defining characteristic. It's not trying to do anything more than that. Ideally the contrast wouldn't be Bedrock _or_ NixOS, but rather NixOS alone or Bedrock with NixOS. Bedrock's goal of getting features from other distros includes distros like NixOS. Sadly, there's still R&D work to be done there: while Bedrock supports a large number of distros, NixOS isn't yet one of them. > I don't know if I would enjoy crossing distro boundaries constantly just for a small handful of desired packages, and I'm not sure what other use cases this might have. I think trying to find use cases other than getting features from multiple distros is driving you in the wrong direction for modelling Bedrock. Most Linux users - quite likely including yourself - are happy with what one distro provides them. Others, however, find it limiting. Bedrock targets the latter group. Try thinking of scenarios where a user has competing pressures for different distros: - A user may require RHEL for work, but miss the large package selection offered by Debian. - A user may like Void Linux's init, but miss Arch's AUR. - A user may like Gentoo's ability to customize packages, but only want to compile about half the system. > Does anybody have experience deploying Bedrock in production? What are some pros and cons? You might be looking for these FAQ entries [0] [1]. [0] https://bedrocklinux.org/faq.html#why-use-bedrock https://bedrocklinux.org/faq.html#why-use-bedrock [1] https://bedrocklinux.org/faq.html#why-not-use-bedrock https://bedrocklinux.org/faq.html#why-not-use-bedrock
dang 6y ago
If curious see also 2013 https://news.ycombinator.com/item?id=6504878 https://news.ycombinator.com/item?id=6504878 (big) 2012 https://news.ycombinator.com/item?id=4966445 https://news.ycombinator.com/item?id=4966445 (small)
ChuckMcM 6y ago
I think they should just say "An easy way to get Linux without systemd" and they would drive a lot of adoption. :-)
- MuffinFlavored 6y ago
  What are the top 3 alternative ways to do GNU/Linux without systemd?
  - deleted 6y ago
    [deleted]
  - easterncalculus 6y ago
    Void Linux uses its own init system and it's pretty nice and familiar. The distribution has gotten a lot better over the years. https://voidlinux.org https://voidlinux.org
  - ChuckMcM 6y ago
    I was going to mention the debian distro. I've got a 'cleanse' script that has grown over time for Ubuntu installs that I first install stock Ubuntu, then cleanse it of snap, systemd, modem-manager, and a couple of other things. And then add the packages that I like. But every release it gets more onerous to do this.
  - kingofpandora 6y ago
    Slackware.
  - tannhaeuser 6y ago
    https://www.devuan.org/ https://www.devuan.org/
  - Shared404 6y ago
    The most common for me are Void, Alpine, and Artix. For most people you could probably sub Devuan for Artix though.
  - freebuju 6y ago
Blikkentrekker 6y ago
How can this possibly work with incompatable libraries? It says that Bedrock provides the glue to make it work, but it does not come with specifics on how it has solved what seems to be a rather hard problem to solve.
- lucideer 6y ago
  Judging by their "How does Bedrock Linux Work?" section[0], exactly how they fix this hard problem is via an ever-evolving plethora of specific per-system fixes, which they're trying to stabilise enough to document before their 1.0 release, but is likely to continue changing as needs arise. Sounds challenging. [0] https://bedrocklinux.org/faq.html#how-work https://bedrocklinux.org/faq.html#how-work
- theamk 6y ago
  It is like overlay of many chroots / containers with some logic to preset unified view of all installed apps and to transparently switch between them. So for example typing “mplayer” runs it in Ubuntu container, and typing “vlc” runs it in Arch container. And each container has is own libraries. Pretty cool, but requires many rules about shared / unshared dirs. Like, home is shared but fontcache isn’t... Their release page has a long list of compatible subsystems.
ParadigmComplex 6y ago
I'm the Bedrock Linux founder and lead developer. I'm happy to answer any questions.
- MiguelX413 6y ago
  How did you get so based?
  - ParadigmComplex 6y ago
    Either stubbornness or perseverance, depending on how charitable one is feeling.
    - reitanqild 6y ago
      Whatever it is, thanks! Edit: and don't burn out.
- qlk1123 6y ago
  You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, and what triggers you do start this project. As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo.
  - ParadigmComplex 6y ago
    > You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, Before Bedrock Linux I was mainly a Debian user. I did briefly run Arch Linux before working on Bedrock, but I found the churn bothersome. While I was running Arch, it updated AwesomeWM from 2.X to 3.X, which changed AwesomeWM configuration formats and functionally broke on my system. Arguably, this wasn't a mistake on the part of Arch Linux developers; the expectation is that the user reads about updates before applying them. Had I done this diligence, I could have withheld the AwesomeWM update. However, I didn't feel like I was able to apply this diligence with the expected regularity. Personally, I prefer Debian's pattern of only releasing security updates with any regularity, only making breaking changes every few years which can be applied when I have time to dedicate to understanding and handling them. Bedrock lets me get _most_ of my system from Debian, but still get newer packages from Arch or rare packages from the AUR when the trade-off of new-ness vs churn is worthwhile for me. > and what triggers you do start this project. I didn't actually set out with the goal to combine distros. Rather, initially (circa 2008) I worked on a sandbox technology. My aim was to fluidly transition resources between security contexts, minimizing user friction while maintaining permissions segregation. I realized only afterward that the technology I developed could be used to fluidly combine features from different distros. Once it occurred to me I could do this, I started seeing use cases everywhere, and pivoted direction to what became Bedrock. > As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo. In that case, I fully encourage you to stick with Arch rather than switch to Bedrock.
peteretep 6y ago
I think those of us who don’t use Linux as a daily driver forget how completely incompatible different distros are. I made the mistake of trying to provision Amazon Linux desktops to users via Workspaces, and quickly realised I was going to need to build almost everything I wanted from source.
- gtf21 6y ago
  Even those of us who do use Linux as a daily driver can forget sometimes ;) I spend my days in Arch and occasionally interact with Debian-based servers but never have to consider the cross-compatibility (or otherwise) of other distros.
- AnIdiotOnTheNet 6y ago
  Yeah, as someone who theoretically would love to be using an open OS and has been waiting for Linux Desktop to become a tolerable experience for about 20 years now, application installation is by far my biggest gripe with it and it not only remains a huge problem in 2021, it remains a problem the community doesn't even seem to want to fix.
  - bogwog 6y ago
    What do you find problematic about app installation on Linux? The poster you replied to was talking about mixing packages from different distros, not about installing apps in general. Installing packages on your distro is very easy, either via a simple command like `apt install <package>` or via a graphical appstore-like interface to the same thing. All major distro package managers are very mature and reliable. Distributing software through those repos as a developer is not very easy, but it's not required either. If you want to distribute your app to all Linux distros without worrying about compatibility, and without requiring your customers to use the command line, you can use something like [App Image](https://appimage.org/ https://appimage.org/), which is basically the same concept as [App Bundles](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html https://developer.apple.com/library/archive/documentation/Co...) on Macs. There are also a lot of (less good) alternatives to App Images, like [Flatpack](https://flatpak.org/ https://flatpak.org/) and [Snap](https://snapcraft.io/ https://snapcraft.io/). If you want something fancier, you could go with something like [Guix](https://guix.gnu.org/ https://guix.gnu.org/) or [Nix](https://nixos.org/explore.html https://nixos.org/explore.html) if your customers are developers or otherwise technical. If you want to get less fancy, you could distribute your binaries with an install script that detects the current distro/version and downloads dependencies using the installed package manager. And if you're a user who just wants to download stuff on their computer, you just need to follow the instructions from the provider. It usually involves one of the methods above.
theamk 6y ago
Reminder about alternatives: For the less extreme case, when you want mostly one distro, but also a few packages from another one, there is “alien” [0] which converts between different package formats. It sometimes needs help with system integration or dependencies, but occasionally “just works” For a more extreme case, there is a schroot (or a docker container) with /home, audio and X mapped in. Works surprisingly well for desktop apps, like those embedded IDEs which require a specific Linux distribution you don’t want to run. You do have manage desktop integration (menu items, file associations) yourself though. Those solutions are hard to set up than bedrock, but they also do not have special filesystem magic, so I bet they are much easier to debug. [0] https://manpages.debian.org/unstable/alien/alien.1p.en.html https://manpages.debian.org/unstable/alien/alien.1p.en.html
- jcelerier 6y ago
  I also like junest, which gives a archlinux userspace very easily on any other Linux. Pretty useful when you want the latest GCC, clang, etc.. but don't have an hour to loose to find the right configure flags.
- aszen 6y ago
  Another solid alternative is to install the nix package manager[0] and get access to thousands of packages. I have stopped installing stuff from apt and thankfully my system never breaks now. [0] https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
  - isitdopamine 6y ago
    I don't understand. I am sure the nix repository is quite large, as are Debian's and Fedora's ones. But how would nix help you mixing packages from different repositories, which is Bedrock Linux use case?
    - ubercow13 6y ago
      You can install nix on top of any Linux distribution.
deleted 6y ago
[deleted]

203 points by rhencke 6y ago

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.

myWindoonn 6y ago

It's pretty cool that this can host other distros, but is that the only advantage over NixOS? I don't know if I would enjoy crossing distro boundaries constantly just for a small handful of desired packages, and I'm not sure what other use cases this might have. Does anybody have experience deploying Bedrock in production? What are some pros and cons?

karlmdavis 6y ago
I’m considering proposing this just to watch my security friends’ heads explode.
ParadigmComplex 6y ago
> It's pretty cool that this can host other distros, but is that the only advantage over NixOS? The ability to transparently get features from other distros is Bedrock Linux's defining characteristic. It's not trying to do anything more than that. Ideally the contrast wouldn't be Bedrock _or_ NixOS, but rather NixOS alone or Bedrock with NixOS. Bedrock's goal of getting features from other distros includes distros like NixOS. Sadly, there's still R&D work to be done there: while Bedrock supports a large number of distros, NixOS isn't yet one of them. > I don't know if I would enjoy crossing distro boundaries constantly just for a small handful of desired packages, and I'm not sure what other use cases this might have. I think trying to find use cases other than getting features from multiple distros is driving you in the wrong direction for modelling Bedrock. Most Linux users - quite likely including yourself - are happy with what one distro provides them. Others, however, find it limiting. Bedrock targets the latter group. Try thinking of scenarios where a user has competing pressures for different distros: - A user may require RHEL for work, but miss the large package selection offered by Debian. - A user may like Void Linux's init, but miss Arch's AUR. - A user may like Gentoo's ability to customize packages, but only want to compile about half the system. > Does anybody have experience deploying Bedrock in production? What are some pros and cons? You might be looking for these FAQ entries [0] [1]. [0] https://bedrocklinux.org/faq.html#why-use-bedrock https://bedrocklinux.org/faq.html#why-use-bedrock [1] https://bedrocklinux.org/faq.html#why-not-use-bedrock https://bedrocklinux.org/faq.html#why-not-use-bedrock

dang 6y ago

If curious see also 2013 https://news.ycombinator.com/item?id=6504878 https://news.ycombinator.com/item?id=6504878 (big) 2012 https://news.ycombinator.com/item?id=4966445 https://news.ycombinator.com/item?id=4966445 (small)

ChuckMcM 6y ago

I think they should just say "An easy way to get Linux without systemd" and they would drive a lot of adoption. :-)

MuffinFlavored 6y ago
What are the top 3 alternative ways to do GNU/Linux without systemd?
- deleted 6y ago
  [deleted]
- easterncalculus 6y ago
  Void Linux uses its own init system and it's pretty nice and familiar. The distribution has gotten a lot better over the years. https://voidlinux.org https://voidlinux.org
- ChuckMcM 6y ago
  I was going to mention the debian distro. I've got a 'cleanse' script that has grown over time for Ubuntu installs that I first install stock Ubuntu, then cleanse it of snap, systemd, modem-manager, and a couple of other things. And then add the packages that I like. But every release it gets more onerous to do this.
- kingofpandora 6y ago
  Slackware.
- tannhaeuser 6y ago
  https://www.devuan.org/ https://www.devuan.org/
- Shared404 6y ago
  The most common for me are Void, Alpine, and Artix. For most people you could probably sub Devuan for Artix though.
- freebuju 6y ago

Blikkentrekker 6y ago

How can this possibly work with incompatable libraries? It says that Bedrock provides the glue to make it work, but it does not come with specifics on how it has solved what seems to be a rather hard problem to solve.

lucideer 6y ago
Judging by their "How does Bedrock Linux Work?" section[0], exactly how they fix this hard problem is via an ever-evolving plethora of specific per-system fixes, which they're trying to stabilise enough to document before their 1.0 release, but is likely to continue changing as needs arise. Sounds challenging. [0] https://bedrocklinux.org/faq.html#how-work https://bedrocklinux.org/faq.html#how-work
theamk 6y ago
It is like overlay of many chroots / containers with some logic to preset unified view of all installed apps and to transparently switch between them. So for example typing “mplayer” runs it in Ubuntu container, and typing “vlc” runs it in Arch container. And each container has is own libraries. Pretty cool, but requires many rules about shared / unshared dirs. Like, home is shared but fontcache isn’t... Their release page has a long list of compatible subsystems.

ParadigmComplex 6y ago

I'm the Bedrock Linux founder and lead developer. I'm happy to answer any questions.

MiguelX413 6y ago
How did you get so based?
- ParadigmComplex 6y ago
  Either stubbornness or perseverance, depending on how charitable one is feeling.
  - reitanqild 6y ago
    Whatever it is, thanks! Edit: and don't burn out.
qlk1123 6y ago
You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, and what triggers you do start this project. As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo.
- ParadigmComplex 6y ago
  > You mentioned both Arch and AUR in the target user part, which makes me wonder if you were mainly a Arch user before, Before Bedrock Linux I was mainly a Debian user. I did briefly run Arch Linux before working on Bedrock, but I found the churn bothersome. While I was running Arch, it updated AwesomeWM from 2.X to 3.X, which changed AwesomeWM configuration formats and functionally broke on my system. Arguably, this wasn't a mistake on the part of Arch Linux developers; the expectation is that the user reads about updates before applying them. Had I done this diligence, I could have withheld the AwesomeWM update. However, I didn't feel like I was able to apply this diligence with the expected regularity. Personally, I prefer Debian's pattern of only releasing security updates with any regularity, only making breaking changes every few years which can be applied when I have time to dedicate to understanding and handling them. Bedrock lets me get _most_ of my system from Debian, but still get newer packages from Arch or rare packages from the AUR when the trade-off of new-ness vs churn is worthwhile for me. > and what triggers you do start this project. I didn't actually set out with the goal to combine distros. Rather, initially (circa 2008) I worked on a sandbox technology. My aim was to fluidly transition resources between security contexts, minimizing user friction while maintaining permissions segregation. I realized only afterward that the technology I developed could be used to fluidly combine features from different distros. Once it occurred to me I could do this, I started seeing use cases everywhere, and pivoted direction to what became Bedrock. > As an satisfied Arch user, I always find AUR has already included something I need. Better, sometimes I just found them already in community repo. In that case, I fully encourage you to stick with Arch rather than switch to Bedrock.

peteretep 6y ago

I think those of us who don’t use Linux as a daily driver forget how completely incompatible different distros are. I made the mistake of trying to provision Amazon Linux desktops to users via Workspaces, and quickly realised I was going to need to build almost everything I wanted from source.

gtf21 6y ago
Even those of us who do use Linux as a daily driver can forget sometimes ;) I spend my days in Arch and occasionally interact with Debian-based servers but never have to consider the cross-compatibility (or otherwise) of other distros.
AnIdiotOnTheNet 6y ago
Yeah, as someone who theoretically would love to be using an open OS and has been waiting for Linux Desktop to become a tolerable experience for about 20 years now, application installation is by far my biggest gripe with it and it not only remains a huge problem in 2021, it remains a problem the community doesn't even seem to want to fix.
- bogwog 6y ago
  What do you find problematic about app installation on Linux? The poster you replied to was talking about mixing packages from different distros, not about installing apps in general. Installing packages on your distro is very easy, either via a simple command like `apt install <package>` or via a graphical appstore-like interface to the same thing. All major distro package managers are very mature and reliable. Distributing software through those repos as a developer is not very easy, but it's not required either. If you want to distribute your app to all Linux distros without worrying about compatibility, and without requiring your customers to use the command line, you can use something like [App Image](https://appimage.org/ https://appimage.org/), which is basically the same concept as [App Bundles](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html https://developer.apple.com/library/archive/documentation/Co...) on Macs. There are also a lot of (less good) alternatives to App Images, like [Flatpack](https://flatpak.org/ https://flatpak.org/) and [Snap](https://snapcraft.io/ https://snapcraft.io/). If you want something fancier, you could go with something like [Guix](https://guix.gnu.org/ https://guix.gnu.org/) or [Nix](https://nixos.org/explore.html https://nixos.org/explore.html) if your customers are developers or otherwise technical. If you want to get less fancy, you could distribute your binaries with an install script that detects the current distro/version and downloads dependencies using the installed package manager. And if you're a user who just wants to download stuff on their computer, you just need to follow the instructions from the provider. It usually involves one of the methods above.

theamk 6y ago

Reminder about alternatives: For the less extreme case, when you want mostly one distro, but also a few packages from another one, there is “alien” [0] which converts between different package formats. It sometimes needs help with system integration or dependencies, but occasionally “just works” For a more extreme case, there is a schroot (or a docker container) with /home, audio and X mapped in. Works surprisingly well for desktop apps, like those embedded IDEs which require a specific Linux distribution you don’t want to run. You do have manage desktop integration (menu items, file associations) yourself though. Those solutions are hard to set up than bedrock, but they also do not have special filesystem magic, so I bet they are much easier to debug. [0] https://manpages.debian.org/unstable/alien/alien.1p.en.html https://manpages.debian.org/unstable/alien/alien.1p.en.html

jcelerier 6y ago
I also like junest, which gives a archlinux userspace very easily on any other Linux. Pretty useful when you want the latest GCC, clang, etc.. but don't have an hour to loose to find the right configure flags.
aszen 6y ago
Another solid alternative is to install the nix package manager[0] and get access to thousands of packages. I have stopped installing stuff from apt and thankfully my system never breaks now. [0] https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
- isitdopamine 6y ago
  I don't understand. I am sure the nix repository is quite large, as are Debian's and Fedora's ones. But how would nix help you mixing packages from different repositories, which is Bedrock Linux use case?
  - ubercow13 6y ago
    You can install nix on top of any Linux distribution.

deleted 6y ago

[deleted]