Programmer in California

I’m also on https://leminal.space/u/hallettj

  • 17 Posts
  • 311 Comments
Joined 2 years ago
cake
Cake day: May 7th, 2023

help-circle
rss





  • I think there’s a way that might be easy-ish. In short what the services setting does is to get necessary packages, write configuration files, and install systemd unit files. You can build a NixOS configuration, and symlink or copy the necessary systemd units and configuration files. I think that would work, and would not interfere with other stuff on your system.

    NixOS configurations must be built with nixos-rebuild - you can’t use nix-build by itself. You can put your configuration wherever, and run:

    $ nixos-rebuild build -I nixos-config=./configuration.nix
    

    That will build everything in paths under /nix/store/ without touching anything else on your system. It will create a symlink in your working directory called result/ with a fully-built, bot not installed, NixOS. If you were running NixOS you would run nixos-rebuild switch to update symlinks to point to all of this stuff. But you’d skip that step.

    result/etc/systemd/system/ contains systemd units. There will be a lot of stuff there that you don’t want. You’d need to selectively symlink or copy units from this directory to your /etc/systemd/ tree.

    The units use full paths to binaries in /nix/store/ so you don’t need to do anything extra to install software packages.

    You might need to symlink or copy configuration files for your services. Those should also be somewhere in result/.

    If NixOS and Debian use the same systemd target names your services should run automatically on boot. If not you might have to do some fix-up, or run systemctl commands manually. I think you’d need to run some systemctl commands to start and stop services if you want to update without rebooting.

    You can probably do all that symlinking just once if you symlink everything through that result symlink.

    Edit: Although, taking a closer look at what services.nextcloud does I see that it does a lot, like initializing databases and creating user accounts if you choose to use a local database. It might be a lot of work to chase down all of the configuration that you would have to copy over. Running NixOS is definitely going to be easier.




  • (This is probably explained in the article, but I don’t have a subscription.) The National Ignition Facility (NIF) creates fusion by bombarding a fuel capsule with lasers. The laser beams are reflected many times to build up energy, and to converge on the capsule. There is energy loss during that process so the laser energy that goes into the capsule is a small fraction of the electricity used to fire the lasers. When they say they got twice the energy out, that’s compared to the laser energy going into the capsule, not the energy required to fire the lasers. So its a long way off from a practical power plant, but still important progress.

    The purpose of the NIF is to study what goes on inside the capsule - for better understanding, and to figure out how to get the most possibly energy out of a fusion reaction. Once they have figured that out a possible next step is to design a system that delivers laser beams with less input energy. It’s easier to do that after you know the ideal way for beams to interact with the capsule. Or maybe we never build a power plant based on the NIF design, but the findings help to make other reactor designs work.



  • I haven’t worked with the deployment tools which is what I think would make the most direct comparison to other automation frameworks so I don’t know how comparatively opinionated they are. I suspect it varies between those tools.

    Using NixOS or Home Manager there is a certain way of doing things. But these are intended to be opinionated. Packages and modules come from either nixpkgs, or from third-party flakes which package for Nix. Services are usually orchestrated through systemd units which come from Nix packages.

    You can do anything with Nix. The tools and frameworks encourage certain ways of doing things. But that depends on the framework. You can always build a new framework that works differently. Since they are all based on common concepts of Nix expressions, derivations, and in many cases flakes you get a certain baseline interoperability between frameworks.


  • Well you’re really feeding my Nix confirmation bias here. I used to use Ansible with my dot files to configure my personal computers to make it easy to get set up on a new machine or server shell account. But it wasn’t great because I would have to remember to update my Ansible config whenever I installed stuff with my OS package manager (and usually I did not remember). Then along came Nix and Home Manager which combined package management and configuration management in exactly the way I wanted. Now my config stays in sync because editing it is how I install stuff.

    Nix with either Home Manager or NixOps checks all of the benefits you listed, except arguably using a “known” programming language. What are you waiting for?








  • Well ok, they both use symlinks but in different ways. I think what I was trying to say is that in NixOS it’s symlinks all the way down.

    IIUC on Fedora Atomic you have an ostree image, and some directories in the image are actually symlinks to the mutable filesystem on /var. Files that are not symlinks to /var (and that are not inside those symlinked directories), are hard links to files in the ostree object store. (Basically like checked-out files in a git repository?)

    On NixOS this is what happens if examine what’s in my path:

    $ which curl
    /run/current-system/sw/bin/curl
    
    $ ls -l /run | grep current-system
    /run/current-system -> /nix/store/p92xzjwwykjj1ak0q6lcq7pr9psjzf6w-nixos-system-yu-23.11.20231231.32f6357
    
    $ ls -l /run/current-system/sw/bin/curl
    /run/current-system/sw/bin/curl -> /nix/store/r304lglsa9i2jy5hpbdz48z3j3x2n4a6-curl-8.4.0-bin/bin/curl
    

    If I select a previous configuration when I boot I would get a different symlink target for /run/current-system. And what makes updates atomic is the last step is to switch the /run/current-system symlink which switches over all installed packages at once.

    I can temporarily load up the version of curl from NixOS Unstable in a shell and see a different result,

    $ nix shell nixpkgs-unstable#curl  # this works because I added nixpkgs-unstable to my flake registry
    $ which curl
    /nix/store/0mjq6w6cx1k9907vxm0k5pk7pm1ifib3-curl-8.4.0-bin/bin/curl  # note the hash is different
    

    I could have a different version curl installed in my user profile than the one installed system-wide. In that case I’d see this:

    $ which curl
    /home/jesse/.nix-profile/bin/curl
    
    $ ls -la /home/jesse | grep .nix-profile
    .nix-profile -> /nix/var/nix/profiles/per-user/jesse/profile
    
    $ ls -l /nix/var/nix/profiles/per-user/jesse
    profile -> profile-133-link
    profile-130-link -> /nix/store/ylysfs90018zc9k0p0dg7x6wvzqcq68j-user-environment
    profile-131-link -> /nix/store/9hjiznbaii7a8aa36i8zah4c0xcd8w6d-user-environment
    profile-132-link -> /nix/store/h4kkw1m5q6zdhr6mlwr26n638vdbbm2c-user-environment
    profile-133-link -> /nix/store/jgxhrhqiagvhd6g42d17h4jhfpgxsk3n-user-environment
    

    Basically symlinks upon symlinks everywhere you look. (And environment variables.)

    So I guess at the end everything is symlinks on NixOS, and everything is hard links plus a set of mount paths on Fedora Atomic.