I've recently installed NixOS on an old Thinkpad I got from work, and I was pleasantly surprised by the graphical installer. Even though NixOS is far from a beginner distro, removing friction in the initial installation process is a good thing.

Looking forward to seeing and reporting back on what my first NixOS upgrade experience is like.

Going back to an OS that doesn’t have this property feels like programming without version control.

Obligatory disclaimer, they're still in beta, but everyone's using them anyway. There's some ongoing work[1] before they're officially released.

[0] https://nixos.wiki/wiki/Flakes [1] https://www.youtube.com/watch?v=JE-vLFMTXxM

It's a shame this isn't explicitly highlighted on nixos.org, it's only implied in the "Is the previous version better? Roll back anytime."[0] section, when it's true for both packages and your entire system's config.

[0] https://nixos.org/explore.html

Also if anyone is wondering, nixos-unstable feels very stable as an end-user.

If you want an FHS, you can get one using a function like buildFHSUserEnv (that's defined in the Nixpkgs project; Nix itself doesn't know or care what FHS is; indeed, Nix will happily run on non-Linux platforms)

[1]: https://github.com/Lassulus/nix-autobahn

The vpn client at work wasn't available for the latest ubuntu and the old version did not work due to changes in some libs. Wrapping it with nix providing the right libs was way easier and much more replicable than manually building the required stuff. Did in on my machine and than 3 mins to do the same for a colleague.

It works very well for me under Ubuntu these days, but if I can get it working equivalently well on NixOS I may legitimately consider switching.

First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config (however, kexec will not likely work, read more how to run it later)

Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.

Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.

If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750

For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...

However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.

To get iPXE, the easy option is to go along with https://netboot.xyz. You will find the `iPXE shell` option here to which to write the boot option from the previous paragraph.

I also added AMD to the iPXE menu for whomever decides to test it. Sway is launched by writing `sway`. Steam should be started with `AMD_VULKAN_ICD="RADV" VK_ICD_FILENAMES="/run/opengl/driver/share/vulkan/icd.d/radeon_icd.x86_64.json" steam` to use the faster RADV driver.

Also setting Coolbits doesn't seem to work either on my end, which means no overclocking support for the Nvidia GPU (if that's something you care about).

NixOS, just like any other OS, can have you walking down the familiar caverns of, "getting the thing to work that this system isn't designed to accommodate well."

But this time is different: you can start over fresh at any time.

This is really the situation where NixOS shines the most. No more, "wondering what you installed where when you were trying to get that over program working the other day." No more, "did I just do the steps in the wrong order?"

It's unbreakable. Your OS is guaranteed to feel like a fresh install. Forever. Because it can't be anything else.

I don't have a laptop like that anymore, but check the NixOS manual and NixOS.wiki, and ask around if you get stuck!

