More specifically, issues for one distro (or maybe family of distros if applicable) and not other distros.

I’ll start: NixOS. I love how I can have my whole operating system configuration defined deterministically with configuration files, but what I believe is a serious flaw, is when you choose the “unstable” channel, the channel for receiving the latest packages rather than ones up to 6 months old: stable. Unstable package often build dependencies on device, and I’ve often faced build failures, why are new package versions given if they fail to build?!

Why can’t Nixpkgs backend ensure that new package versions build successfully before shipping them to end users?! It would take a lot of work to do so, but I can’t think of any other distros that have this problem: where installing a new package version that came out a few days or even a week ago, has a chance of failing after its made available in the distro’s official package manager.

There are a handful of workarounds for your NixOS configuration in this case, but it happens too often for me and I shouldn’t have to edit my config for to work around it.

  • stuner@lemmy.world
    2·
    10 hours ago

    Mostly, I’ve only had minor issues: Old packages on Linux Mint, missing packages on Debian and Arch, system instability after updating without a reboot on many distros (NixOS, Fedora, Alma, …). But I’ve had two major issues that caused me to abandon a distro:

    1. On Fedora KDE, I felt that my system was overall not as stable as other distros. Then they decided to ship (as a rolling update to a “stable” version) an experimental KDE patch that broke the lock screen for a week. The breakage itself was not so bad, but shipping a patch before upstream merged it to their nightly builds irked me quite a bit.

    2. On NixOS, I was not able to get development stuff to work (I’m probably just too dumb for Nix/NixOS). First, I tried to set up a dev workflow that has quite a few external constraints (glibc version, Python version, running on other distros, …). I failed on multiple fronts and gave up on this. Then I tried to build my own KDE/Kirigami app on NixOS and also struggled a lot with it. I struggled for quite a while but gave up on it in the end. I moved to CachyOS afterwards and it worked flawlessly 🤷

    • ultimate_worrier@lemmy.dbzer0.com
      2·
      4 hours ago

      At least you were intellectually honest about NixOS rather than blaming them.

      I swear by it but had a year or two where I was struggling. Particularly with languages like Python, it can be tough to train yourself in the Nix way (or to wrap compilation and dependency management into the nix paradigm in this case). With languages like Haskell though, the Nix way goes hand-in-hand with it.

      I’ve found Zig to work well with Nix. And there are ways to use Nix REALLY elegantly with Python

      Here’s an example of how you’d provision a super simple nix flake dev environment in x86_64 Linux for undetected web scraping with Python

      
# save this as flake.nix then run nix develop in the root of the repo

{
  description = "Web Scraper";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs?ref=nixpkgs-unstable";
    utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, utils }: utils.lib.eachSystem ["x86_64-linux"] (system: let
    pkgs = import nixpkgs { system = system; };
  in rec {
    packages = {
      pythonEnv =
        pkgs.python3.withPackages (ps: with ps; [ webdriver-manager openpyxl pandas requests beautifulsoup4 websocket-client selenium keyboard ]);
    };

    devShell = pkgs.mkShell {
      buildInputs = [
        pkgs.chromium
        pkgs.undetected-chromedriver
        packages.pythonEnv
      ];

      shellHook = ''
        export PATH=${pkgs.chromium}/bin:${pkgs.undetected-chromedriver}/bin:$PATH
      '';
    };
  });
}