• 0 Posts
  • 68 Comments
Joined 2 years ago
cake
Cake day: November 28th, 2022

help-circle
  • Your personal files e.g. ~/Documents are not recreated, you’ll still need backups of those.

    caveats are you’ve got to use:

    • home-manager to generate your dotfiles.
    • something akin to sops to generate and securely store your private keys and secrets.

    But all this can be written in the one flake, so yes nixos-install --flake <GIT URL>#<HOSTNAME> Is sufficient for me to rebuild my desktop, laptop or server from the same repository.

    I’ve never used Gentoo, and I’m sure there are other methods of achieving the same level of reproducibility but I don’t know what they are.

    Nixos can be as modifiable as Gentoo with the caveat being it’s a massive pain in the ass to do some things. I have a flake for making aarch64-musl systems which has been an endeavour, and… It works? I have a running system that works on 2 different SoCs. I do have to compile everything quite often though.

    There are efforts to recreate Nixos without systemd, but that’s a huge effort; because it’s very “infrastructure as code”, you have to change a lot of code where editing a build script would’ve sufficed on arch/Gentoo.

    As for nix vs guix, guix was described to me as “if you only ever want to write in scheme”, whereas nix feels much more like a means to an end with practical compromises spattered throughout.








  • I wish.

    It was a bcachefs array with data replicas being a mix of 1,2 & 4 depending on what was most important, but thankfully I had the foresight to set metadata to be mirrored for all 4 drives.

    I didn’t get the good fortune of only having to do a resilver, but all I really had to do was fsck to remove references to non-existent nodes until the system would mount read-only, then back it up and rebuild it.

    NixOS did save my bacon re: being able to get back to work on the same system by morning.








  • ~/.config is probably a poor comparison on my part; it’s management is actually done by home-manager rather than Nixos proper, and I can’t think of another OS that fills this same role.

    Nixos generates (for example) /etc/systemd/network to a path in /nix/store and symlinks it to it’s appropriate locations. After the files are generated the appropriate /nix/store paths are (re-mounted? Over-mounted? I’m not sure the implementation) made read-only (by default), but anything that isn’t generated is absolutely both mutable and untracked, and that “not tracking everything in /etc” is more what I’m going on about.

    If you use Nixos as intended (when you find that a package is lacking a config option you want, create your own nix option internally) the distro is effectively immutable, but if you use Nixos for anything moderately complex that changes frequently e.g. a desktop os, you eventually run into the choice: become competent enough to basically be a nixpkgs contributor, or abandon absolute immutability.

    I think the first option is worth it, and did go down that route, but it is unreasonable to expect the average Linux consumer to do so, and so something like fedora atomic is going to remain more “immutable” for them than nixos.

    This need to git gud is thankfully lessening with every commit to nixpkgs, and most people can already get to most places without writing their own set of nix options or learning how to parse //random markup language// into nix, but you’ll eventually run into the barrier.


  • I’d argue it’s closer to a mutable distro than an immutable one.

    Nixos tends to lean on the term reproducible instead of immutable, because you can have settings (e.g files in /etc & ~/.config) changed outside of nix’s purview, it just won’t be reproducible and may be overwritten by nix.

    You can build an ‘immutable’ environment on nix, but rather than storing changes as transactions like rpm-ostree, it’ll modify path in /nix/store and symlink it. Sure, you can store the internal representation of those changes in a git repo, but that is not the same thing as the changes themselves; if the nixpkgs implementation of a config option changes, the translation on your machine does too.




    1. Get kicked from freedesktop for fostering a toxic community.
    2. Ditch wlroots for your own compositor.
    3. Shit on other compositors in your spare time.
    4. Tell people they should just be plugging into Hyprland instead of rolling their own compositor.

    Man if I was concerned about sinking the time to make a configuration for the compositor with a bus factor of 1 man-child, and a toxic community; I can’t imagine anybody investing the time to make a compositor is going to want to hitch themselves to that cart.

    The compositor is really solid and makes for a great user experience but I’ll be fucked if every word vaxry writes doesn’t make me want to move to sway or niri.