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).