HayadSont

joined 2 weeks ago
[–] [email protected] 1 points 14 hours ago* (last edited 13 hours ago)

To clarify, this is just my list that I shared in the hope that others would follow suit πŸ˜…. (Which hasn't been successful so far...) Consider posting yours πŸ˜‰!

[–] [email protected] 9 points 15 hours ago (1 children)

As someone with a perpetual desire for clean system managementβ€”even back in my M$ days^[Which I 'dealt' with by factory resetting every few months πŸ˜…]β€”I deeply resonate with the desire to declare the desired state within a config file and treating it as the single source of truth; this is exactly why NixOS with the Impermanence module has captivated me ever since it appeared on my path, like a long-sought truth.

I've only abstained this long due to lacking a spare device for a proper test run that might lead to permanent adoption. Perhaps this summer will finally be the time to take the plunge.

Looking forward to bringing order to chaos at last.

[–] [email protected] 2 points 16 hours ago

The expectation that package maintainers should backport security patches rather than simply updating to the latest upstream version is a rather peculiar quirk.

Can't agree more.

 

Fellow open-source enthusiasts,

We all have that mental backlog of promising projects β€” those distros, tools, and systems we keep tabs on but haven't yet deployed. Perhaps you're waiting for that mythical free weekend, lacking a spare/compatible device or just holding out until that one killer feature drops.

FWIW, my 'someday' list includes:

Operating Systems/Distros:

  • Gentoo – Source-based meta-distribution driven by Portage and USE-flags for near-granular control; binary packages also available if you'd rather skip marathon compile sessions.
  • Guix System – GNU's functional, declarative distro built with Guile Scheme.
  • MocaccinoOS – Image-based, container-built distro that originated from Gentoo/Sabayon but now uses the Luet package manager and OTA-like updates.
  • NixOS – Declarative Linux distribution using the Nix package language.
  • Qubes OS – Security-focused OS that uses Xen virtualization to compartmentalize your digital life into isolated environments with a unified desktop.
  • Spectrum – In-development security-oriented OS built on Nixpkgs using KVM-based microVMs for compartmentalization.

Desktop Environments/Window Managers:

  • COSMIC - System76's comprehensive Wayland-native desktop environment written in Rust.
  • Hyprland – Dynamic tiling Wayland compositor with scriptable layouts and impressive animations.

System Security/Firmware:

  • coreboot – Open source alternative to proprietary BIOS/UEFI firmware (though recent x86 still needs vendor blobs such as FSP/AGESA).
  • Heads – coreboot + Linux payload providing TPM-measured, tamper-evident boot for select laptops.
  • nix-mineral - NixOS module for convenient system hardening.
  • TrenchBoot – Framework for dynamic root-of-trust (DRTM) launches via Intel TXT, AMD SKINIT, or SEV-ES.

Applications/Tools:

  • Android Translation Layer - Run Android apps natively on Linux (still in early development).
  • Emacs – The self-extensible Lisp machine masquerading as a text editor; someday I'll embrace the config rabbit hole.
  • Olive – FOSS non-linear video editor in alpha.
  • systemd-sysext – Overlay read-only /usr and /opt (or /etc via confext) with extra images; extensions auto-activate at boot or can be merged/unmerged/refreshed live with a single command. Handy for immutable distros, though it’s additive-only and not a full package manager.

What open-source projects are you admiring from afar? Time to compare notes!

 

Fellow open-source enthusiasts,

We all have that mental backlog of promising projects β€” those distros, tools, and systems we keep tabs on but haven't yet deployed. Perhaps you're waiting for that mythical free weekend, lacking a spare/compatible device or just holding out until that one killer feature drops.

FWIW, my 'someday' list includes:

Operating Systems/Distros:

  • Gentoo – Source-based meta-distribution driven by Portage and USE-flags for near-granular control; binary packages also available if you'd rather skip marathon compile sessions.
  • Guix System – GNU's functional, declarative distro built with Guile Scheme.
  • MocaccinoOS – Image-based, container-built distro that originated from Gentoo/Sabayon but now uses the Luet package manager and OTA-like updates.
  • NixOS – Declarative Linux distribution using the Nix package language.
  • Qubes OS – Security-focused OS that uses Xen virtualization to compartmentalize your digital life into isolated environments with a unified desktop.
  • Spectrum – In-development security-oriented OS built on Nixpkgs using KVM-based microVMs for compartmentalization.

Desktop Environments/Window Managers:

  • COSMIC - System76's comprehensive Wayland-native desktop environment written in Rust.
  • Hyprland – Dynamic tiling Wayland compositor with scriptable layouts and impressive animations.

System Security/Firmware:

  • coreboot – Open source alternative to proprietary BIOS/UEFI firmware (though recent x86 still needs vendor blobs such as FSP/AGESA).
  • Heads – coreboot + Linux payload providing TPM-measured, tamper-evident boot for select laptops.
  • nix-mineral - NixOS module for convenient system hardening.
  • TrenchBoot – Framework for dynamic root-of-trust (DRTM) launches via Intel TXT, AMD SKINIT, or SEV-ES.

Applications/Tools:

  • Android Translation Layer - Run Android apps natively on Linux (still in early development).
  • Emacs – The self-extensible Lisp machine masquerading as a text editor; someday I'll embrace the config rabbit hole.
  • Olive – FOSS non-linear video editor in alpha.
  • systemd-sysext – Overlay read-only /usr and /opt (or /etc via confext) with extra images; extensions auto-activate at boot or can be merged/unmerged/refreshed live with a single command. Handy for immutable distros, though it’s additive-only and not a full package manager.

What open-source projects are you admiring from afar? Time to compare notes!

 

Fellow open-source enthusiasts,

We all have that mental backlog of promising projects β€” those distros, tools, and systems we keep tabs on but haven't yet deployed. Perhaps you're waiting for that mythical free weekend, lacking a spare/compatible device or just holding out until that one killer feature drops.

FWIW, my 'someday' list includes:

Operating Systems/Distros:

  • Gentoo – Source-based meta-distribution driven by Portage and USE-flags for near-granular control; binary packages also available if you'd rather skip marathon compile sessions.
  • Guix System – GNU's functional, declarative distro built with Guile Scheme.
  • MocaccinoOS – Image-based, container-built distro that originated from Gentoo/Sabayon but now uses the Luet package manager and OTA-like updates.
  • NixOS – Declarative Linux distribution using the Nix package language.
  • Qubes OS – Security-focused OS that uses Xen virtualization to compartmentalize your digital life into isolated environments with a unified desktop.
  • Spectrum – In-development security-oriented OS built on Nixpkgs using KVM-based microVMs for compartmentalization.

Desktop Environments/Window Managers:

  • COSMIC - System76's comprehensive Wayland-native desktop environment written in Rust.
  • Hyprland – Dynamic tiling Wayland compositor with scriptable layouts and impressive animations.

System Security/Firmware:

  • coreboot – Open source alternative to proprietary BIOS/UEFI firmware (though recent x86 still needs vendor blobs such as FSP/AGESA).
  • Heads – coreboot + Linux payload providing TPM-measured, tamper-evident boot for select laptops.
  • nix-mineral - NixOS module for convenient system hardening.
  • TrenchBoot – Framework for dynamic root-of-trust (DRTM) launches via Intel TXT, AMD SKINIT, or SEV-ES.

Applications/Tools:

  • Android Translation Layer - Run Android apps natively on Linux (still in early development).
  • Emacs – The self-extensible Lisp machine masquerading as a text editor; someday I'll embrace the config rabbit hole.
  • Olive – FOSS non-linear video editor in alpha.
  • systemd-sysext – Overlay read-only /usr and /opt (or /etc via confext) with extra images; extensions auto-activate at boot or can be merged/unmerged/refreshed live with a single command. Handy for immutable distros, though it’s additive-only and not a full package manager.

What open-source projects are you admiring from afar? Time to compare notes!

[–] [email protected] 2 points 1 day ago* (last edited 1 day ago) (2 children)

Off-topic, but AFAIK the team responsible for PrivacyTools.io's content has moved to PrivacyGuides.org.

PrivacyTools is now (mostly) solely run by its original owner and its content has ceased to be reliable ever since the likes of NordVPN and Surfshark have appeared at the top of their VPN recommendations.

While I wouldn't argue that PrivacyGuides is perfect, it's undoubtedly better than the alternative. And thus unsurprisingly the actual (spiritual) successor of (what used to be) PrivacyTools.

FWIW, PrivacyGuides doesn't recommend Ubuntu.

P.S. while it doesn't tackle as many topics as PrivacyGuides does, privsec.dev offers comprehensive guides on the topics it does. FWIW, they also used to be in the PrivacyGuides team (and perhaps even in PrivacyTools).

[–] [email protected] 2 points 1 day ago

woah, that’s a lot of information.

Yeah πŸ˜…, lol πŸ˜‚. The first draft was even longer; so much so that it exceeded the character limit :P . FWIW, I had written two drafts on two different days until I landed on (another day) with the third and final version.

Atomic distros do sound pretty good.

Yup, I can vouch for that.

I might try one someday,

Please do :P

but I’ve already setup Fedora Workstation and am very happy with it :D

Glad to hear that, fam! Enjoy!

[–] [email protected] 2 points 2 days ago* (last edited 2 days ago) (2 children)

Thanks for your detailed reply! Note that in the following writing I've chosen to address matters in generalities and oversimplifications for the sake of readability and brevity. No need to drown you in technicalities πŸ˜….

On KDE Plasma vs GNOME, I would like to try both out and see which I like better long-term. KDE Plasma seems a bit more familiar (closer to Windows 10) whereas GNOME is a bit more different but I'm open to using either.

That makes perfect sense. As noted by others, while installing both DEs on the same system is technically possible, it often leads to conflicts and inconsistencies. For the cleanest experience, consider dual-booting with separate installations for each DE. Since you've already installed Fedora Workstation, you might want to try KDE on a separate installation.

a laptop with an Intel i7-1360P. It's one of those 2-in-1 convertible 360 degree hinge laptops.

Your hardware should work well with either DE. For future reference, check the Linux Hardware Database and ArchWiki's laptop entries for compatibility information. Since you've confirmed the touchscreen and rotation are working, you're already past the biggest hardware hurdles!

I would say I'm open to learning how to work with the terminal and customising the distro a bit, but I don't want to do anything too out of my scope. I don't want to spend too many hours setting it up, I'd rather have something that works mostly out of the box :D

Both Fedora and openSUSE nail this balance perfectly. They provide sensible defaults that work immediately while giving you room to tinker when you're ready.

Stable as I don't want to break my system after an update. I still want an up-to-date distro though. I am open to rolling release distros, but to my knowledge those are usually less stable with more breaking changes than fixed release options.

FWIW, this is where atomic distros really shine: they offer both stability and current software through their unique update model.

Also, how are the "immutable" distros from UB different from the "mutable" distros?

First, a clarification on terminology: The term "immutable" is actually a misnomer that Fedora has moved away from. These systems aren't truly immutable – they can change, but in a controlled, atomic way. That's why Fedora now refers to them as "Atomic" systems, which better describes their update mechanism and system architecture.

Fedora offers traditional Fedora and Fedora Atomic for desktops, with Atomic including variants like Silverblue (GNOME) and Kinoite (KDE). For servers with atomic updates, Fedora offers Fedora CoreOS. Universal Blue (uBlue) enhances these atomic systems with additional features and optimizations.

The key differences between traditional and Atomic systems include:

  • A read-only base system where core system files are protected from casual changes, ensuring system integrity. On traditional Fedora, you can easily remove or modify system files with commands like sudo rm -rf /usr/bin/important-file, but this fails on Atomic systems with an "Error: Read-only file system" message.
  • Many system changes are tracked, which enables you to 'undo' these changes and return to a cleaner state. This tracking mechanism is what makes factory reset features possible, which are being investigated for these systems. This is surprisingly rare in Linux, with few exceptions like Pop!_OS and TUXEDO OS.
  • Atomic updates mean changes either occur or don't – no half-updated broken states. On traditional systems, interruptions can leave you with partially updated components (like an updated kernel but broken system libraries), while on Atomic systems, the previous deployment remains fully intact and bootable if an update fails.
  • Deployment tracking keeps multiple system versions you can switch between using commands like rpm-ostree status to view deployments and rpm-ostree rollback to return to a previous state.
  • Rebasing capability lets you change your entire system base without reinstalling. For example, you can switch from Silverblue to Kinoite with rpm-ostree rebase fedora:fedora/42/x86_64/kinoite.

uBlue enhances these Atomic systems with proactive maintenance. A great example: when the kernel 6.13 update introduced regressions affecting flatpaks, uBlue maintainers pinned the kernel to 6.12, protecting all users while traditional distro users experienced crashes documented in Fedora discussions, Reddit, and EndeavourOS forums.

uBlue also offers streamlined setup with better onboarding than almost any other distro, simplified handling of troublesome hardware, and purpose-built variants optimized for gaming, development, and other specific use cases.

Does it just mean that you're unable to change system-level settings and such/break anything with a mistyped terminal command?

It's more nuanced than that. While changing /usr contents is restricted, modifying /etc works the same as in traditional systems (though changes are tracked). The real protection comes from the deployment system - even if something breaks, you can easily roll back to a working state.

What are the downsides to using an immutable distro?

There are some trade-offs to consider:

  • Traditional Fedora uses a single approach for software management, while Atomic systems use a combination of methods including Flatpaks, containers, and layering. This creates a more compartmentalized but potentially complex software ecosystem.
  • There are also some system limitations to be aware of. Native messaging in browsers installed as flatpaks require workarounds, kernel module options are limited to uBlue's own akmods repository, and there's no current support for UKI. Granted, I don't expect you to engage with the latter two anytime soon.
  • Additionally, with uBlue, you're trusting their maintainers alongside Fedora's team, though uBlue is mentioned in Fedora's documentation.

For someone wanting stability without sacrificing current software, uBlue variants (Bluefin for GNOME, Aurora for KDE, or Bazzite for both) offer significant advantages, though standard Fedora remains excellent if you prefer a conventional approach. Your successful experience with Fedora suggests you're on the right track!

[–] [email protected] 2 points 5 days ago* (last edited 5 days ago) (4 children)

Okay then, new question, for a beginner friendly distro, should I go for Fedora, OpenSUSE, or something else?

OP, consider making up your mind regarding which one between GNOME and KDE Plasma you'd like to use (at least for the foreseeable future). Afterwards, consider answering the following so that we may do a better job at helping you:

  • What kind of hardware are we dealing with? Can we have the specs?

Note that both Fedora and openSUSE may be considered beginner-friendly. Though, there does exist some considerable difference in design ethos between these and say something like Linux Mint; the former two give you a relatively bare system and assume (at least some) responsibility from its user while setting up the system. By contrast, Linux Mint offers considerable more hand-holding. This may of may not be to your liking.

Note, however, that Fedora and openSUSE are far from the worst offenders in this regard; within the spectrum, they definitely belong to the better half as we've even got distros that assume their users are willing to learn an otherwise useless programming language from scratch. (FYI: I love NixOS and I wouldn't want it anyway else.)

