GNU/Linux "immutable" distro BlendOS

[DiTBho]

it's here, it's still a beta version, but it's interesting as it allows the final user to have apps from any of the distributions { Arch, Fedora, Ubuntu, Corel, ... }, even Android.

Unlike all other immutable distributions, there is a mechanism that allows you to install system packages normally, thanks to an "overlay system"(1), that also allows you to "roll back"(2) to existing snapshots.


(1) similar to merge-fs, which is what I usually use.
(2) it's not 100% working at the moment, and ... you cannot "step back", if you can only "roll back", which means that your reset everything to factory defaults, losing everything you've modified. Not good.

[Marco]

I've always liked the idea of overlay filesystems since I saw it used in Skyrim modding. Just automatically having a set of all the root configuration files I personally changed would be very handy ... I could personally keep track of that of course, but I'm far far too lazy for that.

I was just looking at mergerfs, was considering trying it for running 32 bit steam games which are incompatible with XFS (due to 64 bit inodes). Bit high overhead though for normal use.

[MK14]

A question for anybody.  Are there any drawbacks to this OS?

Such as the package installations taking up excessive amounts of disk space, lots of annoying bugs or runs rather slowly, even on decent hardware, and so on.

Things are often good at listing the feature list, which I treat like a pro's list.  But, I'd prefer to see a list of the con's as well, so that I can make a balanced decision.

[MK14]

Well, to answer my own post.

I can't seem to easily find a Wiki article about it, but maybe I didn't search hard enough.

On Distro Watch:
https://distrowatch.com/dwres.php?resource=ratings&distro=blendos

There seem to be around 8 reviews, which in a very quick and approximate summary.  Seem to be saying, it is a cool, neat and promising idea, which could be useful when ready (e.g. Android development work).

But, currently, has too many issues/problems/bugs with it.  It does superficially work, initially with some things.  But, with slightly more taxing things, soon starts to play up, rather badly.

To make matters worse, apparently the very limited support options, are too fixed and require using a method, which some/many won't be happy to use. (Telegram).

[DiTBho]

