I was curious about the same, so had a look round.

The main innovation in blendOS is the "blend" package manager: https://github.com/blend-os/blend

Under the hood, this uses "distrobox" to create containers for supported distributions: https://github.com/89luca89/distrobox

Supported distributions are defined in "blend" here: https://github.com/blend-os/blend/blob/4e4bdd33d2de374cb01e4...

Additionally, there are wrappers for commands like "apt", which in turn call "blend", which in turn calls "distrobox": https://github.com/blend-os/blend/blob/main/pkgmanagers/apt

In contrast, Bedrock Linux has a quite different implementation, with the most widely used strategy being based on "strata" and a FUSE filesystem "crossfs". See "How does Bedrock Linux Work?" on https://bedrocklinux.org/faq.html#how-work

Right, Bedrock really plugs the various distros into each other in a deep way, and offers ways to do that for many components of the stack (init system, display server, network management stack, etc.)

It sounds like the blendOS approach is a bit coarser but probably also safer and less likely to be surprising to non-expert users.

`blend` seems like it could potentially be adapted and usefully added to almost any distro as a feature that users could enable/install if they want, whereas Bedrock Linux might be a useful upstream for more custom distros where things are more tightly integrated.

Anyway it's cool to see a distro developer writing tools like this because there's a lot to learn from Linux package managers, but there's also a lot of space between the state of the art and what's in common use. Writing tools like this might be the kind of practice one needs for putting together something next-gen which incorporates the state of the art but suits mainstream tasted and benefits from hindsight.

I can speak authoritatively for Bedrock Linux, although blendOS is new to me. From what I can tell reading about blendOS, key differences seem to be:

- blendOS appears to use a common host-container relationship, with automation to make things in containers transparently accessible in the host. Bedrock does not currently privilege a section of the system like this; everything is "equal." The Bedrock philosophy here is that privileging a section like this is limiting; it essentially defines a section of the system which must come from one distro rather than have the same flexibility as other sections of being able to come from any (supported) distro. The downside to Bedrock's flexibility is that has a higher ceiling on complexity.

- blendOS's documentation refers to getting "apps" from other distributions, where as Bedrock's aim is as much as it can do. My guess is Bedrock lets you integrate more types of things across distro boundaries. Bootloader, kernel, init, desktop environments, fonts, man pages, shell completion, etc. Like the previous bullet point, this can be a mixed bag and result in a higher ceiling on complexity.

- I do not see blendOS mentioning the ability to run systemd services from different distros. However, it seems to be built on distrobox, which does offer such a thing by leveraging systemd's ability to manage services in host-container relationships, and so my guess is blendOS can or easily could/will allow for such functionality. Bedrock does not currently offer this. Bedrock explicitly is not containers, and so it does not support multiple simultaneous init systems like this. Bedrock has an alternative on the roadmap, but it's a very long ways away.

I think a closer alternative to blendOS would be Vanilla OS [0]. Like blendOS, it has an immutable "base", although it is Ubuntu-based rather than Arch-based.

[0] https://vanillaos.org/