Therefore, allow me to ask another question:

  • How much hand-holding would you deem desirable?

There's also the fleet of distros by Universal Blue that some swear by. These operate with a different paradigm; most of its users would describe them as a better alternative for newbies (under certain circumstances). But I digress...

Finally, I have noted how you've pronounced your preference for a stable system. I do think I understand what you mean by stable, but just to be sure:

  • Stable, as in little to no updates except for those related to security? OR Stable, as in not being afraid to bork your system after an update or otherwise (i.e. kinda synonymous to reliable)? OR... Another use/definition that I've missed?
[–] [email protected] 1 points 6 days ago (1 children)

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.

 

While this is an especially great development for the Fedora Atomic aficionados among us, I wouldn't be surprised if we'll be hearing a lot more from sysexts as (yet another) avenue for installing software, particularly on other atomic/immutable distros. The concept itself isn't new - Flatcar has been utilizing this approach for some time (and has been a significant influence on this Fedora initiative).

The gist would be that it basically allows installing software natively without the traditional rpm-ostree layering method. This approach eliminates both the lengthy installation times and reboot requirements typically associated with that process. Though, it doesn't seem to completely replace the conventional method as it comes with certain limitations (as per the developer):

They can not be used to:

  • install another kernel
  • install kernel modules
  • make changes to the initrd
  • make changes to /etc
  • add udev rules

