Many Linux distributions are composed of packages, which are collections of
related files. In such distros most distro-specific files and processes are
associated with some package. For example,
/usr/bin/vim may be provided by
vim package. Packages are typically written with the expectation of
interacting with other packages from the same Linux distribution release.
For example, an executable from one package may utilize a library provided by
another package. This interaction expectation typically breaks down across
packages from different Linux distributions, or even packages across different
releases of the same distribution. For example, two packages from different
distributions may each expect a different build of a library at the same file
A Bedrock Linux system is composed
strata. Like packages, these are
collections of related files. Unlike packages, however,
strata have a
relatively high degree of tolerance for interacting with other files from other
Linux distributions. A Bedrock system may be composed of
strata that each
expect a different build of a library at the same file path but still work, and
Strata are often one-to-one with traditional Linux distribution installs.
One may have an Arch
stratum, a Debian
stratum, a Gentoo
etc. However, they do not have to be related to Linux distributions. For
example, one may have a stratum that is composed of a single man page.
With the exception of
global files (discussed below), every process and
every file on a Bedrock Linux system is associated with some
Bedrock provides commands to manage strata.
hard dependency is a dependency on either:
specificbuild of a given file or process. For example, a dependency on a specific glibc build would be a
specificfile path. For example, dependency on not just
In contrast, a
soft dependency is a dependency that a given file or process exists, but allows for freedom around the dependency's specific build or location. For example, a process may require an Xorg server to display a window, but it may not care about which specific Xorg build is used.
Bedrock operates under the assumption that all of a given
hard dependencies are provided by that same
stratum. For example, if a
/usr/bin/vim requires a specific libc at
/lib/x86_64-linux-gnu/libc.so.6, that same
stratum should provide such a file at that location. However,
soft dependencies may be missing from a given
stratum so long as another
stratum provides them. For example, a
stratum may have a script which requires some build of
gcc, but does not care which specific
gcc or which specific file path provides the
gcc, in which case another
stratum may fulfill the
strata may have mutually exclusive assumptions around the same file path. For example, a Debian
apt and an Ubuntu
apt may each require different file contents at
/etc/apt/sources.list. For both of these
apt binaries to work, each must see its own
stratum's instance of
/etc/apt/sources.list. However, if all file are treated this way,
strata are unable to interact with each other. Thus this system is only applied to some file, which are referred to as
In contrast to
local files are
global files. All processes see the same files at
global paths. For example, a
firefox process from one
stratum may download a PDF file at
global path, and an
evince process from another
stratum may read it.
Global paths allow
strata to share access to some files, but not all. To fully interact,
strata also need to be able to see other
local files. For example, the aforementioned
firefox process may benefit from the ability to directly launch another
evince. Thus, a third category of file path:
cross file paths. Bedrock adds
cross paths to various application look up locations such as the
$PATH environment variable to make
stratum functionality work transparently.
By default, most file paths are
local. The bedrock.conf global section is used to configure which are
global, and the bedrock.conf cross sections are used to configure
cross paths. The brl which command can be used to query which
stratum provides a given path.
To execute a specific
local executable, prefix the command with
strat . For example, to run Debian's
vim (rather than, say, Ubuntu's), run
strat debian vim. To read or write a specific
local file, prefix the file path with
/bedrock/strata/. For example, to edit Ubuntu's
/etc/apt/sources.list (in contrast to, say, Debian's), run
vim /bedrock/strata/ubuntu/etc/apt/sources.list. These can be combine. For example, to use Debian's
vim to edit Ubuntu's
strat debian vim /bedrock/strata/ubuntu/etc/apt/sources.list.
stratum may be either
stratum is integrated with the rest of the system. Its binaries are available for execution, its man pages detectable by
man, etc. One may wish to
stratum, de-integrating it from the rest of the system, at times such as:
stratum's files are fully acquired and setup.
stratumwhich require it to be
disabled, such as removal or renaming.
stratumout of the way while keeping its files around in case it will become useful in the future.
stratum may also be
broken. This indicates that the
stratum's target state is
enabled, but that something went wrong.
Bedrock provides commands to manage strata state.
stratum may be either
hidden in/from various subsystems, controlling:
brl listwithout requiring the
strata to keep them from being accidentally
enabled at sensitive times such as mid-acquisition or just before removal. Users may wish to
strata if they are not expected to be useful for an extended period of time to keep them out of the way while still retaining them on disk for future use.
Bedrock provides commands to manage strata visibility.
Aliases may be created as alternative names for
aliases may be created, removed, or renamed irrelevant of their corresponding
stratum's state, making them more flexible than the
Some example situations where this may be useful:
strataby their release code name, e.g.
cosmic, then create
ubu-ltsaliases and update them as new Ubuntu releases come out.
strataby their Debian release code names, e.g.
buster, then create
deb-stablealiases and update them as Debian releases shift branches.
stratumproviding their preferred
firefoxbuild such as in shell scripts which call
strat. Should the preferred
stratumchange, the user would have to find and change each shell script. Instead, the user may create a
aliasand have the scripts reference that instead. This will allow an update to a single location to effectively change all hard-coded references.
Bedrock automatically creates a
alias during the hijack install to track which stratum corresponds to the initial install. This is solely for the benefit of the user, and you are free to remove this.
Bedrock also automatically creates and updates an
alias corresponding to the
stratum that is providing the init system for the current session. Bedrock's default
bedrock.conf functionality leverages this to ensure init-related commands such as
reboot are provided by the correct
stratum. If you are not intimately familiar with how Bedrock works it is best to leave the
Bedrock provides commands to manage aliases.
This covers all the background required before continuing to the Bedrock commands.