HayadSont

joined 1 week ago
[–] HayadSont@discuss.online 1 points 11 hours 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 😜.

11
submitted 19 hours ago* (last edited 18 hours ago) by HayadSont@discuss.online to c/linux@lemmy.world
 

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

11
submitted 19 hours ago* (last edited 18 hours ago) by HayadSont@discuss.online to c/linux@lemmy.ml
 

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

[–] HayadSont@discuss.online 4 points 3 days 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!

[–] HayadSont@discuss.online 25 points 3 days ago* (last edited 3 days 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).

[–] HayadSont@discuss.online 4 points 4 days 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.

[–] HayadSont@discuss.online 15 points 5 days ago* (last edited 5 days ago)

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

[–] HayadSont@discuss.online 3 points 6 days ago* (last edited 6 days ago)

Without trying to be exhaustive:

But all I know about Linux is 1: it’s a cantankerous beast that can smell your fear and lack of computer skills and 2: that’s apparently not true any more?

Exactly.

I’m pretty much a fairly casual PC-user, I don’t do much more than play games.

Noted.

Will my ability to play games be significantly affected compared to Windows?

Your queries on which specific games work and don't work should be answered between the databases of ProtonDB, WineHQ, Lutris and Are We Anti-Cheat Yet?. Note, however, that these are not necessarily exhaustive (even if put together); e.g. after visiting the aforementioned websites, you might think that Roblox can't be played on Linux. But it's simply one of the many games that exist in the compatibility blind spots between these databases; as the excellent Sober isn't accounted for.

Can I mod games as freely and as easily as I do on Windows?

There will definitely be a learning curve to be had. Though, AFAIK, there's nothing that outright prevents you beyond an initial (and potential) knowledge gap.

If a program has no Linux version, is it unusable, or are there workarounds?

Wine is your best friend in these cases. Or, an alternative. Note that -again- compatibility blind spots in these databases continue to exist; like this significant one.

Can Linux run programs that rely on frameworks like .NET or other Windows-specific libraries?

Again, Wine comes to the rescue.

How do OS updates work in Linux? Is there a β€œLinux Update” program like what Windows has?

This depends entirely on the so-called Linux distribution you end up installing. Some opt to do updates automatically (perhaps in the background even), while others simply prompt the user whenever updates are available. Yet others expect the user to do them manually. What are your preferences in this regard?

How does digital security work on Linux? Is it more vulnerable due to being open source? Is there integrated antivirus software, or will I have to source that myself?

This is somewhat of a controversial topic thanks to articles like this one. Note that while the article continues to be shared and thus remains 'popular', the fact of the matter is that at least some parts of it have become outdated since. Refer to this (more recent) article as an addendum. The gist would be that Linux might be secure enough for your intents and purposes. But this depends entirely on what you intend to use it for. Downloading and executing random files from the dark web is probs a bit much and not something any OS would appreciate. But playing your games through Steam and surfing the internet should be fine unless you're somehow targeted by a resourceful adversary. If you didn't worry too much about this on Windows and thus went with the default settings -so no hardening whatsoever-, then popular distros like Fedora should be more than fine for your use case. However, if you require more than that, then you may find solace in the fact that projects like Kicksecure and secureblue do exist. (There's also Qubes OS, but I'll assume that's too hardcore.)

Are GPU drivers reliable on Linux?

In most cases, yeah. Historically, Nvidia used to be a pita. And, frankly, continues to be for some peeps. But it has improved significantly over the last couple of years.

Can Linux (in the case of a misconfiguration or serious failure) potentially damage hardware?

Any bad software (irrespective of platform) can potentially damage hardware. Linux is no different in this regard. Though you shouldn't have to worry about this unless you intend do some janky stuff.

And also, what distro might be best for me?

As gaming seems high on your list, consider Bazzite.

[–] HayadSont@discuss.online 2 points 1 week ago

FWIW, I actually do understand the difference πŸ˜….

As the term "immutable distro" has -unfortunately- become a misnomer, I went with the (more) descriptive "atomic distro" instead. At least it rings better than names like "distro with transactional updates", "distro with (some degree of) managed state" or -heck- "distro with anti-hysteresis properties" 😜.

Granted, perhaps the notion (and/or intention) to lump the likes of NixOS together with Endless OS under one oversimplified umbrella term isn't being helpful either. But I digress...

Though, I find solace in the fact that (at least within these discussions) Gentoo is regarded as a traditional distro 🀣.

Or..., put more formally: Creating and maintaining precise terminology for the diverse Linux ecosystem is incredibly challenging. While nerds like myself would enjoy the classification work, the effort required to keep terms accurate and widely understood in this ever-evolving landscape is no joke 😭.


Anyhow, I might as well hijack the remainder of this comment to thank you and everyone else that made contributions to this discussion. Much appreciated!

 

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.