18 ms·

My First Impressions of Nix

275 points by signa11 3y ago

seungwoolee518 3y ago
Seems like link is dead.
- signa11 3y ago
  seems to work just fine here.
ghuntley 3y ago
easiest way to get up and running w/value in the nix ecosystem is https://devenv.sh https://devenv.sh and as time goes on use escape hatches to utilise more of nix ala https://nix.dev https://nix.dev
- toastal 3y ago
  Disagree. The larger selling point is Nix reproducible builds. Getting a reproducible developer environment is a start, but everything inside that “shell” is then mutable. Hiding Nix behind YAML is obscuring a tool, Nix, to make the entire build stateless—and that YAML can often be a stopping point where folks aren’t going ‘deeper’ to unlock the reproducible build part. There are things it does that are very helpful, like enabling a PostgreSQL server without much setup, but other things like forcing certain language toolsets goes a bit too far—especially when those tools are already in Nixpkgs and setting up a base devShell provisioned with a few console tools is one of the easiest things to do with Nix the language already.
  - ghuntley 3y ago
    i agree with some of your points but differ as follows: getting an entire team or project up and running in less than 5 mins with devenv is a fanstastic introduction for folks who do not have experience with nix. devenv solves the “onboarding new developer in a couple seconds without having to learn nix” pain point. the next step there is to migrate away from only using nix shell (via devenv) and go for making ci reproducible locally once folks are more comfortable with nix/less career risk for introducing new tech. then the world is your oyster. use build2dockerImage and start creating docker images that are reproducible and use them in production.
    - toastal 3y ago
      Getting someone up and running with a flake.nix with a defined devShell is just as simple and probably requires less knowledge since it's not another tool bolted on. Making the env and CI reproducible should be seen more like a good stepping stone and you can take the next leap when ready since it can all happen in the same flake file rather than a separate YAML one. The world is your oyster approach is skipping Docker and just running Nix on the server without the overhead of containers.
  - Foxboron 3y ago
    > reproducible builds fwiw, NixOS does not support reproducible builds as defined by the Reproducible Builds project. They support reproducible environments/configuration/deployments or how you want to describe it.
    - ghuntley 3y ago
      1307 out of 1331 (98.20%) reproducible https://reproducible.nixos.org/nixos-iso-gnome-runtime/ https://reproducible.nixos.org/nixos-iso-gnome-runtime/ see also https://reproducible.nixos.org/ https://reproducible.nixos.org/
      - Foxboron 3y ago
        Yes, they are testing this for a fraction of their packages. It still amounts to less testing then what distros like Guix, Debian and Arch Linux is currently doing.
