Historically, major Bedrock releases coincide with substantial architectural and code changes. This pattern reduced confidence in the ROI on writing tests. However, recent Bedrock releases has each reduced the scope of architectural changes. Confidence in Bedrock's architecture has reached the point where Naga's code should receive a fair bit of unit and integration test coverage, as well as the usual static analysis tool coverage.
Nyla supported two installation options:
Poki's hijack option was sufficiently polished that the expectation was interest in the competing manual install option would be dropped. However:
Thus, the manual option will be reintroduced in Naga.
In Poki, most Bedrock-specific files were available in
/bedrock. As a result, many users never interact with the
bedrock stratum. This exacerbated confusion over what Bedrock Linux is, as it appears to simply be a
/bedrock directory placed "on top" of another distro install. To resolve this, Naga will move Bedrock specific files into the
bedrock stratum. This should cause users to interact with the
bedrock stratum in the same manner they do other strata, making it appear to be at least a coequal part of the system. For example (using Poki's filesystem layout):
Two concepts need to be accessible to all strata:
/bedrock/strataequivalent, so that files from other strata may be read or written to by other strat.
/bedrock/crossequivalent, so that resources from other strata may be consumed transparently.
Given the above goals, there are two options currently being considered:
/strata, comparable to Poki's
/cross, comparable to Poki's
/bedrock/crosson their root directory.
/bedrockdirectory on their root, comparable to Poki's
/bedrock/cross. In addition to the usual
/bedrock/crosscontent will be a
/bedrock/stratadirectory comparable to Poki's
/bedrock/stratadirectory neighboring read-only directories (e.g.
/bedrock/applications) might cause confusion.
/bedrock/strata/...paths, this results in longer file paths than the competing option due to the
As of the time of writing, Bedrock independently reproduces similar documentation content both on its website and in the release's
--help output. Moreover, it lacks Bedrock specific man pages.
Nyla's development will shift documentation into a single source from which the website,
--help output, and man pages will be generated. Once implemented, this will reduce the documentation maintenance burden.
Over Poki's life, crossfs and etcfs have not evolved quite as originally expected, and technical debt is slowing slowing further development. They will be rewritten with the following architecture in order to expedite future development:
struct fuse_operationsfunctions that forward calls to module functions per the incoming file path categorization per the Bedrock configuration.
struct fuse_operationsfunctions. For example:
This modular architecture should expedite support for new Bedrock cross-stratum feature subsystems, such as eventual cross-stratum service and desktop environment support.
In Poki, each stratum has its own
etcfs instance. This both pollutes the process list and consumes more memory than necessary.
etcfs will be rewritten so that only one instance is needed, similar to
brl fetchrequires per-distro support files to be busybox shell scripts using an esoteric
brl fetchspecific format. Naga will generalize the API, treating them as general executables. This will make them easier to understand and implement for people new to the code base.
brl fetchdoes not support verifying bootstrap packages. Naga development will investigate the possibility of maintaining and utilizing distro-specific package verification keys.
The stratum status management code will be rewritten with the following goals:
brl repair, as people seem to misunderstand what it does. Instead, move the functionality into
brl enable, making
brl statusreport show/hide status
The Bedrock init selection menu will be rewritten with the following goals:
brl tutorial pmm.