• 0 Posts
  • 12 Comments
Joined 3 years ago
cake
Cake day: June 14th, 2023

help-circle
  • It’s the same controversy as it was last year and the year before that: should the military-industrial complex be allowed to benefit from the Nix commons? It’s disappointing that you don’t think that the ethics of our profession is worth more than the output of our labor, particularly when it comes to exploitation, mass surveillance, war, and genocide.

    Most of us write flakes outside of nixpkgs. I’m still listed as a maintainer and get pinged, but I don’t really care; anything I care about is already being actively developed out-of-tree. I doubt I’m the only maintainer taking that sort of quiet-quitting path.



  • Good notes. Another trick is to replace /etc/hosts (which is usually a symlink to /etc/static/hosts) with a custom file; for example, copy all of the hosts from /etc/static/hosts and then add new hostnames for the failing caches. This can turn an indefinite network timeout into a fairly quick connection-failed error.

    Personally I think it’s a design deficit in Nix that is compounded by the serial, one-at-a-time, timeout-based way of operating. A Nix implementation should have a sense of trading off disk, bandwidth, compute, and time; a substitution should only be preferred when it is likely to save at least one of those resources, and abandoned if it isn’t making progress.


  • As a relatively heavy solution, you can use a container orchestrator that understands a failure to pull an image as a temporary or transient situation. The lightest orchestrator that I’ve used on NixOS in a homelab is k3s:

    services.k3s.enable = true;
    

    It is more-or-less a cut-down Kubernetes, and as such it will not fail to start merely because one Pod had an error pulling one Image. It will also offer a path forward if you want to continue building up software-defined networking.

    That all said, I’d re-examine what you want from service isolation during OS upgrades; it’s possible for routine NixOS updates to only restart affected services and not reboot. In production, nixos-rebuild switch can do things like upgrade shared libraries, switch webroots, or flip feature flags. Containerization might be unnecessary overhead, and I say that as a Kubernetes proponent.


  • I don’t really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don’t mind writing bare Nix) but part of it is a desire to not rely on flakes which don’t carry their own weight, following Wirth’s principle for compilers.

    That said, github:numtide/flake-utils does carry its own weight by managing multiple system values, especially in flakes that support more systems than upstream nixpkgs, and I’ve found myself using it in nearly everything; flake-utils makes it fairly easy to have leaf packages that are e.g. supported on both amd64 and aarch64. I know flake-parts does this too, but not in a way I enjoyed.

    I just noticed that you said “my configuration.” A machine, perhaps? My NixOS configuration is split into over a dozen NixOS modules and each machine has a list of included module files. I’m not using any flake-management tools for that flake; each machine has a hardcoded system and (like sibling comment from @algernon@lemmy.ml) they’re all crammed into one big flake.nix so that the machine hostnames line up correctly when using the flake in argv:

    $ sudo nixos-rebuild switch --flake git://git.example.local/one.big.flake.git
    

    Seems facetious at first, but it facilitates automatic updates via flakes, just like with classic channels.


  • Can notifications be started from a systemd unit? Kind of. notify-send can be invoked from systemd, but getting the correct user notified is non-trivial and I’m not sure how it would be done on NixOS.

    Can nixos-rebuild have a progress bar? Not really. It’s not a process with a predictable end time.

    Can there be notifications when updates are available? There are scripts out there (like this one which I have never used) which can poll git repositories and run notify-send, but that’s not very useful. Instead, it’s worth knowing that most of the cost of auto-upgrade is running the nixos-rebuild command at all, even if there are no available upgrades!

    Instead, consider setting system.autoUpgrade.dates to a fixed time when you definitely won’t use the computer, and also set system.autoUpgrade.persistent. This will run auto-upgrade on boot in the worst case.

    Also, USB devices should not be disconnecting on every update. If USB disconnections happen under high load, check dmesg for possible hints; you may merely need to add an override to boot.kernelParams.





  • The nixpkgs community has been operating and maintaining nixpkgs-update since 2018. Earlier in the thread, you were shown the infamous Repology graph; it’s also linked from the nixpkgs-update documentation. We already have a concerted plan to offer the freshest ports tree in the world and are executing on it. If your particular pet package isn’t available, then contribute it yourself and the bot will ensure that it stays fresh and updated.