I had to log in just so I could upvote and thank you for doing these! My biggest issue with nix on MacOS (besides not grokking the DSL even after a couple years) is that there are a decent handful of packages that dont support Darwin. How do you handle those?
Some of them actually do support darwin and we have a function in our company overlay:
withDarwinEnabled = drv:
drv.overrideAttrs (oldAttrs: {
meta = with super.stdenv.lib.platforms; {
platforms = darwin ++ oldAttrs.meta.platforms;
};
});
but really, we've only run into a couple of things we've cared about that are Linux-only, and just PR'd fixes upstream and duplicated them to our overlay temporarily.
That's awesome. Just finished the video on home manager which seems very useful.
Your videos being directed at co-workers actually serves to highlight the usefulness of this tool.
"Oh, you're missing dependency x, y and z? Here, just copy and paste this nix command to get my Nix environment."
Then you can immediately continue discussing more productive things.
I'm curious about generations. If you roll back to a previous generation and then continue to modify that, will the generation be overwritten? If not, is there a way to track only the history of generations that contribute a change to their current generation?
Also, I saw you run NixOS in a droplet. Do you have any experience running it locally as a desktop environment? I'm curious how mature it is as a full blown Linux Desktop.
Generations are linear, so if you are on 6, roll back to 3, and make a new change (I'm 90% sure) it will create 7.
I've used NixOS a liiiiitle bit on a laptop but not enough to really get into it. We're toying with the idea of exploring supporting NixOS as a primary local development environment (and a host for cloud-based development environments) but there's lot of work to do to make that work well.
Thanks for making those videos! These are the kinds of videos, I think, the newcomers need to see to get value out of Nix.
Can you please share what screencasting software/setup you're using? It seems pretty effortless on your part to get your picture-in-picture move around.
It’s all about using Nix on macOS for now, but a vast majority of the topics apply on Linux as well. And yes, very very little specific coverage of NixOS.
This is a fun read. Curious how this works for large systems:
> This shell instance is special because it only contains sufficient information just to make GNU Hello, available. We can even inspect the value of $PATH, here:
> (list of 20 or so paths to binaries)
Do binary path lookups slow to a crawl when you’ve got 100s or 1000s of separate directory paths to look through? IIUC, there’s a separate directory added to PATH for each binary right? Which presumably would be a disk I/O to read the file list for PATH matching for each command.
Good question, you can of course test this yourself with `time`.
In the case of Bash, non-built-in commands are stored in a lookup table, exposed via the hash built-in (`help hash`). So, there should only be a one-time performance hit per shell instance.
Generally speaking, stat'ing hundreds of directories is surprisingly quick, most binaries do it all the time, when loading libraries for example. You can `strace` to see the numerous file tree crawls.
It usually doesnt get that bad because transitive dependencies don't get added to the path. I.e. you actually need to have a list of 1000 direct dependencies to get 1000 path entries.
If for some reason you have a crazy amount of paths like that and path lookups were a problem, you could use buildEnv to create a single bin directory that had symlinks to all the binaries in it.
I have struggled with understanding Nix package manager for a long time. I use it on my macOS as a daily driver, but never understood the various pieces involved for me to comfortable make changes to my configuration. `nix-env -i` and `nix-env -e` were all I was comfortable with.
This blog post does a good job of breaking down the Nix package manager's knowledge into decent sized chunks that one can easily understand and reason about.
And you can get it on every distribution! You can install Nix on virtually all Linux distributions (IIRC Fedora Silverblue is the exception due to read-only /) and macOS.
Of course, you will lose some benefits, such as the NixOS module system. But set up Nix and you have access to packages in nixpkgs and nix-shell (basically virtual environments with any package). Add home-manager and you can set up your user environment declaratively.
An easy, relatively worry free installation/out of the box experience? The option to install uncommon software in a way that may be crappy but would work (make install?)?
That's what's holding me back, although I'm fascinated by the concept.
I would say the installation experience might be a bit more involved, but once it's installed it's much more worry-free for me. On every other distribution I've used (including Ubuntu and co), it's very easy to break the system completely. On Nix, it's almost impossible because you can always boot directly into the state before your update. Once you've set up your configuration, you can install it instantly on other machines by copying one file. On other distributions, you would have to re-install and configure everything by hand. Many of the tweaks for which you usually have to read Arch Wiki are also built into Nix, so you just have to write services.myService.myOption = foo; and you're done.
For the second point, if you've got a package that just builds with the usual ./configure, make, make install, here is all you need to get a nix package for it:
{ stdenv }:
stdenv.mkDerivation {
name = "my-package";
src = ./.;
buildInputs = [ ... whatever dependencies you need ...];
}
And the standard build commands will be run automatically. The only thing that's kind of annoying is installing binary distributions of packages since they need to be patched to work on Nix, but it's not the end of the world. Also, nixpkgs is so universal that I very rarely find myself having to add a package that's not in it.
> The only thing that's kind of annoying is installing binary distributions of packages since they need to be patched
This worries me, as every once in a while I do feel like using some proprietary app. What does it even mean more precisely? What about Steam games and such? Would it make sense to run them in a container or something like that?
I suppose I like to use unpopular software in general. How would I use (make a package or otherwise install) the odd go, python, js, nim, rust ... project that is made with its own weird build system? If I made a package for it I could very comfortably make changes to the code and directly recompile/reinstall, right?
For Steam, NixOS actually builds a full FHS with all the packages from SteamOS and then runs Steam within that using a simple chroot.
It works surprisingly well and can also be used for stubborn software that cannot work without FHS and without messing up the rest of your system.
> Your output is going to be different from mine because of the hashes in the store paths.
Does this mean that a nix install is not reproducible? If the same installation is performed twice, the file names and contents will be different due to some randomness?
The hashes will only be different if you install different versions of the derivation (package). All the inputs of a derivation, so even selected plugins and compile options influence the hash.
That said, if me and you agreed on a specific git commit of the nixpkgs repo and build some packages from that, our hashes would be the same. This knowledge is also used to download packages from the binary cache. You can see the automatic building of the packages on hydra.nixos.org, from there they will be made avaiable on the binary cache.
It is reproducible, but only for the same exact version, and with no overlays at all. If you’re running this with a different channel, or months later, you’ll get drastically different hashes, since the software will be different.
From my understanding it is reproducible, although the hashes might be different they'll still be linked in the same way. Give someone your nix.conf and they will be able to build your machine. You reference things by variable name anyway.