For those wondering what is actually envisioned to be installed using this method, the software that's already available may shed some light πŸ˜‰.

In any case, note that this is FAR from its final form. The (relative) complexity currently involved in installing and updating software reflects this clearly; don't expect shiny wrappers that will make all of us blissfully ignorant of the underlying complexity right away 😜.

 

While this is an especially great development for the Fedora Atomic aficionados among us, I wouldn't be surprised if we'll be hearing a lot more from sysexts as (yet another) avenue for installing software, particularly on other atomic/immutable distros. The concept itself isn't new - Flatcar has been utilizing this approach for some time (and has been a significant influence on this Fedora initiative).

The gist would be that it basically allows installing software natively without the traditional rpm-ostree layering method. This approach eliminates both the lengthy installation times and reboot requirements typically associated with that process. Though, it doesn't seem to completely replace the conventional method as it comes with certain limitations (as per the developer):

They can not be used to:

  • install another kernel
  • install kernel modules
  • make changes to the initrd
  • make changes to /etc
  • add udev rules

For those wondering what is actually envisioned to be installed using this method, the software that's already available may shed some light πŸ˜‰.

In any case, note that this is FAR from its final form. The (relative) complexity currently involved in installing and updating software reflects this clearly; don't expect shiny wrappers that will make all of us blissfully ignorant of the underlying complexity right away 😜.

 

