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.

  • SolarBoy@slrpnk.net
    link
    fedilink
    English
    arrow-up
    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.space
      link
      fedilink
      English
      arrow-up
      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.