(When I last used it, Bumblebee was the best option and worked well, but these days, native PRIME offloading should also work fine and it's what I would prefer.)

As for Steam, just add

  programs.steam.enable = true;

(If you're accustomed to Flatpak Steam, you can alternatively enable Flatpak and just install Steam that way, like you would on your existing distro.)

- As mentioned by another commenter you will not be able to run random binaries by default. You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS environment for the binary.

- It is significantly more bandwidth- / rebuild-heavy. If an input for a derivation changes it will trigger a rebuild, which means either a redownload from the binary cache or a recompilation.

[0] https://github.com/tazjin/nix-1p

[1] https://nixos.org/guides/nix-pills

[2] https://github.com/thiagokokada/nix-alien

That seems weird to me. I don't have to learn package configuration language in other distributions. I thought that one could just install packages with a package manager.

> You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS shell for the binary.

That's actually fine. I want to put closed source software into a chroot anyway.

NixOS is more like a distro bundled with Ansible, so you can describe your entire system as code.

If you just want to use nix for packages, you can run any distro and install nix the package manager into it. This is a good way to dip your toes in the water. And in that case you can just use the cli commands for installing packages.

I still encourage you to give it a try. You can build different versions of same package and not "install" them. Instead just execute the binary from the built version (I do this where I have a built-but-not-installed version of openssh-8.6 laying around because I have an old service that modern SSH no longer supports).

You can also run `nix-shell -p <custom-package-version>` to get a shell with a specific package available in the path, overtop of whatever might be globally installed.

Who knows, you might even be tempted to dip your toes into the Nix language by writing a custom `shell.nix` to build a shell with some more complex development environment, or to simply automate a complex `nix-shell -p` command.

You can browse some here: https://search.nixos.org/options

For example, to install an OpenSSH server and run it, you'd write:

  services.openssh.enable = true;

  services.openssh.ports = [
    22
    2222
  ];

  environment.systemPackages = [
    pkgs.firefox
    pkgs.jq
  ];

(For NixOS, the Nix you write only starts looking like real code when you want to add new features or some packages to NixOS.)

The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time.

Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given shell, but it works off of a configuration file written in the Nix language that you write. The programs that are available are controlled by environment variables such as PATH and MANPATH.

Nix is a big shift from the usual way of dealing with packages, programs, etc. It isn't really useful until you really make the effort to understand what is going on, learn the Nix language, etc. If you are not interested in "programming" your system, then it probably isn't for you.

That’s not really true and is only a limitation of how PATH works on UNIXes (the first match is used). But you can for example add an aliased name for multiple versions of the same package, or for another meaning of use you can have different executables in the same environment different versions of the same lib (e.g. one bash script references python3, the other python3-at-specific-patch/minor-version/whatever)

That's a bit hand-wavey. More precisely: when you run a command, like `python3`, you can only associate that with one file. If you want multiple Python 3 interpreters, you'll have to use different names (e.g. making symlinks).

Alternatively, you don't need to bother "installing" anything; e.g. I use Nix for projects which use Scala, Maven, Python, NodeJS, etc. yet I don't have any of those installed. Instead, each project includes a `shell.nix` file which specifies the tools it wants. Running `nix-shell` in different folders gives me access to different tools.

Also, with Nix we only need to care about the end result: we can "install" a bunch of different programs, even if they have incompatible dependencies, since we're not "installing" those dependencies. ("Install" just means putting a symlink in some bin/ folder, like /run/current-system/sw/bin on NixOS or $HOME/.nix-profile/bin on non-NixOS)

You could use the command

    nix-env -iA mypackage

But... the interesting part of Nix is that it lets you install packages declaratively, by editing a config (like vim and emacs packages). Besides installing packages, all configuration is done through this config file (or bunch of config files): nix generates all files in /etc for you, again, like vim or emacs, but for the whole OS

That way, you easily transfer your setup to another computer or even keep two machines in sync. And you can add it to version control. And you get a grub menu with all your previous setups (until you uninstall them)

If this doesn't appeal you, you probably won't like to use NixOS

For general usage I didn’t notice it much, like, as an alternative to apt/pacman/etc. Ok, maybe don’t use it from a limited data plan (but isn’t true of every desktop OS?).

But sure, if you patch some lib n layers deep you will have to recompile many things, which is a godsend (in that you can actually do that), but will take a bit of time. But you can usually decrement its impact by really changing what has to be changed and using a “standard” channel for all the rest. With flakes it is especially easy to mix and match multiple nixpkgs repos at different versions.

https://nixos.wiki/wiki/Steam

but it's just a few lines in your config and then it works

hardware.opengl = { extraPackages = with pkgs; [ intel-compute-runtime # OpenCL library intel-media-driver # video encoding/decoding hardware accerlation ]; extraPackages32 = with pkgs.pkgsi686Linux; [ intel-media-driver # video encoding/decoding hardware accerlation ]; };

Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and people will say I'm wrong, but I'm 100% right. Go see yourself, it's bad. Language is called Nix, OS is actually called Nix, package manager is called Nix, just the whole thing seems like it was written in 1 week by a squirrel with 12 hands and a sack of ritalin.

That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it.

Like Docker, but works.

The notion of portability is Docker's bread and butter. With proper version pinning you _might_ get lucky with repeatability too. Most people anticipate repeatability to be part of portability, but it really is a distinct notion.

> it wouldn't be surprising if it does not build at all.

This part is a stronger point, and it's true. When you repeat something and what you get is not just a different version or variation but something with totally different or broken behavior, that seems bigger than an ordinary failure of reproducibility.

Like Ansible but more bdsm.

Linux not making you feel superior anymore? Try Nix!

- NixOS: Full OS that says "what if we did the same for the whole OS"

Nix solves what Docker merely works around.

The secret of Nix is the application of the common wisdom of memory management discipline in modern programming language design to the process of building and distributing software.

The payoff is, as with garbage collection in the original case, and immense leap in safety, productivity, and maintainability for software build and deployment systems.

Concretely, Nix and the ecosystem of tools built upon it and each other mean:

  - configuration management that never drifts
  - upgrades that can always be rolled back in seconds
  - servers that don't accrue cruft
  - software whose bill of materials comes for free
  - an end to version conflicts
  - packages which can always be bundled into a minimal container image in seconds
  - build artifacts which turn out the same no matter where or when you build them
  - software running as-needed, even locally, without having to be installed or manually cleaned up
  - a single, simple language capable of defining your entire stack, from building individual assets to managing cloud infrastructure to deploying service-oriented systems
  - an end to 'works on my machine' bullshit in their development environments *without* the inefficiencies of virtualization— even on macOS
  - user-mode package management for supercomputers and mainframes
  - the ability to boot into yesterday's workstation with two keystrokes at boot time
  - a time machine for running obsolete software which can't build on modern systems
  - a time capsule for software research being conducted today
  - the largest, most up-to-date package collection in the world

Not true. The distro is called `NixOS`. The package manager and it's language is called `Nix`.

I do agree that the learning curve is extremely steep.

Maybe call the package manager something catchy like "pacman" or "update_software_from_repos" :)

Yep; that's a bummer. The manual calls it the "Nix expression language", and some people refer to it as "nixlang" (similar to Gophers saying "golang")

> OS is actually called Nix

Nope, it's always NixOS; 100% of the time. In fact, the naming confusion goes the other way in this case, since the whole project (Nix, NixOS, etc.) lives on the domain nixos.org, and the GitHub account NixOS!

> package manager is called Nix

The commands are called Nix; but I personally find the idea of "package manager" just complicates things. Nix is more of a build tool, like Make; internally, it uses "derivation" to refer to anything from a text file to an entire OS. An application, like a music player, may involve many derivations (e.g. a derivation for its source code, a couple of derivations containing patches, a derivation for an interpreter with the required libraries, etc.); indeed the "actual program" in our $PATH is often just a script which invokes some other binary defined via a different derivation ;)

more commonly just nix language or you know it out of context

No, not really. They are not consistent for every part and not every package is up to date with everything but if you get the gist you can easily guess things. If things are really weird we can always rename them.

OK, I’ll bite.

Nix is a build system. NixOS is a Linux source distro built on top of it (cf Gentoo, gittup, BSDs). Except you won’t need to build anything.

Nix builds (should) execute in an isolated environment, thus the build artifacts are (ideally) bit-for-bit identical no matter where they were built. This means you can have a shared artifact cache (cf Bazel). Now for the clever part: in a distro, such an artifact cache is the same thing as a binary repo. Thus you are in fact using a (somewhat disk-space-hungry) binary distro until you want to patch something, at which point it transparently reverts to a source one (up to and including rebootstrapping the system compiler if you wish).

That’s the gist, but there are some more goodies on top of that.

First, none of this really requires a NixOS-only world. Thus, as an intermediate step, there’s Nixpkgs: a ports-like collection of packages that runs on conventional Linux and macOS systems (*BSD support is possible but has bitrotted). To maintain isolation in such an environment, all binaries it builds refer to dynamic libraries by build hash rather than load whatever’s present, and are usually wrapped to ensure other parts of the ambient environment don’t leak through. But once you’ve done that, more or less the only thing remaining to have a “gimme a shell with P, Q, and R in it” command is to point PATH to the right build directories. Hermetic build environments (cf virtualenv) for any supported language, user-scoped rootless package installs, good stuff.

Second, what NixOS adds on top of that (apart from a kernel) is a system for building system configurations out of Nix-language descriptions. It’s a bit clunky, like all config generators, but once you commit to maintaining all of your /etc that way a full rollback of (the NixOS-managed part of) the system is a single GRUB selection away. There are also things like “run a QEMU with this system config inside”, “build a Docker-compatible image with this system config inside”, etc.

Finally, as to how this works, Nix the build language is really simple, it’s JSON + (pure) functions + laziness + a build recipe type. Usually you just generate some shell or Perl or whatever scripts and stuff them into the recipe, so for Nixpkgs it’s honestly a bit overkill, but NixOS uses it to define a rather clever system with options that (if defined) set values of other options that ... all the way to the options that define the raw content of each file in /etc, with rules for merging option values if you wish (cf CUE, Dhall). If your mental model of your system is more abstract than the configuration of each individual service, it’s not hard to write it down as Nix code that defines some new NixOS options, then define your system—or several—in terms of those options.

Bad parts:

Apart from the build system as such, the CLI includes support for a lot of the idioms I mentioned above, so the separation may not look that clean. (This is not helped by the fact that a complete CLI overhaul is in progress, with old commands like nix-build and nix-env being superceded by a single new one, nix. The nixos-* ones are separate for now.)

The language is perhaps a bit too minimal and lacks a standard library, so Nixpkgs ends up containing that as well, without much in the way of documentation. You will have to refer to the source there. The library is mostly simple list and mapping utilities, so it’s not difficult, but figuring out whether the thing you want is in it or not can be frustrating, and the API won’t win any beauty contests.

It can be slow.

Now that I’ve written this, I see I can’t really phrase the benefits such that the result is neither a shallow-sounding platitude nor a laundry list of features, when the reality is a laundry list of features that mostly fall out of a couple of overarching ideas. And it’s not like each of those features haven’t been done before, but this particular implementation comes out remarkably simple and sane given the length of the list.

Perfectly reproducible OS with easy rollbacks. OS never gets crufty, no need to reinstall every release version or two. Single configuration language for all apps and system components. Composable and shareble config modules at any level of abstraction, e.g. you can piece together many git repos to custom roll your OS. Isolated dependencies for every package, meaning no dependency hell (similar to docker). You can have multiple versions of everything running live. Ability to run temporary environments using the same config language.

Current OSes are like VAX or TRS-80 in comparison. Nix-likes are the future.

Nix the set of tools gives you convenient command line tools that can: evaluate Nix language expressions, build recipes, analyze build-time or run-time dependency graphs of a recipe, give you ephemeral shells with the packages you want in scope but not installed "globally", package management tools to install packages globally, and recipe diffing tools so you can see how recipes changed.

Nix the package manager is a convenient, gigantic, community effort to explicitly describe how to (reproducibly) build almost all of the OSS software that users need and it comes with a substitution cache so that most recipe build products are easily substituted when installing, so you don't have to build. Even if you don't use Nix, nixpkgs is still impressive because you have the most explicit documentation for how to build a piece of software from source and all of its dependencies than anywhere else on the internet, it usually rivals project author's in its specificity, explicitness, and clarity.

NixOS the Linux distribution combines all of this together with a convenient configuration module system and generally good defaults to give you an operating system that is declaratively specified from your etc hosts file all the way down to the recipe for building the kernel, a rich and granular dependency graph, reproducible OS configuration builds, and diffs between closures.

My biggest gripe with Nix is the lack of static types. This was the originator's biggest mistake that Nix will be living with for a very long time to come. Static types would have helped bring the learning curve down IMHO and made it easier to document and less frustrating to debug.

That being said, the overall properties of Nix, nixpkgs, and NixOS far outweigh the pain points in my six years of production experience with it and for what we care about: auditability, reproducibility, explicitness, efficiency, and integrity.

so basically, when you install something with nix, it's specified all the way down to the bare metal (except for perhaps the kernel)

Nix and Nixpkgs are messy, evolved things with a lot of history and quirks. They're also very powerful tools that can change the way you even approach computers. If you stick with them long enough, they may inspire you to extend and leverage them in creative ways... continuing the process of messy evolution. :)

Its the first distro I've used in 20 years that doesn't feel like a stiff wind could cause the whole thing to collapse and catch fire in an unrecoverable way, while still allowing me to run any software I want instead of just what is in some limited curated repo. And unlike Nix, I didn't need to learn a new language to use it.

  toolbox create new_dev_env_or_whatever
  toolbox enter new_dev_env_or_whatever
  dnf install all_the_things

I have my issues with both Flatpak and Toolbox as far as how they're put together and work, but overall I find it to be a vast improvement on the status-quo way of doing things. YMMV, of course.

The limitations are:

1) Each invocation of the package manager (install/upgrade/uninstall, the usual stuff) results in a new OS 'commit' and requires a reboot to switch to it.

This is the entire point of the distro (random .rpm broke your system? just rollback), and is why Silverblue users generally only use DNF packages for low-level tools and run regular applications as flatpaks, appimages, or podmans.

2) Occasionally you'll run into a package that wants to write to a folder that Silverblue made read-only and version-controlled, and breaks. In that case your only options are to run the package inside a toolbox (a special Podman container that comes with Silverblue for these scenarios), or patching the package.