(it's beta state)

[MK14]

(it's beta state)

So, for fun playing around with at the moment, presumably educational, but not ready for serious or real work, yet.

Interesting OS idea, anyway, thanks!

[MK14]

Don't get me wrong.  I'm still very interested in it.  These immutable OS systems, sound promising for robustness, integrity and security of the operating system.  The concept of having a Linux system, which is able to accept, a wide range of Linux package types and the fact it is based on a (as I understand) containerisation mechanism.  Make it sound very interesting.

It's a pity, (like you said) it is not out of beta, but still a useful entity, for some purposes.

Although I'm generally a fan of Linux/BSD, the relative lack of standardisation, as regards packages, installation and dependencies, between different flavours of Linux/BSD, can be annoying at times.

As much as I have serious gripes about windows (or more accurately Microsoft), the fact that there can be files, which just simply install by clicking on them (in many cases), is a desirable and very useful method.  Rather than having many different methods, each with their own idiosyncrasies.

E.g. (On Linux's, when installing software) Some take too long (need lots of compiling), are too big to quickly download (e.g. snaps, seems 650MB is somewhat common), have too many potential dependency issues, or simply tend to just not work, e.g. many things, more than perhaps 5 or 10 years old (because of lack of a maintainer), tend to be difficult to install and whose dependencies can be very problematic.

I sometimes wish they could come up with a universal Linux/BSD packaging/installing/dependency-resolving system, that almost all distributions can agree upon.  So, in that respect, things can be much more like windows single file system (except even windows can have variations, such as 32 bit, 64 bit, XP/win7 and Win 10/11 versions, etc).

[SiliconWizard]

So it's "immutable", but not really.

[MK14]

So it's "immutable", but not really.

It's 100% waterproof, but don't ever get it wet or damp, as water can get in.

[SiliconWizard]

Jokes aside, as far as I had gotten it before BlendOS, an "immutable" LInux distro was a Linux install that could run on read-only storage with no major loss of functionality.

But "immutable" is currently one of those buzzwords, so you never quite know what it's supposed to mean now.

Next big breakthrough in physics may very well be the immutable oscillator.

[MK14]

Jokes aside, as far as I had gotten it before BlendOS, an "immutable" LInux distro was a Linux install that could run on read-only storage with no major loss of functionality.

But "immutable" is currently one of those buzzwords, so you never quite know what it's supposed to mean now.

Next big breakthrough in physics may very well be the immutable oscillator.

It's suppose to mean (as I understand it) that the OS (main install and working gubbins), can't be altered (even though it can be written to in theory).  To hopefully, much more effectively make it relatively hack proof, and bug free (as regards things inadvertently changing things during installation of software and stuff).
Hence giving a fixed platform, so anything that does get installed (elsewhere on the system), knows exactly what that exact version of the OS, consists of.  Hence potential reduction or elimination of dependency nightmares, as the OS should be (or is, hence immutable) fixed, between significant versions (releases),

But it is a bit like inventing a much better air-defence system or safe.  Sooner or later, the enemies (or safe crackers), create better missiles and/or aircraft, which defeat it, until even better air-defence systems are invented.

So the hackers/malware/etc, will probably just end up getting better, until they succeed again.

[Marco]

As much as I have serious gripes about windows (or more accurately Microsoft), the fact that there can be files, which just simply install by clicking on them (in many cases), is a desirable and very useful method.  Rather than having many different methods, each with their own idiosyncrasies.

Just installed Unigine benchmark from a run file and it worked just fine. 6 years old, meant for X.org but running under Xwayland. Ran a major distro upgrades while it was installed, still ran fine. Showed up in Ubuntu app view too. As long as you're fine with single user, then just by limiting your dependencies to the bare necessities and statically compiling everything, you can do this even under Linux.

Will that work for something multiple decades old? Probably not ... but no one else does backwards compatibility like Microsoft, they are ahead of everyone by a huge margin.

[MK14]

Just installed Unigine benchmark from a run file and it worked just fine. 6 years old, meant for X.org but running under Xwayland. Ran a major distro upgrades while it was installed, still ran fine. Showed up in Ubuntu app view too. As long as you're fine with single user, then just by limiting your dependencies to the bare necessities and statically compiling everything, you can do this even under Linux.

Will that work for something multiple decades old? Probably not ... but no one else does backwards compatibility like Microsoft, they are ahead of everyone by a huge margin.

I can accept, that some or even many or most (older) things can work, smoothly.  But some, just don't want to run, on modern Linux's.  At least not without major headaches.

Things like older 32-bit stuff (assuming you're running 64 bit) and things where the dependencies no longer exist and/or have changed a lot, can be rather problematic.

E.g. The 32-bit stuff, (incorrectly) assumed that the pointer size (32-bit) and integer size (32-bit) will always be the same, without bothering to use sizeof() etc (depending on the languages used, and other factors).

Edit: Hence it can mess up, e.g. they add 4 to a byte counter, to move to the next pointer or value, in an array, which now needs to be 64 bit not 32 bit.  So the missing sizeof(), ends up causing misalignments, and hence usually causes bugs or crashes etc.

I think psychologically, we (or just me), can put too much emphasis on the things which refuse to work, giving too much weight to the idea, that older stuff, doesn't work well.

It helps if the source code is available, but sometimes the original source code has been lost, further creating difficulties.  (E.g. The ancient link to the source code, now gives an error 404).

If it is very important, you can often, go back to a suitably old version of Linux (perhaps in a VM), and then run it.  Such as when dealing with very old files, in specific formats, such as rather dusty backups from an old system.

[DiTBho]

Jokes aside, as far as I had gotten it before BlendOS, an "immutable" LInux distro was a Linux install that could run on read-only storage with no major loss of functionality.

Things go inside $home, the system is really immutable, and users cannot modify the core because it's RO.
Even the admin can only add an overlay, and that's the only RW part.

[MK14]

Things go inside $home, the system is really immutable, and users cannot modify the core because it's RO.
Even the admin can only add an overlay, and that's the only RW part.

Although, on the one hand you are right, it is immutable, as described.  So, 100% water proof.

The fact it is beta, means that it may not really be 100% waterproof, especially under huge pressures (deep depths), as intended.  Because of possible mistakes in the beta OS.

E.g. The write protection mechanism(s), may have feasible ways of defeating them, through ring security level escalation exploits (hypothetical example).  So, although it was suppose to be 'immutable', there could be 'leaks' in its supposedly impenetrable armour.

Until it goes out of beta.  When hopefully, any such issues (only one hypothetical example given, but there are probably numerous other possible mistakes in beta versions), have been fixed, as necessary.

[DiTBho]

ring security level escalation exploits

I have a military laptop here; it has two PowerPC750 CPUs, the kernel (VxWorks) is loaded from Flash0 (8Mbyte), the rootfs is mounted RO from Flash1 (64Mbyte), /var and /tmp are mounted in ram, and $home  is mounted from an hw encrypted CF2 (LBA32).

The kernel Flash driver has ".write" method removed, so it's physically impossible to write into flash0 and/or flash1 without modifying the kernel, and reprogramming it requires physical access to the motherboard.

Game over, if you want to update the kernel or the rootfs, you have to:

• 1) to physically access the motherboard; not an easy task as the shell is waterproof, you need a suction cup to detach the hull
• 2) to turn on the write pin of the system flash0 and/or flash1
• 3) to turn on the boot serial
• 4) to attach a serial cable to the motherboard in order to download a special software able to reprogram the flash
  

