Bedrock Linux
Table of Contents
1. Intro
About a year ago, I was frustrated with the state of Linux packaging. I was a
Gentoo user, having been lured in at the possibility of mixing testing and
stable channels. This worked better than I initially suspected, but on the
flipside, running a source based distro was a lot more exhausting than I'd
originally thought. It required me to constantly debug issues, apply patches,
and maintain a huge use flag and accept_keywords list. I was looking to keep
Debian's stability and quality with Gentoo's flexibility, and Bedrock Linux
seemed like a silver bullet. I was intimidated by the (at the time) laborious
install process but time (and good documentation) eventually willed me to try
running it as my daily driver.
2. What is Bedrock?
Bedrock isn't a traditional Linux distribution, but rather a framework for letting traditional distributions (or 'strata') to interact with each other to form one cohesive system. This may seem like magic, but it's not too bad under the covers; each distribution is isolated in its own chroot, and some directories are exposed through bind mounts to effectively "undo" some of the chroot isolation. The rest is automation to make the process easy to use and work as "expected" (ie: linking man pages, shell completion, and desktop files across strata).
2.1. What's the Catch?
After all, mixing software across disparate distributions with zero input from the distro maintainers seemed too good to be true. During my time using Bedrock nyla, I found no bugs in Bedrock itself. Instead, I found things I wished Bedrock did (feature requests) and I found bugs in third party programs that I used. Recently, a new version of Bedrock released, codenamed 'poki' which has addressed most of my gripes, and I can now firmly recommend using Bedrock if you're willing to occasionally debug a weird issue.
2.2. What I use Bedrock For
I've become completely reliant on Bedrock's features for my day-to-day activities. Here's a short list of the non-obvious things I use Bedrock for.
- When I submit a patch for some software, I want to test it against many environments, from ancient to bleeding edge. I use Bedrock to quickly launch my changes on Debian stable, Fedora, Gentoo, and Arch Linux to sanity check my patches. I've caught many bugs with this method, helping improve the quality of my patches.
- Sometimes, software is a pain to install in an isolated directory, and insists on installing itself into your system with root. On Bedrock poki, I don't have to deal with looking up flags/config to change any of that, instead, I spin up a quick Debian strata, install the development version, and throw the strata away when I'm done.
- I find the Gentoo build system useful; for example, I build my python with an
extra option (
--with-dtrace) to enable UDST probes for advanced profiling with eBPF. These probes are only truly useful if I'm running my daily applications with the probes (which is why a custom one-off build isn't optimal). However, configuring my entire system with Gentoo is a huge hassle, and I don't have the time to invest for that. I configured Bedrock to run most of my python programs from Gentoo, while leaving a couple on Debian stable. This way, I'm able to usepythonflow.pyto trace python calls on almost every python process I'm running, while having many (4) backup strata in case anything fails. - I really don't like to install software manually, I would much rather have it
managed for me properly by a package manager. However, not all software is in
the repos! Having many distros around greatly reduces the chance that I ever
need to use any
curl | bashinstallers. - Sometimes, I want to run a bleeding edge version of some software that I use
regularly. However, if there's a bug, I don't want to be impacted beyond
reporting it! With Bedrock, I can install the dev version in its own strata
(maybe from the aur or with
9999packages), and instantly downgrade to the Debian stable version (with stable dependencies as well) whenever I need to, no waiting for reinstalls or messing around with moving files.
2.3. Downsides
Unfortunately, Bedrock isn't completely flawless. Here's a list of all issues/gripes I've personally run into, although many of them are solved now.
- When first trying Bedrock, I found that docker wouldn't start. I tracked it down to a bug in docker's cgroup detection logic.
- I had a couple issues with ocaml programs crashing. It turns out, there's a
bug in the ocaml standard lib which causes exceptions when
TZ=:/etc/localtime(which is allowed by spec). - When using a library that interfaces with jedi, I found that it was occasionally crashing with an odd exception. It turned out jedi was trying to run some code in a different version of python than which it was launched, after which point, jedi got very confused (as it was in a different strata).
- Chrome
<70had a bug where it would throw an exception whenTZ=:/etc/localtimewas set upon calling some js apis. - When compiling software on Bedrock,
cmakeand other tooling get confused about having software from different strata, and give weird behavior. The solution to this is to use the--restrictflag tostratto force cmake to only see binaries from its current strata.
As you can see, most issues with Bedrock are actually issues with software. Because bedrock isn't a "normal" environment, it exposes a lot of bad assumptions in software.
3. Overall…
If you find Bedrock Linux interesting, give it a try in a VM! It's easier than ever, with a hijack script that runs almost instantly (compared with a several hour long setup process before).
If you run into issues or have questions, the primary developer (paradigm) is extremely active on the #bedrock channel on libera, and has helped countless people with questions and issues.
In order to help reduce typing when selecting strata, I made a quick script which I call 'b'. It makes it so you can make the following replacements, assuming unique strata prefixes:
strat debian ls # b d ls strat --restrict gentoo ls # bh g ls sudo strat --restrict fedora yum update # bsh f yum update