https://gitlab.com/ahayzen/silverblue-nix

NixOS people will prefer NixOS, but Silverblue seems like a nice complement to Nix if you need an FHS base system and want to retain some Nix-ish features like rollbacks and atomic upgrades.

I think is easier to see this with what is their main strength: A declarative/reproducible OS setup. Is AMAZING for server deployment (like what you put in a docker file but that not mutate after it).

But I don't think will be so nice for day to day use. That is where a mutation OS is easier.

Fwiw the best summary of "should I use NixOS" is https://news.ycombinator.com/item?id=33679621

Also since things are declarative, that means things like e.g. updating bash aliases has additional friction vs the traditional way of editing the file directly.

Additional friction (not much imo), but you will actually be able to move that bash plugin that does that thing you didn’t even realize were not available in a vanilla shell.

If Nix is CVS or even Subversion, I'm hoping for Git.

Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.

Tweaking a few NixOS modules it replacing a package is easy, but neither the Nix codebase nor Nixpkgs is characterized by perfect modularity or uniform layering.

https://news.ycombinator.com/item?id=33679621

Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring, and if we want converts we have to manage expectations properly!

> Look ma, no /usr/lib

and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve.

I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glorious Nix symlink forest under /nix/var/nix/profiles for the first time. :)

Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere). A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.