VxWorks is a commercial OS, so I prepared a Linux kernel for the laptop, and a custom firmware (PPC assembly) to perpetually tftpboot from the optical network, so I can easily develop the kernel and the GNU/glibc-based rootfs without that "crazy" restrictions used for making VxWorks as RO.

And ... I think it must have cost as much as a Cadillac, a splash and waterproof laptop, which is no longer splash and water resistant as I damaged the seals to open it, in order to repurpose it as a dumb X11 terminal ...

... which is all LOL ... you know I love this kind of thing.

But hey? I am playing with a decommissioned military laptop, trashed away, among the many reasons to throw it away, because it was made when there were no dual-core CPUs, and cryptographic stuff was made by perpetually allocating a CPU in AMP to serve cryptographic stuff to the other CPU!

I have never seen an SMP PPC laptop around; PowerBooks from 603 to G3 to G4 only have one CPU!

Unfortunately, I am too ignorant to work on AMP and SMP kernel stuff, so ... the CPU1 stays disabled from the firmware up, while CPU0 runs Linux with no encryption for the CF2, which makes it even easier to deal with.

Anyway, apart from the uselessness of playing with unique military hardware in the world, you can get the idea about how deep the level of paranoia of a true "immutable" system can go

[DiTBho]

another example of a true "immutable" OS is Risc/OS (classic) on RiscPC/600!
The whole kernel and rootfs are stored in a couple of ROMs, and you can extend features with an overlay 

Weird filesystem, nice machines, deprecated. Modern Risc/OS for RPI is ... different, and boots from an SD-card.

[MK14]

ring security level escalation exploits

I have a military laptop here; it has two PowerPC750 CPUs, the kernel (VxWorks) is loaded from Flash0 (8Mbyte), the rootfs is mounted RO from Flash1 (64Mbyte), /var and /tmp are mounted in ram, and $home  is mounted from an hw encrypted CF2 (LBA32).

The kernel Flash driver has ".write" method removed, so it's physically impossible to write into flash0 and/or flash1 without modifying the kernel, and reprogramming it requires physical access to the motherboard.

Game over, if you want to update the kernel or the rootfs, you have to:

• 1) to physically access the motherboard; not an easy task as the shell is waterproof, you need a suction cup to detach the hull
• 2) to turn on the write pin of the system flash0 and/or flash1
• 3) to turn on the boot serial
• 4) to attach a serial cable to the motherboard in order to download a special software able to reprogram the flash
  

VxWorks is a commercial OS, so I prepared a Linux kernel for the laptop, and a custom firmware (PPC assembly) to perpetually tftpboot from the optical network, so I can easily develop the kernel and the GNU/glibc-based rootfs without that "crazy" restrictions used for making VxWorks as RO.

And ... I think it must have cost as much as a Cadillac, a splash and waterproof laptop, which is no longer splash and water resistant as I damaged the seals to open it, in order to repurpose it as a dumb X11 terminal ...

... which is all LOL ... you know I love this kind of thing.

But hey? I am playing with a decommissioned military laptop, trashed away, among the many reasons to throw it away, because it was made when there were no dual-core CPUs, and cryptographic stuff was made by perpetually allocating a CPU in AMP to serve cryptographic stuff to the other CPU!

I have never seen an SMP PPC laptop around; PowerBooks from 603 to G3 to G4 only have one CPU!

Unfortunately, I am too ignorant to work on AMP and SMP kernel stuff, so ... the CPU1 stays disabled from the firmware up, while CPU0 runs Linux with no encryption for the CF2, which makes it even easier to deal with.

Anyway, apart from the uselessness of playing with unique military hardware in the world, you can get the idea about how deep the level of paranoia of a true "immutable" system can go

Thanks, that is very interesting.  That does sound very safe, at least as regards, keeping the appropriate parts of the flash system, as read only, when required.

Hackers and/or hacking researchers, seem to find amazingly ingenious ways of hacking into systems.  So, I'd be very reluctance, to declare something as being 100% safe.

I can understand the paranoia.  Some secrets, e.g. codes to DISABLE a huge bunch of nuclear (deterrent/MAD) response missiles.  If obtained by the enemy(s).  Could allow those enemies, to launch a massive attack (either conventional, nuclear or both), in the knowledge that they have DISABLED the opponents nuclear (deterrent) defences.

Of course the US, has a number of separate nuclear defence (attack) systems, so even if one of the methods was taken out of action.  They would still have plenty of reserve capabilities.

The thing with something being at beta, is that it is not clear, how near production release it actually is.  E.g. Some things end up getting to R.C.5. (Release Candidate 5), at around the time of official (stable) release version.

