Compared to other distros, Vanilla OS 2 'Orchid' is rewriting how Linux works

Vanilla OS is an experimental distro testing out new implementations of immutability, cross-distro packaging, A/B failover, and more. Vanilla OS 2 Orchid appeared earlier this week. It's a very different OS from version 1, which came out 18 months ago and that we tried out in January 2023, but the same overall goals remain. …

[Zolko]

chicken come home to roost

The root file system is read-only [...] AppImage needs the libfuse libraries, but they weren't installed – and as it's an immutable distro you can't readily do that

so in an ideal world you'd like to separate really essential components in a read-only partition, and additional optional core libraries in an administrator managed writable partition. We could call this latter ... let's say ... /usr for example, how would that be ? Oh wait, they're doing exactly the opposite, merging /bin and /usr/bin together. And guess who is driving that move again ? The same ****** that imposed that SystemD cancer and Gnome. Einstein said that intelligent people learn from other people's mistake, idiots not even from their own.

So now new distros are coming up to do what old Debian did – or could do – by default. Yes I know that /etc would be read-only which would be problematic, but that's an easy fix (I built a LinuxFromScratch where I did that).

[Liam Proven]

Re: chicken come home to roost

[Author here]

> merging /bin and /usr/bin together

I am in favour of this. Unix was meant to be simple. The differences between /bin, /sbin, /usr/bin and all that are historical and obsolete. Junk the lot, make it as simple as it can possibly be.

Binaries on read-only FSs, data on selectively R/W.

Yes they are all flailing around and nobody _really_ knows what they're doing and yes they have conflicting goals and methods and rationales, but that's how evolution works. It's all good. May the best tech win.

[Mage]

Re: chicken come home to roost

Sadly often be best marketing wins. Or some other factor.

See 8088 and PC-DOS / MS-DOS

Or Win95 vs NT 3.51 or NT 4.0

Or USB vs anything better. USB HID anyone?

[Sandtitz]

Re: chicken come home to roost

"See 8088 and PC-DOS / MS-DOS"

What's wrong with i8088? What would you have preferred and why?

Which OS from early 1980's would you have preferred and why?

"USB vs anything better. USB HID anyone?"

What's the better tech that USB has supplanted?

[Roland6]

Re: chicken come home to roost

> What's the better tech that USB has supplanted?

Depends on viewpoint and use case, but…

A laptop with a pair of USB-C Swiss Army knife ports isn’t as useful out-of-the-box and unadorned with hubs, as one with a few dedicated port’s like: Full size RJ45 LAN, full sized HDMI and a few full sized USB 3.0 type A ports…

From a charging and robustness viewpoint, the Apple lightning spade connector was better.

From a general usage viewpoint, USB has had to embed a lot of complexity just to handle a problem caused by the dropping of the D type connector….

> What's wrong with i8088?

Compared to Motorola and National SemiConductors chips it had a more constraints on board architecture and made compiler writing more difficult due to the different memory models.

However its big advantage was that it used 8 bit PCB components and single layer manufacturing facilities. We forget just how far PCB design and manufacturing has progressed with multilayer boards now being the norm.

[doublelayer]

Re: chicken come home to roost

So your answer to what better thing that USB replaced is...USB? I don't think they were talking about the port shape, and nothing about USB limits how many of them the laptop manufacturers put on their devices. That's a separate issue which doesn't depend on what ports they've provided not enough of.

[jake]

Re: chicken come home to roost

"Which OS from early 1980's would you have preferred"

The one I had been using since the '70s. And still use today.

"and why?"

If you have to ask ...

[jake]

Re: chicken come home to roost

"What's wrong with i8088?"

Every CPU has it's quirks, some are more quirky than others. They all suck, but we use 'em all anyway.

[Zolko]

Re: chicken come home to roost

Binaries on read-only FSs, data on selectively R/W

but how do you install the binaries of libfuse then ?

If I remember well, the local / (root) partition was meant to be specific to the host machine, including kernel and drivers, and /usr was mounted from the network and included the programs. So kinda what this Vanilla OS does: have 2 partitions for the core OS, one immutable read-only and the other standard with root privileges. Having everything in /usr/bin seems like a lazy solution. Why not /bin then ? This stinks of what Poettering would do.

[jake]

Re: chicken come home to roost

"The differences between /bin, /sbin, /usr/bin and all that are historical and obsolete."

It's a file system. Logically placing the files into subdirectories according to their use only makes sense.

The granularity was put there for a reason, after long discussions. Contrary to popular belief, it's not just an affectation to make your life miserable.

Is your copy of the K&R Whitebook on the same shelf as The Joy of Cooking and your old Motor repair manuals, your Tolkien collection, the Chicago Manual of Style and Black's Law Dictionary? Why? Why not?