While this is an especially great development for the Fedora Atomic aficionados among us, I wouldn't be surprised if we'll be hearing a lot more from sysexts as (yet another) avenue for installing software, particularly on other atomic/immutable distros. The concept itself isn't new - Flatcar has been utilizing this approach for some time (and has been a significant influence on this Fedora initiative).

The gist would be that it basically allows installing software natively without the traditional rpm-ostree layering method. This approach eliminates both the lengthy installation times and reboot requirements typically associated with that process. Though, it doesn't seem to completely replace the conventional method as it comes with certain limitations (as per the developer):

They can not be used to:

  • install another kernel
  • install kernel modules
  • make changes to the initrd
  • make changes to /etc
  • add udev rules

For those wondering what is actually envisioned to be installed using this method, the software that's already available may shed some light πŸ˜‰.

In any case, note that this is FAR from its final form. The (relative) complexity currently involved in installing and updating software reflects this clearly; don't expect shiny wrappers that will make all of us blissfully ignorant of the underlying complexity right away 😜.

[–] [email protected] 4 points 1 week ago

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!

[–] [email protected] 25 points 1 week ago* (last edited 1 week ago) (2 children)

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

[–] [email protected] 4 points 1 week ago (1 children)

I was looking for an official documentation entry on this matter to share with OP, ideally something centralized like Fedora's RPM Fusion or the comprehensive Arch Wiki. While I found various user-created resources, I was surprised not to locate a centralized official documentation page addressing this topic. I'm quite familiar with Linux Mint's user-friendly approach, so perhaps I've overlooked something? I'd be genuinely delighted if someone could point me to such a resource, as it would be tremendously helpful not just for OP but for the community as a whole.