So I see that departure as a pretty huge one, that will affect someone learning Linux on NixOS for many years, as they need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs. Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.

As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".

(Also, that sounds like a great approach to explaining NixOS!)

1: https://search.nixos.org/options

That's true. Once you have found your footing with the Nix language and figured out some basics of how to navigate the NixOS modules in Nixpkgs, the latter becomes a rich source of examples on how to configure everything on a modern Unix-like system, from mounting a btrfs subvolume in your initrd via systemd/dracut integrations to setting up PipeWire to emulate PulseAudio. But while NixOS can still teach you a lot about how a working Unix-like system is put together and how its stack is configured, the most useful point of entry for such exploration is very different from what you might be used to on other distros.

You can also learn by exploring the Nix profiles and the Nix store of a working system, much like you would walk through the FHS on a ‘normal’ Linux system— after all, all of your system-wide config files can eventually be hunted down in the Nix store. If you run `ps` on a NixOS system, you'll see explicit references to RC files for lots of programs that are wrapped to point to specific config files, and for running persistent services. But it's probably not as useful as going directly to the Nixpkgs source, once you've learned to read a little Nix.

> A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.

That's an interesting thought. I didn't come to NixOS as a beginner in the Linux world; NixOS was not my first distro. (I think that's true for most of us in the community.) With NixOS, neither the paradigm nor the community really encourages the kind of monkey patching, that kind of learning by brute intervention on a running system. Even so, I think it would be possible (if perhaps a bit perverse) to write a textbook or a course like ‘Learning Unix with NixOS’. I think using a read-write store as a teaching tool before showing the reader how to use Nix itself to wrap programs that live in the Nix store would be fine.

> [NixOS users] need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs.

Right, NixOS definitely changes the sort of ‘order of recourse’ users will want to make when configuring a piece of software. I'd say it looks something like this:

  1. Is there an existing NixOS module for configuring the software I want to use?
  2. If so, does the module have any high-level options that look so convenient that I should try them right away?
  3. Is there any additional, special configuration that I need to do?

A NixOS fanatic might frame this

> Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.

in an alternative way:

> Whereas Debian only helps you to install the package, NixOS will also help you perform common configuration tasks. It's only when you need to perform peculiar configuration tasks for your specific needs that you really have to dive into the upstream documentation.

At the same time, knowledge of some upstream component (e.g., Xorg, connman, OpenSSH, etc.) always remains applicable with NixOS, if you want it to be. Everything that's configurable under /etc/something/or/other on Debian remains configurable on NixOS in a straightforward way, either by specifying key-value type config in the Nix language or (in the worst case) by embedding a config file snippet in your NixOS configuration.

> As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".

I think this is well put, and it's what I was getting at above with the idea that thinking about the particular structure of some program's RC file is a last resort in NixOS. But it's not entirely one-sided! The NixOS module system serves not just to shield users from that complexity when they don't need to confront it, but also to teach them about it when they do. For me, that's one of the reasons that learning the Nix language and exploring the Nixpkgs codebase is so worth it.

Any recommendations on how to best set up pre boot encryption and opt in state these days?

Like the other reply suggests, I'm using ZFS and it's built-in encryption.

Anyway trying my hand on Kivy. Work for once for iOS and android undder macOS. Then never so far. Trying Gm even of macOS. No.

May be start again with this and try to install Kivy again

No. Docker is a way to execute processes (e.g. servers).

Nix is a way to define the contents of files (e.g. an OS filesystem).

[1] https://francis.begyn.be/blog/nixos-home-router

Moved to NixOS almost 5 years ago now and haven’t looked back, my router config is in Git and I’m able to make changes with confidence.

Best part is making a change/installing an update and being able to rollback if I mess something up. I also use Nixus to push new configs which has a nifty feature where it will autorollback if you e.g make a config change that locks you out of SSH.

I also moved from ESXI to NixOS for a virtualisation host more recently and that has been great as these machines are inherently long lived so you can’t apply the “cattle not pets” mindset here, but I feel like I can make changes and install updates with confidence. It also helped when I migrated to a Threadripper build where there were some strange quirks which needed Linux kernel patches, it’s nice being able to do this declaratively and to store everything in a versioned Git repo.

A couple years ago I was searching for a good way to declaratively manage them, and the best I came up with was libvirt + terraform + nixos-generators for images. It feels like you should just be able to set them up as systemd units, but I couldn’t figure it out.

microvm has caught my eye recently but I haven’t played with it yet: https://github.com/astro/microvm.nix

However, none of my VMs are always-on, so I don’t have to deal with restarts on config change. That said, when libvirt isn’t managing the lifecycle of the VMs as much, writing a systemd unit should be quite a bit easier.

MicroVM looks awesome though, thanks for the pointer!

I've been using OPNSense[0] as my router for the past several months. So far, I am quite happy with it, but I've also thought that NixOS would be the next step.

My OPNSense router has 30+ VLANs and many layered firewall rules (my take on "zEr0 tRuSt") and so the task of converting it all to NixOS seems a little daunting.

I appreciate the utility of OPNSense's web GUI when configuring and troubleshooting my router config. It would be awesome if something like that could be integrated with NixOS. Additionally, something like nsh[1] to provide a traditional router/switch style CLI would be a dream come true.

[0] https://opnsense.org/

[1] https://www.nmedia.net/nsh/

I haven’t done much with vlans yet so I can’t comment on that.

NixOS still does everything I need it too, but the parent comment sounded like they had a bit more complex of a setup.

{ pkgs, lib, ... }:{

  networking = {
    useNetworkd = true;
    useDHCP = false;
    enableIPv6 = true;
  };

   networking.wireguard.interfaces = {
     wireguard = {
       ips = [ "172.20.60.1/24" ];
       listenPort = 61891;
       privateKeyFile = "/etc/nixos/secrets/wireguard-privateKey";
       peers = [
         {
           publicKey = "897mRPejuv9yVnmTvcUL7ckQkIiM0wnSgHmgR15Evyw=";
           allowedIPs = [ "172.20.60.10/32" ];
           presharedKeyFile = "/etc/nixos/secrets/wireguard-presharedkey";
         }

  systemd.network.networks = {
    "10-eno1" = {
      matchConfig.Name = "eno1";
      networkConfig.LinkLocalAddressing = "no";
      networkConfig.DHCP = "no";
      extraConfig = ''
        VLAN=wan
        VLAN=vlan99
        VLAN=vlan30
        VLAN=vlan20
        VLAN=vlan1
        VLAN=podnet
        LLDP=no
        EmitLLDP=no
        IPv6AcceptRA=no
        IPv6SendRA=no
      '';
    };
    "11-vlan1" = {
      matchConfig.Name = "vlan1";
      linkConfig.RequiredForOnline = false;
      networkConfig.DHCP = "no";
      networkConfig.Address = "192.168.1.1/24";
      networkConfig.Domains = "tanso.net";
      networkConfig.ConfigureWithoutCarrier = "yes";
    };
    "11-podnet" = {
      matchConfig.Name = "podnet";
      linkConfig.RequiredForOnline = false;
      networkConfig.DHCP = "no";
      networkConfig.Address = "172.20.2.1/24";
      networkConfig.Domains = "tanso.net";
      networkConfig.ConfigureWithoutCarrier = "yes";
    };
    "11-vlan20" = {
      matchConfig.Name = "vlan20";
      networkConfig.DHCP = "no";
      networkConfig.Address = "172.20.20.1/24";
      networkConfig.Domains = "tanso.net";
      networkConfig.ConfigureWithoutCarrier = "yes";
      extraConfig = ''
      IPv6SendRA=yes
      DHCPv6PrefixDelegation=yes
      '';
    };

  systemd.network.netdevs = {
    "11-vlan1" = {
      netdevConfig = { Name = "vlan1"; Kind = "vlan"; };
      vlanConfig.Id = 1;
    };
    "11-podnet" = {
      netdevConfig = { Name = "podnet"; Kind = "vlan"; };
      vlanConfig.Id = 2;
    };
    "11-vlan20" = {
      netdevConfig = { Name = "vlan20"; Kind = "vlan"; };
      vlanConfig.Id = 20;
    };
    "11-vlan30" = {
      netdevConfig = { Name = "vlan30"; Kind = "vlan"; };
      vlanConfig.Id = 30;
    };

The options under systemd.network almost map 1:1 to systemd-networkd ones.

As other commentators have said, switching to systemd networkd has allowed for more advanced network configurations than I ever managed with pfSense. IPv6 works pretty much out of the box with my ISP which uses DHCP prefix delegation, I can assign /64's to different VLAN networks, and more recently I set up network prefix translation (I think that's what it's called) for my lab kubernetes cluster so each pod gets a unique IPv6 address in the RFC 4193 range which maps to my actual ISP provided IPv6 prefix, so if I change ISP the IPs in the cluster would remain the same. Being able to expose Kubernetes services directly to the internet with unique IPv6 addresses is pretty nice :)

In terms of documentation: the lines between nix-the-language, nix-the-tool, and nixos-the-system are often too blurry. Familiarity with one of the three is often assumed or implied.

Everyone seems to be using Flakes and/or home-manager; the official docs and tools all try to scare you away by labeling it unstable/experimental (if ever mentioning them at all), yet it seems difficult to find third-party resources that don't refer you to Flakes at some point.

The "getting started" manual is very good at getting you to a basic and very usable desktop system, but once you want to go anywhere beyond that, the difficulty (and complexity) immediately ramps up to crazy levels.

The references usually feel like they're complete, but I found it extremely difficult to find a simple answer to quite basic questions of the "how to do X" kind; e.g. I want to supply the same list of packages to python310.withPackages and python311.withPackages, to have both Python versions available system-wide (so I can trivially fire up an IPython shell and hack away at a simple problem). I solved this on other systems e.g. by using stupid text substitutions in a shell script, or calling "python3.xx -m pip -r requirements.txt", but it's still unclear to me how to do it with Nix - do I need to learn more of the language, or more about nixpkgs, do I stick with copy-pasting the package list, etc.

I wish the documentation was even 10% as good as OpenBSD's, but many commands don't even have basic man pages. It's definitely the most intriguing OS I've tried in many years, with a lot of promise for a return on the investment, it's just that it feels incredibly steep to get anywhere when you're just getting started.

> python310.withPackages and python311.withPackages

I think that should be solvable by supplying them the same function.

env = ps: with ps; [ numpy toolz ] python39.withPackages(env) python310.withPackages(env)

Major problems: installing niche proprietary software that you may have to package yourself, and fighting Nix for languages with package manager, e.g. Python, which frequently uses packages not in nixpkgs.

As for last problem.. Yeah. It is a problem. x.x

The nix language itself is pretty straightforward and if you know haskell your should feel straight at home.

You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.

Yes, but that still doesn't solve this:

> Major problems: installing niche proprietary software that you may have to package yourself

If some software _isn't_ packaged, it's a pain in the butt to get it running on NixOS. Either you have to create Nix derivations, which have a pretty steep learning curve, or you have to do some hackery patchelf business, which also isn't easy.

At least, as of 2018, when I last tried. Things could be better now.

You almost never want to invoke patchelf by itself but use some wrapper like autoPatchelfHook, FHS, nix-ld, nix-autobahn, etc.

Since 2018 a lot quite a lot happened. Give it another chance.

The unfortunate part is that creating a Nix derivation is no more approachable than the patchelf hackery was in the first place.

So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix.

I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach.

And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it.

Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition.

Have 10 different projects all with different dependencies and version requirements that would normally collide with each other? Trivial, each project has its own default.nix file and Nix can drop you right into that environment while you're working on those projects.

NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!

If there's some easier way, I'm eager to hear about it.

1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this.

2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful.

3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual?

4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix.

5. Some build tools without wrapper (iirc mold, ldd) will cause loader error.

But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.

3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks

5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.

So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)

And if you don't have any FP background you're just.. out of luck. /s

And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others.

Making packages for nix is way easier than making debs or rpms in my experience.

It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.

I don't think I agree here. There are plenty of examples of how to package/update/fix anything custom you desire. The learning curve is there, definitely, but this is not major - I do this several times for my own OS and software that utilizes Nix.

Am I just missing something?

Because it actually fulfills the original promise of Nix: Forever-reproducible builds.

Anyone who's ever dealt with a lockfile across any stack that supports that idea in dependency definition, knows how this works and what it's good for.

Using Nix without Flakes is going through 99% of the trouble for concrete, reproducible builds but then dropping the last 1%.

I had my non-Flake builds break like it was a mutable operating system. I just don't get why Flakes aren't the standard.

Flakes provide a consistent entry-point to a set of Nix files (rather than just a hoping that Nix files conform to some convention).

Nix flakes also let you get by with even less worry about the system state: e.g. you don't need to add channels or put your code in your user's overlays directory. You can just use the path/URI to a flake, and nix will take care of downloading all the inputs appropriately.

They're apparently better than using channels, and env vars like NIX_PATH; but I don't bother with those either.

I just use `fetchgit`/`fetchFromGitHub` with specific commit IDs, and that seems mostly reproducible. I've got Nix repos dating back about 8 years, and the only reason some commits can't be reproduced is due to link rot (mostly GitHub repos being deleted in protest at Microsoft purchasing it). I don't think flakes solve that? (Seems more suitable for something like IPFS)

e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's:

  nix run github:NixOS/nix/master

A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort.

Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.

From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-... ):

> If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.

With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs.

I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).

They're still less convenient for me than flakes because they don't have great integration with Nix's profile managers (nix-env, nixos-rebuild, home-manager). But they do have fewer quirks in some ways, since they don't try to enforce pure evaluation like the flakes implementation does. They don't worry about whether the pinning happens inside a git repo or whatever.

(I think some orgs that use Nix in production are still using Niv, and haven't touched flakes. Niv is certainly still maintained.)

I tend to have a single git repo with my system config, which uses import-from-derivation to grab a bunch of other stuff; and defines a single "package" that's a big `buildEnv` of all the programs I want. That seems to work fine across NixOS (on an old i686 Thinkpad), an old Ubuntu desktop, macOS (a couple of work laptops; old one used nix-darwin, new one just uses nix-env), and I'm currently trying it on nixos-mobile (on my Pinephone).

The other nice thing they do (that I use) is provide a nice way to define entry points (either ones accessed by a specific nix flake command, or just Nix flake run). Nix flake check and nix flake fmt are the ones I use.

But mostly it’s not anything new, just a (eventually, right now needing to be manually turned on is annoying) nicer UX on top of things that were already possible.

Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583

I maintain multiple pet servers. When I used Ubuntu, doing release upgrades cost me ~6 hours per server per upgrade every 2 years. Most of that time went into merging updated upstream configuration files with my changed configuration files, often for silly stuff like upstream changing tabs to spaces in the config file syntax. With the Debian-style upgrader, you also have to wait 5 minutes until you're prompted for the next config file to merge, while other packages are "configuring" with `dpkg`. So you cannot do them all in a batch, but have to stare at the screen throughout the procedure, attending every 5 minutes.

So with multiple servers that was multiple days of upgrades per year.

With NixOS, these days are is reduced to minutes.

For example, on one of my servers I upgraded just now:

    18:07    -- starting NixOS 21.05 -> 21.11 upgrade command
    18:10    -- download finished
    18:10:15 -- rebooted into new running system

    * webserver
    * mailserver (with web UI, spamfilter, etc)
    * nameserver (with dynamic DNS updates)
    * VPN server
    * mumble voicechat server
    * XMPP server
    * Matrix server with signal bridge
    * vaultwarden server
    * some custom web services

For the server above, the config file is 800 lines long, of which 200 are comments.

So NixOS is saving me multiple days per year in sysadmin tasks, which is pretty good!

A main reason people use containerisation is to work around the problem that different versions of libraries and binaries cannot coexist in classical Linux distributions. This problem does not exist in NixOS.

The services are declared as NixOS modules, which manifest as plain systemd services on the server.

Systemd has its own set of options for resource/security isolation, and some NixOS modules use them where possible, for example: https://github.com/NixOS/nixpkgs/blob/8d559672bedd54034b711d...

virtualisation.docker.enable = true;

The best comprehensive guide is the manual:

https://nixos.org/manual/nixos/stable/

I think video resources are maybe under-emphasized in talk about Nix on HN, and they're important for people who prefer that modality, so I've compiled a list of videos on Nix that I have watched and feel might be helpful for learning it.

There is no comprehensive YouTube series that I can recommend, but you can find really good introductory and overview videos in the form of past conference lectures in the NixCon and NixOS channels on YouTube.

NixCon: https://youtube.com/@NixCon

NixOS: https://youtube.com/@NixOS-Foundation

Here are some playlists and direct references to educational material on Nix and NixOS that I've actually watched. Taken together, they will at least outline all of the normal stuff you might want to do on NixOS, from configuring your system to writing packages to (if you want) leveraging flakes to running your own binary cache.

Reading Nix Expressions (Zimbatm, NixCon 2019) — https://youtu.be/61MuMY9XFNo

Nix: Why and How It Works (Graham Christensen, NixCon 2019) — https://youtu.be/lxtHH838yko

Fearless Tinkering: How NixOS Works (Graham Christensen, NixCon 2019) — https://youtu.be/DK_iLg2Ekwk

Learning the Nix Store Layer (John Ericson, NixCon 2022) — https://youtu.be/utQf4VH7QMw

Overrides: In and Out (Graham Christensen, NixCon 2019) — https://youtu.be/6VepnulTfu8

Nix Flakes in Production: What, Why, and How (Alexander Bantyev, NixCon 2020) — https://www.youtube.com/watch?v=o1Y7rWrPEO8

Nixpkgs Overlays: A place for all excluded packages (Nicolas B. Pierron, NixCon 2017) — https://www.youtube.com/watch?v=W85mF1zWA2o

The Architecture and History of Nixpkgs (Jon Ringer, Summer of Nix 2022) — https://www.youtube.com/watch?v=TKgHazs3AMw

Hydra, Nix's CI (Thomas Bereknyei a.k.a. tomberek, Summer of Nix 2022) — https://www.youtube.com/watch?v=AvOqaeK_NaE

There's also some really good content outside of the official NixOS YouTube channels! See below.

Informal intro to the Nix language, derivations, and Nixpkgs (Silvan Mosberger, from a Nix onboarding for another Tweag employee, recorded 2022): https://www.youtube.com/watch?v=9DJtHIpdp0Y

Burke Libby's Nixology series — https://youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgM...

NixOS 101: Introduction to a Different Type of Linux Distro (Tweag onboarding document, 2022) — https://www.youtube.com/watch?v=pfY9Hc_zChs

Introduction to NixOS (Charles Strahan, NYLUG Presents 2017) — https://www.youtube.com/watch?v=VivXSoovUFI

Nix Flakes 101 (Jörg Thalheim a.k.a. Mic92, rC3 2020) — https://www.youtube.com/watch?v=QXUlhnhuRX4

Why NixOS: An Introduction (Ingolf Wagner, rC3 2020) — https://www.youtube.com/watch?v=0eTgQaNiRF0

Sane System Management with NixOS (Tim Steinbach, LambdaConf 2020) — https://www.youtube.com/watch?v=_LDzO5_d1a0

Nix for Functional Systems (Brian McKenna, YOW! LambdaJam 2017) — https://www.youtube.com/watch?v=mIxtBVKo7JE

There are others out there which I didn't list because I've never watched them, and there are probably some older ones I did enjoy which I was unable to dig up. It's probably really only worth watching one or two of the generic, overview, intro-type videos. But there are plenty of them, so feel free to decide within a few seconds whether one clicks with you, and choose it based on that. FWIW, I think Charles Strahan's NixOS intro video is my favorite of that type.

If you really want a comprehensive lecture playlist, the curriculum I recommend is:

  1. Charles Strahan's intro to NixOS
  2. Burke Libbey's Nixology series (because his videos are relatively short)
  3. The listed NixCon and Summer of Nix videos
  4. Mic92's Flakes 101

NixCon videos not listed here can be useful for pointing you to interesting, new or important ancillary and third-party projects in the ecosystem. :)

> I am not a smart man. The difference between success and failure to me, is razor thin. I am impatient. I am hubristic. I am easily bored. I have it in my to be tenacious, but it has to be drawn out by reward at the end. And NixOS ticks all these boxes for me, in a way that other systems really don't.

https://www.youtube.com/watch?v=17-TRCpDizA

I think it's worth listening to as it is, but below, I've tried to condense and summarize the parts of that 30-minute video most relevant to that point, for folks to whom the pacing of a relaxed, rambly, personal monologue does not appeal.

> I'll give you an example. All my systems have the same set of installed programs now. Now that seems real simple. Y'know, they all say, let's say, `screen`, or `tmux, or they all have Ardour, or they all have the same Emacs configuration. I know that sounds basic, but that has never happened to me before [laughs]! I'm just too easily bored [smiles] to invent such a thing that would make it possible for me to do that. [...] System configuration, instead of being this laundry list of chores to be done, becomes a programming exercise. I'm comfortable with programming exercises. I do not like chores.

> [...]

> The integration between Nix the language, Nix the package manager, and NixOS the operating system means that I'm not required to invent very much. [...] Everything I just described to you, I could have done 15 years ago, with systems like Puppet [or] Ansible[.] [...] However, while using those systems, I am required to make choices about how things are done. And those choices really have some stop[ping] energy to them. Some of the choices are so low-level that they're uninteresting, and it becomes rather boring rather quickly to do [something like] Puppet or Ansible. ‘Where is this `authorized_keys` file supposed to go?’ I don't really care! [laughs] I just want [...] to be able to log into that system.

> On top of all that, where [with NixOS, it feels like] I'm just motoring along [unimpeded]— I'm creating a configuration very quickly that rewards [rather than drains] me— at the end of it, I can share that configuration with someone else in a meaningful, even executable, way. And the way to execute it is well-understood. There's no trickery [hidden in the deployment environment]. This is also [supposedly] the same with Puppet and Ansible, but somehow, no one seems to do it! You don't see people sharing Ansible configurations. This culture of sharing configuration, of sharing declarative statements about builds, is something that is [...] in quantity and quality, unique to NixOS.

> I recently heard from a friend [...] who somehow saw my videos [on NixOS]. [...] We never spoke about NixOS before I heard from him [about this]. But he took the configuration that I'd put up on GitHub, [...] made a couple of changes to it, and he got one system up and running. And he said ‘Wow, that was easy!’. This guy has been doing [Unix and Linux systems administration] for 25 years, and I can't imagine that he's ever done such a thing before. [I can't imagine that he has ever] just walked up to some repository, and [simultaneously] had [...] the inclination, the confidence, and the ability to repeat a build [of it] on his own system. [...] He actually said to me at some point, ‘What have you done to me?’ [laughs]. Of course, I didn't do anything. He's well on his way to converting all of his other systems to NixOS.

> [...]

> I think [Nix's features] sort of feed into each other, as a [...] virtuous cycle. Like I said: I am not a smart man, I am not a patient man. I can be tenacious, but it really takes me feeling like I'm gonna get something at the end. [...] [W]ith Nix, I don't feel like I'm wasting my time, I find myself— surprisingly!— getting to the bottom of issues that I could have gotten to the bottom of on Ubuntu, or Manjaro, or Fedora, or whatever else I was using, [but never did]. I could have fixed them there, but man, the reward for doing so was just minimal.

> [...]

> [That's because] first of all, if you're not running a configuration management system, and you have to do it manually on every system... that is really boring to have to do. So the answer is to run a configuration management system. But the configuration management tools that are available for these systems are [...] just me typing, except automated. [...] There are sort of [declarations], but they definitely have an order. And you have to know the order, you have to control the order. In the NixOS stuff, I'm not concerned about order. [...] Nix uses `bash`, under the hood, so of course I'm [actually] running bash­— yeah, sure. But I'm not [thinking about it] very often.

> People have anticipated the kinds of things I wanna do in [the] Nix [world;] I just reuse whatever they did. It is [admittedly] a game of inches here. I often found myself in a place, with my other systems, where all of them were configured completely differently. I just didn't bother with configuration management stuff. It's not like I haven't used configuration management tools. I use them all the time. [I use them] at work and stuff, but for my own systems, it just seemed like ‘ugh’. It was like going to work! [...] ‘Ok, now I'm back at work, and I have to name these steps.’ It's dull. It's boring.

> [But] now that I have Nix[OS], I'm getting to the bottoms of these stupid issues, like [...] fixing my computer's sleep. Even though I would have had to do exactly the same thing on Ubuntu or Manjaro or Fedora, or any of that stuff— it's the same system— but I actually do it now. Because I'm like ‘Okay, fine. I can write this down once [and for all].’ NixOS has nudged me over the edge of feeling like I'm not wasting my time [...] and that makes me tend to get to the bottoms of issues. Success [now] more often seems possible than impossible. Before, it just seemed impossible, like

> > I am never gonna get this under control. I am just gonna live with chaos.

> [laughs] Everyone has chaos. But in this game of inches, NixOS has just pushed me over the edge that little bit, to where I have things working that I've never had working before. Some concrete examples:

> - I can bring up a new system with the vast majority of configuration that I actually use in 20 minutes. [...] (20 minutes would be a long time, actually. I would have to make a couple mistakes.)

> - [Due to random differences in sleep behavior, mDNS configuration, and God knows what, before] it was always a crapshoot when I'd type `ssh some-host-name` whether I'd actually get in. [...] Now that all of these systems share the same configuration, that hasn't happened to me.

> - I can print from any system. I know it sound stupid. But yes! I don't print often, but when I wanna print, I just wanna print. That was never possible in my old configurations. I'd always have to [fuck] around with printing.

> - I can shut the lid on any of my laptops that are connected to external monitors... and the won't go to sleep. I know, I know— it seems stupid, but it's true! I figured it out. [Thanks to NixOS], I put enough time into that to fix it.

> - I can shut the lid on laptops not connected to external monitors, and they do go to sleep. They go to sleep! They don't just sit there [...] [shining] the monitor light on the keyboard for two hours, running down my battery. [...] It's because I was rewarded [along the way] when I put the time in.

> - I can carry around [...] an external ZFS-formatted drive, and I can plug it into any of these systems and mount it. It can even be encrypted!

> - Once I log in, I can send and receive Keybase messages on any of these [5] systems.

> - I can use my stupid Roland looper on any of these systems. [NixOS encouraged me to] put the time in to add the kernel patch that it requires.

> - I can use an old build of a package— built years ago— to solve dependency bitrot. The current version of a package I use will not build. But I can transport myself back in time, just for that one.

> Another thing I noticed while I was asking questions in various support channels for NixOS is that it somehow also happens to have a really excellent community. I haven't seen this kind of community in many other places. I saw it (way back in the day) with Python. And before then, [laughs] I think the only other place I've seen it was on bulletin board systems. There's unreal politeness, and humility, and thoughtfulness, and thoroughness on all of the support channels I can think of— Discourse, Matrix, IRC, GitHub. [...] There's no ‘RTFM’, there's nobody flexing there. [...] It is the default [on the Internet] to see people flexing and being assholes in support [...] but there's none of that in the NixOS community. [...] It is astounding to me. How did it happen? [In the NixOS community], everybody is smarter than I am. Everyone. I love that!

> [...]

> Once you give [NixOS] a fair shake, you will not go back to something else. [...] The idea that you would look at NixOS, use it for a month, and then be like ‘eh, idk, I'll go back to Fedora’... I don't see that happening to many people. My mind would be blown by that happening.

Creating a vanilla flake.nix for each project to use with nix shell and direnv doesn't seem like a practical approach considering each language has very different requirements and there doesn't seem to be a go to repository of flake templates available anywhere.