nittanymount 3y ago
planning to learn/use ansible, wonder if Nix is ready to use ? have most functions/features ?
- throwaway6835-8 3y ago
  Go with Ansible unless you want to fully dedicate into Nix ecosystem and spend a lot of time learning it (and it's not easy, for example because of lacking documentation). Also Ansible is something you more often find in actual projects/workplace.
  - SuperSandro2000 3y ago
    well, yes true, but ansible sucks and especially for small and chaotic projects where people just change things on the machines without reflecting it in ansible it is a nightmare
    - totallywrong 3y ago
      You can hardly blame the tool for that, it's your process that's flawed.
    - throwaway6835-8 3y ago
      Why would anyone change anything on the machine if the machine is managed by Ansible?
- SkyMarshal 3y ago
  Try it out in a VM and see for yourself.
- hamandcheese 3y ago
  If you can adopt NixOS, then it's worth considering. But if you have to use a standard distro then Nix on its own won't solve your configuration-management problems. To sum it up succinctly, I would say that Nix helps you manage $PATH while NixOS helps you manage /etc.
- 3y ago
troupo 3y ago
> A lot of Nix documentation I’ve found says things like, “Simply add these lines!” > Huh? > Which file? And where in the file do I add those lines? This issue is prevalent everywhere. Even the best documented projects fail into this trap almost immediately.
- rendaw 3y ago
  And why, what do those lines mean
- SuperSandro2000 3y ago
  > Which file? And where in the file do I add those lines? /etc/nixos/configuration.nix if you haven't structured your config differently. > And where in the file do I add those lines? Consult `man configuration.nix` or search.nixos.org
- kertoip_1 3y ago
  That's why I like documentation with the comment section. Even if something's missing, there is a good chance someone asked about it. Also comments section provides an instant feedback to people writing posts to that documentation.
  - troupo 3y ago
    While I wholeheartedly agree, you need a full-time moderation team if you want to enable comments.
lvncelot 3y ago
I'm a huge fan of Nix, and I'm glad to have stuck with the often times daunting process of getting into it - and I have to agree with the author's point regarding the documentation. That's not a fault of the people who actually did sit down and document their process, or distill their learning path into a tutorial - I myself understand it well enough to use it, but not well enough to really explain it without confusing people even more, but it's still a pity that finding good, exhaustive documentation for Nix is really difficult. Another pitfall is the usage of flakes, which, on the one hand are (imho) great, recommended everywhere and often times even assumed to be used implicitly, but on the other hand are still experimental. I myself started using flakes not because of the promised benefit (although I did realize the benefit later on) but just because multiple tutorials I've read gave me the feeling that flakes were the de facto way to do Nix from now on - and mind you, that was in late 2020. I'm using Nix for setting up my work machine (Mac via nix-darwin), my private machines (NixOS), selfhosting that's not in my k8s (also NixOS), and some private projects (dependencies, ci, and containers) - where the issues I've described don't really bother me, but for professional projects, where I'd have to convince and/or instruct colleagues, Nix feels a bit too rough around the edges for me right now. Edit: I also think it's important to distinguish between Nix the technology (fantastic) and Nix the language (meh) - which is why I'm still itching to try out Guix[1], which is similar to Nix (the technology) in a lot of ways while using Guile[2] as a language. [1] https://guix.gnu.org/ https://guix.gnu.org/ [2] https://www.gnu.org/software/guile/ https://www.gnu.org/software/guile/
- mteigers 3y ago
  I'm curious if you have any pointers for whole Mac config with nix-darwin. This is something I've just started looking at and at the moment don't have much more than a nix-shell with some nice-to-haves. Any tips / tricks / guides are greatly appreciated.
  - cormacrelf 3y ago
    Life’s short. Don’t waste it configuring nix-darwin.
hamandcheese 3y ago
> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix. Nix is not fast because it is stateful. It is fast because it is functional and reproducible, which allows for caching without compromising correctness. I don't want to split hairs, but referentially transparent caching like this is not quite what I'd call state. Yes, there is some statefulness in system activation, but this is not what makes Nix Nix -- quite the opposite.
- hardware2win 3y ago
  Functional?
  - globular-toast 3y ago
    Just in case: https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming
    - hardware2win 3y ago
      I mean how Nix uses FP?
      - maleldil 3y ago
        Did you read the entire comment? The core idea of functional programming is pure functions (given the same outputs, the output is always the same). Nix applies that to building systems.
        hardware2win 3y ago
        Pure functions are just a concept that is used in FP world Yet, pure functions can "stand alone". You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them. So unless you want to sound fancy and trendy then why call Nix functional instead of side-effects free?
p-e-w 3y ago
I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?
- seqizz 3y ago
  Afaiu it's trying to become all. Nix is on core, you can get packages from nixpkgs / write your own definitions, use it on OS configurations via NixOS, use its built-in helpers to run your containers with it, make a whole CI and cache it with the help of Hydra etc.
  - politelemon 3y ago
    That's confusing because NixOS also seems to be an operating system, looking at the blog post?
    - chpatrick 3y ago
      NixOS is just a super barebones distro where everything is configured with Nix. You can also use Nix on Ubuntu or some other distro.
      - SuperSandro2000 3y ago
        Bare bones as in by default you don't get much unless you turn it on
        chpatrick 3y ago
        Right, it's just bash, Nix and systemd by default.
- hamandcheese 3y ago
  Most of the above. - Nix is a tool for building and installing software. - Nix is a language for expressing how to build a package. Nix-the-tool reads expressions defined in Nix-the-language to know what to do. At the end of the day, this translates into normal commands that run in a sandboxed build environment. - Nixpkgs is a monolithic repository of 80000+ packages, defined literally as one giant expression in the Nix language (this works fine because Nix is an extremely lazy language). This also includes lots of helpers and abstractions for building packages that can be handy in your own projects. It is possible to use Nix-the-tool without Nixpkgs, but nobody does. - NixOS is a Linux distribution built on these foundations. Everything under /etc is built from nix expressions. You can not directly edit these. Mostly NixOS is about building systemd unit files from Nix expressions - viewed through that lens it's not really all that exotic of an OS. NixOS has modules that make it very easy to configure and run lots of software.
wesapien 3y ago
Does anyone have any ideas on what the most likely outcome would be for NixOS losing the S3 bucket funding?
- throwawayqqq11 3y ago
  You propably have to pull all your sources from github and compile them yourself once, since there is no remote store that provides prebuild artifacts? (I dont know what use the S3 bucket/s is for.)
- seqizz 3y ago
  As far as I remember there was enough money to keep them alive on current setting about a year. Worst case they'll switch to an alternative provider which _might_ be a bit slower?
- WJW 3y ago
  IMO, one of the budget storage companies (Backblaze, Storj, etc) and/or a CDN stepping up to support it out of their marketing budget.
- mdaniel 3y ago
  It seems to me that this "hash all the things" setup seems absolutely made for IPFS integration, which AIUI would mean that everyone who chooses to seed those nix stores would incrementally reduce the bandwidth burden upon the "main" nix store. I'm not sure if nix hashes take the $(uname -sm) into consideration, so that could be a hurdle, too I can very easily imagine that it would need to be opt-in, to keep security peeps from losing their minds, but my suspicion is that a non-zero number of actual nix users would choose to turn it on in support of the community
- Cloudef 3y ago
  Binary cache for old builds will be lost, they move to some other storage solution, but they can't transfer the binary caches due to AWS's egress costs.
deleted 3y ago
[deleted]
bouk 3y ago
If you want to install a package, search for it at https://search.nixos.org https://search.nixos.org The gnome system monitor is gnome.gnome-system-monitor for example https://search.nixos.org/packages?channel=23.05&show=gnome.gnome-system-monitor&from=0&size=50&sort=relevance&type=packages&query=System-monitor https://search.nixos.org/packages?channel=23.05&show=gnome.g...
- drdaeman 3y ago
  > If you want to install a package, search for it at https://search.nixos.org https://search.nixos.org And if this doesn't work, go to https://github.com/NixOS/nixpkgs/issues https://github.com/NixOS/nixpkgs/issues and search for the name (in both open and closed issues and PRs).
- mtlynch 3y ago
  Oh, thanks! That's super clear and fills a huge gap in my understanding how to use Nix. It sure beats my previous method of finding packages, which was just blind guessing. I've updated the post to include the correct package name and how to find it.
FpUser 3y ago
I have shell script with bunch of common functions to simplify particular tasks and then main script that when ran installs all needed packages, creates / copies various config files, pulls my C++ code from repo and builds my servers and installs those as daemons. It also installs cron jobs that execute backups / replication. It is smart enough to skip already performed steps and can safely run multiple times. It can run on Debian, Ubuntu, Arch and Mint. It is fast and reliable and can deploy new infra and or restore state of that from backup. I use it for years without any problems.
- colordrops 3y ago
  That is awesome and I'm glad it works for you. Nix does a lot of other things as well, and also has a large package repo and community around it.
- SuperSandro2000 3y ago
  Let me interrupt that in the middle and undo some steps by hand and it will probably fall on its nose. Nix can handle interruption in the middle of all build steps and can cleanly recover from them.
CapsAdmin 3y ago
I feel a little lost on nixos. Been using it for a while now on my main personal desktop and it's fine, but whenever I want to do something like running a python project (ml based ones for example), or compile software from source, I'm lost because I don't know what I'm doing. Most projects target Ubuntu, so I feel you need to know a lot about how nix really works to get them compiling, which is often not what I'm in the mood for tinkering with when I just want to test something. So in the end I end up using distrobox with Ubuntu which works surprisingly well, but feels very hacky as I'm supposed to try and use nix. The way I rationalize this is that I'll get rid of distrobox slowly over time as I learn how it works.
- madjam002 3y ago
  I've used Nix for 5 years now and use it heavily in production, and in my opinion, just do what works for you. If you try and use Nix 100% "correctly" then you'll end up like the countless other people who tried Nix and failed. Especially for toying around in dev environments, be pragmatic and take advantage of its amazing strengths, but if distrobox lets you enjoy using NixOS and speed up your workflow, so be it. Heck I'm spinning up some services in production just now and I'm reaching for Docker Compose as that's how the vendor officially supports deploying their software. Turns out NixOS can still bring some benefits to a Docker Compose workflow, deploying it via a systemd service, config managed in Nix, it's not as nice as building the service entirely in a Nix derivation and deploying it natively, but it's still better than without NixOS.
  - dpatterbee 3y ago
    How are you managing docker compose with nix? Individual docker containers are easy to manage with `oci-containers`, but there's no obvious way for compose. Unless of course you're just writing the systemd configs in nix.
    - madjam002 3y ago
      Yeah I normally use oci-containers but for this workload the only supported method of installation is a `docker-compose.yaml` file. I've just written a systemd service that does `docker compose pull` and `docker compose up -d --remove-orphans` with the compose file being written to the Nix store, works well.
arminluschin 3y ago
I love how this is written. Very relatable, very approachable.
scandinavian 3y ago
Now that we have another Nix post, maybe someone can enlighten me about something I've been wondering about. I'm one of the maintainers of a popular django application. Someone made a nix package of the project, but we've now twice gotten invalid bug reports from people using the package because the package depends on "django_4" and whenever someone updates that nix package, the package for our project breaks. Of course we, like all other python projects, don't support using other dependency versions then the ones in the requirements.txt file. So when someone just uses a different minor version of django, stuff breaks. What's the disconnect here? Why does all nix packages that use django_4 need to use the same version, that seems super prone to breaking all kinds of stuff. Same for the other 35+ dependencies that run arbitrary versions instead of the ones defined in the requirements.txt file.
- jacereda 3y ago
  The answer today would probably be to use flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
- hamandcheese 3y ago
  It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpkgs maintainers would allow all that extra duplication upstream.
  - scandinavian 3y ago
    I get what you are saying, but nothing you said works in practice for python packages, so not sure that I actually learned anything. Is it fair to summize that python applications with python dependencies do not really work well as nix packages and shouldn't be used?
    - nrabulinski 3y ago
dottedmag 3y ago
> Using VS Code Remote SSH on NixOS systems This is the main of issue with Nix and other niche distributions: they are new operating systems, with their set of file layouts, package managers, and even syscall variations. Linux ecosystem is awfully fragmented. If you ever want to use any software outside of your not-very-well-walled-garden provided by distribution authors, you have to hope your operating system (that is, distro) is sufficiently similar to one of few distros software authors have built and QAed their software on. I have written at length about it here: https://dottedmag.net/blog/linux-is-not-os/ https://dottedmag.net/blog/linux-is-not-os/ I wish for a system that: 1. provides declarative configuration. 2. allows for easy local patching. 3. is ABI-compatible with a major distro. Alas. Fedora Bluesilver delivers 1 and 3. Gentoo provides 2. NixOS provides 1 and 3.
- rowanG077 3y ago
  I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.
  - cosarara 3y ago
    Depending on what you are patching, it will invalidate a great part of the cache, and you will be looking at very long build times for everything in your system.
    - kaba0 3y ago
      If that dependency is deep in your dep tree and is statically linked somewhere than there is no way preventing that. If it’s only dynamic linking than yeah, it might happen that you need a huge recompile (but that is not that big of a problem nowadays in my experience - gentoo used to compile way longer in my subjective experience for example). Also note: nix will soon get content-based hashing which may solve this problem.
    - SuperSandro2000 3y ago
      For that reason many modules have options to set the packages used, so that you can eg. patch openssh without rebuilding everyone.
Jedd 3y ago
My experiences with Saltstack and Ansible are inverted - I realise the comparison was only a casual aside in TFA, but the 'Ansible executed the idea better than Saltstack' comment invites so many questions, especially in the context of an article that dwells on how unpleasant Ansible is. Ansible certainly defaults to slow, and I never got into the weeds for performance tuning it, but Saltstack felt fast, especially the example of 'install package foo' which he anticipated takes 15 minutes to run against one of his VMs using Ansible. I agree, that sounds unpleasant. Others have noted the slight confusion about state (and where that state is or should be maintained), and certainly writing idempotent salt or ansible recipes takes some thought, just as writing performant recipes does. The 'have to rewrite everything' whenever Ansible releases a new feature doesn't sound right - perhaps I misunderstand the problem described there. Author mentions apt, but ultimately sounds like they wanted something more container-y than a fat VM running a full GNU/Linux distro with managed packages + config files. In that light, the mention of Hashicorp - specifically Terraform & Nomad - felt tantalisingly prescient.
ryangibb 3y ago
> When does the determinism happen? > When I specified packages to install, I didn’t specify an integrity hash, let alone a version number. If I ran the same Nix configuration a year from now, I assume I’d get a different system because it would install different versions of the vim and curl packages I specified. That would be from the Nixpkgs [0] instance obtained from a Nix channel [1]. Nix flakes [2] provide an alterative way to specify inputs which pin them in a `flake.lock`. This allows things like Nix expression caching due to hermetic evaluation (as opposed to just builds being hermetic). [0] https://nixos.org/manual/nixpkgs/stable/ https://nixos.org/manual/nixpkgs/stable/ [1] https://nixos.org/manual/nix/stable/package-management/channels.html https://nixos.org/manual/nix/stable/package-management/chann... [2] https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake.html https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...
spacesuitman2 3y ago
>I see words like “flakes” and “derivations,” and I currently don’t know what they mean. >So far, I don’t get how it’s deterministic. To make nix deterministic you can specify a hash in non-flakes (or a git rev) for your dependencies, but flakes make this easier. When you "run" a flake (be it nix build, nix shell, nix develop), nix pulls the latest (if no explicit rev given in the flake.nix already) version of whatever is specified in flake.nix that it can find, and creates a `flake.lock` file that specifies the exact version that was used. This file is very similar to cargo's Cargo.lock, and specifies the exact version that was captured by ref/hash. The next time nix is "run", it uses the lock file to get the exact same version as it had previously. One can develop a flake.nix locally, install, check if everything works, and alternatively change the refs in the lock file to make everything work. When this is done you can move the nix and lock file to another machine and get the same exact build there (with the exception of architecture differences). Because you can put flake.nix and flake.lock inside of git, you can also share the exact same dependencies with other people using a repository. Whenever I see a repository using these I know that building will be a breeze because I don't have to do any dependency hunting.
- skhm 3y ago
  i've been using nix for a few years and i finally understand flakes now. thank you!
datadeft 3y ago
I am still waiting for a tool that compiles to a binary and that is run on the servers that I would like to manage.
- SuperSandro2000 3y ago
  You can just copy a build nixos system to a server and activate it there.
samsquire 3y ago
I use Replit a lot and it uses Nix. I think everybody has a different idea of what they find intuitive or what they think of as being "good". Some people struggle with git for example. As a tool writer (I wrote https://devops-pipeline.com https://devops-pipeline.com), I want (command line) tools to be elegant and the command line tools to be obvious.
deleted 3y ago
[deleted]
stayfrosty420 3y ago
Nix reminds me about that xkcd comic about standards. It seems to be to be solving a problem solved in a much better way by other alternatives with the mindset of IT from a bygone era. I may just not really be the target demo, or maybe am just a huge idiot, but I struggle to see the appeal, especially when you hear about the occasional horror stories about complex and/or broken environments, or the vim-like overhead to learn it properly.
- kaba0 3y ago
  No package manager before Nix solved the whole problem at all. Nix is the first of its kind. A good litmus test: install the gnome and the kde desktop envs on your linux system with your preferred package manager. Now remove both. Will you get back to a fresh install state? And it’s not even a hard problem yet. Now how would it solve installing a second chromium browser that uses a patched libc beneath?
- SuperSandro2000 3y ago
  I don't know of anything before nix comparable to it but I happily learn something new.
- drdaeman 3y ago
  > or the vim-like overhead to learn it properly. In my opinion, it's somewhat simpler than learning how to do Debian packaging properly (with emphasis on "properly", following all the modern best practices). Quite a lot of folks that run Nix or NixOS write themselves decent derivations that could be (and frequently are) contributed to nixpkgs (of course, there are a lot of quirks/hacks as well). But I think quite a few folks who run Debian make themselves high-quality packages - e.g. why bother setting up cowbuilder and do the proper repo for gbp with all the pristine-tar branch oddities, when checkinstall does the trick.
  - stayfrosty420 3y ago
    Ah, I will concede I probably am just a huge idiot then. I suppose I don't often find myself needing to bootstrap a linux OS in this way.
wkdneidbwf 3y ago
the article goes from talking about nix to talking about issues installing nixos. anyone new to nix will be thrown off track reading this.
lloeki 3y ago
The problem the author hit with the Raspberry Pi is that the ARM image is meant for a standard environment (e.g UEFI ), like VMs. e.g it'll boot on Fusion or kvm because they provide UEFI, a well known device tree, and don't require any firmware at that stage. Pis (and many such ARM boards) don't have that so they won't be bootable. But there are Pi images built on Hydra. If one uses that then it boots right away. It's all documented in the Nix wiki. https://nixos.wiki/wiki/NixOS_on_ARM#Installation https://nixos.wiki/wiki/NixOS_on_ARM#Installation
- mtlynch 3y ago
  Author here. I'm working on a follow-up post specifically about NixOS on the Pi 4, but there are several gotchas to the process. The biggest issue I've run into is that the latest versions of the NixOS SD card images don't work on the Pi 4. You can boot to them, but when you run nixos-install, they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable. The link you shared declares itself to be out of date in several places, so it's not super helpful as a resource for newcomers.
  - lloeki 3y ago
    > You can boot to them, That is the only part I wanted to draw attention to: ARM boot is a peculiar beast and very surprising when you don't know about it, especially when you're used to PC (BIOS or UEFI) booting. > but when you run nixos-install, If one intents to run from the SD card that was just booted then the process should be changing configuration.nix to one's liking and nixos-rebuild switch to that (which is a testament to the power of nix: one can pivot to an entirely new "install" on the spot). Or maybe you attempted to do an install on another block device, e.g to boot straight from USB? > they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable. Does that error also appear with nixos-rebuild switch? If so, then pi4 support is borked in nixos. Otherwise, assuming the install to USB process, maybe nixos-generate-config was run and produced a non-functional hardware-configuration.nix? (which would be a bug too) (it's been a while since I tried nixos on Pis, last time it did work OOTB for me on 3 and 4, save for a kernel / device tree bug for 3 that kills the virtual console) > outdated I agree, all the spread out bits are confusing. The ARM boot situation is common an issue enough that I would expect that to be part of the manual. > Author here. Thanks for the article, I enjoyed it!
jordanbeiber 3y ago
Biggest drawback of ansible is that it is stateless and as such you can’t simply declare a desired system state and apply it. Nix is absolutely awesome in that regard. Possibly this is Ansibles biggest strength as well, as it feels incredibly simple to get going. Salt has a much steeper learning curve due to both weird nomenclature and the infrastructure. Nix is in many ways easy to use “on the surface” but quickly becomes hairy as you dive deeper. Just my 2c having spent quite some time with all three.
- ed25519FUUU 3y ago
  Maybe I’m naive but I’ve just never found various “states” to be desired in config management. It’s always binary: either in the “right” state or a bad one!
  - jordanbeiber 3y ago
    If you have drift in actual state using Ansible you have to account for all eventualities and you simply can’t declare “make my system(s) look like this”. I’m talking “desired state” here and how to fulfill it - not “various states to switch between”. With nix(os) I feel you treat a machine more like an appliance!
hdoehxoshs 3y ago
nix: automating running scripts from random readme.md as root. the amount of JavaScript devs just learning SE in this thread defending the maybe-good-enough-for-your-dev-box nix is so amusing. it's like seeing second year CS students thinking they mastered system programming because they wrote one toy compilet that optimizes one loop they were looking at the time. not saying it's bad. it's a very essential first step and everyone will step on this starting their journey, but the amount of misplaced self confidence is too funny looking from a more experienced vantage point.
- reocha 3y ago
  This is a pointless comment, nix is more than robust enough for servers, gaming machines, general purpose desktops and developer machines. If you don't understand the tech don't disparage the users or the tech.
totallywrong 3y ago
15 minutes to configure a local VM for development with Ansible? That feels very off. It used to take me about that long to set up a Kubernetes cluster on remote VMs from scratch (with etcd, load balancing, etc.). I haven't used it for a while though.
- mtlynch 3y ago
  This a bit like saying a 15-minute commute sounds "very off" because it only takes you 10 minutes to drive to your office. Ansible run times are going to vary wildly depending on what's in your playbooks and how fast your nodes are. In my case, a lot of my VMs share a set of common roles I've been developing over 8 years of using Ansible. The roles span several different OSes and versions, and every play adds time to the run, even if Ansible just skips it or has no action to take. And then third-party roles from Ansible Galaxy typically take even longer to run because they're not optimized for speed either, and they're targeting an even larger set of possible OSes.
xwowsersx 3y ago
Seeing a tweet like the one from Mitchell makes me want to try Nix. Or at least I want to want to try Nix. Then I read the comments here and am reminded that no one can even succinctly explain what Nix is. I've read dozens of comments here and I still don't have a clear idea!
- hackernudes 3y ago
  Your mind must be pure to understand Nix. Work on your purity. Just kidding. You might explain why you want to try nix? That would help customize an explanation for you, because there are levels. Umm... here is my attempt. Sorry. Nix is a programming language plus utilities that are useful to define and work with software packages in a reproducible way (https://github.com/nixos/nix/ https://github.com/nixos/nix/). Each package is called a "derivation", which is a function that takes inputs and makes output. The inputs are everything that is needed to make the output. It is "pure functional" package management - for the same input arguments, the same output will be produced. Nix is really fast because each derivation is hashed and cached and the language is lazy-evaluated. Builds are "hermetic", meaning only the inputs specified in the derivation are available at build time. Contrast this to some packaging systems, where the build is done against some staging area where packages get installed as they are built and the output can depend on the non-deterministic order that packages are built. Nixpkgs (https://github.com/nixos/nixpkgs/ https://github.com/nixos/nixpkgs/) is a large collection of recipes for existing software. It contains both rules to build software as well as "modules" to configure it or extend it. NixOS the linux distribution is also part of nixpkgs. There are lots of design patterns here and it can go pretty deep. There are also tons of hacks and patches and workarounds to make software conform to the way nix works. Nixpkgs also has a lot of useful library modules built in. Nix is the latin word for snow. Nix "flakes" are a way to combine multiple inputs as well as pin the version of inputs. Kind of like pipenv/requirements.txt or "cargo lock" or "yarn lock" but for anything. The output of derivations go in the "nix store" which is a path like /nix/store/<hash>/, so all sorts of software can co-exist (think multiple incompatible versions of the same library) and can be referenced in a fixed way. Usually you will end up with an output that is mostly symlinks to other /nix/store/ paths. Nix can make practically any combination of software you can cobble together trivially rebuildable/reproducible. You can write some nix code that will produce a a VM image with test scripts as well as a script to launch the VM with a patched version of qemu and run those tests. You can have all your dotfiles/configuration in code with nix installed just for your user on top of Ubuntu. You can generate a raspberry pi sd card image from a short nix source file and a single command, and then 6 months later change a single line and regenerate it without worrying it might be broken. You can achieve a lot of that stuff with Yocto or Ansible or a Dockerfile and scripts, but it would be slower than nix and more fragile.
lenova 3y ago
Coincidentally I came across Fleek this morning, which appears to be a simplified Nix abstraction? https://getfleek.dev/ https://getfleek.dev/
- bketelsen 3y ago
  (fleek author here) Fleek is a simplified wrapper around Nix Home-Manager, which is used to install and configure the apps that make up your $HOME and shell environment.
  - lenova 3y ago
    This is what I love about Hacker News: post about a random tool I found, and the author shows up! :-) I came across your blog (and from that, Fleek) as I'm rebuilding my home WSL setup, and I just want a simple way to destroy and rebuild my distros and move my installed apps easily. Would Fleek be a good use-case for this?
    - bketelsen 3y ago
      very much so, that's how I use it. Especially if you want your dotfiles/configs to come with it.
totallywrong 3y ago
The problem Nix wants to solve is a valid one. But there are better alternatives imo, such as the newer distros based on rpm-ostree. You can do atomic upgrades, and easily rollback to a previous known good state if needed. No changes are allowed to a live system. And best of all, it's practically the same in terms of management, there's hardly any learning curve.
- colordrops 3y ago
  Sounds interesting. Is rpm-ostree config declarative? Can it install multiple versions of packages and libs simultaneously? Are adding custom packages to your setup a matter of a few lines of additional config, or must you learn RPM? Can you manage home directory config as well?
  - totallywrong 3y ago
    There's the treefile [1] for declarative config, no need to learn RPM, just add package names and any extra config. As for managing home and multiple versions simultaneously, I think those are non-goals for this tool. [1] https://coreos.github.io/rpm-ostree/treefile https://coreos.github.io/rpm-ostree/treefile
    - colordrops 3y ago
      I meant creating an entirely new package from scratch. Regarding non-goals - I think that exposes the fundamental difference. rpm-ostree isn't "better". It's trying to solve different problems. The use case you described is a very small part of what Nix makes possible. Nix isn't just trying to fix or improve on existing systems - it present a fundamentally new abstraction that can be used for many purposes. Yes, you can configure and snapshot a list of packages, but that's a tiny part of it. With Nix, the capability allows you to also create any environment from scratch, isolated from other environments on your machine, e.g. for CI or development, or running some obscure python repo. It's like the difference between SVN and git.
      - 3y ago
kertoip_1 3y ago
That's funny, I've gone through almost exactly the same path trying to use NixOS. Tried on VirtualBox and failed. Tried on Raspberry Pi than failed. Didn't have spare bare metal, so I ended up on a "failed" state for now
0x69420 3y ago
> Nix optimizes for local configuration yes yes yes yes yes. nix makes deployment feel bottom-up, not top-down. you understand how a system is constructed locally before you (optionally, if it's in your job description) graduate to doing devops stuff with it. that was the singular thing that hooked me; the functional reproducible stateless referentially-transparent cacheable stuff was just what kept me on board.
- drdaeman 3y ago
  I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes is not exactly an OS, but is a notorious example), but they could make the same mess with any technology. They're just unlikely to pick Nix, NixOS or NixOps (or any alternative to it), because mainstream tutorials won't cover it [yet]. The deployment and learning process is not that different from, say, Arch Linux, or even Debian. You still learn the higher-level interactions (pacman/apt/nixos-rebuild), divert to individual programs, then dive in (.ebuild/dpkg-buildpackage/nix), then learn even finer details as you get hit with nuances. NixOS is absolutely not LFS, where you really go bottom-up. And nixpkgs is covering more and more every day. Just an anecdote example: I've started with run-of-the-mill tutorial approach on setting up NixOS on single machine, and ran than for a while. Then I've realized my configs are a non-DRY mess and I want to manage my systems in organized fashion, so I've spent a significant amount of time unifying the configurations so I could manage and deploy it with deploy-rs (thinking of switching to colmena now, but that's not relevant). And only at that point I've realized that I'm missing some fundamental bits like signing (aka why nix-copy may fail, and how to deal with this without the trusted-users "see-no-evil" hack), or exact operation of substituters (aka, essentially, binary caches). Because with local nixos-rebuild it's all sort of hidden and I never had any issues. What makes Nix/NixOS different are its fundamental principles, not how one approaches it. Starting somewhat more low-level than with "just works" tools is just a popularity issue: more rough edges, so one needs to learn how to polish them.
  - 0x69420 3y ago
    well, an anecdote for an anecdote: reading the definitions of nixos modules became a matter of course for me when i started doing strange stuff that didn't quite fit into the authors' expectations, and those module definitions contain the implementation, i.e. exactly where files are placed and what's written to them. i learned things about how a distro is put together that i never had any reason to look into in the past. but i wasn't referring to how a system is put together at that level; i was referring to how a system is put together with the tool at hand, i.e. nix. and yes, you're right, that is top-down from the latter to the former > What makes Nix/NixOS different are its fundamental principles, not how one approaches it. you'll have no disagreement from me here; i was referring to what qualitatively hooked me, not making any statements about fundamental design
