1. 22
  1.  

  2. 12

    In a true multi-user system, the system administrators normally do not want users to be able to install arbitrary software or run services.

    I don’t know where the author gets this idea. On the multi-user systems of the 80’s and 90’s, users building and running their own software was quite commonplace. It was one of the main things that propelled the GNU toolchain to become the de-facto standard for open source software around that time: if your OS or admin did not provide a compiler for your system, you could always download GCC and build what you needed yourself. Many administrators preferred this because it meant they didn’t have to bothered with every program their users needed. Of course, a good admin would install software system-wide if enough users needed it, to save on disk space and make users lives easier.

    This seems to be a bit of forgotten history… Linux did not make the GNU ecosystem popular, it was already popular for being a free set of build and userspace tools on commercial and less-capable Unix systems by the time Linux came around. It was an easy and obvious choice to marry Linux and GNU together into various distributions.

    1. 3

      I don’t know where the author gets this idea.

      Kids these days don’t know their history. :)

      What I wrote is my experience with multi-user systems. I’ve only used them at university (in the late 2000s), at research labs (in the early 2010s) and $globochem (these days). In the past, the sysadmins at those places were not excited about me installing things, and I wasn’t very comfortable compiling things on my own so I didn’t make serious attempts at it. The sysadmins didn’t mention that as a possibility, so it’s not something they were pushing people to do. At $globochem, there’s a mix of treating servers as cattle and security getting more paranoid about what you can do the closer you get to user data, so people are not excited about ad-hoc software on those hosts. Other people’s experience may of course be wildly different; people on tilde communities probably have a very different one.

      1. 1

        Oh, yeah, my university account with a 2mb quota. And if you don’t have enough space, you could temporarily go out to /tmp to compile stuff, and keep the binary but delete the source.

      2. 4

        I went through a similar epiphany with home-manager, the difference being that I think it does fit my purpose. Most of the people that start using it believe that it is just a convenient way to have a quick system to sort dotfiles, but its purpose is similar to NixOS: declaratively define an environment and being able to reproduce it quickly and reliably somewhere else. Yes, it is cumbersome to use a specific shell to test the changes to a configuration file, but that ensures that all generations include a working setup of your desktop. That is its value for me: being able to reproduce my (stupidly complex) setup easily and knowing it will work.

        1. 4

          I’m currently trying NixOS and seeing config after config example using home-manager, had to try it myself. But just after futzing around with it for an hour I was already feeling the same way as this review. With home-manager now I have to learn two package managers instead of just one. I’ll just manage my dotfiles myself and call it good.

          1. 2

            home-manager is not just about dotfiles, but also for a) installing packages, b) setting up services. Here’s an example of configuring user-level systemd service for a package in a Git repo.

            And you can share your entire home-manager config between Linux and macOS (good luck doing that with apt or homebrew). Here’s mine: https://github.com/srid/nix-config

          2. 4

            This experiment with home manager coincided with a regular low point in my life in which I try to use emacs. This comes with quite a lot of .emacs changes as I use Lisp for the only thing it’s ever been good for; configuring a text editor in the most complicated way imaginable. Now, the dotfiles that home manager (or Nix) puts on our systems are read-only, so every change would involve changing the source file and running home-manager switch.

            When making big configuration changes, like setting up an initial emacs configuration, why not first do it in .emacs mutably and then later formalizing it as a home-manager configuration? No need to be absolutist ;). I carried over my Emacs configuration from my prior macOS/Arch/Fedora use, so it was never was a big issue [1]. Most other programs have such simple configurations that I am mostly done after at most two or three home-manager switch.

            The first one was never a big attraction. Home manager lets us define a list of packages in home.packages of packages to install. If we control the system configuration, we can acheive the same by defining those packages in users.users.$username.packages.

            I think one of the nice things about home-manager and NixOS is that you often don’t have to specify a list of packages at all, unless you want them to be globally available on the system or as a user. E.g. if you want to use pass somewhere, there is no need to rely on pass being installed. You can just do something along the lines of the following in a Nix string:

            "${restic}/bin/restic --password-command='${pass}/bin/pass Storage/Restic'"
            

            And the full store path of restic and pass will be used through antiquotation. E.g.:

            "/nix/store/654w9743wxdhwyb24si6q0s139pz8jpl-restic-0.9.6/bin/restic --password-command='/nix/store/0i4vyzgfl1dzr12r94z44in84p9ikc6v-password-store-1.7.3/bin/pass Storage/Restic'"
            

            The given store paths will automatically be fetched/built if needed.

            [1] I did rewrite my Emacs configuration in Nix, using rycee’s hm-init: https://github.com/danieldk/nix-home/blob/master/cfg/emacs.nix

            1. 1

              I am a bit uncomfortable of wrapping random configuration files in here-strings just to be able use ${restic}. I wish there was some clever way to be able to use ${pkgs.restic} in arbitrary files that would be copied to the correct location without using here-strings. The reason is mostly you don’t get help from your editor to edit here-strings.

              1. 3

                I wish there was some clever way to be able to use ${pkgs.restic} in arbitrary files that would be copied to the correct location without using here-strings.

                There is. You can use @varName@ in your configuration file and then use the substitute/substituteInPlace/substituteAll to replace the variables by a string that comes from Nix, such as a store path.