Are your cookbocks, gardening books, technical manuals, scifi and reference books all jumbled together willy-nilly on your home bookshelves? Or do you have them organized into hierarchies for ease of browsing? Perhaps with the cookbooks in the kitchen, automotive repair manuals in the garage, tractor manuals in the tractor shed and etc?

Or perhaps you place all books with blue covers on one shelf, sorted further by size, all books with brown covers on another, and all books with brown covers on a third? Or all books organized by author's name and date of publication? (I've actually seen this last one ... the person only had a couple hundred books, and it was already quite unwieldy ... )

A library uses the Dewey Decimal System[0] for a reason, EVEN THOUGH that system has evolved over time as our knowledge has increased.

Why people think that such a complex system that evolves over time as capability is added to that system shouldn't become more complex is beyond me.

_{[0] Yes, I know, there are other ways of storing books in a library. UDC, BISAC, LCC, etc, all have their merits and problems, but anyone with a couple of brain cells to rub together should have no issues working within and switching between their frameworks. Note that none have become more condensed over the years.}

[HereIAmJH]

Re: chicken come home to roost

What are these books you speak of? Some kind of ancient technology?

Seriously though, this is a perfect example of how things change. All my tech books are getting recycled, most of them are so out of date that they are useless. Everything else is getting donated to charity. I don't use them any longer, and no one wants to buy even collector's additions. They are just dust collectors. First instinct now is to search the Interwebs, which unfortunately tends to lead to YouTube videos rather than an image and a paragraph of text. And if I could get everything replaced with PDFs, I'd just drop them in a single directory on my network.

[stiine]

Re: chicken come home to roost

What books do you have? I have cash.

[Grogan]

Re: chicken come home to roost

It makes me fucking sick, what distributors are doing. Merging those directories and leaving symlinks in their place, because they are expected to be there at those paths. It's silly

Dumping everything in /usr is messy... people suck.

[mcswell]

Re: chicken come home to roost