yencabulator 3y ago
> With Nix, changes are atomic. Nix either gets your system into the desired state or it rolls back to the state before you tried changing the configuration. Except the "activation script" is an imperative sequence of steps which can fail or hang. Atomicity really exists only if you `nixos-rebuild boot && systemctl reboot`, and there rollback means picking the previous entry from the boot menu.
pxc 3y ago
Great writeup of your first impressions! Looks like your questions are mostly answered, or at least you have starting points for most of them, so I'll leave those aside. Thanks for giving such a detailed writeup of your early experiences with Nix!
anarchogeek 3y ago
When i see a project uses Nix, i think, oh fuck me, they don't care about anybody using their stuff.

275 points by signa11 3y ago

seungwoolee518 3y ago

Seems like link is dead.

signa11 3y ago
seems to work just fine here.

ghuntley 3y ago

easiest way to get up and running w/value in the nix ecosystem is https://devenv.sh https://devenv.sh and as time goes on use escape hatches to utilise more of nix ala https://nix.dev https://nix.dev

toastal 3y ago
Disagree. The larger selling point is Nix reproducible builds. Getting a reproducible developer environment is a start, but everything inside that “shell” is then mutable. Hiding Nix behind YAML is obscuring a tool, Nix, to make the entire build stateless—and that YAML can often be a stopping point where folks aren’t going ‘deeper’ to unlock the reproducible build part. There are things it does that are very helpful, like enabling a PostgreSQL server without much setup, but other things like forcing certain language toolsets goes a bit too far—especially when those tools are already in Nixpkgs and setting up a base devShell provisioned with a few console tools is one of the easiest things to do with Nix the language already.
- ghuntley 3y ago
  i agree with some of your points but differ as follows: getting an entire team or project up and running in less than 5 mins with devenv is a fanstastic introduction for folks who do not have experience with nix. devenv solves the “onboarding new developer in a couple seconds without having to learn nix” pain point. the next step there is to migrate away from only using nix shell (via devenv) and go for making ci reproducible locally once folks are more comfortable with nix/less career risk for introducing new tech. then the world is your oyster. use build2dockerImage and start creating docker images that are reproducible and use them in production.
  - toastal 3y ago
    Getting someone up and running with a flake.nix with a defined devShell is just as simple and probably requires less knowledge since it's not another tool bolted on. Making the env and CI reproducible should be seen more like a good stepping stone and you can take the next leap when ready since it can all happen in the same flake file rather than a separate YAML one. The world is your oyster approach is skipping Docker and just running Nix on the server without the overhead of containers.
