New Distro 'BlendOS' Combines Arch Linux, Fedora Linux and Ubuntu
blendos.co
blendos.co
I'm guessing the rest is just chrome, and getting a base OS of some form down, so you can use distrobox.
Read what the page says, then look one layer deeper. You may want to use distrobox in on your existing machine to try things out.
I get why it may be useful in a few situations, like you want to test code for a server running a certain distro, I suppose.
But it's not like there's exclusive software between the three, or a huge difference between them besides some pre-installed software.
The immutable filesystem seems interesting, but I'm still not sure what the advantage to it is. How would you install software on a read only system?
I don't know about this particular system, but generally you install software on overlay filesystems.
macOS has an immutable (by default) root filesystem. The Steam Deck does that as well.
It helps keep the core system free of malware.
I'm not sure about macOS but my understanding is that the Steam Deck does upgrades in a blue-green fashion so if something goes wrong, the previous, known good system is still available.
macOS obviously has its desktop environment as part of the image, which makes it difficult to accidentally destroy your desktop environment, is that true of SteamOS too? Seems like it’d be smart if the immutable image at least included a minimal fallback like IceWM or something that it spins up if say the package manager loses its marbles while resolving dependencies or something and eats the stock KDE install.
Many developers only bother packaging their apps and software for one platform (e.g. only on a PPA or only on the AUR), which makes it hard to use on others.
More seriously: if you're writing software for Linux, this sort of thing could be a boon for packaging that software.
> The immutable filesystem seems interesting, but I'm still not sure what the advantage to it is. How would you install software on a read only system?
Usually it's just the root FS that's read-only; /home is usually still r/w, so applications would get installed there (or into some other FS that's r/w and not root). This approach ain't terribly new - openSUSE's MicroOS and Valve's SteamOS 3.0 are both good instances of prior art, and I'm pretty sure Android and ChromeOS work similarly - but it's cool to see this idea continue to catch on.
Distrobox is on my to-do list to try out and see if I can hack something together to scratch that itch. This BlendOS might be another option.
Ah, yes, Fedora, Arch, and Ubuntu. That's all of them.
Edit: In retrospect this comment is a little mean, but as someone who uses a distro that isn't one of the "big three", I am pretty tired of the assumption that everyone runs Ubuntu et al. that you frequently see in the blogosphere and elsewhere. Or even the implication, as you see here, that Ubuntu et al. are the only distros.
Might I nominate
> A seamless blend of your favorite Linux distributions.
as a tagline?
Big props to the creator. This is impressive work, especially for one so young.
BlendOS also looks like it could be quite nice for developers who want to be able to quickly build and test locally for a few major distros.
It is a fact of statistics, and a fact of your personal choices vis a vis others' personal choices. But then I consider the language implying victimization, and I wonder why you react in that way.
> Ah, yes, Fedora, Arch, and Ubuntu. That's all of them.
I think the idea is to be able to run applications distributed via Pacman, DNF, and apt (which encompasses many more distros than the named three) rather than needlessly put every single distro into one. It is poorly worded, I'll give you that.
It doesn't really work that way, though. Compatibility runs deeper than that. You can't generally just take a Fedora package and install it on openSUSE or vice-versa, even though you can run DNF on both.
Same for any two releases of a given distro. You can only reliably do this kind of thing where one distro is directly downstream of one another, version for version, like Pop and Ubuntu.
Proprietary software's Linux repos often obscure this, by shipping a big runtime for a package, bundling a ton of deps, so you may not notice this if you only ever add repos for Chrome and Discord via their vendors or whatever. (Not recommended, btw— proprietary software repos for Linux distros are notoriously ill-behaved, often in a way that poses a security risk.)
Did not really come across as mean, just a bit butthurt with a dash of cringe.
> Or even the implication, as you see here, that Ubuntu et al. are the only distros.
They are the only distros for the majority of people out there, most popular and the ones most people know. Smaller distributions need a novel feature to justify the work of implementation i.e the package manager of Nix
- Ultimately this seems to trace back to a bug in the Linux kernel. Sadly, I don't see any reason to believe it's going to be resolved in the kernel any time soon.
- A potential medium-term fix is for Bedrock to offer the corresponding functionality via a kernel module, and to fall back to a FUSE implementation if the module is unavailable (e.g. if you reboot into a kernel that breaks compatibility with the module). The proper way to do this would be via dkms, but is thus blocked on cross-distro dkms functionality. This is a realistic route, but given limited project resources it's likely quite a ways away.
- The long-term fix is to upstream Bedrock's required functionality into the Linux kernel directly. The main issue here is that we don't know exactly what functionality Bedrock actually needs here; it's often changed quite a bit from release to release. Keeping it out of the kernel tree - and using dkms/FUSE - offers needed flexibility in Bedrock Linux's pre-1.0 period.
The creator of one of my favorite distros from my own childhood also started as a Linux distro developer when he was in high school. By the time he went to college he wrote his own (excellent) package manager from scratch for the distro that grew out of those same efforts. blendOS might grow into something that surprises all of us some day. :)
What's the process for adding/porting another distro?
--
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
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.
- 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.
edit: Debian or RHEL/CentOS due to the support contracts
But yeah, in principle I agree.
Sounds like bloatware.
The mutable package management model is broken by design. What we need is a better interface for something that actually works
Different goals,and different audiences.
But, I need to find time in my otherwise busy work- and home-life to learn it all -- every blog post I read describes it as a HUGE learning curve, etc, etc.
Maybe in a few years when that "interface" you describe is ironed out and made more accessible, then I'm in, but right now the ROI of my time investment doesn't look to be worth it for me.
Consider, say:
Arch Linux is bleeding edge, but requires a lot of knowledge / elbow grease to get working.
NixOS allows for declaring the whole operating system from a consistent entry point; but has a steep learning curve.
But when updates didn't roll into Debian Testing timely this has usually real reasons. Most of the time you don't want those updates on any productive system as there are severe issues. (Except when some more exotic software package doesn't have a proper maintainer team behind; than updates may be delayed even infinitely; but in this cases the quality of the maybe existing AUR packages also often isn't good; exotic stuff is just less supported everywhere.)
me having a personal preference on a car
or
a bunch of projects existing, working towards wasteful goals instead of ceasing to exist, uniting, and working towards more meaningful goals
100,000 developers across the world working on 1,000 different Linux distributions each with slightly different takes on init + package managers (managing bugs/releases/documentation) hurts the general population because if they used their time (resources) on something better, we'd all (potentially) benefit
Consolidation might allow some of those auto companies to build better vehicles, but it would also reduce the diversity of vehicles on the market. Both of these factors affect all users and all potential users.
Linux distributions are similar. Each user chooses a distribution that best fits their needs and preferences. Consolidation might improve the quality of some of these distributions, but it would also reduce the likelihood that a user finds a distro that is just right for them.
As long as a vehicle model or Linux distribution is able to attract a user base that drives its creators to continue developing it, it has earned a place on the market.
Debian stable will have packages that feel very out of date. Debian unstable (sid) makes no guarantees that an update won't introduce breaking changes.
Fedora Linux has six month major releases, so the packages feel fresher than Debian stable, but are much more stable than Debian unstable. The six month major release vs a rolling release means twice a year you'll have to watch an update carefully.
The barrier of entry for releasing an AUR package is incompatible with my standards of system security, so I refuse to use them. The official repositories feel a little bare in comparison to Fedora and Debian because they have an expectation that AUR will fill in any gaps.
Doesn't that make all of the efforts spent maintaining separate package managers even worse? It's bikeshedding/hairsplitting at some point, no?
I'm talking about developing + maintaining yum/apt/pacman
Let alone what it takes to maintain 20,000+ (or however many the real number is) packages shipped slightly differently for each repo
Someone mentioned debian-testing, and I agree it gets updates more quickly which is great, and solves for half the problem
However, when you want to make a change to one of those packages, it's probably going to take me a couple days of playing around with the dev tools to repackage it and install
Archlinux's abstractions around this are really good. You download the ABS store, cd into your package and view the pkgbuild file. Once you have abs downloaded, you can edit it and install it like any other aur package
Yes, I've built my own debs, yes I've built my own rpms; abs and aur are miles ahead in this regard
*It's basically Arch + distrobox which handles all the low-level work.
pretty impressive, surely I couldn't pull this off when I was 13.
When I see teenagers founding Linux distros and reverse engineering GPUs it seems a little crazy. Impressive and good, but it’s hard to imagine being that technically capable at that age.
One of the issues many commenters on hacker news have with MacOS is SIP which is exactly this. "If random binaries on my system can't overwrite kernel modules on disk, it's oppression!"
To clarify: SIP is a world-wide large-scale security improvement that people need, especially those that have no clue how their stuff works. Nix is a technical feat that has almost no reach.
macOS uses a snapshotting filesystem by default but doesn't let you create labeled snapshots, or enable automatic snapshotting without cluttering your snapshot list with time-based snapshots or enabling auto-pruning.
macOS doesn't have any of the features that help with disaster recovery, reverting upgrades, etc., that draw people towards immutable Linux, snapshotting filesystems, etc. This is true of not just NixOS and GuixSD, but also Fedora Silverblue, openSUSE MicroOS, and to some extent even non-immutable distros that run snapper integrations with their package managers, and so on.
On the other hand, part of what people are after with immutable Linux is greater separation from the base system and applications, which macOS 10+ has always had.
The post you're replying to is (rudely, dismissively) noting a disconnect between what people in the Linux community (relevant for this article!) and perhaps also on HN actually care for in immutable OSes and the idea that SIP should be agreeable to the same crowd because it is about 'immutability'. And it's right!
Do you truly in your deepest heart of hearts believe that the over 2 billion users that get SIP have any clue about what you are talking about? ;-) (probably also what you're getting at anyway)
You wrote about a bunch of facts, which are true, but it also misses the forest for the trees in a different way. Even if you paid everyone to use Nix, they wouldn't be doing it, because it doesn't fit within their use case ergonomics.
And then there are the technical facts, SIP isn't the same as immutability, it's a mandatory access control where root isn't getting any special treatment. I suppose from a end-user's perspective the 'result' feels similar: no matter how much sudo and su you type, writing/modifying isn't happening.
That is what I was getting at in general: immutability (and reproducible builds of course! without those, what is the point of immutability, what would we measure it against?) is surprisingly little-understood for what it is. As you point out, you can for example use it as a chain of snapshots that with writes can go forward in time but never backwards. Or you could see it as a package-based construction where the packages and their contents are not mutable, but which package you use is. Or if we'd be talking about layers, we could have a union-esque representation of multiple immutable layers together forming a complete rootfs.
As far as I understand, BlendOS is mainly Arch + Docker, but with some added WSL2-like UI sugar. That makes it about as immutable as Docker itself, which is to say: depends on how you configure it, since there are no mutability guarantees with docker, only intentions. You can use cgroups2 to make sure the namespace will never be able to write to an actual persistence store, but at that point people are re-inventing ZFS.
SIP itself is best comparable to mandatory access control, where UID 0 doesn't get to bypass MAC. But if you get something that has the right entitlements, it's just another ACL. Imagine getting a busybox binary with the right entitlements: SIP would let you do anything.
Yes. And it's an area where desktop Linux is really lagging— we don't have much in the way of very simple, toggleable MAC. (We just have the heavy duty stuff where you have to write policies per application in a complex DSL.)
But you can see why that's not exciting, and potentially even annoying, to hackers who want features and capabilities. Barriers aren't fun, even when they're useful and necessary.
> As far as I understand, BlendOS is mainly Arch + Docker, but with some added WSL2-like UI sugar. That makes it about as immutable as Docker itself, which is to say: depends on how you configure it, since there are no mutability guarantees with docker, only intentions. You can use cgroups2 to make sure the namespace will never be able to write to an actual persistence store, but at that point people are re-inventing ZFS.
I admit I don't understand why Distrobox uses OCI with Docker or Podman rather than LXC. Docker is centered on containers that are basically glorified, heavyweight processes. Docker is for shipping individual applications, not persistent operating system environments.
LXC containers, on the other hand, really are system containers— they're for whole, persistent environments rather than for individual, disposable processes. And LXC natively supports snapshotting containers, just like you might do on a VM. So with the appropriate container technology, you don't need to reinvent (or leverage) a CoW filesystem on the metal like ZFS or BTRFS.
You could totally have a tool like `blend` wrap `lxc snapshot` or whatever before and after the guest package manager operations to give you the ability to rollback even each ad-hoc action of the various guest package managers. This is how BTRFS snapshot integration works for pacman via Snapper today, for example. Other package managers integrate it via plugins to the same effect. You'd just be applying the same technique across multiple containerized systems here. You would get time travel, if not reproducibility. :)
Considering all those technologies (LCX, cgv2, Jails, Zones, containerd etc.), you'd think we're all heading for the same goal and might as well combine strengths instead of yet another packaging/state manager method. Maybe once Snap, Flatpak, Nix etc. all get one or two generational replacements we'll get the state/mutability/layered approach right (at least on Linux) and we can all focus on MAC in a way that is less convoluted than LSM/AppArmor etc. But I bet we'll all still be in SBOM hell for years to come before that gets attention again.
https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-repro...
The only feature that makes sense in 2023.
Having a root user with full system r/w permissions had always been a bad idea since the days of UNIX, which is not designed for security uses. Now in 2023 at least one distro makes the change to a fully read-only file system, by default.
Perhaps smashing up the popular distros that have caused this Linux desktop fragmentation for years into an all-in-one fully compatible single distro is the only hope of a Linux desktop standard coming out of this rather than the confusing 'choice' contraption that no-one can define Linux Desktop support for.
mount -o ro,remount /
?
You might have unattended upgrades that fail for instance. Or journal logs failing to be saved.
It can work, but it needs work.
Today we also have Fedora IoT [1] & Silverblue [2].
Seems like a clear security win. /s
The immutability is handled by "nearly", created for blendOS: https://github.com/blend-os/nearly
(In turn, "nearly" is called by the "blend" package manager, e.g., "sudo nearly enter rw", "sudo nearly enter ro" - https://github.com/blend-os/blend/blob/main/blend)
At the heart of "nearly" is toggling inode flag "FS_IMMUTABLE_FL" (equivalent to "chattr +i" / "chattr -i") on each file within specified directories (currently "/usr"): https://github.com/blend-os/nearly/blob/3bb6f662818545cba1eb...
https://en.wikipedia.org/wiki/Hydra_(software)
Already been done? Not that it changes anything, blend is a pretty common word.