Yes to merging the various bin directories (I'd have two: /bin and /local/bin). Also merge some lib directories, which are even less documented IMO than the bin dirs. Now there's nothing saying you can't have subdirs under a lib dir for different things (like, say, a python sub-dir). But having to specify a $LIB set of five or ten paths is just ridiculous.

[Stuart Castle]

Re: chicken come home to roost

There may be good reason why you couldn't do this (e.g. backwards compatibility), but I've long wondered why /usr/bin isn't just a link to /bin.

[katrinab]

Re: chicken come home to roost

FreeBSD kind-of does that.

The base image goes into /bin /usr/bin /etc and so on. Ports to go /usr/local/bin /usr/local/etc and so on.

It isn't immutable though, you can modify stuff in /usr/bin as root, and you will need to modify stuff in /etc.

[karlkarl]

Re: chicken come home to roost

A number of years back efforts were made that ports don't touch anything outside of /usr/local. So even config files are now /usr/local/etc. The only exception is firmware.

[pogul]

Re: chicken come home to roost

Calling someone an idiot is pretty unnecessary and smacks of bullying. You may not agree with the architecture of systemd and I'm not sure I do either, but how about keeping the discussion civil?

As for learning from previous mistakes, I would say that bundling whole applications together in their own directory like Mac OS does would be a better idea, rather than spreading files all over the FS in strange and archaic ways.

[Martin an gof]

Re: chicken come home to roost

like Mac OS does

Or, indeed, RiscOS...

M.

[Zolko]

Re: chicken come home to roost

Calling someone an idiot ...

If you're hinting at me, I was referring to RedHat, a multi-billion company, and idiot was not what I had in mind

[steelpillow]

Immutability

So how does this dual-root immutability thing play to my distro's ability to update and switch kernels as a regular thing? I mean, it can't be /that/ immutable if each can overwrite the other when required, not to mention updating the kernel as and when.

Seriously, it's been around awhile and this kind of rollback robustness is such a no-brainer, why isn't it a standardised thing for most distros? Maybe not in this form, but something similar.

[Liam Proven]

Re: Immutability

[Author here]

> So how does this dual-root immutability thing play to my distro's ability to update

Well, as I said above, different teams and projects have different approaches... complicated by the fact that, as ever in the Linux world, they all either regard each other as bitter rivals, or they don't consider others worthy and totally ignore them. So it's chaotic, but that's FOSS. It's OK. It works out somehow in the end.

Taking the 42,000' view, there are 2 core approaches:

* either keep a full history, or at least a history of working configs, and offer the ability to go back to a working state

or

* Accept that single-step undo is easier and just have "current working" and "upgraded". If an upgrade fails:

1. fall back to the good state that did the upgrade

2. restore the copy to a known good state

3. mark that upgrade as bad and do not re-apply it (maybe, report it as bad)

4. wait for the _next_ upgrade, and try again in the hope it fixes the issue

It's simple and it's working on a huge number of unsupported consumer machines in the field.

Me personally I like simple over complicated. Like, I am not a big fan of either Snap or Flatpak -- I like AppImage, because it's simple -- but if I had to choose, I'd choose Snap, because I know how it works, but I have read up on Flatpak and OStree and they are really complicated and I know I do not understand how they work.

> why isn't it the norm for most distros?

Statistically, if you consider ChromeOS as a Linux distro -- which I do -- it *is* the norm, and about 9 out of 10 desktop Linux machines use it.

(From the best numbers I can find, about 90% of Linux boxes _that are not servers_ are Chromebooks, then about 2/3 of the rest are Debian family. *Of that* 2/3, about 2/3 are Ubuntu and actual Debian is most of the rest. The other 1/3 of the total is about 90% CentOS.)

The FOSS world is flailing around trying to work out how to do this while keeping the distro open to the end-user controlling it and installing their own stuff.

Red Hat has the worst case of NIH syndrome in the industry so is sitting on its heels trying to work out how to make more money.

Canonical could do amazing things with ZFS but it might also be able to do them with Snap and it's working on that. Fair enough.

SUSE could steal a lead on the whole industry if it can make stable, reliable, self-updating and self-healing servers. It's a good bet.

Maybe NixOS might make an end run around the whole thing but I think it's just too hard, too weird, too different.

[katrinab]

Re: Immutability

Isn't Busybox the most popular linux "distro" running on things like TVs and ISP routers?

[karlkarl]

Re: Immutability

Amusingly Debian based distros all start life as "BusyBox distros" upon boot. Only once i.e disk modules are loaded, disks mounted and switchroot occurs does it change to the GNU coreutils.

[Anonymous Coward]

Re: Immutability

> Red Hat has the worst case of NIH syndrome in the industry so is sitting on its heels trying to work out how to make more money.

Canonical would like a word

[mirkobrombin]

Hello, founder of the project here.

First of all I wanted to thank you for covering Vanilla OS and fully getting the philosophy behind the project, we are trying to do something... different.

Regarding the problems you noted, I can say that many of them are due to the documentation being behind schedule. In the next few days, starting from yesterday actually, all the new items will be released.

Regarding libfuse, you can use "abroot pkg add <package-name" and "abroot pkg apply" to apply the update, then reboot. We have documented this in several articles throughout development and it will be coming to the documentation soon.

PS. libfuse is not available in GNOME Software because, as per your assumption, it is only for graphical applications, for command line apps you need to use the package manager like in other Linux distributions.

Regarding APX it seems like a UX problem, it is correct that the terminals in the sidebar are not present because you have to create them first, this is what changed in APX v2. As with ABRoot, we have documented it in several articles throughout development and it will be coming to the documentation soon.

Regarding the installer problems, we are monitoring a bug with the wifi, we will also add the one you reported to the list.

Small clarification:

- when you open the shell you are placed on a container, not on the host, to access the host shell you must use the "host-shell" command

- in the host shell there is no "sudo", which has been replaced by "pkexec" and a set of policies, however in the host there is no apt

- to install graphical or cli applications from the command line that do not require specific drivers, you can use the default shell i.e. the container, where you have access to both sudo and apt, the applications are automatically exported to the system and made available in the applications menu

Thanks again for the article, I hope the documentation allows us to clarify all these new concepts introduced.

[eszklar]

Read about Vanilla OS 2 as well here:

https://www.omglinux.com/vanilla-os-2-released-with-android-app-support/

Very keen to install/try it. Already cut a USB stick, now looking for some decent hardware to install it on.

P.S. The comments in the above weblink are interesting to read regarding problems/difficulties with the installation and afterwards. Perhaps giving your reply there as you did in El Reg would be useful for additional perspective.

[steelpillow]

dumped in a container

Cool. Would love to know more about the security model there.

Whatever process deals with that, I'd suggest you call it "bouncer". ;)

[Luiz Abdala]

Dual Root.

I loved the idea, should an update bork the root, another one takes over. Like two cranes raising each other to build a skyscraper.

Like a watchdog, but 2 watchdogs can switch places to do the rooting ['I will do it myself' attitude?]. Antivirus should also embrace this, because as soon one of the roots gets screwed (some honeypot techniques), it should raise an exception and get the virus/malware on the act.

If only Windows could do that. [staring at Crowdstrike and borked infinite reboot Windows Updates from ages past]

However, if that is so obvious, why nobody thought of that before? Shenanigans afoot. And compare to running VMs that can in theory already do that (or should be able to, upon the hypervisor itself?).

I don't know a lick of Linux or Windows VMs for that matter, I just know that dual rooting looks good on paper, and that resilience would be welcome to the average Windows user.

[Lyndon Hills 1]

Re: Dual Root.

However, if that is so obvious, why nobody thought of that before?

This was how you upgraded the OS of a mainframe I worked on in the 1980s-90s. Upgrade a partition, boot from it. If all is OK continue, else reboot from old (good) partition.

I have not so fond memories of an upgrade that dumped half the new files on the 'new' partition and the rest on the 'old' partition. Followed by boot from 8" floppies, in order to be able to restore a HD partition from backup....

[Denarius]

Re: Dual Root.

and AIX.

[stiine]

Re: Dual Root.

Duh, that's because it was on a separate set of tapes...(I'm not that old that it would have been a separate card deck.)

