Oh hi! Author here. Fun thing to wake up to.
I wanted to point something out that the series doesn't do a good job of highlighting:
You can use Nix alongside your existing package manager.
They won't conflict. You can set up dev environments with Nix without drinking the kool-aid. I still have Homebrew installed, and I still occasionally reach for it in the rare cases where Nix is missing some package I want to try. But I am sad every time I do: I never really realized how unbelievably slow Homebrew is until I tried Nix.
So if you're Nix-curious, you can try it out without committing to anything upfront. I didn't make the switch until part 19:
https://ianthehenry.com/posts/how-to-learn-nix/switching-fro...
Nix is weird and hard to learn, but it's a lot like git in that respect. Yes, the UI is terrible. You have to learn the difference between `reset --hard` and `reset --mixed` and it's weird and unintuitive but you eventually get over it.
And people are using it despite how unintuitive it is, because of how valuable it is to them. No one is arguing that `nix-env -qaP package` is a reasonable command to ask a fellow human being to type, but people are willing to type it anyway because the benefits are worth it. As a fun example, a few weeks ago I wrote up a little hack that I would not have even attempted before spending the time to learn Nix:
https://ianthehenry.com/posts/janet-game/how-to-patch-emacs/
from that newer blog post:
> So even if something bothers you about the software you use every day ā even if you find a bug in tmux, or wish that you had some additional jq function or whatever ā you probably arenāt going to do anything about it. Itās not worth it; itās too hard.
> I am obviously projecting here: that is the way that I thought before I started using Nix. I never would have tried to change this Emacs behavior back then.
> But now?
> Now I can get a working build environment for any package I want, just by running nix-shell. I can write a patch, and I can ask Nix to automatically apply that patch to the latest version of the package. I donāt have to worry about maintaining my own fork or manually updating it ā I can keep using all the same commands to list and upgrade and uninstall packages, regardless of what Iāve done to them.
I think this is what all the old greybeards have always been getting at when they talk about software freedom, this blurring of the line between user and contributor that is possible with F/OSS. I know for a fact that there are some HN posters who do use apt-get and related tools this way (that Debian developer who taught his kids to use Xmonad, for example). But I do think it's something Nix is especially good at, as a flexible, source-based package manager.
It's really nice to be able to treat your customized builds in a first-class way with a mature system for managing software.
Btw, if your main use case for this is customizing F/OSS, there's a SaaS offering you can use for free to recover binary caching without even having to set up a build server. Pretty cool if you have multiple computers! https://www.cachix.org/
`apt-get source` and `apt-get build-dep` is a wonderful thing! It's a shame there isn't more around that (like how to navigate the code to a large software package once you have it, eg Firefox).
I remember how awesome it was to switch from Homebrew to Nix, noticeably the speed. But there is something off about Nix: + Installation process, especially on Mac: nix, and then home-manager. And I don't even mention flake. Right now I'm settled with a helpful script from https://nix.dev/, but I don't say I'm fully confident. + How to add an external package which is not in nixpkgs. I have to learn Nix and dig Nix docs and ask too many questions to figure this process. In the end it is awesome but I could feel the barrier for beginner. + Documentation. It's easy to get started with some popular packages but it's a pain to customize your own. I always find myself banging my head to dig the information I need.
So in conclusion, Nix is awesome to use if you invest time to learn the Nix expression language. Otherwise you have to stuck with the default packages provided by nixpkgs.
I love nix as a concept. I have a couple concerns in practice.
* I don't want to learn nix, nor do I want to learn apt, brew, pip, npm, crates etc. beyond a handful basic commands: install, remove, list all, list package (version & deps), update (at version). A one page cheatsheet would be fantastic.
* There is a ton of QA work sunk in standard package manager workflows. Is there a way to leverage this work? You allude it is possible, hopefully there is a one page cheatsheet explaining how.
Regarding obscure command syntax, I use bash aliases to give names to the most common 7 git commands (which constitute 99% of my daily usage) and never have to remember any git command flags.
The thing is, I don't think the one page cheat sheet is very useful.
npm is a great example of why: pretend that all you have is `npm install -g`. That's sort of how a traditional package manager, like Homebrew, works. But that's not typically how you use Nix, just like you don't typically globally install npm packages. Instead, you write package.json files -- which isn't very hard, because you already know JSON.
But in order to write the Nix equivalent, you have to learn the Nix expression language. You can just copy a template shell.nix file and modify it slightly (as you might for a package.json file), but it's likely that that will be frustrating, because... well, because you still have to learn about garbage collection, and channels, and lots of other incidental things that don't map as cleanly to traditional package managers.
There are cheat sheets, though. I linked my Homebrew <-> Nix translation guide above, and the NixOS wiki has one for apt-get:
https://nixos.wiki/wiki/Cheatsheet
But this requires so many asterisks as to be not extremely useful. For example, that page lists `nix-env -u` as an equivalent of `apt-get upgrade`, but it's not. `nix-env -u` is hopelessly broken and will not do what you want. There actually isn't a "right" way to upgrade packages if you're using nix-env. It's just not a thing that Nix can do.
Which sounds crazy at first glance, but remember: nix-env is like `npm -g`. Even though that's a first class concept in most package managers, it's sort of bolted onto the side of Nix, and accepting "the Nix way" of doing things is important to have a pleasant relationship with the tool.
> Instead, you write package.json files -- which isn't very hard, because you already know JSON.
Even with a package.json you will often use `npm install <package_name> --save`.
You don't go chasing a git commit hash on a third party site to do that
I forgot to mention that an in-depth resource like the OA is invaluable complement to terse cheatsheets for the 1% of the cases when the common commands are not sufficient. Thank you :)
I've bounced off Nix a couple of times and figured that the problem is that it was too different. A lot of Linux distros (especially post-systemd) have a fair number of similarities and it's pretty easy to translate knowledge between them. NixOS _probably_ works very similarly, but it's also got this additional declarative configuration layer on top, which is the point of using NixOS, and it's got its own special way of doing things.
You can't translate Linux knowledge to a NixOS config directly, you need NixOS' documentation to understand the "NixOS Way" of doing things, and the NixOS way of doing things does not translate into other distros. And the documentation is difficult to understand and at times seemingly arbitrary.
You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. Other Linux distros help you learn Linux in general and inform your understanding of Linux system construction, but NixOS is its own thing. Plenty of people learn NixOS anyway, and more power to them, but it's definitely pushed me away.
> "and understand that you are only learning NixOS, it won't help you use anything else"
So ā for one thing ā in my personal case, it helped me at one time when I was experimenting with kernel build flags. With the caveat that finding how to change them was (surprise surprise) typically non-trivial in Nix in the first place... so it may be a feeble counterpoint... but still, after I found how to do it, NixOS made rebuilding new OS with different kernel flags absolute breeze, with basically 0 worry if I bork something (I mean, except maybe going to deep hardware params hacking such that would risk fraying some electronics) ā I'd always automatically be just one GRUB entry away from a previous working configuration. (Though also useful to have `git commit`ed the previous /etc/configuration.nix from before I made some risky change, so that I could easily go tweaking again from there.)
I've had a similar experience with systemd itself. While you could go and read through the systemd docs to understand all of its nooks and crannies, you can actually learn the important bits by reading through the source for NixOS's modules (which are linked directly from https://search.nixos.org/options). You start to see patterns of which options they set in the units, and pretty quickly build up the knowledge you need to write your own. This is also aided by the fact that the repository is one giant git repo hosted on GitHub that you can search, clone, tweak, atomically deploy from a local branch. It buys you so much flexibility when experimenting.
This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big.
I see the benefit of declarative configuration as an admin at work where we need to set up many systems the same way. For home desktop use I don't really see the point, I don't think it's a tech that fits perfectly in every scenario. Like most technologies there's usecases where its benefits shine and the drawbacks are irrelevant, and others where it's the opposite.
For example I often come across software that isn't packaged for my OS and I like to just compile them and try them out without having to do the whole packaging routine.
As to "home use", personally I'm successfully keeping my dotfiles & $HOME/bin/ scripts managed with Nix + home-manager. Becomes useful when changing jobs, and also makes it easier to share new config tricks between work & home machine. Regardless if Linux or Mac.
edit: in particular, going just Nix (not NixOS) on work machine(s) allows me to fall back to apt-get/brew quickly when a particular tool is not (yet) on Nixpkgs.
> For home desktop use I don't really see the point
Lucky that you don't need to run NixOS as your OS to get a lot of the advantages from it then. I use debian for my boring desktop applications but have Nix available to me for when I need any e.g. development tools.
> This is something that is coming to traditional Linux as well though, with zfs snapshots.
Has there been a change in ZFS licensing? I thought it was always going to remain poorly integrated into the Linux ecosystem.
> This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big.
This has been available on traditional Linux for quite some time with btrfs snapshots.
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else.
This is kind of true on a surface level, but NixOS experience can be super helpful for setting up other distros because it turns Nixpkgs into a repository of high quality examples and demos that are always up to date.
Once you learn some basics of reading Nix code and how the NixOS module system works, the Nixpkgs repo itself becomes an excellent cross-distro resource on how to configure Linux software, much like the Arch and Gentoo wikis. I often consult Nixpkgs on how to do things in Linux for the purposes of configuring another distro or helping another user to do so! :)
The NixOS way of doing things (a layer on top of plain config files) is inevitable once configuration management is taken seriously: one needs to be able to merge configuration values from multiple source files; for example, a generic role plus some more machine-specific role, working together to produce one systemd unit or file in /etc. The modules in nixpkgs effectively make it possible to combine configuration values to produce most of the config files that Linux applications want.
If one weren't using NixOS to do it, it would be done with your own templates and configuration management, and probably without the huge advantage of being able to rebuild a whole immutable system without leftovers from prior configurations.
Doing programmatic configuration with a traditional distribution isn't difficult. I've got a python script that starts with a tree of config files and a top level file that says what files to consider per-machine. Each config file is run through Jinja2. Some templating even pulls data from a LibreOffice spreadsheet [0]. By default the script only pushes files that haven't been remote, so if you do deviate and edit a config file on a machine you can diff it to merge those changes back into the centralized config before overwriting.
Having said that, I'm moving towards NixOS for reasons detailed in another comment.
[0] It's ugly but it works. I'd love to find a lightweight curses-based data structure editor.
Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!
One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.
> How many containerization concepts do we need?
Nix and NixOS aren't containers (or VMs, etc.).
> If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again.
The basic concept of Nix is (a) use the `--prefix` argument of ./configure scripts to keep things apart, and (b) use the `PATH` end var to choose what we want to run.
In comparison, containers are much more recent, require more invasive changes (i.e. support from the kernel), etc.
Personally, I like using containers to run binaries. Putting a whole Linux/Busybox installation inside one seems to defeat the point though...
> Docker, lxc, VMs, and now NixOS?
NixOS came out in 2003. For context, that's when Xen came out.
LXC came out in 2008; KVM (Linux's built-in VM support) came out in 2007; Docker came out in 2014.
most people who have claim to be unix experts and cannot grasp nix are usually just don't like functional languages
those who do, say that it's a great idea, but implementation is a bit hacky and not well documented
This is why I feel efforts like Fedora Silverblue might end up becoming mainstream in the years to come rather than esoteric projects like NixOS.
I personally dislike both projects though, when it comes personal desktops. Silverblue is heavily influenced by Flatpak and I don't expect RPMs for GUI applications to survive in Fedora. NixOS needs you to learn Nix which is a pretty steep learning curve and like you said, that knowledge probably won't translate anywhere else. You're probably better off investing your time learning things like shell/python scripting, Ansible, and Docker/podman.
Flatpak and the likes are similar enough to Apple's "bundle" concept where you put all the versions, dedicated libraries and frameworks inside the bundle for your 'thing' that you want to distribute. It has been proven to work well (or well enough). I suppose the additional technology behind overlays/bindmounts etc. is different since a Darwin bundle is practically just a directory with some predetermined layout but the experience is the same.
Once it doesn't depend on (yet again) a daemon, registry, and other system-level components but is understood by the shell (or DE) instead, you get a user experience that something like Nix cannot deliver (or at least, not without cutting down on the whole "learn this language to then learn those features to then get work down" thing).
The bundle concept applies more to AppImages than to Flatpak. Flatpak downloads common runtime libraries and packages and uses them to run all GUI packages in a sandboxed environment using bubblewrap. OStree is also involved.
I dislike Flatpak because it encourages package maintainer obsolescence. I heard a guy from OpenSUSE saying in a MicroOS presentation that why create, manage, and use RPMs when we can just use Flatpak. I also don't want to touch Flatpak anymore because people from GNOME are involved in it.
right now NixOS is for a small subset of geeks(who are ok with using custom functional language for pretty much all configuration) but it's entirely possible to make a GUI based like a SUSE configurator based on nix, and with mature enough nix ecosystem it will work flawlessly an be powerful and simple to use for the end user
> it's entirely possible to make a GUI based like a SUSE configurator based on nix
There is such a project already: https://github.com/nix-gui/nix-gui
For the end user it doesn't matter if a GUI is using some nix-thing in the background. It could just was well run dpkg/rpm behind the scenes and as long as the result is the same it really doesn't matter.
This is also why Nix and NixOS painted itself in a corner; the presented value is only relevant if you are hacking away at it. When you have a smooth GUI experience it really no longer matters what the technical goodness underneath is.
We know documentation is too scattered and incomplete.
I've started https://nix.dev about a year ago to provide a resource for newcomers.
I'm working on comprehensive language tutorial next, but I'm mostly interested what you'd like to learn when getting started.
Recently started using NixOS, and nix.dev has been very useful thanks!
Some more NixOS-specific stuff would be really nice, if itās in scope. I think a lot of the power of NixOS comes from the composition aspect, but I havenāt managed to figure out how mkOverride, mkIf, mkDefault and everything else actually work (rather than at a superficial level). Iām not sure if something as simple as adding an item to an option list from 2 separate bits of config is possible for example.
Along the same line, another thing Iāve found hard to discover is patterns used in the standard library. For example, I recently learned about makeBinPath from some random Nix file, and Iād really like some way of discovering quality of life stuff like that without needing to randomly come across it in some Nix code.
I would like to see it mentioned how to use Nix as a system package manager in MacOS. This guide was exactly what I needed: https://wickedchicken.github.io/post/macos-nix-setup/ and the official documentation made no mention of nix-darwin.
It was frustrating reading all the official intro documentation on Nix and it only talking about nix-env (not declarative AFAIK) or how to use Nix for per-project dependencies.
A couple of things come to mind that I'm struggling with now:
1. how to install outside of NixOS, mostly to use home-manager, in a flake-y way using the new `nix profile` thing that supercedes nix-env. The few folks I've spoken to seem to prefer to use NixOS as a shell, then to manage their dotfiles with home-manager, and trying to figure out how to manage this global state in profiles with flakes (e.g. I've heard ~/.config/nixpkgs/flake.nix is the location, but hits on a web search for this file name are almost non-existent).
2. how does one _develop_ with flakes. I get confused about how to use the repl to add something into my config (thankfully there's :lf now!). Some simple walkthrough that goes from packaging a simple application and troubleshooting in the repl, using shell to check the build stages, etc, would be extremely useful. Once one gets over this hurdle, Nix becomes an extremely attractive tool to bundle existing code and manageg packages, and new users start to see the power of it.
Iāve only read the bit on ad hoc shells but so far this is the best nix resource Iāve seen. Thanks for the hard work.
At part 3 now, and it's great. I feel like I might finally learn what all the arcane stuff in the manuals actually mean. Most of the Nix documentation is like reading ASCII EBNF or research papers. This, on the other hand, has just the right amount of snark:
>> A store path Q is reachable from another store path P if Q is in the closure of the references relation.
>
> Good definition. Intuitive term.I wasn't sure if this is supposed to be snarky, given the author said he has a background in functional programming and thus probably has a good understanding how closures are defined. The statement works both ways I suppose.
It's "closure" in the mathematical sense, not in the functionnal programming sense. It would have been clearer with the full term: "transitive closure" instead of just "closure".
> It's "closure" in the mathematical sense, not in the functionnal programming sense.
The latter being of course an instance of the former :) Your lambda uses a reference to a local variable `x`, so go follow it and transitively capture all its references, repeat until you've closed over all such transitions.
let a = // whatever
let b x = a + x;
let f x = x + b x; // closes over b and transitively over aOne of the things I've hated about being a part-time systems administrator is the fear of the unknown. All the little changes to config files, the different installed programs, everything required to get the system working is scattered around the disk. It creates fear around making changes, because who knows which little configuration change was required to get everything working? I understand that better organizations try to combat this with rigorous processes and documentation, with great effort.
I recently evaluated NixOS for a new server deployment. Being able to describe the entire state of the system in a single file is magical - it is so clearly The Right Way to do things. I am not a Functional Programmer but using the Nix language as just a config file is fairly straightforward. I left convinced that a simple functional language is the best way to make more complex config files, way better than Jinja2 templated YAML. (Though, functionistas, come down out of the ivory tower and make a language that looks C-family. Yeah, "it's just syntax" so why not make it easy for the proles like me to learn.)
However, I ended up giving up on NixOS for two reasons.
First, while learning the basics of Nix was easy I wasn't confident about the more complex things. Packages were missing features and I was going to have to start investing in reading and writing lots of Nix code. I couldn't continue ignoring the many intricacies of the Nix system if I wanted to be confident that I could quickly fix an issue at 2AM on a Saturday. As others have noted, there is a lack of good intermediate-level documentation apart from this great "How to Learn Nix" blog. My whole interest in Nix was being able to completely document the system so that future me or someone else could quickly understand how the system is configured. That doesn't work if you can't count on that person knowing Nix very well. Even if I invested in learning Nix it would feel like professional malpractice to dump some heavily customized Nix system on the next guy to come along.
Second, there's no LTS. That's fine if it's a dev machine, or if you have a professional full-time ops team watching package changelogs and testing upgrades. My machines need to survive with bare-minimum supervision.
I learned Nix a couple days ago because I needed a build system for my project that could handle many different tools: Java+Gradle, Thrift, Rust, Python, CUDA, etc.
It's been kind of a pain: Docker is easier to get started with. But the payoff seems higher because it does handle all these tools in a sensible way: For development I can switch between subprojects written in many different languages and get the exact Python, Java, etc. and all necessary libraries are in scope.
I've gotten it working on Linux, and I expect a little more work porting to Mac OS for teammates(mostly for things like switching from CUDA to CPU based on system), but using it should be similar to Linux. Mac doesn't support cgroups or Linux containers so sandboxing is weaker than Linux, so it's better to develop Nix projects on Linux and add other platforms afterward.
I would recommend it for polyglot or Python projects. But for single-language projects with a sensible dependency manager(Rust Cargo), there's not as much benefit.
Nix is really nice for polyglot development environments on macOS, because the fact that Docker requires full machine virtualization makes it very heavyweight. Nix gets to be a lot faster and simpler. (And you can use it to generate Docker images and full fat VMs if you still want that option.)
I think Nix's complexity is a failure. I love the concept of Nix, but I'll wait until there's something simpler to learn.
I thought so at first too, but then I realized, no matter what distribution comes up in the future, learning a new distribution from the ground up is going to be hard no matter what. I dove head first into Nix and after a understanding the language, the OS and package manager was actually not that hard to understand. Now in after hand, I don't regret any of the the time I spent learning it.
I recently installed GUIX and just out of the gate I like the syntax much more than I ever did with Nix. The Nix syntax is just to random and hard to just guess what is going on if you're not sure what you're looking at. At least GUIX is more traditional looking Scheme type code.
I've recently learned of Spack and really like its package descriptions. https://spack-tutorial.readthedocs.io/en/latest/tutorial_pac...
I don't have time to play with it, but really hope that one day someone will write something that effectively "compiles to nix". As far as I can tell, that could be done using the Spack's python descriptions.
As a Nix user who has recently taken some time with Guix, I envy the Guix CLI but not the language. The Guix DSL seems totally fine, but imo the Nix language is very well suited to its problem domain.
For simple configuration, you can just leave 95% of the Nix language's power on the table and it feels really simple, like it's JSON or something.
You can work your way to to all the real features at your own pace.
I've been looking into Nix a lot lately (but have yet to take the leap - I'll probably start with devshell)
But a couple of projects have come up lately that piqued my interest wrt syntax and alteratives (Since I am not sure about Scheme anymore than Nix (as a langauge) :-)
* https://github.com/maxmcd/bramble
* https://nickel-lang.org/I think Nix's syntax is comparable to jq or to some subset of JavaScript (well, the recent ecmascript versions, anyway).
That is so obviously false. You can be an expert on one distro and moving to another distro can be a breeze & breath of fresh air. In the rare case that I distro hop, this is always my experience.
Most of Nix's complexity is intrinsic and not incidental. It's just that it makes it explicit instead of implicit like every other OS & package manager (many of which don't actually solve a lot of important problems and instead rely on the user to keep things consistent and working.)
Yes, this is definitely a complex problem to solve. Imaging we are talking about providing a pipEnv style abstraction for all the programming languages, tools and operating systems.
Iām waiting for other distros to steal ideas from nix. Guix might be a good candidate but I didnāt manage to get quickly started with it looking the docs (although they looked useful if you wanted to sit down for a couple of hours).
I've tried to learn nix and tried to read various documentation. The problem was that there was always a piece of information missing. That was until I've found the nix pills which are a pretty good and structured introduction on people interested in building packages with nix.
Can you try https://nix.dev and let me know what's missing?
I'm still in the learning process, but one thing I've had a hard time is finding out what functions are available. e.g. there's stdenv.mkDerivation for a generic target, and as your docs mention pythonXY.withPackages for a python virtualenv [1]. But what if I wanted, e.g. Ruby? How do I find out what's available? What options they take?
https://nix.dev/tutorials/ad-hoc-developer-environments#beyo...
No experience with ruby but nixpkgs has sections for many languages. See ruby: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-f.... Also a quick search on the NixOS wiki gives this: https://nixos.wiki/wiki/Packaging/Ruby.
This is less packaging related (more nix lang related) but here is my go to resource for functions: https://teu5us.github.io/nix-lib.html. teu5us extracted the builtin/lib function docs and put them on one place saving you from having it split up into multiple manuals.
One issue with nix is the content has been written down itās very inaccessible. It is split up between blog posts, discourse, nixpkgs code comments, the wiki, Reddit, etc. When working on something in nix Iāll frequently have 10+ sources of information. The google-fu needed is strong.
My biggest recommendation is to dive into the nixpkgs repo and other public dotfiles as most likely what you are doing has been done.
Would love to see some documentation on dealing with SSL decryption for those who are in MITM corporate environments.
I've struggled with this as I recently got a new Mac for work and I tried to set it up from scratch with Nix but I couldn't even get it to connect to the nixpkgs channel. I tried every solution I could find online for pulling the CAs and specifying the NIX_SSL_CERT_FILE, but it borked even after I left the office and connected through another network (and wiping and reinstalling Nix didn't seem to fix it, but I probably didn't do that correctly either...).
Eventually I gave up and went back to homebrew and setup scripts.
You need to make sure the `https_proxy` environment variable is set correctly as well. There used to be some coverage of this in the manual, but it looks like maybe it's gone now.
Nice guide! One thing I noticed missing is how to use nix flakes (e.g. in place of niv). That is my next thing to understand, and I want to convert my NixOS / shell.nix files to use them.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.