title, and to be clear I mean for my usecase specifically. Redhat is being absorbed into IBM and i’m a little worried about how that might affect the fedora project. I’m aware that they’ve been owned by IBM for a while but we are seeing all the typical signs of a company about to go to shit thanks to bad management. I am looking into and preparing to switch in case the fedora project is messed up as well.

I use my pc mainly for gaming (so steam is required) and stuff in my browser and I have a gtx 1650 (can’t get new stuff bc i’m broke) so although I don’t need the proprietary drivers necessarily, I prefer them. I use KDE with a handful of kwin scripts (like temp virtual desktops and karousel) and some cosmetic stuff like klassy, better blur, and a custom color scheme. I need all of that to remain possible. I currently use fedora kde edition, but I have been looking into immutable distros because I don’t know what I’m doing and I want to have a much lower chance of breaking stuff (or at least a way to easily unbreak it). I also want something at least reasonably up-to-date, because I like to get new features quickly. I don’t need to get them as fast as something like arch, but ubuntu and debian are way to slow for me.

what do y’all think would work best for me? I’ve looked at a few things but I haven’t been able to find anything but fedora that serves my usecase the way I want it to yet.

    • hallettj@leminal.spaceEnglish
      4·
      2 months ago

      I think there are arguments for NixOS for a casual user despite the learning curve reputation. But there are also downsides to consider.

      The pros:

      • There is a good, user-friendly installer that makes it easy to get a working system
      • From what I can see setting up KDE is pretty easy - there are configs online that you can paste into configuration.nix without modification
      • NixOS is good for gaming with proprietary drivers and Steam - again it’s a matter of pasting a few lines of configuration
      • Like with other distros it’s easy to recover if something breaks
      • Unlike with other immutable distros you get a lot of options for tinkering with your system, and experimenting. You can dip your toes into the advanced stuff, going from casual user to Linux expert at your own pace, with the safety line of being able to roll back changes at any time.
      • If you stick to the basics you can have a very stable, very update-to-date system without much difficulty.

      The cons:

      • To get the full safety of rolling back a previous point in time you need to ditch channels, and instead use pinned nixpkgs revisions. The best way to do that is probably using flakes - but whatever strategy you use you need to depart from the setup the installer gives you, and learn enough to remake your configuration.
      • You’ll find contradictory instructions depending whether they’re written for use of channels or flakes.
      • Going beyond the basics of installing packages, and using premade NixOS modules gets you into the infamous learning curve. For example I’m guessing that managing kwin scripts declaratively in Nix config might be an adventure. But managing them by hand the way you do in Fedora might be the same. (I haven’t tried this, so I’m not sure.)
      • There is some stuff you have to know, like if you want to run binaries that weren’t built for Nix you want to set up nix-ld first.
      • If you’re building software you have to learn to do things the Nix way because of the lack of FHS. That’s great for Nix fans like me, but frustrating for some.
      • There is no graphical software center, nor automatic updates. You have to use the workflow of installing stuff by editing your config file, and get used to using search.nixos.org to find stuff. This is a pro from the perspective of having a stable system that can be rolled back to earlier states, but might feel less user friendly than a GUI workflow.

      Even if you set up flatpak (which is easy to set up tbf) you’re probably going to be managing flatpaks using the CLI.

      It would be easier for me to recommend NixOS if the installer set up a flake configuration with more niceties pre-installed, like nix-ld. The next best thing would be a de facto standard flake starter configuration for people to copy. But like I said, I think there is a case.

      • SolarBoy@slrpnk.netEnglish
        3·
        2 months ago

        What extra safety do you get by using pinned nixpkgs revisions? And how to do it without flakes (if that’s possible?) I’m currently just using the standard configuration. Occasionally had to do a rollback without issues.

        • hallettj@leminal.spaceEnglish
          1·
          2 months ago

          Oh yeah, I should clarify that - and I might have overstated the issue.

          When you roll back, either by selecting an old entry in the boot menu, or using the nixos-rebuild command you do get an exact replica of the packages from the generation you rolled back to regardless of whether you use channels or flakes. So that’s good.

          The issue comes up in scenarios like these:

          • Something’s not working for you with the latest nixpkgs. You roll back to, and that fixes things. But the next time you run nixos-rebuild switch you get packages from the current channel state again, the one that wasn’t working, and things break again.
          • You want to roll back nixpkgs, but keep your latest configuration changes.
          • You want to go back to an earlier state by getting the old version of your configuration files instead of using the generation manager. For example if you keep your configuration version-controlled with git, reverting to an earlier commit of your configuration history, and running nixos-rebuild switch

          In all cases if you’re using flakes you can roll back nixpkgs by using an older version of the flake.lock file which lets you time-travel nixpkgs independently of changes to other configuration files. With channels you can’t manage the nixpkgs revision with your configuration files. You have to go through some manual steps to reset the channel to the nixpkgs commit you want. It can get more difficult if the commit you want was garbage collected from your local system in the meantime. See https://discourse.nixos.org/t/how-to-roll-back-channel-to-currently-active-version/43161

          In my experience upstream nixpkgs rarely break things, and reverting to an earlier nixpkgs revision is not the best answer. But every once something happens, like a failure in hydra means some package isn’t in the binary cache, and it’s too much for me to build locally (this happened with Electron a few weeks ago), so I can’t use the latest packages until hydra catches up; or there’s some configuration update I need to make for the latest packages, and I don’t have time to work on that for a bit.

      • hallettj@leminal.spaceEnglish
        2·
        2 months ago

        I’ve done that too, and it’s not the same IMO. Ansible doesn’t put entries in the boot loader for older system states you can boot into in case you break something. It’s possible that Ansible configurations aren’t idempotent. The exact versions of packages that get installed can’t easily be managed with Ansible if you’re also regularly updating packages. There’s lots of stuff that is much easier to configure with NixOS and Home Manager. I found my Ansible configs were always out of date, which doesn’t happen with NixOS where editing the config file is how you make any system changes.