- Foxboron 3y ago
  > reproducible builds fwiw, NixOS does not support reproducible builds as defined by the Reproducible Builds project. They support reproducible environments/configuration/deployments or how you want to describe it.
  - ghuntley 3y ago
    1307 out of 1331 (98.20%) reproducible https://reproducible.nixos.org/nixos-iso-gnome-runtime/ https://reproducible.nixos.org/nixos-iso-gnome-runtime/ see also https://reproducible.nixos.org/ https://reproducible.nixos.org/
    - Foxboron 3y ago
      Yes, they are testing this for a fraction of their packages. It still amounts to less testing then what distros like Guix, Debian and Arch Linux is currently doing.

nittanymount 3y ago

planning to learn/use ansible, wonder if Nix is ready to use ? have most functions/features ?

throwaway6835-8 3y ago
Go with Ansible unless you want to fully dedicate into Nix ecosystem and spend a lot of time learning it (and it's not easy, for example because of lacking documentation). Also Ansible is something you more often find in actual projects/workplace.
- SuperSandro2000 3y ago
  well, yes true, but ansible sucks and especially for small and chaotic projects where people just change things on the machines without reflecting it in ansible it is a nightmare
  - totallywrong 3y ago
    You can hardly blame the tool for that, it's your process that's flawed.
  - throwaway6835-8 3y ago
    Why would anyone change anything on the machine if the machine is managed by Ansible?
SkyMarshal 3y ago
Try it out in a VM and see for yourself.
hamandcheese 3y ago
If you can adopt NixOS, then it's worth considering. But if you have to use a standard distro then Nix on its own won't solve your configuration-management problems. To sum it up succinctly, I would say that Nix helps you manage $PATH while NixOS helps you manage /etc.
3y ago

troupo 3y ago

> A lot of Nix documentation I’ve found says things like, “Simply add these lines!” > Huh? > Which file? And where in the file do I add those lines? This issue is prevalent everywhere. Even the best documented projects fail into this trap almost immediately.

rendaw 3y ago
And why, what do those lines mean
SuperSandro2000 3y ago
> Which file? And where in the file do I add those lines? /etc/nixos/configuration.nix if you haven't structured your config differently. > And where in the file do I add those lines? Consult `man configuration.nix` or search.nixos.org
kertoip_1 3y ago
That's why I like documentation with the comment section. Even if something's missing, there is a good chance someone asked about it. Also comments section provides an instant feedback to people writing posts to that documentation.
- troupo 3y ago
  While I wholeheartedly agree, you need a full-time moderation team if you want to enable comments.

lvncelot 3y ago

I'm a huge fan of Nix, and I'm glad to have stuck with the often times daunting process of getting into it - and I have to agree with the author's point regarding the documentation. That's not a fault of the people who actually did sit down and document their process, or distill their learning path into a tutorial - I myself understand it well enough to use it, but not well enough to really explain it without confusing people even more, but it's still a pity that finding good, exhaustive documentation for Nix is really difficult. Another pitfall is the usage of flakes, which, on the one hand are (imho) great, recommended everywhere and often times even assumed to be used implicitly, but on the other hand are still experimental. I myself started using flakes not because of the promised benefit (although I did realize the benefit later on) but just because multiple tutorials I've read gave me the feeling that flakes were the de facto way to do Nix from now on - and mind you, that was in late 2020. I'm using Nix for setting up my work machine (Mac via nix-darwin), my private machines (NixOS), selfhosting that's not in my k8s (also NixOS), and some private projects (dependencies, ci, and containers) - where the issues I've described don't really bother me, but for professional projects, where I'd have to convince and/or instruct colleagues, Nix feels a bit too rough around the edges for me right now. Edit: I also think it's important to distinguish between Nix the technology (fantastic) and Nix the language (meh) - which is why I'm still itching to try out Guix[1], which is similar to Nix (the technology) in a lot of ways while using Guile[2] as a language. [1] https://guix.gnu.org/ https://guix.gnu.org/ [2] https://www.gnu.org/software/guile/ https://www.gnu.org/software/guile/

mteigers 3y ago
I'm curious if you have any pointers for whole Mac config with nix-darwin. This is something I've just started looking at and at the moment don't have much more than a nix-shell with some nice-to-haves. Any tips / tricks / guides are greatly appreciated.
- cormacrelf 3y ago
  Life’s short. Don’t waste it configuring nix-darwin.

hamandcheese 3y ago

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix. Nix is not fast because it is stateful. It is fast because it is functional and reproducible, which allows for caching without compromising correctness. I don't want to split hairs, but referentially transparent caching like this is not quite what I'd call state. Yes, there is some statefulness in system activation, but this is not what makes Nix Nix -- quite the opposite.

hardware2win 3y ago
Functional?
- globular-toast 3y ago
  Just in case: https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming
  - hardware2win 3y ago
    I mean how Nix uses FP?
    - maleldil 3y ago
      Did you read the entire comment? The core idea of functional programming is pure functions (given the same outputs, the output is always the same). Nix applies that to building systems.
      - hardware2win 3y ago
        Pure functions are just a concept that is used in FP world Yet, pure functions can "stand alone". You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them. So unless you want to sound fancy and trendy then why call Nix functional instead of side-effects free?

p-e-w 3y ago

I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?

seqizz 3y ago
Afaiu it's trying to become all. Nix is on core, you can get packages from nixpkgs / write your own definitions, use it on OS configurations via NixOS, use its built-in helpers to run your containers with it, make a whole CI and cache it with the help of Hydra etc.
- politelemon 3y ago
  That's confusing because NixOS also seems to be an operating system, looking at the blog post?
  - chpatrick 3y ago
    NixOS is just a super barebones distro where everything is configured with Nix. You can also use Nix on Ubuntu or some other distro.
    - SuperSandro2000 3y ago
      Bare bones as in by default you don't get much unless you turn it on
      - chpatrick 3y ago
        Right, it's just bash, Nix and systemd by default.
hamandcheese 3y ago
Most of the above. - Nix is a tool for building and installing software. - Nix is a language for expressing how to build a package. Nix-the-tool reads expressions defined in Nix-the-language to know what to do. At the end of the day, this translates into normal commands that run in a sandboxed build environment. - Nixpkgs is a monolithic repository of 80000+ packages, defined literally as one giant expression in the Nix language (this works fine because Nix is an extremely lazy language). This also includes lots of helpers and abstractions for building packages that can be handy in your own projects. It is possible to use Nix-the-tool without Nixpkgs, but nobody does. - NixOS is a Linux distribution built on these foundations. Everything under /etc is built from nix expressions. You can not directly edit these. Mostly NixOS is about building systemd unit files from Nix expressions - viewed through that lens it's not really all that exotic of an OS. NixOS has modules that make it very easy to configure and run lots of software.

wesapien 3y ago

Does anyone have any ideas on what the most likely outcome would be for NixOS losing the S3 bucket funding?

throwawayqqq11 3y ago
You propably have to pull all your sources from github and compile them yourself once, since there is no remote store that provides prebuild artifacts? (I dont know what use the S3 bucket/s is for.)
seqizz 3y ago
As far as I remember there was enough money to keep them alive on current setting about a year. Worst case they'll switch to an alternative provider which _might_ be a bit slower?
WJW 3y ago
IMO, one of the budget storage companies (Backblaze, Storj, etc) and/or a CDN stepping up to support it out of their marketing budget.
mdaniel 3y ago
It seems to me that this "hash all the things" setup seems absolutely made for IPFS integration, which AIUI would mean that everyone who chooses to seed those nix stores would incrementally reduce the bandwidth burden upon the "main" nix store. I'm not sure if nix hashes take the $(uname -sm) into consideration, so that could be a hurdle, too I can very easily imagine that it would need to be opt-in, to keep security peeps from losing their minds, but my suspicion is that a non-zero number of actual nix users would choose to turn it on in support of the community
Cloudef 3y ago
Binary cache for old builds will be lost, they move to some other storage solution, but they can't transfer the binary caches due to AWS's egress costs.

deleted 3y ago

[deleted]

bouk 3y ago

If you want to install a package, search for it at https://search.nixos.org https://search.nixos.org The gnome system monitor is gnome.gnome-system-monitor for example https://search.nixos.org/packages?channel=23.05&show=gnome.gnome-system-monitor&from=0&size=50&sort=relevance&type=packages&query=System-monitor https://search.nixos.org/packages?channel=23.05&show=gnome.g...

drdaeman 3y ago
> If you want to install a package, search for it at https://search.nixos.org https://search.nixos.org And if this doesn't work, go to https://github.com/NixOS/nixpkgs/issues https://github.com/NixOS/nixpkgs/issues and search for the name (in both open and closed issues and PRs).
mtlynch 3y ago
Oh, thanks! That's super clear and fills a huge gap in my understanding how to use Nix. It sure beats my previous method of finding packages, which was just blind guessing. I've updated the post to include the correct package name and how to find it.

FpUser 3y ago

I have shell script with bunch of common functions to simplify particular tasks and then main script that when ran installs all needed packages, creates / copies various config files, pulls my C++ code from repo and builds my servers and installs those as daemons. It also installs cron jobs that execute backups / replication. It is smart enough to skip already performed steps and can safely run multiple times. It can run on Debian, Ubuntu, Arch and Mint. It is fast and reliable and can deploy new infra and or restore state of that from backup. I use it for years without any problems.

colordrops 3y ago
That is awesome and I'm glad it works for you. Nix does a lot of other things as well, and also has a large package repo and community around it.
SuperSandro2000 3y ago
Let me interrupt that in the middle and undo some steps by hand and it will probably fall on its nose. Nix can handle interruption in the middle of all build steps and can cleanly recover from them.

CapsAdmin 3y ago

I feel a little lost on nixos. Been using it for a while now on my main personal desktop and it's fine, but whenever I want to do something like running a python project (ml based ones for example), or compile software from source, I'm lost because I don't know what I'm doing. Most projects target Ubuntu, so I feel you need to know a lot about how nix really works to get them compiling, which is often not what I'm in the mood for tinkering with when I just want to test something. So in the end I end up using distrobox with Ubuntu which works surprisingly well, but feels very hacky as I'm supposed to try and use nix. The way I rationalize this is that I'll get rid of distrobox slowly over time as I learn how it works.

madjam002 3y ago
I've used Nix for 5 years now and use it heavily in production, and in my opinion, just do what works for you. If you try and use Nix 100% "correctly" then you'll end up like the countless other people who tried Nix and failed. Especially for toying around in dev environments, be pragmatic and take advantage of its amazing strengths, but if distrobox lets you enjoy using NixOS and speed up your workflow, so be it. Heck I'm spinning up some services in production just now and I'm reaching for Docker Compose as that's how the vendor officially supports deploying their software. Turns out NixOS can still bring some benefits to a Docker Compose workflow, deploying it via a systemd service, config managed in Nix, it's not as nice as building the service entirely in a Nix derivation and deploying it natively, but it's still better than without NixOS.
- dpatterbee 3y ago
  How are you managing docker compose with nix? Individual docker containers are easy to manage with `oci-containers`, but there's no obvious way for compose. Unless of course you're just writing the systemd configs in nix.
  - madjam002 3y ago
    Yeah I normally use oci-containers but for this workload the only supported method of installation is a `docker-compose.yaml` file. I've just written a systemd service that does `docker compose pull` and `docker compose up -d --remove-orphans` with the compose file being written to the Nix store, works well.

arminluschin 3y ago

I love how this is written. Very relatable, very approachable.

scandinavian 3y ago

Now that we have another Nix post, maybe someone can enlighten me about something I've been wondering about. I'm one of the maintainers of a popular django application. Someone made a nix package of the project, but we've now twice gotten invalid bug reports from people using the package because the package depends on "django_4" and whenever someone updates that nix package, the package for our project breaks. Of course we, like all other python projects, don't support using other dependency versions then the ones in the requirements.txt file. So when someone just uses a different minor version of django, stuff breaks. What's the disconnect here? Why does all nix packages that use django_4 need to use the same version, that seems super prone to breaking all kinds of stuff. Same for the other 35+ dependencies that run arbitrary versions instead of the ones defined in the requirements.txt file.

jacereda 3y ago
The answer today would probably be to use flakes: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
hamandcheese 3y ago
It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpkgs maintainers would allow all that extra duplication upstream.
- scandinavian 3y ago
  I get what you are saying, but nothing you said works in practice for python packages, so not sure that I actually learned anything. Is it fair to summize that python applications with python dependencies do not really work well as nix packages and shouldn't be used?
  - nrabulinski 3y ago

dottedmag 3y ago

> Using VS Code Remote SSH on NixOS systems This is the main of issue with Nix and other niche distributions: they are new operating systems, with their set of file layouts, package managers, and even syscall variations. Linux ecosystem is awfully fragmented. If you ever want to use any software outside of your not-very-well-walled-garden provided by distribution authors, you have to hope your operating system (that is, distro) is sufficiently similar to one of few distros software authors have built and QAed their software on. I have written at length about it here: https://dottedmag.net/blog/linux-is-not-os/ https://dottedmag.net/blog/linux-is-not-os/ I wish for a system that: 1. provides declarative configuration. 2. allows for easy local patching. 3. is ABI-compatible with a major distro. Alas. Fedora Bluesilver delivers 1 and 3. Gentoo provides 2. NixOS provides 1 and 3.

rowanG077 3y ago
I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.
- cosarara 3y ago
  Depending on what you are patching, it will invalidate a great part of the cache, and you will be looking at very long build times for everything in your system.
  - kaba0 3y ago
    If that dependency is deep in your dep tree and is statically linked somewhere than there is no way preventing that. If it’s only dynamic linking than yeah, it might happen that you need a huge recompile (but that is not that big of a problem nowadays in my experience - gentoo used to compile way longer in my subjective experience for example). Also note: nix will soon get content-based hashing which may solve this problem.
  - SuperSandro2000 3y ago
    For that reason many modules have options to set the packages used, so that you can eg. patch openssh without rebuilding everyone.

Jedd 3y ago

My experiences with Saltstack and Ansible are inverted - I realise the comparison was only a casual aside in TFA, but the 'Ansible executed the idea better than Saltstack' comment invites so many questions, especially in the context of an article that dwells on how unpleasant Ansible is. Ansible certainly defaults to slow, and I never got into the weeds for performance tuning it, but Saltstack felt fast, especially the example of 'install package foo' which he anticipated takes 15 minutes to run against one of his VMs using Ansible. I agree, that sounds unpleasant. Others have noted the slight confusion about state (and where that state is or should be maintained), and certainly writing idempotent salt or ansible recipes takes some thought, just as writing performant recipes does. The 'have to rewrite everything' whenever Ansible releases a new feature doesn't sound right - perhaps I misunderstand the problem described there. Author mentions apt, but ultimately sounds like they wanted something more container-y than a fat VM running a full GNU/Linux distro with managed packages + config files. In that light, the mention of Hashicorp - specifically Terraform & Nomad - felt tantalisingly prescient.

ryangibb 3y ago

> When does the determinism happen? > When I specified packages to install, I didn’t specify an integrity hash, let alone a version number. If I ran the same Nix configuration a year from now, I assume I’d get a different system because it would install different versions of the vim and curl packages I specified. That would be from the Nixpkgs [0] instance obtained from a Nix channel [1]. Nix flakes [2] provide an alterative way to specify inputs which pin them in a `flake.lock`. This allows things like Nix expression caching due to hermetic evaluation (as opposed to just builds being hermetic). [0] https://nixos.org/manual/nixpkgs/stable/ https://nixos.org/manual/nixpkgs/stable/ [1] https://nixos.org/manual/nix/stable/package-management/channels.html https://nixos.org/manual/nix/stable/package-management/chann... [2] https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake.html https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...

spacesuitman2 3y ago

>I see words like “flakes” and “derivations,” and I currently don’t know what they mean. >So far, I don’t get how it’s deterministic. To make nix deterministic you can specify a hash in non-flakes (or a git rev) for your dependencies, but flakes make this easier. When you "run" a flake (be it nix build, nix shell, nix develop), nix pulls the latest (if no explicit rev given in the flake.nix already) version of whatever is specified in flake.nix that it can find, and creates a `flake.lock` file that specifies the exact version that was used. This file is very similar to cargo's Cargo.lock, and specifies the exact version that was captured by ref/hash. The next time nix is "run", it uses the lock file to get the exact same version as it had previously. One can develop a flake.nix locally, install, check if everything works, and alternatively change the refs in the lock file to make everything work. When this is done you can move the nix and lock file to another machine and get the same exact build there (with the exception of architecture differences). Because you can put flake.nix and flake.lock inside of git, you can also share the exact same dependencies with other people using a repository. Whenever I see a repository using these I know that building will be a breeze because I don't have to do any dependency hunting.

skhm 3y ago
i've been using nix for a few years and i finally understand flakes now. thank you!

datadeft 3y ago

I am still waiting for a tool that compiles to a binary and that is run on the servers that I would like to manage.

SuperSandro2000 3y ago
You can just copy a build nixos system to a server and activate it there.

samsquire 3y ago

I use Replit a lot and it uses Nix. I think everybody has a different idea of what they find intuitive or what they think of as being "good". Some people struggle with git for example. As a tool writer (I wrote https://devops-pipeline.com https://devops-pipeline.com), I want (command line) tools to be elegant and the command line tools to be obvious.

deleted 3y ago

[deleted]

stayfrosty420 3y ago

Nix reminds me about that xkcd comic about standards. It seems to be to be solving a problem solved in a much better way by other alternatives with the mindset of IT from a bygone era. I may just not really be the target demo, or maybe am just a huge idiot, but I struggle to see the appeal, especially when you hear about the occasional horror stories about complex and/or broken environments, or the vim-like overhead to learn it properly.

kaba0 3y ago
No package manager before Nix solved the whole problem at all. Nix is the first of its kind. A good litmus test: install the gnome and the kde desktop envs on your linux system with your preferred package manager. Now remove both. Will you get back to a fresh install state? And it’s not even a hard problem yet. Now how would it solve installing a second chromium browser that uses a patched libc beneath?
SuperSandro2000 3y ago
I don't know of anything before nix comparable to it but I happily learn something new.
drdaeman 3y ago
> or the vim-like overhead to learn it properly. In my opinion, it's somewhat simpler than learning how to do Debian packaging properly (with emphasis on "properly", following all the modern best practices). Quite a lot of folks that run Nix or NixOS write themselves decent derivations that could be (and frequently are) contributed to nixpkgs (of course, there are a lot of quirks/hacks as well). But I think quite a few folks who run Debian make themselves high-quality packages - e.g. why bother setting up cowbuilder and do the proper repo for gbp with all the pristine-tar branch oddities, when checkinstall does the trick.
- stayfrosty420 3y ago
  Ah, I will concede I probably am just a huge idiot then. I suppose I don't often find myself needing to bootstrap a linux OS in this way.

wkdneidbwf 3y ago

the article goes from talking about nix to talking about issues installing nixos. anyone new to nix will be thrown off track reading this.

lloeki 3y ago

The problem the author hit with the Raspberry Pi is that the ARM image is meant for a standard environment (e.g UEFI ), like VMs. e.g it'll boot on Fusion or kvm because they provide UEFI, a well known device tree, and don't require any firmware at that stage. Pis (and many such ARM boards) don't have that so they won't be bootable. But there are Pi images built on Hydra. If one uses that then it boots right away. It's all documented in the Nix wiki. https://nixos.wiki/wiki/NixOS_on_ARM#Installation https://nixos.wiki/wiki/NixOS_on_ARM#Installation

mtlynch 3y ago
Author here. I'm working on a follow-up post specifically about NixOS on the Pi 4, but there are several gotchas to the process. The biggest issue I've run into is that the latest versions of the NixOS SD card images don't work on the Pi 4. You can boot to them, but when you run nixos-install, they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable. The link you shared declares itself to be out of date in several places, so it's not super helpful as a resource for newcomers.
- lloeki 3y ago
  > You can boot to them, That is the only part I wanted to draw attention to: ARM boot is a peculiar beast and very surprising when you don't know about it, especially when you're used to PC (BIOS or UEFI) booting. > but when you run nixos-install, If one intents to run from the SD card that was just booted then the process should be changing configuration.nix to one's liking and nixos-rebuild switch to that (which is a testament to the power of nix: one can pivot to an entirely new "install" on the spot). Or maybe you attempted to do an install on another block device, e.g to boot straight from USB? > they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable. Does that error also appear with nixos-rebuild switch? If so, then pi4 support is borked in nixos. Otherwise, assuming the install to USB process, maybe nixos-generate-config was run and produced a non-functional hardware-configuration.nix? (which would be a bug too) (it's been a while since I tried nixos on Pis, last time it did work OOTB for me on 3 and 4, save for a kernel / device tree bug for 3 that kills the virtual console) > outdated I agree, all the spread out bits are confusing. The ARM boot situation is common an issue enough that I would expect that to be part of the manual. > Author here. Thanks for the article, I enjoyed it!

jordanbeiber 3y ago

Biggest drawback of ansible is that it is stateless and as such you can’t simply declare a desired system state and apply it. Nix is absolutely awesome in that regard. Possibly this is Ansibles biggest strength as well, as it feels incredibly simple to get going. Salt has a much steeper learning curve due to both weird nomenclature and the infrastructure. Nix is in many ways easy to use “on the surface” but quickly becomes hairy as you dive deeper. Just my 2c having spent quite some time with all three.

ed25519FUUU 3y ago
Maybe I’m naive but I’ve just never found various “states” to be desired in config management. It’s always binary: either in the “right” state or a bad one!
- jordanbeiber 3y ago
  If you have drift in actual state using Ansible you have to account for all eventualities and you simply can’t declare “make my system(s) look like this”. I’m talking “desired state” here and how to fulfill it - not “various states to switch between”. With nix(os) I feel you treat a machine more like an appliance!

hdoehxoshs 3y ago

nix: automating running scripts from random readme.md as root. the amount of JavaScript devs just learning SE in this thread defending the maybe-good-enough-for-your-dev-box nix is so amusing. it's like seeing second year CS students thinking they mastered system programming because they wrote one toy compilet that optimizes one loop they were looking at the time. not saying it's bad. it's a very essential first step and everyone will step on this starting their journey, but the amount of misplaced self confidence is too funny looking from a more experienced vantage point.

reocha 3y ago
This is a pointless comment, nix is more than robust enough for servers, gaming machines, general purpose desktops and developer machines. If you don't understand the tech don't disparage the users or the tech.

totallywrong 3y ago

15 minutes to configure a local VM for development with Ansible? That feels very off. It used to take me about that long to set up a Kubernetes cluster on remote VMs from scratch (with etcd, load balancing, etc.). I haven't used it for a while though.

mtlynch 3y ago
This a bit like saying a 15-minute commute sounds "very off" because it only takes you 10 minutes to drive to your office. Ansible run times are going to vary wildly depending on what's in your playbooks and how fast your nodes are. In my case, a lot of my VMs share a set of common roles I've been developing over 8 years of using Ansible. The roles span several different OSes and versions, and every play adds time to the run, even if Ansible just skips it or has no action to take. And then third-party roles from Ansible Galaxy typically take even longer to run because they're not optimized for speed either, and they're targeting an even larger set of possible OSes.

xwowsersx 3y ago

Seeing a tweet like the one from Mitchell makes me want to try Nix. Or at least I want to want to try Nix. Then I read the comments here and am reminded that no one can even succinctly explain what Nix is. I've read dozens of comments here and I still don't have a clear idea!

hackernudes 3y ago
Your mind must be pure to understand Nix. Work on your purity. Just kidding. You might explain why you want to try nix? That would help customize an explanation for you, because there are levels. Umm... here is my attempt. Sorry. Nix is a programming language plus utilities that are useful to define and work with software packages in a reproducible way (https://github.com/nixos/nix/ https://github.com/nixos/nix/). Each package is called a "derivation", which is a function that takes inputs and makes output. The inputs are everything that is needed to make the output. It is "pure functional" package management - for the same input arguments, the same output will be produced. Nix is really fast because each derivation is hashed and cached and the language is lazy-evaluated. Builds are "hermetic", meaning only the inputs specified in the derivation are available at build time. Contrast this to some packaging systems, where the build is done against some staging area where packages get installed as they are built and the output can depend on the non-deterministic order that packages are built. Nixpkgs (https://github.com/nixos/nixpkgs/ https://github.com/nixos/nixpkgs/) is a large collection of recipes for existing software. It contains both rules to build software as well as "modules" to configure it or extend it. NixOS the linux distribution is also part of nixpkgs. There are lots of design patterns here and it can go pretty deep. There are also tons of hacks and patches and workarounds to make software conform to the way nix works. Nixpkgs also has a lot of useful library modules built in. Nix is the latin word for snow. Nix "flakes" are a way to combine multiple inputs as well as pin the version of inputs. Kind of like pipenv/requirements.txt or "cargo lock" or "yarn lock" but for anything. The output of derivations go in the "nix store" which is a path like /nix/store/<hash>/, so all sorts of software can co-exist (think multiple incompatible versions of the same library) and can be referenced in a fixed way. Usually you will end up with an output that is mostly symlinks to other /nix/store/ paths. Nix can make practically any combination of software you can cobble together trivially rebuildable/reproducible. You can write some nix code that will produce a a VM image with test scripts as well as a script to launch the VM with a patched version of qemu and run those tests. You can have all your dotfiles/configuration in code with nix installed just for your user on top of Ubuntu. You can generate a raspberry pi sd card image from a short nix source file and a single command, and then 6 months later change a single line and regenerate it without worrying it might be broken. You can achieve a lot of that stuff with Yocto or Ansible or a Dockerfile and scripts, but it would be slower than nix and more fragile.

lenova 3y ago

Coincidentally I came across Fleek this morning, which appears to be a simplified Nix abstraction? https://getfleek.dev/ https://getfleek.dev/

bketelsen 3y ago
(fleek author here) Fleek is a simplified wrapper around Nix Home-Manager, which is used to install and configure the apps that make up your $HOME and shell environment.
- lenova 3y ago
  This is what I love about Hacker News: post about a random tool I found, and the author shows up! :-) I came across your blog (and from that, Fleek) as I'm rebuilding my home WSL setup, and I just want a simple way to destroy and rebuild my distros and move my installed apps easily. Would Fleek be a good use-case for this?
  - bketelsen 3y ago
    very much so, that's how I use it. Especially if you want your dotfiles/configs to come with it.

totallywrong 3y ago

The problem Nix wants to solve is a valid one. But there are better alternatives imo, such as the newer distros based on rpm-ostree. You can do atomic upgrades, and easily rollback to a previous known good state if needed. No changes are allowed to a live system. And best of all, it's practically the same in terms of management, there's hardly any learning curve.

colordrops 3y ago
Sounds interesting. Is rpm-ostree config declarative? Can it install multiple versions of packages and libs simultaneously? Are adding custom packages to your setup a matter of a few lines of additional config, or must you learn RPM? Can you manage home directory config as well?
- totallywrong 3y ago
  There's the treefile [1] for declarative config, no need to learn RPM, just add package names and any extra config. As for managing home and multiple versions simultaneously, I think those are non-goals for this tool. [1] https://coreos.github.io/rpm-ostree/treefile https://coreos.github.io/rpm-ostree/treefile
  - colordrops 3y ago
    I meant creating an entirely new package from scratch. Regarding non-goals - I think that exposes the fundamental difference. rpm-ostree isn't "better". It's trying to solve different problems. The use case you described is a very small part of what Nix makes possible. Nix isn't just trying to fix or improve on existing systems - it present a fundamentally new abstraction that can be used for many purposes. Yes, you can configure and snapshot a list of packages, but that's a tiny part of it. With Nix, the capability allows you to also create any environment from scratch, isolated from other environments on your machine, e.g. for CI or development, or running some obscure python repo. It's like the difference between SVN and git.
    - 3y ago

kertoip_1 3y ago

That's funny, I've gone through almost exactly the same path trying to use NixOS. Tried on VirtualBox and failed. Tried on Raspberry Pi than failed. Didn't have spare bare metal, so I ended up on a "failed" state for now

0x69420 3y ago

> Nix optimizes for local configuration yes yes yes yes yes. nix makes deployment feel bottom-up, not top-down. you understand how a system is constructed locally before you (optionally, if it's in your job description) graduate to doing devops stuff with it. that was the singular thing that hooked me; the functional reproducible stateless referentially-transparent cacheable stuff was just what kept me on board.

drdaeman 3y ago
I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes is not exactly an OS, but is a notorious example), but they could make the same mess with any technology. They're just unlikely to pick Nix, NixOS or NixOps (or any alternative to it), because mainstream tutorials won't cover it [yet]. The deployment and learning process is not that different from, say, Arch Linux, or even Debian. You still learn the higher-level interactions (pacman/apt/nixos-rebuild), divert to individual programs, then dive in (.ebuild/dpkg-buildpackage/nix), then learn even finer details as you get hit with nuances. NixOS is absolutely not LFS, where you really go bottom-up. And nixpkgs is covering more and more every day. Just an anecdote example: I've started with run-of-the-mill tutorial approach on setting up NixOS on single machine, and ran than for a while. Then I've realized my configs are a non-DRY mess and I want to manage my systems in organized fashion, so I've spent a significant amount of time unifying the configurations so I could manage and deploy it with deploy-rs (thinking of switching to colmena now, but that's not relevant). And only at that point I've realized that I'm missing some fundamental bits like signing (aka why nix-copy may fail, and how to deal with this without the trusted-users "see-no-evil" hack), or exact operation of substituters (aka, essentially, binary caches). Because with local nixos-rebuild it's all sort of hidden and I never had any issues. What makes Nix/NixOS different are its fundamental principles, not how one approaches it. Starting somewhat more low-level than with "just works" tools is just a popularity issue: more rough edges, so one needs to learn how to polish them.
- 0x69420 3y ago
  well, an anecdote for an anecdote: reading the definitions of nixos modules became a matter of course for me when i started doing strange stuff that didn't quite fit into the authors' expectations, and those module definitions contain the implementation, i.e. exactly where files are placed and what's written to them. i learned things about how a distro is put together that i never had any reason to look into in the past. but i wasn't referring to how a system is put together at that level; i was referring to how a system is put together with the tool at hand, i.e. nix. and yes, you're right, that is top-down from the latter to the former > What makes Nix/NixOS different are its fundamental principles, not how one approaches it. you'll have no disagreement from me here; i was referring to what qualitatively hooked me, not making any statements about fundamental design

yencabulator 3y ago

> With Nix, changes are atomic. Nix either gets your system into the desired state or it rolls back to the state before you tried changing the configuration. Except the "activation script" is an imperative sequence of steps which can fail or hang. Atomicity really exists only if you `nixos-rebuild boot && systemctl reboot`, and there rollback means picking the previous entry from the boot menu.

pxc 3y ago

Great writeup of your first impressions! Looks like your questions are mostly answered, or at least you have starting points for most of them, so I'll leave those aside. Thanks for giving such a detailed writeup of your early experiences with Nix!

anarchogeek 3y ago

When i see a project uses Nix, i think, oh fuck me, they don't care about anybody using their stuff.