[–] [email protected] 15 points 1 week ago* (last edited 1 week ago)

To add to this, a 'distro' -if you will- that was launched recently with this theme would be the aptly-named Blue95.

 

Look, I've only been a Linux user for a couple of years, but if there's one thing I've learned, it's that we're not afraid to tinker. Most of us came from Windows or macOS at some point, ditching the mainstream for better control, privacy, or just to escape the corporate BS. We're the people who choose the harder path when we think it's worth it.

Which is why I find it so damn interesting that atomic distros haven't caught on more. The landscape is incredibly diverse now - from gaming-focused Bazzite to the purely functional philosophy of Guix System. These distros couldn't be more different in their approaches, but they all share this core atomic DNA.

These systems offer some seriously compelling stuff - updates that either work 100% or roll back automatically, no more "oops I bricked my system" moments, better security through immutability, and way fewer update headaches.

So what gives? Why aren't more of us jumping on board? From my conversations and personal experience, I think it boils down to a few things:

Our current setups already work fine. Let's be honest - when you've spent years perfecting your Arch or Debian setup, the thought of learning a whole new paradigm feels exhausting. Why fix what isn't broken, right?

The learning curve seems steep. Yes, you can do pretty much everything on atomic distros that you can on traditional ones, but the how is different. Instead of apt install whatever and editing config files directly, you're suddenly dealing with containers, layering, or declarative configs. It's not necessarily harder, just... different.

The docs can be sparse. Traditional distros have decades of guides, forum posts, and StackExchange answers. Atomic systems? Not nearly as much. When something breaks at 2am, knowing there's a million Google results for your error message is comforting.

I've been thinking about this because Linux has overcome similar hurdles before. Remember when gaming on Linux was basically impossible? Now we have the Steam Deck running an immutable SteamOS (of all things!) and my non-Linux friends are buying them without even realizing they're using Linux. It just works.

So I'm genuinely curious - what's keeping YOU from switching to an atomic distro? Is it specific software you need? Concerns about customization? Just can't be bothered to learn new tricks?

