They don’t seem to give a shit about security. I think the well is poisoned.

Nah, I wouldn’t go that far. That’s like way too dramatic.

Best to just use apt

I will whenever apt doesn’t (majorly) rely on backports for its security updates AND actually sandboxes its own packages. Zero Trust, FTW!

Ah okay, thanks for the clarification! I haven’t delved deep into that aspect yet. But I’ve recently become aware of this unaddressed attack vector. And it is definitely something to worry about.

Unsure if it’s solved anytime soon. But, if it is properly addressed and solved at some point in the future, would that (completely) redeem Flatpak’s security model? Or, at least make it superior to what’s found elsewhere?

Hehe :P , thanks for sharing your experiences!

Uhmm…, please allow me to elaborate upon my first question, as I don’t feel it’s quite answered yet.

You noted the following in an earlier comment:

Edit: I’m leaving it

Which led me to believe that you left Bluefin for some reason. But after reading your great wall, it doesn’t seem as if you actually left it. So…, I’m mostly confused at the moment :P . Would you mind elaborating in hopes of (at least) alleviating this confusion?

But how is it a security nightmare? Or did you mean “distraction”, but chose to use “nightmare” for -I suppose- exaggeration (or similar/related reasons)?

doesn’t matter if you downloaded malicious code

Hmm…, please help me understand: say, I installed a flatpak that included malicious code. But, it required some permission to enact upon its maliciousness. Which, it never received. And thus, if my understanding is correct, it couldn’t enact upon its maliciousness. How didn’t Flatpak’s security model not matter in this case? Apologies if I sound obnoxious (or whatsoever)*, but I’m genuinely trying to understand your case.

Thanks for sharing your experiences! As much as I absolutely love and favor ‘immutable’/atomic “Doritos” distros over their traditional counterparts, I can’t but accept the reality that it’s not (prime-time) for everyone (yet). Though, I do wonder what put you off (specifically). Would you mind sharing it?

Anything needing deeper access or only available in package form, I’ve been able to run in boxes.

I assume you’re referring to distroboxes and not to (GNOME’s) Boxes used for running VMs.

Its a security nightmare

How so? Doesn’t its sandbox offer superior security (under most circumstances) over most other solutions? Even in its relative infancy*.

Apologies for my ignorance, but what’s OST?

As the person in question has remained silent, I do wonder if I could perhaps help out instead. Would you be so kind to vocalize your question(s) as elaborate as possible? Afterwards, I’ll try to answer them to the best of my abilities.

I want my apps to be able to talk to each other. So flatpak is just in the way.

This is (at least somewhat of) a legit concern. But is mostly directed towards Flatpak’s limitations in its current implementation.

Also, I don’t see the point of immutable distros. I could boot off of btrfs snapshots years ago. Immutability gives me absolutely nothing of value either

Have you ever wondered why openSUSE started working on (what would eventually become) Aeon while they had previously pioneered the BTRFS + Snapper workflow with Tumbleweed? I believe you may find the point of immutable distros in there 😉.

If you’re still (relatively) new to Linux and are mostly interested in “just works”, then you simply can’t go wrong with systemd. It has (for better or worse) become the de facto standard on Linux and is therefore often assumed to be present. Hence, actively resisting it might be ‘costly’. Therefore, you should carefully consider whether it’s worth straying from the beaten path. Like, what do you hope to achieve?

As for the elephant in the room, what alternative can even put up a fight? While I’d be the first to admit that systemd’s design ethos leaves a lot to be desired; it’s so feature-rich that I’ve yet to find any distro that puts good use to (almost) all of them. But, including everything and the kitchen sink does make it hard for its competitors to compete whenever it matters; perhaps it’s one of the key reasons why systemd is as reliable as it is OR why attempting to replace systemd on Fedora/NixOS/openSUSE is a nonstarter. (Being founded and funded by Red Hat doesn’t hurt either. Nor does it hurt when its main developer is on Microsoft’s payroll.)

Though, even if I don’t see the likes of OpenRC/runit/sysvinit ever compete with systemd in terms of capabilities, I am cautiously optimistic for dinit and s6.

