> Image based is the future.

While this is the direction many are going for particular use-cases (IoT in particular), I am very much conflicted.

Yes, inconsistent updates between components have caused a couple of nights of fixing my RPM or DEB based systems in my 27 years of using Linux on desktop (but mostly when I mixed sources of packages).

But at the same time, the modern systems thinking is to decouple things to be able to update and upgrade independently. Think distributed systems like web applications. This needs a change in developing components, but once internalized, both improves and speeds up the delivery.

So with traditional Linux distributions already being a mix (small packaged upgrades, but released as a collection - a "release" or "version" of a distribution), this decidedly moves in the other direction.

How does a security fix get quickly applied here? Can one do kernel livepatching? How do you quickly update a component depended on by everything else?

▲

palata 5 hours ago | parent | next [-]

> Yes, inconsistent updates between components have caused a couple of nights of fixing my RPM or DEB based systems in my 27 years of using Linux on desktop (but mostly when I mixed sources of packages).

Exactly this. I think I have spent something like 2 hours fixing such issues in the last 15 years.

I don't get it when people say "at least with X I don't need to reformat and reinstall my whole system every year", or "it keeps breaking". I have used Debian, Arch, Alpine and Gentoo, and I really just don't have problems? Lucky me, I guess.

▲

luckydata 5 hours ago | parent [-]

I have been a lot less lucky

	▲	palata 2 hours ago \| parent [-]
		Genuinely interested: did the distro break "on its own", or was it due to something you did? Not trying to suggest you are incompetent: maybe "doing it right" is not intuitive, and that's an issue. But I wonder which distro publishes changes that they call "stable" and just break things. Or worse get to the point where it requires a complete reinstall every year... For instance, by installing stuff on the system with "sudo make install" that breaks the expectations of the system package manager, or by modifying config files and then not handling the merge conflict during the update, or stuff like this? Very, very long ago I remember having to reinstall some nvidia drivers once in a while (but while annoying it took minutes), and I haven't used nvidia since then.

▲

mindcrash 3 days ago | parent | prev | next [-]

When scrolling down I noticed that Aurora is based on Universal Blue (https://universal-blue.org/), a initiative to create Linux distributions based on the same containerization tech which sits behind the likes of Docker and Podman.

You might find some extensive answers to your questions in the bootc documentation which is the container runtime running at the core of Aurora and other Universal Blue distributions, like the increasingly popular distribution Bazzite for Linux based gaming.

https://bootc-dev.github.io/bootc/

▲

skydhash 6 hours ago | parent [-]

I tried Fedora Atomic for a while and my takeaway from image-based distro is that they would work fine for fixed workflow, but you take an hit to versatility. The biggest pain point for me was Emacs. It’s one of the major hub in my computing experience and having workflows strewn across containers doesn’t help.

▲

sham1 4 hours ago | parent [-]

I personally run Fedora Kinoite (the KDE equivalent of Fedora Silveblue) and Emacs works fine for me. I ended up installing it as a sysext[0] and it works just fine. I did also use it at one point both in a toolbox container and a flatpak, but it always felt a bit flaky there.

But honestly, since Emacs is so core to my personal workflow, I think that it's fine to use a system extension for it. Alternatively it could be layered on, which would also of course work. After that, interacting with the containers is of course just using TRAMP to "connect" to them, and that of course works just fine.

[0]: <https://github.com/fedora-sysexts/fedora> & <https://fedora-sysexts.github.io/fedora/>

	▲	skydhash an hour ago \| parent [-]
		It’s not really about emacs, but the fact that it relies on software being available on $PATH. You could use proxy scripts for stuff that are in containers, but yeah, it’s flaky. I’ve not encountered OS crashes for a long time, and I’m fairly confident on troubleshooting config issues. Image based OS could be fine for single purpose computing, but I tinker a lot on my PC. Anything that is declarative is usually an hassle.

▲

dartharva 4 hours ago | parent | prev [-]

Plus most of the things that are prone to breakage aren't a part of Flathub anyway. KDE Plasma's sddm and launcher were what kept breaking due to broken updates in Fedora KDE the last time I tried it; Aurora won't be immune from that since none of them are updated via flatpak.