I’m very impressed that Rudra is apparently 13 years old and has built this. Despite the fact that I started coding around 12 years old, I’m pretty sure I wasn’t capable of building something like this at 13. That’s really awesome. His parents should be proud!
I think 13 year olds can make great software, and I have no doubt that the person who made this is intelligent.
Like any distro, I would probably not trust it in production until it’s been around awhile (though I might play with it). This isn’t a product of the creators age, though, just a product of hacker culture.
> 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 does. It also suits very well the use case of the personal computer and other personal devices, as exemplified with macOS and the Steam Deck.
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.
Immutable base image also reduces chances of software that’s not malware unintentionally screwing things up or putting files in places it has no business putting them (as Adobe loves to do).
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.
There are some professional software, like AMD's ROCm that only work properly in a few officially supported Distro's. `amdgpu-install` specifically checks what distro you are on and refuses to proceed when it encounters unfamiliar OS releases. It's a headache to work around.
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.
Maybe I’m wrong, but I kind of think that if Linux wants widespread adaption, there gas to be a one stop solution for users, instead of a distro thats ideal for ML, a distro ideal for video editing (looking at you davinci resolve), a distro for audio editing, a distro for streaming and a distro for gaming (surprisingly all distros). Maybe that involves a kernel implementation that can handle all of that (seemingly easier said than done) or a convergent distro, or flatpaks, or scripts that seeks updates im the source code…
At this point I'm kind of leaning toward the opposite: if it was easy to install a bunch of tiny distros alongside each other that each do one thing and do it well, I'd be down to switch over to that. Being able to fire up a dedicated "mode" for programming v. music composition/production v. general leisure (and being able to quickly switch modes without losing state) would be awesome both from an "I want to make sure the software I need runs in as optimal an environment as possible" standpoint and an "I want to be explicitly in a programming/music/leisure headspace right now and don't want distractions" standpoint.
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.
Reducing fragmentation for Linux desktop end-users?
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.
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.
From what I can tell, as a meta distribution, it technically supports a lot more distributions, but Arch, Ubuntu, and Fedora are the highlighted (and officially supported) ones.
> 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.
> 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.)
Perhaps 'all distros' is more aspirational? I hope so, because while I see less use for more conventional distros like those currently given, something similar could be a really nice escape hatch for distros with less conventional, less compatible bases. Combining a distro like Fedora with one like NixOS, GuixSD, Alpine, Void Linux, etc. could be much more valuable.
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.
> I am pretty tired of the assumption that everyone runs Ubuntu et al.
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.
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
I tried Bedrock on a throwaway machine, but gave up on it because Linux wouldn't sleep properly when the FUSE server process got suspended before the applications with ongoing filesystem operations could complete to a suspendable state: https://www.reddit.com/r/bedrocklinux/comments/h8sgkk/suspen...
I've looked into this further since the link you've provided. I have medium/long term ideas to work around this, but nothing in the short term:
- 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.
Before people come to early conclusions, remember that this is done by Rudra Saraswat, a known figure in the FOSS scene. I guess it's more than just another distro doomed to die quickly.
Is that the kid who maintains Unity 7 these days? My (very distant) impression is that he gets taken seriously by collaborators because he does serious work, so he's not limited to gimmicks. I don't think he makes stuff just to put his name on it, but because he really wants to do something.
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. :)
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.
A similar project is Vanilla OS (https://vanillaos.org/). It has its own `apx` package manager, which has roughly the same interface as apt, but also supports installing packages from Fedora or Arch - though it encourages using Flatpaks where possible, as the other packages run inside containers.
Honest question, why does anybody typically need anything other than Debian? Imagine if we took all of the resources used in the different flavors of BSD/Linux distributions and paired them to more common goals instead of doing the same thing (package management, init) slightly different ways. Seems like a huge amount of waste on a massive scale.
edit: Debian or RHEL/CentOS due to the support contracts
I think you might be underestimating how different package management is between Debian, Arch, and Fedora. This also ignores the many other differences.
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.
Arch Linux is most of the time not more "bleeding edge" than Debian Testing.
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.)
Personally I don't like debian because of how hard it is to crack to make changes
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
While I use debian for all my personal stuff (and years ago before that - slackware ) most my employers have used RHEL or CentOS due to the support contract (or potential to easy transition to RHEL with support in the centos case). This satisfied both compliance and contractual needs.
How are these not exactly the same thing? If Toyota only made one car, it would be better and cheaper, so why don't they consolidate their efforts instead of "working towards wasteful goals"?
Me choosing to spend my extra resources (money) on something that I prefer above the base (something other than a Toyota Corolla) only hurts me
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
Millions of auto company employees across the world have designed and built thousands of vehicle models. Many of these models overlap in terms of form factors, use cases, and target markets.
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.
I would love to get into NixOS, and have contemplated diving into it for some time, as I agree with you fully about the mutability point.
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.
Goal seems similar to Bedrock but implementation* differs. This one seems more desktop oriented, more stable (uses a a conventional approach of containerization of other distros), but also less flexible (Bedrock allows mix-and-matching even system packages).
*It's basically Arch + distrobox which handles all the low-level work.
Yeah, if my memory isn’t failing me, at that age I think I was mostly doing desktop customization stuff by downloading/making Kaleidoscope schemes and wallpapers and editing resource forks with ResEdit. I’d started dabbling in REALBasic and could build some toy apps with it, but nothing terribly complex or useful.
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.
Praising children, even when it involves a nominal comparison to oneself 'at that age' or whatever, is about celebrating their successes, not actually competing with them.
I'm surprised they're advertising immutability on here.
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!"
On the contrary, I like having SIP turned on so long as there’s a a way to turn it off. With as many 0days as there are floating around now and how sophisticated phishing and social engineering is becoming, I don’t want to make things any easier for a bad actor than I have to… anything that can reduce the impact crater is good. Yeah I write software for a living but that doesn’t mean I’m magically immune to this stuff, and I so rarely need to modify the root filesystem any more that it’s not much of an inconvenience.
With Linux, the word "immutable" (in the context of a file system) doesn't ever actually mean it can't be changed. Here's it explained better than I ever could:
Imagine confusing Nix for something a large user base actually wants.
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.
No, you're missing something here. What people are after with immutable Linux isn't generally security like SIP provides. 'Immutable Linux' is about many of the features Nix provides, like atomicity of upgrades and rollbacks. But it still also has a packaged base, unlike macOS, and is generally more flexible than any tools for interacting with the base system.
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!
tl;dr: agree, but there are some valuable semantics that matter more than we think.
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.
> SIP itself is best comparable to mandatory access control, where UID 0 doesn't get to bypass MAC.
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. :)
If I'm not mistaken, Sun did the same thing with Solaris and ZFS; rolling forwards or backwards was just a matter of choosing the rootfs snapshot of choice. You can even run multiple zones from the same base snapshot and have their own (ephemeral) writes on their own timelines. And on BSD we can do similar things with Jails.
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.
> blendOS is an immutable operating system. This means your filesystem is read-only, thus resulting in stable experience.
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.
What happens when the same app is installed from both RPM and APT? Does it correctly say that it is already installed? Or does it overwrite and cause conflicts and issues down the line?
Anyone know how the immutability is handled? I've seen OSTree, btrfs snapshots, and partition swapping in the wild; very interested to know the take here.
The primary distinguishing feature between linux distros is the package manager, the secondary distinguishing feature is how the network is configured, that is going away as network manager becomes more common. Anyway forget the network config, my point is that having more than one package manager does no one any favors, so they are going to have to pick one.
It's just an immutable Arch Linux based distro using distrobox to provide the other distro packages. It has some pretty nice polish & the blend package manager seems good, but it's really nothing I can't do myself with some time; even if it's a little crude compared to what he has here.