Your answers might actually help developers focus on the right pain points. The atomic approach makes so much sense on paper that I'm convinced it's the future - we just need to figure out what's stopping people from making the jump today.

So what would it actually take to get you to switch? I'm all ears.

 

Look, I've only been a Linux user for a couple of years, but if there's one thing I've learned, it's that we're not afraid to tinker. Most of us came from Windows or macOS at some point, ditching the mainstream for better control, privacy, or just to escape the corporate BS. We're the people who choose the harder path when we think it's worth it.

Which is why I find it so damn interesting that atomic distros haven't caught on more. The landscape is incredibly diverse now - from gaming-focused Bazzite to the purely functional philosophy of Guix System. These distros couldn't be more different in their approaches, but they all share this core atomic DNA.

These systems offer some seriously compelling stuff - updates that either work 100% or roll back automatically, no more "oops I bricked my system" moments, better security through immutability, and way fewer update headaches.

So what gives? Why aren't more of us jumping on board? From my conversations and personal experience, I think it boils down to a few things:

Our current setups already work fine. Let's be honest - when you've spent years perfecting your Arch or Debian setup, the thought of learning a whole new paradigm feels exhausting. Why fix what isn't broken, right?

The learning curve seems steep. Yes, you can do pretty much everything on atomic distros that you can on traditional ones, but the how is different. Instead of apt install whatever and editing config files directly, you're suddenly dealing with containers, layering, or declarative configs. It's not necessarily harder, just... different.

The docs can be sparse. Traditional distros have decades of guides, forum posts, and StackExchange answers. Atomic systems? Not nearly as much. When something breaks at 2am, knowing there's a million Google results for your error message is comforting.

I've been thinking about this because Linux has overcome similar hurdles before. Remember when gaming on Linux was basically impossible? Now we have the Steam Deck running an immutable SteamOS (of all things!) and my non-Linux friends are buying them without even realizing they're using Linux. It just works.

So I'm genuinely curious - what's keeping YOU from switching to an atomic distro? Is it specific software you need? Concerns about customization? Just can't be bothered to learn new tricks?

Your answers might actually help developers focus on the right pain points. The atomic approach makes so much sense on paper that I'm convinced it's the future - we just need to figure out what's stopping people from making the jump today.

So what would it actually take to get you to switch? I'm all ears.

 

Look, I've only been a Linux user for a couple of years, but if there's one thing I've learned, it's that we're not afraid to tinker. Most of us came from Windows or macOS at some point, ditching the mainstream for better control, privacy, or just to escape the corporate BS. We're the people who choose the harder path when we think it's worth it.

Which is why I find it so damn interesting that atomic distros haven't caught on more. The landscape is incredibly diverse now - from gaming-focused Bazzite to the purely functional philosophy of Guix System. These distros couldn't be more different in their approaches, but they all share this core atomic DNA.

These systems offer some seriously compelling stuff - updates that either work 100% or roll back automatically, no more "oops I bricked my system" moments, better security through immutability, and way fewer update headaches.

So what gives? Why aren't more of us jumping on board? From my conversations and personal experience, I think it boils down to a few things:

Our current setups already work fine. Let's be honest - when you've spent years perfecting your Arch or Debian setup, the thought of learning a whole new paradigm feels exhausting. Why fix what isn't broken, right?

The learning curve seems steep. Yes, you can do pretty much everything on atomic distros that you can on traditional ones, but the how is different. Instead of apt install whatever and editing config files directly, you're suddenly dealing with containers, layering, or declarative configs. It's not necessarily harder, just... different.

The docs can be sparse. Traditional distros have decades of guides, forum posts, and StackExchange answers. Atomic systems? Not nearly as much. When something breaks at 2am, knowing there's a million Google results for your error message is comforting.

I've been thinking about this because Linux has overcome similar hurdles before. Remember when gaming on Linux was basically impossible? Now we have the Steam Deck running an immutable SteamOS (of all things!) and my non-Linux friends are buying them without even realizing they're using Linux. It just works.

So I'm genuinely curious - what's keeping YOU from switching to an atomic distro? Is it specific software you need? Concerns about customization? Just can't be bothered to learn new tricks?

Your answers might actually help developers focus on the right pain points. The atomic approach makes so much sense on paper that I'm convinced it's the future - we just need to figure out what's stopping people from making the jump today.

So what would it actually take to get you to switch? I'm all ears.

view more: next β€Ί