[doublelayer]

Re: Dual Root.

For updates, it's not exactly a new concept. It's not often done on computers nowadays, but mostly that's due to the long period where disk space was at a premium and reserving lots of it for the image you're not using wasn't considered worth it. For instance, when people did an in-place update from Windows 7 or 8 to 10, the process included moving all the old Windows files, installing the new ones, and if you didn't like the update, you could revert by moving the old files back. In the meantime, many gigabytes of disk space would be used, and I remember some unhappy people talking about that.

However, from your other suggestion: "Antivirus should also embrace this, because as soon one of the roots gets screwed (some honeypot techniques), it should raise an exception and get the virus/malware on the act." That is less likely to work out well. There are only so many techniques that can be used that reliably. It could easily turn into a CroudStrike-esque situation where some program gets updated and starts doing something which is incorrectly identified as malware. Using the previous methods, antivirus software would block that program from running and quarantine its files, and someone would have to go tell it to stop doing that. With this behavior, the antivirus program would force the computer to the old disk image, possibly damaging the user's work, rebooting to apply it, and then the program would install the update and start the loop all over again. If the antivirus was less sensitive, then it might only do this after malware tried to elevate, meaning that the old disk to which it is resetting would still have the malware on it anyway.

[jake]

Re: Dual Root.

"why nobody thought of that before?"

People have.

And then we noticed that it was turtles all the way down ... and lots of turtles need lots of feeding. And cleaning up after.

[Alistair]

Re: Dual Root.

Umm.

We had *several* HPUX clusters where each node had two root volumes. And in several cases two application volumes. And we used the saturday night shut down /slam in update/reboot/run validation/ process. From the OS perspective the validations took roughly 15 minutes. The application team on the other hand.......

Once all was validated top to bottom, fix the config and hand it back to ops.

[AdamWill]

Re: Dual Root.

"However, if that is so obvious, why nobody thought of that before? Shenanigans afoot. And compare to running VMs that can in theory already do that (or should be able to, upon the hypervisor itself?)."

Plenty of people have. Android phones have worked this way for several years, they have two separate boot chains, A and B. When you "install an update" it installs it to whichever is not currently active, then reboots to that one. If the boot is successful it then installs the same update to the first chain; if not, it rolls back to the first chain and removes the update from the other chain. See https://source.android.com/docs/core/ota/ab .

[Anonymous Coward]

Orchid drops Snap support

Well done people. And an extra plus for going with Debian.

Not my cup of tea though. Chrome and Android are on my 'Thanks but no thanks' list but it shows that Ubuntu is not the only answer to life, the universe or anything.

[tekHedd]

Re: Orchid drops Snap support

"also means that Orchid drops Snap support, though."

They say this like it's a bad thing, whereas I see it as very positive.

[Herbert Meyer]

I tried it

And it won't install. Tried 3 times, different choices in install. Hardware is troublesome old lenovo laptop, not great choice. I will wait for other hardware, new release.

[Anonymous Coward]

Re: I tried it

I've found Sparky particularly good for odd hardware. Rescued many a destined for e-waste system with it.

[yetanotheraoc]

A/B upgrades

How I do it today: Two computers, same OS (as near as hardware differences allow). Update/upgrade one, see how it goes, then do the other one. A/B computers seems far simpler than A/B root. And recovering a bricked computer (not only from updates) always needs a second one anyhow. In the distant past I would use a computer at work as the second, but now that's locked down.

[Anonymous Coward]

If the package manager (wrapper) accepts repos from different distributions, how would it resolve conflicts between packages from different distros? E.g. RPM X requires lib Y, which is installed as a dependency for APT package Z, or would it for simplicity just isolate each? For non trivial apps (R/LaTeX) that can be expensive, but the other way around could lead to complex failures, because distros do not compile libs with the same flags, so you could get hard to trace failures.

[Mockup1974]

It would be really neat, but it only comes with GNOME so I'm not going to bother.

[david1024]

Guess this tech would be useful many places

There is a demonstrated need for automated-server-failure-recovery options. While there are other solutions out there, baking it in during installation has value. Wish them luck!