See the Introduction to Bedrock.
The exact details may change drastically from release-to-release, but the general concept is explained here.
clientBedrock Linux, or something as simple as fixing typos. Once you have something to submit, stop by the website git repo.
Bedrock Linux's functionality differs from virtual machines in three key ways:
clients, there is little to stop it from affecting the rest of the system. Virtual machines, by their very design, sandbox the
clients, such that an attack on one of them will have a difficult time propagating to others.
Containers contain things. They, purposefully, keep the contained software from interacting with the rest of the system. This has numerous benefits:
However, containers have disadvantages as well:
Things within containers are kept from interacting with each other. For
things which run as stand-alone services, such as web servers like apache and
nginx, this is not a problem. However, other software is intended to coexist
with like software. Containing things such as
separate containers would significantly reduce the benefit of each.
Services such as Docker can be used to create what are effectively very portable packages. However, someone has to do some work to create these packages. One cannot simply grab a .deb or .tar.gz from the repositories of other Linux distributions, drop them in a container and expect them to work.
Where containers are useful, one is certainly encouraged to use them. However,
one cannot be realistically expected to contain everything independently. What
most Linux distributions do is provide software that can interact natively
for when that is useful. Bedrock Linux is no different here, conceptually,
from other major distributions. What makes Bedrock Linux unique is that the
software it can install natively is provided from a very large variety of
sources. If one wants to use
mkdir from one distribution and
another, for whatever reason, Bedrock Linux, for the most part, can make this
happen. A more realistic example would be utilizing xorg from one distribution
and a window manager or desktop environment from another - neither is good
alone, they need to interact, but there could be legitimate reasons to want
them from different distributions. See the compiz story
here, for example.
Containers and Bedrock Linux have very different goals and go about them by largely different means. The two are not in competition in any way; in fact, one could run Bedrock Linux in a container, or run containers on top of Bedrock Linux, no different than any other distribution.
If there is an estimate for a release, it will be stated in the index page for the specific release. If not, then it will be released when it is done.
Bedrock Linux does not do very much by itself; rather, it is the foundation upon which other Linux distributions are placed. Initial ideas for a name were intent on reflecting this fact. Other proposed names included "Foundation Linux", "Frame Linux" and "Scaffolding Linux". The name chosen has nothing to do with the television show The Flintstones.
All of the Bedrock Linux releases are named after characters from the Nickelodeon television program Avatar: The Last Air Bender.
The system requirements are listed in the specific pages for each release. This is done in case changes between versions alter the system requirements. The system requirements for the initial alpha can be found here.
At the time of writing, the immediate goal is to figure out how to do everything Bedrock Linux is trying to do. Retaining full control of the underlying system simplifies development, and so that is what we are doing at this point in time. Bedrock Linux changes so much between releases it is not possible to say whether, when it has achieved the desired feature set, the techniques it is using could be cleanly implemented on top of another distribution. If it is found to be cleanly possible, the Bedrock Linux developers will likely attempt to package and provide code for other use on top of other distributions. That is still too far out to say.
However, even if it is possible to run Bedrock Linux code on top of another
distribution get the desired effect, there will be a number of downsides to
doing so, and so Bedrock Linux will still benefit from being its own
distribution. In theory, once Bedrock Linux is feature complete, the base
distribution would not be able to provide anything one would not be able to get
client. As a result, the base distribution should be as small as is
possible while still being able to provide the necessarily functionality to
Anything more than being able to utilize things from
unnecessary overhead. Most distributions would consume disk and RAM
unnecessarily in this situation.
If code from a
client breaks, one should be able to easily get it from
client. However, the base distribution is a single-point of
failure and, thus, it should be minimized.
Bedrock Linux provides some useful functionality for maintain
However, this would not extend to the base distribution. Thus, again, the
base distribution should be minimized to limit maintenance.
Finally, consider the possibility that there may not end up being a functional
difference between installing Bedrock Linux as the base and some other
distribution as a
client, and installing Bedrock Linux "on top" of some
other distribution, only to end up morphing it into the exact same system.
What really is a "base"?
Bedrock Linux is not based on or an offshoot of any other Linux distribution; it was written "from scratch." It has unusual twin goals of needing to be as minimal as possible while supporting the features necessary for a full-blown desktop. Rather than attempting to tweak an existing distribution into such a shape a new one was made from the ground up.
An argument could be made either way if Bedrock Linux was still in the planning stages, prior to any functional release, but since Bedrock Linux was publicly announced along with a functional (if unpolished) alpha: yes. Not only is it possible, it has been done, and the necessities for you to see this for yourself have been made available if you don't want to take my word for it. Much work needs to be done such as polish and the addition of many features, but the core idea has been proven quite definitively to work.
It should be noted that no other operating system family has such a disparate variety of userlands which all run on the same kernel. Bedrock Linux's strengths wouldn't be nearly as beneficial anywhere else. Attempting to do something such as Bedrock Linux will inherently require leveraging operating-system-specific tools, and so it may require a fair bit of additional research to port Bedrock Linux's tools to another platform. Bedrock Linux is still under heavily development and changes quite a bit between releases. It may be best to first wait for Bedrock Linux to settle on one strategy before putting the efforts to port it elsewhere to avoid wasted effort.
Android's utilities may be dependent on Android's patches to the Linux kernel. However, "traditional" Linux programs seem to run fine on the Android kernel. Thus, any port of Bedrock Linux to android would likely require an Android kernel to be used.
The Android file system layout is significantly different from traditional Linux distributions. PATH and bind-mount system changes may be required.
Android does some unusual things with its UID/GIDs. For example, does not seem to be a UID-username map at /etc/passwd as one would expect from other Linux-based operating systems. UID namespaces and brc-style translation programs may be necessary.