The Linux ecosystem does not lack for distributions; there are hundreds of
them catering to almost any need that one might think of. But where does
that leave the poor user who is unable to decide between the virtues of two
or more different distributions? Distribution choice tends to be
all-or-nothing: there is no easy way to obtain the benefits from multiple
distributions at the same time on a single machine. That is a situation
that the folks at
trying to change — but the result is unlikely to be suitable for everybody.
The design goal of Bedrock Linux is to allow users to mix and match pieces
from multiple distributions at will. If one wants something that looks mostly like
openSUSE, but with the ability to source-install a bleeding-edge
LibreOffice from Gentoo next to tried-and-stable PostgreSQL server from
CentOS, Bedrock Linux will make that possible. If one wants to fall back
to Emacs from Debian stable because the latest Rawhide update broke it
again, one can. As the project web site says:
"Packages feel disposable, like toothpicks. No need to fret over one
breaking; just use another." The end result should be a world where
users never have to commit to a specific distribution because all
distributions of interest to them will be available simultaneously.
The Bedrock Linux core exists mostly to boot the system and facilitate the
running of applications from multiple "client" distributions. As such, it
is a bit of a strange and minimal beast. The syslinux bootloader is used
to keep things as simple as possible. The kernel is Linux, of course; the
Bedrock user space is based on Busybox, so there is not a lot to it. It is
all intended to be robust and to function even if an important client
distribution breaks; to that end, the core Bedrock binaries are all statically linked.
Static linking is also needed to ensure that those utilities
will work regardless of the client distribution context they might be run in.
The client distributions are installed under /var/chroot, so
/var/chroot/fedora would host a Fedora installation. Users can
run a command out of any distribution, but the work that must be done under
the hood to make that happen is significant. As might be guessed from the
directory names, Bedrock Linux uses the chroot() system call to
run programs in the distribution context they expect. The brc
command makes all this happen; typing:
brc fedora firefox
would use chroot() to restrict the process's view to
/var/chroot/fedora, then run the firefox binary from there.
The idea is conceptually simple, but it quickly runs into complications.
What if that firefox binary wants to run a helper program from a different
distribution? That requires the ability to break out of the restricted
root, somehow. Bedrock makes this happen with a combination of setuid
binaries and bind mounts. From the outside, it looks like it might have
been better to make use of namespaces to reshape each process's view of the
filesystem, but that is not the direction Bedrock took.
The result is that everything that must be visible to any
distribution-specific program must be bind-mounted into the restricted
root. That is, to begin with, how commands get access to the user's home
directory. Regardless of which distribution context a process is running
in, /home will be properly mounted to be visible there. In the
current alpha release (1.0alpha2, known as "Momo"),
every process has all of the directories for all distributions bind-mounted
into it. This mounting is done on the fly as commands are run, leading to
some complex topologies.
That complexity turns out to be a bit of a problem; as the Bedrock
developers say in the notes for the upcoming
Real-world use of Momo can easily result in hundreds of thousands
of mount points. Since it is not possible to predict how deep the
tree will go, Momo cannot set up all of these mounts at
boot. Rather, it attempts to create these mounts just before they
are necessary on-the-fly. This has a number of down sides.
Performance is at the top of the list of "down sides," but it's clear that
a system configured like this can be unwieldy in a number of ways. So it
will be replaced in 1.0alpha3 with a new version of the brc
command that, when a distribution boundary is to be crossed, will simply
break out of the restricted root and enter a new one for the new
distribution. That eliminates the need to set up lots of new bind mounts
at every command invocation, at the cost of needing to run a setuid
breakout program instead.
Given that initialization systems have been a hot topic recently, one might
well wonder what Bedrock does in this area. Can one easily switch from,
say, OpenRC to systemd? The answer is that Bedrock literally does
The Bedrock Linux developer has been unable to think of any sane
way of determining which init script to run when the clients
conflict (which CUPS daemon should run, if multiple are
available?). Additionally, an automated way to determine the launch
order from all of the possible systems it will run into seems far
too challenging of a project. Thus, Bedrock Linux requires manually
setting which programs from which client's init is launched when.
Setting up Bedrock, thus, is not a task for users wanting a one-click
installation experience. Especially since Bedrock does not really have an
installer of its own at all. The FAQ
entry on why there is no installer is amusing reading, to say the
least. Suffice to say that Bedrock, for now, is for users who want to do a
lot of their own setup and tweaking. It may be especially well suited for
those users who have gotten frustrated with the way distributions like
Gentoo do everything for them.
It is also not for users who want something in a hurry; 1.0alpha3 is
planned for release by "end-of-summer 2013." And that will still be an
Whether Bedrock Linux will ever get past the alpha stage is anybody's
guess. It has the look of an ambitious project with a relatively small
amount of developer time available to it. It also looks a little bit
insane. But, then, what is free software for if somebody can't take an
insane idea and run with it? Some interesting ideas may well come out of
the Bedrock Linux project; it will be fun to watch.
to post comments)