NixOS 21.05

Yes, and you can specify your .vimrc, your vim plugins, the users you want setup, their SSH keys, your systemd config, etc.

> Is there some way I can boot-to-git-configuration?

Bootstrapping a system is the one place where you still need to do a bit of work, but it's not bad.

I personally have a script in my Nix config repo which pulls my config down to disk, sets up symlinks, and then switches to the new config. From there everything then goes through standard Nix tooling.

Package managers typically have a concept of a “selected set” or something o that nature which is often simply a file that contains all the packages the user wants to install on a new line at some places. Simply copy that file and do a world update with the package manager and it will install all those packages an their dependencies and typically uninstall what is not needed.

Kind of. It works very well if you own multiple computers that you want to be configured similarly (like a dotfiles repo on steroids).

It doesn't work so well for I borrowed my coworker's computer for 5 minutes and want to use my own Vim configuration.

However, Nix does also supply the "nix run" command, which allows you to use software without installing it permanently (but without NixOS' configuration support).

> Is there some way I can boot-to-git-configuration? So I could do this in RAM on someone else's hardware, like a network boot?

Yes. You could either build an image with a service that git clones your configuration and switches to it, or you could build an image containing a prebuilt snapshot of your configuration.

Either approach should be possible for basically any medium (USB drive, DVD, netboot, whatever). That said, for the build-and-switch setup I'd recommend something that can give at least /nix/store a writable partition (to avoid having to rebuild/redownload the whole world on every reboot).

Yes, the NixOS installer is a live disk with all the features of NixOS. I have booted configurations directly from IPFS in the installer, and many nix commands and functions support git (or GitHub) natively.

You can declaratively specify your whole infrastructure from software configuration to remote machines with their own VMs.

For example here's my nix function for matrix: https://0x0.st/-2CA.nix

It does a whole bunch of stuff.

First it reads in the hostname and domain from the system configuration and put that in a variable to be used when configuring the subdomains later.

Then it opens up your firewall, starts a postgres service, creates the matrix db/user, configures nginx for matrix.hortname.domain, gets your SSL certificate (and sets up automatic renewal), sets up matrix, and lastly a hosted web client at element.host.domain. All services run under their own users on the host system.

It's zero configuration, I just import that to any machine that I want and it's running a matrix server with all appropriate ancillary configuration done.

I ultimately find it easier to have one host that is keeping track of all configurations and pushing my changes to all hosts since I otherwise end up with a lot of machines with different changes I've been working on.

I've been using NixOS for a year now, and I have a definite love/hate relationship. Many times I miss the simplicity of Arch, where I understood _everything_ about my system and how it was configured.

NixOS is like learning everything all over again, but in a weird, poorly documented language+standard lib that nothing else uses.

I think when you are super comfortable with it, is when it becomes truly amazing. But that takes a lot of dedicated time and effort.

nixpkgs (which you can use on macOS or any Linux distro), quite little, you can get up to speed in 15min as a Homebrew replacement:

    nix-env -qas ruby             # 'q'uery 'a'vailable 'search'
    nix-env -I ruby.              # install by package name (not recommended)
    nix-env -iA nixpkgs.ruby_3_0  # install by "attribute", recommended
    nix-env -q                    # 'q'uery (i.e list installed)
    nix-env -e ruby               # uninstall (like deleting a git ref)
    nix-env -q
    nix-collect-garbage           # cleanup, like `git gc`
    # etc...

    $ cat shell.nix
    {
      pkgs ? import <nixpkgs> {}, # you can have multiple of these with different names to have e.g a mix of stable and unstable
    }:
    let
      openssl = pkgs.openssl; # just an example of how to set a var
    in pkgs.mkShell {
      buildInputs = [
        openssl
        pkgs.ruby_3_0 # or reference attires directly
      ];
    }
    $ nix-shell
    (nix) $ ruby --version
    ruby 3.0.1p64 (2021-04-05) [x86_64-darwin17]
    (nix) $ openssl version
    OpenSSL 1.1.1k  25 Mar 2021
    (nix) $ exit
    $ openssl version # back to the system one
    LibreSSL 2.8.3

NixOS, it's barely different, only generalised to the whole OS, but it's a bit tougher, because there's this abstraction via configuration that generates e.g systems files or other configurations that you'd operate with directly otherwise on a traditional distro. But the minute you screw things up, having the generation selector to pick and boot on straight in the boot loader you can see the absolutely unparalleled value of the proposition.

Writing Haskell in it was a joy, but Ruby was pure pain. I actually never could get RoR to run (this might have changed), so I gave up and went to OSX for that stuff.

I only ran into one hiccup: NixOS has an open pull request for supporting plymouth for silent boot with a LUKS encrypted drive. For now, I am stuck with an ugly password prompt when I turn my computer on.

By sheer happenstance, I blogged earlier this week about one particular killer feature that doesn't get enough air time: https://news.ycombinator.com/item?id=27344677

My not-flake-yet configuration can be found at https://github.com/rraval/nix

Nixpkgs itself is several times the size of the base Arch Linux package collection, and by ‘non-unique’ package count, Nixpkgs is also much larger than the AUR. In addition to Nixpkgs, you can find Nix packages in several community ‘overlays’ for Nixpkgs as well as Nix's own user repositories.

You can check to see whether everything you currently use/need is conveniently available for NixOS in a comprehensive-ish way through the combination of these two web search tools:

• for Nixpkgs/NixOS: https://search.nixos.org/packages?channel=21.05

• for NUR: https://nur.nix-community.org/

NixOS also includes native Flatpak support.

Fwiw, packaging most things for Nix is very easy. I left Arch in ~2010 because at the time the package management stack and default repos on Arch basically sucked compared to most distros I'd used and liked, and from then on I decided that if I wanted software that wasn't in my distro's repos I'd just package it myself. After taking a little time to learn the tools on whatever distro I was using, I never missed Arch or the AUR. Compared to other distros, packaging normal software from source is usually exceptionally easy on NixOS.

If I were you I'd just dive right in and hit Nix's channel on Matrix with the Nixpkgs manual in hand if I found something I wanted to use that wasn't already packaged. But you can fall back on the options outlined above.

From a quick search, it seems you can use `services.postfix.config` and pass key-value pairs as arbitrary options. Not familiar with this service, but usually if a given one has more complex syntax, there is a “pass-through” option that will simply append to the given config file whatever text you provide, as well as as the sister reply says you can create manually additional files.

With one exception (nginx, because it's very well supported) I always just use raw config files and ignore the options. For TVL[0] we've written a bunch of NixOS modules[1] ourselves where the upstream one was either not flexible enough, or deviated strongly from how we wanted things to work.

Nix is the kind of tool that lends itself well to solutions that are more complicated than the problem, but once you get comfortable with the tool it's easy to sidestep that. Despite these warts it's 100% worth the investment.

[0]: https://code.tvl.fyi/about/

[1]: https://cs.tvl.fyi/depot/-/tree/ops/modules

lots of services defined in the NixOS options will have an "escape hatch" option named something like `extraConfig`. this usually lets you append verbose text to a complex config file, like in the case of Postfix where the options couldn't conceivably cover everything.

you can also always just write a static file to /etc if you want or need to:

    environment.etc.foo-config = {
      target = "foo.conf";
      text = ''
        enable_spline_reticulator = true
      '';
    };

    systemd.services.foo = {
      after = [ "network-online.target" ];
      wantedBy = [ "multi-user.target" ];

      serviceConfig = {
        ExecStart = ''
          ${pkgs.foo}/bin/food \
            --config /etc/foo.conf
        '';
        User = "foo";
        Restart = "on-failure";
      };
    };

another useful escape hatch is that you can run Docker/Podman containers declaratively. I have some things I want the flexibility to upgrade on a different cadence than NixOS itself (such as my family's "production" Jellyfin server) that I just run as standalone Docker containers with volume mounts for their data.

It can be a superb experience after you go through that trouble. Or it might not be. It depends on what you're trying to do, exactly, but you have to first spend a lot of effort learning before you'll have your answer.

Personally, I found it worth my while.

There's very little in the way of "here's a common task that new users want to do and here's the blessed way to do it." Even something that should be Nix's MAJOR selling point, like "create a single repo that configures a bunch of machines, including some NixOS and some other OS" doesn't have a recommended way to do it.

Another challenge with the docs is the fact that Nix is

* An OS * A package manager * A way to manage dev environments

A lot of times I find someone who solves my problem but they solve it in the context of building a dev environment and I want to do it in the context of setting up an OS package. It means that even with all the good tutorials and blog posts out there, you might still have a bunch of work to do to get things to work how you want. This translates into tons & tons of opportunities for users to give up.

Also, for some reason, so many examples are done in the imperative manner, and it's not always super clear how to translate them to a declarative setup. Again, just defeating the strengths of Nix and clouding the benefits. If a new user sees a bunch of examples that involve starting nix-shell and installing some dependencies it's both hard to understand the benefits and hard to translate that to a declarative setup.

With other popular distributions, you can rely on being able to find a StackOverflow answer with whatever your error message is. Most other OSs and package managers are malleable enough that you can easily beat them into shape should anything go wrong. It's also usually easy enough to adapt how things are done in one Linux distribution to another, but Nix is weird and takes a long time to figure out. (Nix stuff itself being expressive enough that there's often more than one way to do things).

If that happens, users will easily double and maybe more hands might fix the docs or perhaps it's a chicken egg problem but if it's the doc, it's easily solvable.

But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop owner (because my Master's required running Cuda and pytorch) I'm simply left hanging on Guix.

I understand and often appreciate Guix's stand on everything above. No. of packages is because of strong stance on bootstrapping, proprietary package unavailability is self a explanatory.

But, that doesn't solve my problems, and creates few new ones. Even Debian allows using proprietary firmware blobs with some fiddling and doesn't turn people away for asking. These barriers are so much that I bit the bullet and (mostly) learned the weird Nix DSL.

As much as I'd like to go for Guix, for my personal use case, it is a nonstarter.

For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.

I'm wondering whether that's some especially oddly-behaved software, or if what's lacking here is some onboarding (that maybe can solved for you with a little community engagement or something).

https://nixos.wiki/wiki/Flakes#Non-NixOS

(And yeah, obviously all the docs are non-flake too, which leads to confusion about flake.nix vs default.nix...)

But the problem is, many many new shiny things are so comingles with flakes that they are now stuck in limbo, thanks to the one amazing feature that was showcased back in 2019 and then rotted away in implementation hell. Initial RFC was rushed, barely discussed (there are lots of comments, but very little progress, as is the way with flakes) and then simply merged as experimental akin to pushing mess under the carpet. Well the mess was useful, but now the carpet is uneven and the first timers can barely walk straight. I just want a conclusion on flakes, any conclusion would be better than this stupid silent march.

Making it stable now locks Nix into the current flakes model forever - it's too early for that.

Releases are maintained until one month after the next release. So, 21.05 will be maintained until a month after 21.11 is released.

Yet it's normal for Linux distros to patch upstream so that it works well inside of the distro. You may say "but that's crazy! Downstream patching Node packages opens up a whole can of worms!" Maybe you would be right--or maybe not. My point is that when I would raise these kinds of issues, I was met with a collective shrug or various justifications for why brokenness is actually a good thing.

That's what I call a kind of academic/purist mentality that's really great for a research project and not practical for a product. If you ship a Linux distro (and note, I'm talking here about NixOS, not just Nix) that comes with software in the repo, the universal expectation is that the software works as intended, and if it doesn't that it's a bug. There can be an argument over whether the bug is upstream or downstream, but the fault is recognized. That recognition doesn't seem to happen in Nix world in cases where the package comes from an ecosystem that has assumptions that contradict Nix's (or NixOS') assumptions.

> So I would even wager that without some language-specific help nix can’t really work seamlessly across other dependency managers.

The thing is, Nix provides various helper functions to aid in writing derivations for packages from the different ecosystems. They actually try to adapt to the various idioms, which is admirable.

My gripe is that each set of adaptations for each different ecosystem has its own entirely unique API. There's no meta-framework or set of common practices for writing makeNodePackage vs. makePythonPackage vs. makeHaskellPackage even though in many cases they share similar challenges (e.g., X and Y ecosystem's packages import dependencies from hardwired relative paths). It's a question of abstraction; makeXYZPackage exists, but there's no supra-ecosystem abstraction for writing it.

That sounds like an obscure concern until you try using Nix as your daily driver for dev work. As long as you stick to one ecosystem, it's passable. Still a bad UX because nothing is properly documented and really bad anti-patterns (such as forcing package maintainers to update hundreds of thousands of packages to update a single package) are championed, but at least you only need to learn one ecosystem's quirks and idiosyncrasies. The situation changes very quickly as soon as you try to mesh NPM packages with Python with Ruby, etc.

I actually raised this concern a while ago with the Nix devs, and their response was basically that it would take too much effort to harmonize all the different approaches. I thought that was a valid response, but it's unfortunate since I think it's the project's Achilles' heel.

The problem is that they're trying to solve different problems. NPM/pip etc are mostly about letting the developer of an internal application choose and acquire dependencies for their project. Nixpkgs/dpkg etc are about letting the developers of a system acquire and maintain dependencies for a whole system.

These two goals pull in different directions.

NPM/pip want to have available every released version of every package, so that when I can keep using legacy-package with a well-tested version of web-dependency. This way, I can focus my attention on the important matters of writing new code for contemporary-project. I can be confident that legacy-package will keep running the same way it used to, security bugs and all, until I make a decision to attend to it.

Nixpkgs/dpkg want to have available as many packages as possible with a target that every api incompatible library is included, so that any two programs which use the same api use the same version of a package. This way, if they need to patch a well-tested but insecure version of web-dependency, all programs which use it will be kept up-to-date.

Because nix is an agnostic build tool, it can run in both modes simultaneously. You can create a nix expression that uses nixpkgs to build a system that provides a runtime environment and a system that provides a buildtime environment and then uses internal project dependency managers to fulfil the lockfile and installs the product of that, node_modules and all, onto the runtime system. You will lose certain guarantees by doing it this way, and perhaps some parts will require awkward, but that is an engineering decision. For instance, nix won't be able to verify that you aren't depending on changeable remote systems, because you'll have chosen to do that: Nix doesn't trust that npm is add-only, but you might. (Also, some aspects of this will be poorly documented. That's a fixable problem, but the maintainers of a package distribution are probably less interested in the case that optimises for concerns they've chosen not to optimise for, so the documentation for working that way will naturally be worse.)

I think it is fair as long as I make it clear (which I hope I have) that I didn't investigate fully after I saw some warning signs.

>spread doubts just because they don't get fixed in a day or two.

I am not a security expert, but tptacek is, and in 2017 he wrote that "You don't want your browser to be any number of days behind the Chromium patch cycle."[1] IIRC, tptacek or someone of similar credibility said that the browser and the kernel are the primary targets of zero-days exploits on a desktop Linux install.

[1] https://news.ycombinator.com/item?id=13517227

Also let's see how another party handles patches for Chrome: the Arch User Repository's Chrome package (not an official part of Arch Linux) "will automatically get updated as soon as the Debian package is available. This is checked at least once per hour."[2]

There are many many things a distro needs to get right to compete with, e.g., Debian or Fedora on all the criteria desktop Linux users care about. It is not easy. My thanks to Nixos's maintainers for investing their time in trying to advance the state of the art. But Linux users invest a lot of time, too, and in chiming in today I did so because I thought I could save Linux users some time by presenting my conclusions after spending many 10s of hours installing and exploring Nixos.

[2] https://aur.archlinux.org/packages/google-chrome/

>Installing your preferred version of Chrome using Nix is as simple as supplying an alternative upstream URL for the google-chrome package.

Please correct me if I am wrong: this requires building Chrome from source, which will spike the user's CPUs for hours and is impossible with less than 8 megs of RAM ("More than 16GB is highly recommended")[3]

[3] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...

The interval of time during which I was most concerned about unpatched holes in Nixos-unstable's google-chrome was the days leading up to Mar 12.