[theamk]

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

[aszen]

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

[isitdopamine]

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?

[znpy]

you (rightfully) don't understand because nix doesn't really fit in this discussion. actually, i'd say that nix is off-topic here.

nix is a package manager, that is going to install packages in its own way.

the discussion here is about bedrock linux, that answers a specific question: what if, for any reason, you need packages from two (or more?) specific, very different distros?

what if you need packages from BOTH ubuntu and rhel?

to that question, the answer is not "install nix".

which is really bad because i see the value in nix, it's a very nice system, but nix fanboys are getting really annoying with mentioning nix in any discussion where package management is even tangentially related. it kinda reminds me of that old video about mongodb being webscale.

[ubercow13]

It solves a specific instance of the problem of needing packages from two distros, which is a common instance of that problem: wanting a stable base set of packages on your system with the ability to use some newer, up to date ones.

Nix is highly relevant because it solves that case: you can run Nix on any stable distribution like Debian, and the Nix package repository contains a very large amount of mostly up-to-date software, similar to the Arch+AUR repositories.

Another problem it solves more generally is getting access to a large repository of maintained packages from a base system that only has a small repository, even if those packages are up-to-date.

Both of these are reasons you might use Bedrock, so it doesn't seem off-topic.

[aszen]

The only reason you would want packages from different distro's is if they have a different version.

With nix you can install packages with different versions, you can also install old packages by going back in nixpkgs history and building the package.

Nix being source based means you can install any software package as long as you have access to it's source.

Ofcourse some of this is possible with other systems too but the nix ecosystem makes it far easier to build packages in different languages.

In short nix can treat the disease (missing different versions of packages in distros) instead of treating the symptoms (installing packages from different distros)

[ubercow13]

You can install nix on top of any Linux distribution.

[DyslexicAtheist]

have been running debian sid on all my dev machines since ~7 years and not once had an issue. sure sometimes you need to diff a config file during a dist-upgrade but nothing every broke. ymmv. all my WM/DE sway/i3 gui stuff is self-compiled and so I get to see issues, dependencies and problems at compile time on my machine which I report upstream. It forces me in some rare cases dig until I understand and solve the problem. On the upside I know my tools really well down to every log entry that should or should not be there. Solving things becomes muscle memory (works better with a minimalist approach similar to the suckless philosophy). There is also a performance benefit of getting to use better CFLAGS such as `-mtune=native -march=native` or other hardening not available with packages. Once a day there is a cronjob polling git status for changes of relevant packages so I won't run out of date critically unpatched code. (oh and the great thing is by doing this often you also can follow the patches/diffs and quickly understand what is happening)

being lazy I've never considered the NixOS packing. it's a steep learning curve and also "old dog, new tricks". I'm sure it's awesome to use professionally but unless I see a commercial reason to use and apply it on the job, I won't bother (not because of lazy but because of many other competing things I want to do).

[jcelerier]

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.

[mobilio]

Or just like on mine case - built from source.

Most of time it's 5 commands tar -xf code.tar.gz && cd blah && ./configure && make -j5 && sudo make install

[ParadigmComplex]

> 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.

Very early Bedrock Linux prototypes were exactly this; including the choice of schroot. Bedrock could be correctly described as taking this idea and running with it, trying to stomp out as many of the "you do have to"'s and "except"'s as it can.

> Those solutions are hard to set up than bedrock, but they also do not have special filesystem magic,

I think a fair description of the trade-off between Bedrock and the two alternatives you've laid out should mention the breadth of functionality Bedrock offers they do not. This includes but is not limited to:

- Shell tab completion. For example, Debian's zsh can tab-complete Arch Linux's pacman

- Init systems. For example, one could run Void Linux's runit init, install Arch Linux's systemd, and reboot into systemd.

- Kernels. One could run Arch's kernel, install Debian's, update the bootloader configuration, reboot, and select Debian's kernel.

et al.

I expect, if you think about it long enough, you could see some ways schroot with things like /home mapped in could be extended to cover those use cases. If you pursue those, you'd end up recreating Bedrock.

> so I bet they are much easier to debug.

I am doubtful any user which understands setup schroot you described, who also takes the time to familiarize himself or herself with Bedrock, would have comparative difficult debugging a Bedrock system.

[enkid]

This mix and match of assumptions seems like a security nightmare.

[ParadigmComplex]

My understanding of Bedrock Linux's security concerns are addressed in this FAQ entry [0]. In the decade or so I've been working on Bedrock, I have yet to come across any situations where the differing assumptions between distros results in a security issue. Historically, every time assumptions differed in a way Bedrock did not handle, this resulted in things locking down rather than opening up. For a concrete recent example, Void Linux's build of OpenDoas updated recently [1], which resulted in removing Bedrock entries from the $PATH.

The primary concern I personally hold is in Bedrock's code to bootstrap parts of other distros, which does not currently verify the initial set of files used. I am hoping to address this with Bedrock's next major release (0.8.X) [2].

When Bedrock is far enough along that the architecture/code churn slows, I plan to seriously investigate the possibility of independent security reviews. For the time being, if someone claims heightened security needs, I usually redirect them to Qubes OS [3].

[0] https://bedrocklinux.org/faq.html#security. [1] https://github.com/Duncaen/OpenDoas/releases/tag/v6.8.1 [2] https://github.com/bedrocklinux/bedrocklinux-userland/issues... [3] https://www.qubes-os.org/

[enkid]

Awesome, thanks for the detailed reply!

[ParadigmComplex]

You are very welcome

[soraminazuki]

Alien just repackages files and doesn't keep important metadata like package dependencies, so it likely won't work at all in most cases.

[The_rationalist]

From my experience alien is not reliable

[fsflover]

I prefer Qubes OS, where you run various distributions in VMs. It has a great UI hiding the complexity, still allowing full access to everything.

[swirepe]

>schroot

I learned something new. I only knew about chroot. If I'm understanding, schroot is chroot for normal users?

[ParadigmComplex]

Without something to constrain where it is used, chroot can be theoretically abused as part of an attack. Thus, by default chroot requires root permissions. Part of what schroot does is indeed allow root to approve a list of known-safe locations for a unprivileged users to chroot to. It can do much more, including automate setting up the chroot environment prior to a given user's entry. A more minimal solution that just lets unprivileged users chroot to a given list of directories is capchroot, written by an Arch Linux developer. It used to be hosted here [0] but does not appear to be any longer.

[0] https://dev.archlinux.org/~thomas/capchroot/