Dude, thank you for this. IMO reducing that down to simply “cloud native” is doing a disservice to how absolutely cool that methodology is.

The methodology IS cloud native, we didn't invent this. 😼 People will update their terminology, we're not doing anything new, Linux in infrastructure went through this a decade ago. It's an update in vocabulary because it's a shift away from the traditional distro model and has more in common with the rest of industry (k8s, docker, etc) than a desktop. The desktop is just the payload.

We know some people will complain but whatever, it's our job to help people understand the tech and there are proper definitions for this stuff - The whole "immutables" or whatever slang people are making up doesn't really make sense but we can't control what people think, we can just do our thing and keep pushing out updates.

RancherOS doesn't exist anymore, but a difference here is everything on the machine runs on the metal except whatever workload you have. Here's people who do a way better job explaining it:

• https://www.youtube.com/watch?v=zF7aTCoWoLQ
• https://www.youtube.com/watch?v=T9aDEF_4vr8

Our systems share the same tooling as Fedora CoreOS so this is probably a better example. You can make custom server images -- we build on top of that too, similar to Bazzite but for server nerds: https://github.com/ublue-os/ucore - basically if you can script it, you can make an OS image out of it. Here's bootc upstream where people are hanging out: https://github.com/containers/bootc/discussions

Hope this helps!

bluefin/aurora co-maintainer here, the 1password ssh agent is a miniboss we haven't conquered yet, just a heads up.

Did you experience the Silverblue issue on a ublue image? We mitigated that last month so you should only have one problem or the other, not both.

Yeah checkout ucore, which is derived from CoreOS instead of Silverblue: https://github.com/ublue-os/ucore

What kind of printer? What's the name of the package that got it working? We can add printer drivers pretty easily.

Flameshot is 3.6MB on disk according to flatpak info org.flameshot.Flameshot

Immutable is new to me,

It's best to ignore the whole "immutable" thing as most of the discussion around that is conflating a bunch of other concepts and it just leads to confusion. When it comes to things like host daemons, these systems are designed to deploy daemons the same way as cloud servers, so for mpd it'd be running the service as a container. A quick search of /r/selfhosted shows some options, but I'm on the road so don't have time to recommend a specific image, but generally speaking anything server related is done via containers.

I use the 1password firefox plugin for my password management. There still isn't a flatpak portal that allows flatpaked password managers to talk to flatpaked browsers, that can be a pain point to some people depending on your use case.

As far as how you manage your distroboxes, that's up to you. We differ from fedora here where they default to "just use toolbox" for everything, whereas we default to "just use brew" for everything. I keep an ubuntu and fedora distrobox in case I need to check something from those distros, and arch is a popular choice. If you're happy with your existing distro but want the reliability of atomic updates then this is a good option. For most new users I recommend not caring about distrobox, most of that stuff is for developers or people that know how to linux already and know exactly what they want.

Also, are there any issues with upgrading a distrobox to a new major release over time?

Containers are designed to be ephemeral, so that you can recreate them on the spot when something goes bad. So I never upgrade boxes, I recreate on the spot using my custom configs. That way I have the same experience on all my machines and when something breaks I don't lose any time setting things up again. Distrobox assemble is awesome for this: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md

So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?

I don't really layer anything, I use everything via containers or brew. Generally speaking some people might have a few things they have no choice to layer - a good example is a VPN provider that doesn't provide a wireguard config for network manager and instead you have to layer some 3rd party app. But it's also not the end of the world, updates will take longer but 99% of the time I'm asleep when that happens or it happens in the background and is transparent to me. The more you layer the more maintenance you'll have to do when you do upgrades, so if you end up adding a bunch of 3rd party repos it'll behave the same way as a traditional distro and likely need to be babysat.

The system will update all your boxes and your brew packages as well, so whichever one you use you'll never be out of date. Hope this helps!

I disagree on your view about the Fedora atomic spins, especially universal blue. Who cares if the underlying OS downloads as one big image. It all happens in the background, you don’t notice that. Everytime you reboot, you are on an updated system.

Universal Blue co-maintainer here, this is a temporary situation, efficient downloads are coming, I'm actually at the Red Hat Summit and have been discussing things with the right engineering teams. This involves an intersection of podman, ostree maintainers etc. all aligning on it. It's definitely a priority for them to fix this.

We've pushed pretty hard and pretty fast on the cloud native model, part of it was convincing people that this was a thing that users want, they hear us loud and clear now, it's going to be an awesome year.

This requires the presence of rpm-ostree and a kernel, which are both missing in the CentOS Stream image.

There are ostree-enabled OCI containers of centos if you know where to look. :D

This should be enough until they start publishing official ones, never used it:

https://quay.io/repository/centos-bootc/centos-bootc-dev?tab=tags

We use quadlets to manage those containers: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

As others in the thread have pointed out just having systemd manage them is the way to go, it's a nice combo!

Flatcar linux (this is what I use for my NAS/homeserver) and CoreOS are both good.

edit: OpenSUSE has microOS: https://microos.opensuse.org/

I'm the author of the blog post and a former sysadmin, there's really no maintenance to do with flatpaks, not having to deal with traditional package manager issues have removed that problem completely from my life.

Distros may or may not provide this functionality, but on my systems they're set up for zero maintenance of the OS base image and the flatpaks via service units and then I don't have to do anything.