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

Main Nav

External Links

Bedrock Linux Roadmap

The specific details of what Bedrock Linux hopes to accomplish varies from release to release as new techniques are found to enable functionality previously out of reach. Should major discoveries be found, the roadmap may change drastically. Below is a rough roadmap assuming no such major surprises occur.

Near future releases

There are several broad areas of improvement Bedrock Linux will focus on in the near future release:

Far future releases

Given the ambitious nature of the project, there is no guarantee every issue covered by the "near future releases" may be solvable. Eventually those working on Bedrock Linux will reach some limit with regards to how far Bedrock Linux can be pushed. Once this limit is reached, the development focus will move from research and user-facing polish towards improving underlying code quality.

While concepts such as high percent unit test coverage are admirable, the time/effort they require is largely wasted on early Bedrock Linux releases in which it is not only possible but likely a new feature will require a substantial change in strategy and, consequently, code. Once ideas to push Bedrock Linux have been exhausted and the general code churn slows this will change. Substantial refactoring/rewrites may be made as should they found to be beneficial, along with heavy use of tooling (e.g. valgrind) and test suites to minimize the chance of any Bedrock Linux bugs hampering a post-beta "stable" release.

Very far future releases

Bedrock Linux development has a number of self-imposed limitations followed to maximize the flexibility and minimize the maintenance efforts of the resulting system. For example, users should not be required to regularly compile kernel modules for Bedrock Linux specific features. Post 1.0 stable, the project may explore the benefits of dropping some of these requirements. For example, it may be worthwhile to have a single kernel module which handles all of the filesystem redirection and abstraction on which Bedrock Linux depends. If it becomes evident a substantially improved system would result, work towards a 2.x release to replace 1.x may then follow. If it becomes evident there is a trade-off with no clear net win or loss, a 2.x may follow along to be developed alongside a maintained 1.x for those who prefer it.