Why did you choose the nix you nix?
lobste.rs
45 comments
  • lobsters__tenta_48c4@crustaceanson.theshelf.topM
    1·
    3 days ago

    I’ve been on NixOS for about 10 years. I just reinstall git and other programs whenever they stop working (presumably after GC sweeps a .so dependency away?), never bothered with flakes or home-manager or whatever, don’t understand the configuration language. I get screenfuls of “xx dependency is out of date, use xy” messages on system updates. It’s low-maintenance and high-maintenance at the same time, if that makes sense.

    I’ve been thinking of switching to something simpler. I don’t think there are any Nix features that are unique, important to me, and outweigh the rest of it. I kept starting to try Guix (so I can actually write software packages for my own computer!) but every spare machine I could test a new OS on is 32-bit, so they’re getting Haiku or NetBSD for fun, and I guess I’ll have to set aside a sunday to just jump ship.

    score 1 · canonical

    • lobsters__5d22b@crustaceanson.theshelf.topM
      1·
      3 days ago

      I just reinstall git and other programs whenever they stop working (presumably after GC sweeps a .so dependency away?), … I get screenfuls of “xx dependency is out of date, use xy” messages on system updates.

      I’ve been using NixOS more than 10 years and I don’t think I’ve heard of either of these issues before. How is it that you “install git and other programs”? Dependencies of packages installed through Nix should not be getting GC’d.

      It’s low-maintenance and high-maintenance at the same time, if that makes sense.

      I do agree with this, though.

      score 1 · canonical

      • lobsters__tenta_48c4@crustaceanson.theshelf.topM
        1·
        3 days ago

        Dependencies of packages installed through Nix should not be getting GC’d.

        I thought that too! I used nix-env -iA nixpkgs.gitFull last time - git is the only one that simply disappears from $PATH, the rest of the time it’s usually some graphical program or other refusing to start. Every time, nix-env -iA fixes it. I think it happens after a nixos-rebuild --switch, but I don’t currently have enough disk space to find out.

        The deprecation messages look to be custom per package during nix-env -u (which, incidentally, takes freakin’ years to start downloading anything these days). (I heard once upon a time nix-env isn’t the best thing to use, but it comes preinstalled, the NixOS manual endorses it, and it does what I want it to, so, shrug!)

        score 1 · canonical

  • lobsters__toastal@crustaceanson.theshelf.topM
    1·
    3 days ago

    I use NixCpp since I want BLAKE3 hashes & Lix doesn’t support it. Otherwise, at least for now, Lix aligns more with some of my beliefs & I would like to try it again. NixCpp has been improving too tho.

    I could see NixCpp being better/leaner/cleaner if it could shed the baggage of Flakes being merged prematurely. That feature IMO needs to be label “experiment failed” & moved out into a plugin (Lix’s goal) or separate project such that 1) the binary is not concerned with input pinning, schemas, or the extra maintenance burden of forge-specific support in fetchTree (largely to facilitate in adding input pinning / refreshing to the binary) 2) those that wish to use/adopt/contribute to flakes can iterate independent of the binary 3) alternatives can be on equal footing as I think the design has a lot of flaws (but it’s hard to compete with “just enable this flag”). There just so many bad patterns that have resulted from when flakes ergonomics push projects into heavy coupling; the way folks use flakes get their otherwise stable code completely locked behind an unstable feature that is non-trivial to evaluate (since flake.nix isn’t valid Nix).

    I’d like to try Guix in theory but I don’t care for LISPs & it’s as simple as that for me, an ML-family fan (I believe there are non-LISP-y way to use it, but technically you can skip Nix the language by compiling to the .drv files too).

    score 1 · canonical

  • lobsters__wilhe_f7e4@crustaceanson.theshelf.topM
    1·
    3 days ago

    I chose Lix because I like the idea of Nix with community-first principles that takes Rust seriously, and really I only chose it over Guix because Nix is more popular and will have more industry usage as time goes on. Guix is probably cooler but being Lisp it’ll never be popular enough that a guy like me could get employed to work with it.

    score 1 · canonical

  • lobsters__polywolf@crustaceanson.theshelf.topM
    1·
    3 days ago

    Lix because I trust the dev team more than any other Nix-like, with Guix as a close second in that regard. Not Guix because I don’t like lisp and I do like the convenience of the world’s largest package repository.

    score 2 · canonical

  • lobsters__quasi_b0ee@crustaceanson.theshelf.topM
    1·
    3 days ago

    Determinate Nix is the “corporate” version. It’s run by big names in the Nix ecosystem but there’s perennial concerns about them not upstreaming improvements, trying to shove features in, whatever. I don’t know if it has any compelling benefits over cppnix.

    Lix I like because it feels like they’re trying to fix a lot of the papercuts that are involved in the ecosystem, untangle the gnarly codebase, and so on. AFAIK there are no incompatibilities between it and cppnix unless you do weird stuff.

    Guix has the advantage of using a proper language and first class home-manager(-equivalent) support. The biggest downside is that it’s a gnu project so nonfree software support will always be secondary, and IIRC there were still enough sharp edges when I tried it that I went back to Lix. But I wish them well and hope they succeed!

    So I’d say either Lix (if you want to be able to interop with the broader Nix ecosystem) or Guix (if you like Scheme, copyleft, or a more cohesive system).

    AFAIK none of snix/tvix/etc are usable as a replacement for the cppnix binary in the way Lix/Detsys Nix are.

    score 5 · canonical