LOL, who am I kidding, systemd will (probably) only be dethroned whenever its PipeWire/Wayland is introduced.

they’ve been apparently working on its replacement for quite some time, so the “news” of its retirement actually comes because of the discovery of its replacement and the chatter around it.

Are you referring to the combination of Agama, Ansible and Cockpit?

Thanks for posting.

It has been my pleasure!

I was worried that it might have been forgotten about

The XZ utils supply chain attack has actually made the community more wary of blobs. Some projects were even prompted to come clean on this matter.

Fedora has also recently made a push towards reproducible builds. In the lwn.net article that discussed that push, one of Fedora’s spokespeople explicitly said that it would help combat supply chain attacks.

So, all in all, I can confidently say that it did leave a mark on the Linux landscape. Hopefully, this specific attack vector will not be as viable in the foreseeable future.

Please correct me if I’m wrong, but my understanding is that we didn’t get any alternative in return. Right?

The following has been prepared with help from an LLM. The content is basically mine; it only helped me with wording/phrasing etc. Sometimes, my RSI-like pains come up and I can’t be bothered to do otherwise. Thank you for your understanding:

I saw wireguard tools, isn’t that a kernel module?

The WireGuard implementation has two parts - the kernel module (built into the Linux kernel) and the userspace tools package. This sysext only provides the userspace tools (wg and wg-quick commands), not the kernel module itself.

Although this looks interesting, I have trouble understanding the pro’s and cons vs something like flatpak or containers.

Sysexts fill a critical gap in the Fedora Atomic ecosystem that neither Flatpak nor containers adequately address.

While traditional distros let you install packages natively, Fedora Atomic’s direct alternative to this (i.e. layering) comes with significant drawbacks - updates take longer, require reboots that disrupt workflow, and can sometimes block future updates entirely. This has been a persistent pain point for users.

Flatpaks technically support CLI tools but rarely package them, and containers are impractical for things like shells (imagine running fish or zsh in a container to use on your host). Similarly, applications like Steam or certain browsers sometimes need deeper system integration than Flatpak provides - which is why projects like Bazzite and SecureBlue install them (read: Steam and Chromium-derivative respectively) natively.

The CLI situation has been particularly frustrating, even for Universal Blue, which has driven much of Fedora Atomic’s ever-growing adoption. Their exploration of various solutions (eventually landing on Homebrew) demonstrates how challenging this problem has been.

Sysexts offer an elegant alternative - they provide system-wide integration without breaking immutability or requiring reboots. You intuitively know when to use a sysext versus Flatpak or containers - they’re not competing but complementing each other.

They aren’t a silver bullet (we’ll still need layering for kernel modules, etc.), but for many tools, sysexts provide the solution the immutable OS ecosystem has been waiting for.

I was hoping someone else would step in, but alas…

Look, if your goal is spreading awareness of software freedom, search manipulation isn’t the way 😅

GNU’s approach has become increasingly dogmatic while the ecosystem moves forward. Their stance on firmware blobs and microcode updates creates genuine security problems that projects like coreboot solve with a more balanced approach.

The FSF views software freedom as an absolute, even when it means sacrificing security or functionality - kinda like refusing to use an umbrella because it wasn’t made with 100% free-range organic materials… while standing in a thunderstorm

This is why Torvalds rejected GPLv3 for the kernel and why distros are finding better ways to respect user freedom without the absolutism.

People discover valuable ideas when they solve real problems, not when they’re forced into terminology debates. If GNU’s philosophy is truly compelling, it’ll spread on its own merits, no search engine tricks required!

Why? The likes of Alpine Linux and Chimera Linux don’t adhere to GNU/Linux to begin with. Even Ubuntu has intentions to replace the GNU coreutils with alternatives that have been written in Rust.

Don’t get me wrong; GNU has been instrumental for enabling the Linux ecosystem to begin with and will probs remain relevant (at least to some capacity) for the foreseeable future. However, I absolutely don’t see any reason to be pedantic about this; especially as something like systemd -whether you like it or not- has become a lot more important for what mainstream Linux has become. Yet, nobody in their right minds would even consider to refer to Linux as systemd/Linux (thankfully so).