I.e. If this BlendOS, is somewhat ready to be used, although it is beta, or not really ready yet.  I.e. Does it crash every few seconds or minutes, which wouldn't be very good, or every other year?  Which would at least make it useable for non-critical, experimentation and stuff.

I think the real answer is for me to have a play with BlendOS, sooner rather than later.

[SiliconWizard]

As long as it can run "overlays" then it's not "immutable", you just basically have a fallback core that can't be altered, this is absolutely nothing new.
Unless the overlays can't do anything too low-level (which I guess is going to be pretty limlting), there is no real benefit in terms of security, except the ability to revert back to something stable/secure, which you can do with backups or with any snapshotting filesystem.

[MK14]

As long as it can run "overlays" then it's not "immutable", you just basically have a fallback core that can't be altered, this is absolutely nothing new.
Unless the overlays can't do anything too low-level (which I guess is going to be pretty limlting), there is no real benefit in terms of security, except the ability to revert back to something stable/secure, which you can do with backups or with any snapshotting filesystem.

If I understand things correctly with BlendOS, then not really.

Because things run inside their own container (the overlays), so they can't affect things, other than themselves and the files, they create.

So (e.g.) you install a (hypothetical, made up name) Paint package, which effectively becomes its own container, for the Paint program.  Then create a few Paint files, with various pictures, you draw.

If it (Paint), tries to affect anything other than itself (Paint) or the files it has access to (the picture files), it will be blocked from doing so, because it is running inside a container (some kind of full or reduced size, VM like thing).  So the VM will protect the rest of the system from harm (N.B. I'm NOT clear about how secure BlendOS, is as regards its containerisation and hence VM mechanisms, as I don't know much about BlendOS).

But (in theory), BlendOS can have secure VMs (Containers), if implemented well.

[RaymondMack]

Unlike all other immutable distributions, there is a mechanism that allows you to install system packages normally, thanks to an "overlay system"(1), that also allows you to "roll back"(2) to existing snapshots.

What about openSUSE's MicroOS (now called Aeon for the desktop/Gnome variant)?

I just got done watching Richard Brown's "Why you should be running the MicroOS Desktop" video



https://en.opensuse.org/Portal:Aeon
https://get.opensuse.org/microos/

and love all the concepts that he talks about: immutable base system, rolling release with snapshots (great for new HW where kernel updates are needed to fix problems/add functionality), flatpacks for distro independent apps, containers for running distro dependent or terminal only apps, atomic updates that only affect the system after reboot and can be delayed indefinitely if wanted (FU Microsoft!). This literally solves everything I hate about Windows. And with modern IOMMU PCIe pass-through (e.g. dGPU/iGPU or specialty cards), the few Windows only applications I need can be done at near native speeds through a VM. Dual boots are effectively obsolete.

Linux has come a long way these past couple years and I'm finally going to make the move to Linux permanently (rather than playing around with it periodically). I don't think immutable distros are for everyone, due to the added complexity and slight overhead they bring, but for a workstation OS they are ideal and require very little effort on my part to maintain the system once it's setup.

[RaymondMack]

[...]

Because things run inside their own container (the overlays), so they can't affect things, other than themselves and the files, they create.

So (e.g.) you install a (hypothetical, made up name) Paint package, which effectively becomes its own container, for the Paint program.  Then create a few Paint files, with various pictures, you draw.

If it (Paint), tries to affect anything other than itself (Paint) or the files it has access to (the picture files), it will be blocked from doing so, because it is running inside a container (some kind of full or reduced size, VM like thing).  So the VM will protect the rest of the system from harm (N.B. I'm NOT clear about how secure BlendOS, is as regards its containerisation and hence VM mechanisms, as I don't know much about BlendOS).

But (in theory), BlendOS can have secure VMs (Containers), if implemented well.

As far as I understand, containers are not true VMs: they use the base system's kernel and simply limit access to the userland of whatever distro is being used inside the container. They also use some form of deduplication to avoid wasting space if multiple containers are used with the same distro.

I believe Qubes uses full VMs, so no sharing of the base system kernel (though individual VMs may share kernels IIRC). Modern immutable OSes like MicroOS and BlendOS are essentually watered down versions of Qubes (which was designed to be secure from the ground up, but honestly is quite unwieldy if one doesn't understand how it's intended to work). Both paradigms require the user to fundamentally change how they interact with the OS and is cumbersome to those who don't want the enhanced security and stability they offer.

[Marco]

Of course video drivers and immutable core systems bite each other, without Apple/Chromebook like control over the hardware an immutable vendor base system is a bit of a pipedream. For PCs you too often just need custom kernel startup options or just plain custom kernels to make everything work.