If you want to go play with /etc/fstab and you have a concept of "everyday cli tools"an immutable distro is not for you.

Please don’t conflate stuff.

On Fedora Atomic^[1], it’s possible to:

• Change the content of /etc/fstab. Heck, the same applies to everything under /etc. The only difference being that a pristine copy is kept at /usr/etc AND the fact that any changes to /etc are being tracked. Said changes can be accessed with ostree admin config-diff.
• Install CLI apps just fine. Refer to this comment for more details.

An immutable distro is made for people that do not use a computer but use a browser.

False. Again.

While I agree that it’s a very sane recommendation to the technologically inept, it would be a huge disservice to suggest it can’t handle more advanced workloads. Because, quite frankly, there’s very little it actually fails at. And most of its user base would vouch for this. And that list of restrictions/limitations is becoming smaller as we speak…

I feel too limited when trying immutable stuff

Is this rooted in experience? Or mostly just on vibes?

No one mentioned it yet, but there’s also AppManager.

Not in my experience. Though, I suppose I have to thank BlueBuild for the heavy lifting. It’s not even restrictive either, even big^[1] projects like secureblue depend on it.

Just to be very clear: the name “immutable distro” is unfortunately a misnomer. In practice, the restrictions found on so-called “immutable” atomic distros are very tame.

For example, on Fedora Atomic^[1], it’s mostly a paradigm shift. That is, you can achieve (almost) everything that you can on a traditional distro, the only difference being how.

So, if we would take OP’s query as an example, they are not able to do sudo dnf install vim btop. Instead^[2], they have to do brew install vim btop. Additionally, these changes persist, as you’d expect. Please note that this is just one of the ways/methods you can achieve this on Bluefin (and other Fedora Atomic derivatives). Other methods include:

• Install within a distrobox and export it.
• Simply layer it.
• Make a custom image that installs these by default and switch to said custom image.
• Install as a sysext.

As you’d expect, each one of these comes with its own set of tradeoffs.

I’ve had some issues with AppImageInstaller that I haven’t had with GearLever

Would you be so kind to elaborate? Being explicit would already make a huge difference. Thank you in advance!

Such a cool device. I hope many other vendors will eventually include that form factor in their lineup. I can’t wait to get my hands on a high-end Thinkpad DUO.

I wonder if they’ll one day just alias a bunch of stuff, kinda like what Ubuntu has done with forcing Snap down people’s throats. So, like:

• sudo dnf install bottles actually doing flatpak install bottles
• OR, e.g., sudo dnf install tldr actually doing brew install tldr
• etc…

I don’t think it’s necessarily bad as long as it’s very transparent on what it actually does (and why). And…, offers choice where applicable*.

Or…, like, introduce a new package manager that basically functions as a front-end. Would that ((and/)or the earlier alias-thing) be worse than sticking to the development of a single package manager until it does all (à la Snap)?

no layering

I foresee a future in which (so-called) sysexts will be used heavily to address the resulting gaping hole. Unfortunately, it’s not perfect either…

Though, I have to say that I find it quite hilarious to see how many alternative package managers are required to replace traditional package managers.

If I may, I’d rather prefer a translation layer like Wine, but for Android. Thankfully, it’s in the works. Soon™.

I do expect that Waydroid’s stocks will increase tremendously as Valve’s Lepton is based on it.

As for your query, it depends mostly on your sensibilities:

• Waydroid is lighter and is ever so slightly better integrated.
• VB offers superior sandboxing (and thus improved security).

FWIW, I’ve had better experiences with Waydroid, but your mileage may vary.