Bedrock Linux is old, the first release was in 2011 and it really hasn’t breached the mainstream. This is for good reason! Most people don’t need Bedrock. Bedrock has been left as a iconoclastic choice for nerds in gated chatrooms, something you use to impress your friends, flex your Linux nerd talent but not something you daily drive. I’ve always been a proponent that the best Linux setup for you is probably the one you already have. Ultimately an operating system exists not as an art project but as something you use to get work done. It’s nice to work in a good looking or ideologically perfect environment, but at the end of the day you need to do that work. You need to let go of every last detail and give in to some jank. With that in mind, let me explain why I’ve still opted to use the weird option.

If you take a look at my GitHub, you will notice one big thing: I write a lot of C++. C & C++ have been the lingua franca of programming languages for the past 20 years. Most big important libraries & projects you use probably were written in the C family. That means Wayland, X11, GTK, QT, pick your poison, the Linux kernel, most things by GNU, musl, Chromium, Firefox, Webkit, Ladybird, I can literally go on all day. C and C++ libraries however exist in a space where the operating system manages them. C++ libraries are either installed by blood, sweat, and tears compiling them manually (that said you can also get CMake to compile the package manually via CPM or FetchContent, which is a nice option occasionally), or by pulling in precompiled libraries from your distro, but there’s no good centralized distro independent C++ package manager.

It sort of sucks, but this is how we write software, and it’s not going to change. So I need to spend a lot of time building code for multiple distros, with different sets of libraries and versions. Let me first cover how Bedrock works, and we will tie it back to how I use it.

You check the distro compatibility page before doing anything. If what you want isn’t there, Bedrock probably isn’t right for you. You first install your base distro, I use Debian, but it could be Arch, or Fedora, whatever you pick will be the init system. It’ll manage systemd probably and your display server, other than that it doesn’t super matter. After you have your base system, you hijack it with Bedrock. Running a shell command from the install page. After that it’s really not that complicated. You can run brl fetch ... to add a new distro and strat ... default to the distro for commands. You can still use packages not on your current distro. For example if I run apt in a fish shell controlled by Arch, it’ll still work and let me use Debian’s apt.

So how does Bedrock Linux look for my workflows? I don’t have to clone files into a docker container to switch operating systems, I can just simply strat alpine and now I’m running Alpine. Everything is preserved, my files, my programs, now it just defaults to using Alpine programs, I can do the same thing with Debian or Arch! Test a package on the AUR then install my .deb to make sure it works. It just makes everything a lot quicker.

If you have a dev environment that is mostly distro independent, say you work with Zig, Rust, or Python, you’re probably not needing to use multiple distros, just use Debian or Arch. I do have a split of i3, my audio setup, and browser on Debian and my development environment mostly on Arch, but this is totally unnecessary from an average Linux user’s point of view.

Bedrock Linux is cool, but probably not right for you.