I use silverblue myself, but I think “cloud nativ” is a terrible name. “Immutable” is IMO better.
Also installing cli tools via toolbox/distrobox is not ideal. I hope for a better solution. Maybe someday i can install htop via flathub.
I agree “cloud native” is not great, I won’t be using that term.
Why are cli tools generally not available as flatpaks? There’s nothing about how flatpak works afaik which distinguishes gui and cli. I get that the original motivation for flatpak was guis, but considering how long it’s been touted as a “universal” package manager for linux, I don’t understand how there could be so few clis.
I’ve heard people say the name for packages from flathub is awkward (which it is), and aliasing everything you install would be annoying (which it would), but that sounds like such a simple problem to solve.
I’ve also heard people say that flatpak clis would be useless because clis tend to be systadmin tools, and thus need to be not sandboxed. But this strikes me as a non sequitur. Gui tools can be used for sysadmin, and there are tons of cli tools which have nothing to do with sysadmin, they’re just userspace programs.
What does your workflow look like with toolbox/distrobox?
Hi! I made the video and also happen to volunteer with flathub. The reason I’ve called it “cloud native” is because that’s the common term used in the industry already and server people know what that means. “Immutable” is a terrible term that is neither technically accurate or something users need to care about.
As for the CLI thing. Shoving CLIs into flatpaks could be a thing but that wouldn’t really solve a problem, it would just mean adding one more ocean to boil and someone would have to volunteer to package htop for the 30th time. There’s no need to do that, distros already have htop!
It’s a better time investment to fix the UX for containers on the desktop, especially since Mac and Windows are already there. :-/ There’s a few options that people are exploring that are worth discussing.
- podmansh has awesome potential, you just define a system-level container that has init and all the stuff people expect, then it would behave like the distro people are coming from. I suspect this is where CoreOS/Fedora will end up.
- exo - we have a spec over at ublue to just add container support directly to the terminal, like how WSL/windows terminal does it. This is the approach Canonical is taking with workshops
- Direct package management in your home dir - also an option, you can just install homebrew, nix, or tea or whatever install packages in your home directory and then it’s totally decoupled from the system.
I personally use distrobox with the assemble pattern to have what I need on all my machines, but hopefully as time progresses distros will do a better job integrating all this stuff. I hope this helps answer some of your questions!
Thanks for the response! Flathub is a fantastic project so glad to hear about your contributions. Your videos have been helpful for me as introductions to Silvelblue ideas and statuses.
I don’t have much to say about the term “cloud native” personally, it doesn’t seem too important. I think myself and others react against it because cloud tech is mostly used by businesses and “server people” to deliver products (sometimes at the cost of user freedom), and so has either a non or negative connotation in the FOSS linux desktop space. But names are names, and accuracy matters most. I don’t think etiher “cloud native” or “immutable” are really all that helpful as technical terms though, maybe something else should be used (image based, atomic, container centric, ?).
I’m not sure I understand “distros already have htop.” Distros already have everything packaged for flatpak, yet they were packaged for flatpak. The real question is why do flatpaks exist at all if you can just run programs in containers, OR why do containers exist at all if you can just run programs as flatpaks (assuming everything we wanted were available as a flatpak). That is: what are the technical / UX reasons to choose flatpak over containers and vice versa?
Podmansh looks very cool! That’s definitely the direction I’d like to see these sorts of projects moving in. The #1 issue I have at the moment with this OS model is customization/tinkering/hackability. I want to have the niceties of atomic updates and reproducible builds, and containers on their own are great. But not if it takes away my ability to make my system fit my needs. I have no interest in using a macbook.
The future of these technologies looks bright, and they are clearly functional today, but I’m not sure any of them meet my needs yet as someone who likes to have a great deal of control and understanding of my system.
The real question is why do flatpaks exist at all if you can just run programs in containers
flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it’s just a specific implementation designed for desktop apps, and it has things like portals and stuff that’s specific for gui apps. So for example, if you use silverblue, you use htop, but it wouldn’t make sense as a flatpak when there’s a full fedora installation delivered via a container already on your desktop, you’d just dnf install htop and move on.
But not if it takes away my ability to make my system fit my needs.
This is the problem with the term “immutable”. For some reason people seem to think that these systems take away configurability and freedom to tinker, which is wrong because the entire point of cloud native is composability. You declare what your system is supposed to look like, and then a deployable artifact comes out the other end, that’s pretty much it. Hope this helps!
I think flatpak could perfectly fine for installing cli applications even though it is designed for desktop applications.
Shoving CLIs into flatpaks could be a thing but that wouldn’t really solve a problem, it would just mean adding one more ocean to boil and someone would have to volunteer to package htop for the 30th time.
Flatpak is distribution independent, which means, it could be actually reduce repackaging.
flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it’s just a specific implementation designed for desktop apps, and it has things like portals and stuff that’s specific for gui apps.
While that is true, I don’t see, why this is a problem for CLI applications to be installed and run via flatpaks.
Direct package management in your home dir - also an option, you can just install homebrew, nix, or tea or whatever install packages in your home directory and then it’s totally decoupled from the system.
Can you explain, why this works better, than flatpaks? I mean it does not matter what flatpaks were intended for originally, if they do the job just fine.
So for example, if you use silverblue, you use htop, but it wouldn’t make sense as a flatpak when there’s a full fedora installation delivered via a container already on your desktop, you’d just dnf install htop and move on.
I found this approach lacking, because:
- I always have to remember what is the right container for the right tool.
- Installing software can be quite annoying. I can’t simply add some
dnf install fooin a bashscript. Controlling a container via bash is not that easy (or, I don’t know how it works) - Tracking installed software is painful. Now I have to check every container, if and where something is installed.
There are two different immutable OS models hot on the table in the linux space I see: The Nix[1] way and the Silverblue[2] way.
Both have immutable filesystems which deviate from the FHS, provide atomic updates, and support the creation of more-or-less isolated environments at the user level. But the way the two models implement these features is very different.
The Nix way takes inspiration from the world of functional programming, while the Silverblue way takes inspiration from the containerized, cloud native technologies which are used so widely in the industry.
I believe the idea that these two approaches share is the future of linux on both the server and the desktop, and it is only a matter of time before some (if not all) of these advantages become mainstream. However, I am uncertain of which approach is superior.
I have personal experience with Guix and enjoyed it greatly and even recommend others try it or Nix out for themselves, but there are some complexity issues. It is not clear to me whether these issues are growing pains, or symptoms of a fundamentally overcomplicated system to solve a seemingly simpler problem.
The Silverblue way I have no experience with, but seems like a more grounded approach to tackling the specific problems laid out. The big area where Silverblue seems to lack in comparison to Nix/Guix is declarative, reproducible system configuration. With Nix/Guix you can just throw your system config file up in a repo, and anybody else can pull it down and install that system bit-for-bit, including future you! With home manager this extends to a large extent to user configuration as well. Of course with Silverblue you can create images, but that is less straightforward and powerful (at least for now).
What are ya’ll’s thoughts on immutable OS’s?
What are ya’ll’s thoughts on immutable OS’s?
As a causal user, they sound awesome. I want a stable system and, if possible, never touch the Terminal to fix some stuff + I’m okay with Flatpaks, since I have more than enough disk space for them. The only slight annoyance would be theming in my case, but that’s a minor problem that is probably easy to fix.
I’m actually very interested in Vanilla OS, since it is a community-driven Distro. I will probably switch fully when they bring out the KDE version.
I don’t know too much about Vanilla OS, is it not possible to install your own DE or WM?
I’m less interested in Vanilla OS since it’s based on Ubuntu and I’d rather not support / rely upon anything Canonical if I can help it.
Silverblue (+ spins) seems like the best option since it is the most mature, most popular, and is a community run distro. Of course Redhat pours a lot of resources into the Fedora project since it’s upstream RHEL, and so does SUSE for MicroOS. But honestly if Redhat/SUSE were to disappear tomorrow, I think Fedora and OpenSUSE would be fine, whereas I can’t say the same for Canonical+Ubuntu (and thus their descendants).
edit: After looking more into Vanilla OS, it looks very nice! Funnily
apxaddresses excatly the issues with distrobox pointed out in this thread by @mogoh@lemmy.ml. They also plan on moving from being Ubuntu based to Debian Sid based, which would be even better than Fedora as Debian is a true, 100% community backed and time tested distro (though still of course much corporate support).
I’ve been using Nix for over a year. And have had a pretty good experience. Then in the last 2 months I’ve switched to Guix. Its definitely farther behind. But it has such a better tooling story. I really wish folks could see the potential it has and build for it rather than nix because Guix has so much going for it.
The overall experience for both is great. You get declarative configuration and easy rollback. You do need more storage but it’s not much worse than windows really.
I’ve played around with NixOS, Silverblue, and MicroOS (has recently been renamed Aeon) in VMs and really dig the concept. My general thoughts are:
NixOS - a genius idea but quite a steep learning curve as you have to throw out a lot of what you know about traditional Linux OSs and learn to do things the Nix way. Is too much for me to use as a daily driver, personally, but for people who need to spin up reproduceable systems super quickly, it would be amazing.
Silverblue - much more user friendly than Nix, but (like Fedora) the out of the box experience is a little awkward, especially if using vanilla Gnome with no extensions or modifications doesn’t appeal to you. If not, then you’re going to have to layer on things like Gnome Tweaks and Extension Manager and that can be a little confusing if all you’re used to doing is running
dnf install packagein a terminal.MicroOS / Aeon - This is, IMO, the best of the three for beginners because it comes with a lot of quality-of-life additions out of the box: distrobox, Gnome Tweaks, and Extension Manager are already built-in so you don’t have to figure anything out (well, apart from how to use distrobox of you aren’t already familiar). The only thing I think that Silverblue does better than Aeon is updates, which are a little opaque in the latter. Also, because Aeon is based on OpenSUSE Tumbleweed it is, in theory, less of a stable base than Fedora. (edit: oh, and documentation too! Silverblue is much better in that regard.)
I haven’t tried Vanilla OS yet, but it looks pretty interesting. I’m waiting for the 2.0 Orchid release where they’ll be moving to Debian Sid before I take it for a test run.
Removed by mod
saw cloud based and thought plan9
I don’t think it’s a coincidence that cloud tech, container tech, Go, and Plan 9 tend to overlap conceptually and demographically.
