__          __             __
\ \_________\ \____________\ \___
 \  _ \  _\ _  \  _\ __ \ __\   /
  \___/\__/\__/ \_\ \___/\__/\_\_\

Bedrock Linux 1.0beta3 Poki

Bedrock Linux "Poki" Progress

This documents the state of Bedrock Linux's "Poki" release as of 2018-05-09.

Rationale for feature choice

Bedrock Linux has a relatively small development team and thus has had to be very judicious with its application of developer hours. Historically, the vast majority of effort has been put into researching and developing the underlying technologies needed to reach Bedrock's goals, which has sadly come at the expense of user experience. Bedrock's rough but functional state that the more adventurous could test has resulted in a fair bit of useful feedback and vindicated the general strategy. Now that the underlying technology has matured adequately to be useful to a broad audience, the upcoming release's focus shifts towards providing a more enjoyable user experience.

User Experience (completion: 100%)

The following items are user experience design and theory which have been mapped out and completed "on paper" but whose corresponding code may not necessarily be fully implemented:

Build System (completion: 100%)

The build system has seen various improvements:

strat (previously: brc) (completion: 100%)

Nyla's brc has been renamed to strat as part of a general move away from the br* executable naming pattern.

bouncer (completion: 100%)

Nyla made use of scripts such as:

#!/bedrock/libexec/busybox sh
exec /bedrock/bin/brc ${stratum} ${command} "$@"

to create user-facing commands that transparently redirect to the appropriate stratum's instance. However, #! executables lose argv[0] and these scripts were found to be unsuitable in situations which leverage argv[0]. A new binary executable was created to fulfill this role while retaining argv[0]: bouncer.

Modifying bouncer's internal content - compiled executable binary - to indicate the desired stratum/command, as is done with the #! scripts, may be unwise. Instead, bouncer checks its own user.bedrock.stratum and user.bedrock.localpath extended filesystem attributes to determine which stratum/executable to redirect to, then executes strat with the appropriate flags.

crossfs (previously: brp) (completion: 100%)

Nyla's brp has been renamed to crossfs as part of a general move away from the br* executable naming pattern.

etcfs (previously bru) (completion: 25%)

Nyla's bru has been renamed to etcfs as part of a general move away from the br* executable naming pattern.

etcfs has only had preliminary work completed thus far.

brl (previously various executables) (completion: 25%)

Various commands have all been moved under the banner of a new, single command: brl.

brl has only had preliminary work completed thus far.

Work which has been completed on brl includes:

Planned features include:

The installer/updater (completion: 5%)

The build system produces a single eventual output file, named something along the lines of


Only preliminary work completed thus far on this feature.

It is planned to serve three purposes:

init (previously brn) (completion: 5%)

Nyla's brn has been renamed to init as part of a general move away from the br* executable naming pattern.

In order to work, Bedrock runs code before the target init system runs. Amongst other things, this provides a menu which can be used to select the desired init for the given session.

In Nyla, the hijacked distro's /sbin/init had to be retained on the root of the offline filesystem, and thus brn had to be elsewhere on the filesystem. To ensure brn was run rather than what the bootloader saw at /sbin/init, the user was expected to configure the bootloader. This was found to be problematic. Poki's new filesystem layout moves all of the hijacked install's local files (including /sbin/init) from the root of the offline filesystem to /bedrock/strata/stratum/. This frees Poki to place its own init system at /sbin/init on the offline filesystem, which is the path most bootloaders default to utilizing.

Documentation (completion: 0%)

A full suite of documentation must be created to accompany Poki's release. Most of the user-facing improvements simplify things which should reduce the documentation load to a significant degree. However, no documentation for Poki's release has yet been written.

Depending on time constraints, man pages may or may not be created for brl and strat. If they are not, the website's documentation and --help are expected to suffice.

Video presentation (20%)

Bedrock is difficult to explain succinctly in text. A short video demonstrating Bedrock is expected to be better received by some audiences. Past attempts at videos have not gone terribly well. Efforts have been made to improve Poki's: