• 1 Post
  • 16 Comments
Joined 4 days ago
cake
Cake day: June 21st, 2026

help-circle

  • Ah, okay. I do concede that -historically- Fedora wasn’t robust, no. They weren’t shy about breaking changes, which even led them to be referred to as Red Hat’s test bed distro by the community and beyond.

    However, for (at least) the last 5 years or so, Fedora’s direction has changed significantly. I’m not entirely sure what prompted this change, but it has definitely been a welcome one. For example: most recently, Fedora has somewhat even formalized this new approach with their new initiative.

    Basically, Fedora wants to be innovative like they’ve always been known for. But, this shouldn’t come at the cost of alienating your own user base. Thus, the proposal details how these two perspectives can see eye to eye with each other.


    As for KDE Plasma; again -historically- it has been a second-class citizen on Fedora; at least, compared to GNOME. But, KDE Plasma has since been promoted. There’s no meaningful difference between the two variants when it comes to how Fedora regards them. Even the website alludes to this:


  • Fedora doesn’t seem to be the right candidate.

    Why do you think that?

    Arch Linux (or Endeavour / Manjaro)

    If you mean that they’re more stable, then I simply have to assume that you think those are more robust than Fedora (because the other interpretation[1] wouldn’t make any sense). Which (again) begs the question… why do you think that?


    1. The way Debian uses the term Stable for its slowest moving release. ↩︎









  • Unsure whether it fits with the rest, but I’d argue it is an innovative and very compelling ‘standard’ that is competing with everything else mentioned in this thread.

    So, the basic idea is as follows: if it is so difficult to deal with the loss of the main package manager found on the mutable/traditional variant, why don’t we pursuit ways to not lose it in the first place and thus try to make it coexist (somehow) with the atomic model. Enter RakuOS’s hybrid design in which everything installed through dnf is overlayed persistently over the bootc-managed base system.





  • FWIW, uBlue has been brewing for almost three years now for their CLI stuff: see this issue tracker and this blogpost from Bluefin’s creator.

    The distrobox workflow overall has mostly been superseded by better alternatives[1]. Though, for completeness’ sake, openSUSE’s atomic offering continues to heavily rely on Distrobox. But, in their defense, I think their atomic offerings are simply better[2] suited for it.


    1. There’s sysext with its (WIP) manager, Brew Tap to tap into homebrew casks and some peeps even use coldbrew. And last, but definitely not least, nix support has improved over the years. And if you just want to use dnf, RakuOS’ innovative hybrid design allows just that; an image-based core you can’t touch (like the other ‘immutables’), but dnf works and is applied through a persistent overlay. ↩︎

    2. Fedora’s container images are tied to its major release versions. Hence, every 7-13 months you’re required to set them up from scratch if you’d like to continue using them 😅. Even if this process can be streamlined, it’s IMO very cumbersome regardless. In openSUSE’s case, the containers are based on Tumbleweed. Which, has a rolling release cadence. Hence, it was meant to be used indefinitely. ↩︎