Nix is a nice research project, but after playing with it for ~6 months and contributing to nix-packages, I came to conclusion that (in my case) it's not suitable for production nor development, and now I manage my personal machines with a simple Ansible playbook.
Main reason for leaving was that Nix package maintainers have to heavily patch all software. Packaging for nix is more like porting software to another operating system. Just check the amount of ad-hoc patches in nix-packages repo, and note that they have automated tools for patching the most common problems, so the problem is even worse. Now how about quality of these patches... I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much, because the original author of the derivations abandoned them.
Moreover, Nix breaks the chain of trust for the language packages. For example, Erlang and Elixir packages are signed cryptographically. Most erlang libraries come with a rebar.lock file containing hashes of the dependencies, so reproducible builds are already ensured. Unfortunately, package hashes are incompatible with Nix derivation SHA's, because they include some additional envelope data. What did Nix people do to work around this problem? They patched out the checks for rebar.lock files from the 3rd party Erlang build system. I would not dare to run a distro that contains patches like this in any kind of production environment.
Additionally, /nix directory is readable by all users, so you cannot use Nix to manage secrets, and there was no universally approved way of doing so (or at least it was the case at the time I was using it).
As for personal use... You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities, and to be honest, do you really need such degree of reproducibility for your very own dev machine?
As said by the other commenter, most of these patches are caused by NixOS not using the FHS (except for /usr/bin/env), which can be considered as a good thing in itself. In an ideal world, it would not be a problem (programs should not assume anything about the filesystem hierarchy, and should always use $PATH or their own environment variables).
The issue of integrating with other language ecosystems is indeed very problematic (and it's a very hard problem), especially with regards to the chain of trust (by the way, it's not completely broken, you can still read the original package hash in the derivation, and evaluate this derivation to get the Nix derivation hash), and with regards to the fact that including all of the packages of every ecosystem in `nixpkgs` is not doable.
There is also the (related) problem that evaluating a configuration implies evaluating `nixpkgs` itself, which requires a good amount of available memory, and this can only get worse as `nixpkgs` grows.
I maintain several Nix packages, and I agree that for some edge cases it can be a pain.
Another annoying thing is that NixPkgs has developed some technical debt, with some packages being perennially broken. Guix is smaller, but much cleaner in this regard. Julia can't be used in Nix, and many Bioconductor packages are broken.
However, I feel like the existence of FHSUserenvs needs to be better advertised and documented. These give you the ability to easily install unpatched software that assumes a regular (FHS) Unix filesystem layout (/bin, /lib...).
Still, I think the benefits of using Nix and NixOS surpass the drawbacks right now. I use Nix in dozens of machines. It is, along with Arch, my favorite distribution. Both sit at two local maxima of the design space. Declarative-functional and imperative with a minimal layer of tooling.
It's not. As far as I can tell, it's used heavily in some corporate environments once you're faced with solving the development environment dependency hell and you need something that actually solves your problem. (This is my story too.)
> ...and now I manage my personal machines with a simple Ansible playbook
Where Nix is used you typically don't have "personal machines". And having a separate guy just doing setups of developer environments is a huge overhead.
I have traditionally used ansible and I hate it and am slowly converting to nix tooling.
With ansible, I feel like everything is poorly solved and you need to weigh decisions about when to use various hashicorp products. Worse still if you use their plugins instead of just script substitutions you get stupid behavior like not being able to fix your configuration because it is broken, or turning off the supposed advantage of these plugins such that they are almost as good as sed again.
> Main reason for leaving was that Nix package maintainers have to heavily patch all software.
Any widely used distros do this. Plus, the statement that you have to patch all packages is false. In many cases, all you have to do is set the right build flags and environment variables, which is handled by standard helpers in nixpkgs.
I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
> Packaging for nix is more like porting software to another operating system.
Dramatic, but again, simply not the case.
> note that they have automated tools for patching the most common problems, so the problem is even worse.
This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
> I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much
All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
> Moreover, Nix breaks the chain of trust for the language packages.
After a quick look, it seems like you can still use the unmodified erlang package manager? The patched version you've mentioned seems to be there for facilitating creation of Nix packages and it looks like the main intent was to remove the ability to download packages from the internet. If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
> /nix directory is readable by all users, so you cannot use Nix to manage secrets
Why not store secrets in a private location, just like you would on any other distros??? What is it that other distros have that Nix is missing? I'm not seeing your point here.
With that being said, note that this feature is being worked on, and systemd very recently introduced a new feature for secrets management [1].
> You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities
Matbe take a look at buildFHSEnv.
> do you really need such degree of reproducibility for your very own dev machine?
Yes, it saves me from having to do a clean install of my system every few months. I haven't done a clean install at all the last few years since I started using NixOS.
Agreed, the language support situation is a very mixed one in nixpkgs, where support ranges from rudimentary (or even non-existing) to well integrated and supported. Particularly the Erlang/Elixir situation is - as you already brought up a while ago[1] - very rudimentary and really needs to be improved.
Right now, I do manage my Erlang dependencies with Nix only and without using rebar/mix (particularly since I do want full release upgrades with hot code reloading), but manually managing those dependencies certainly doesn't scale well for all projects, especially if they already use rebar/mix.
I also haven't looked into newer projects like nix-elixir[2], but as another commenter here mentioned, there are typically tools available to convert between the language-specific package managers, but they all come with their
own set of issues and tradeoffs (eg. duplicating dependency information or importing from other derivations at evaluation time) so they might not be suitable for your project.
The situation with secrets is a long lasting issue[3] with several attempts of solving, but so far the best practice is to just to either leave secrets out of the Nix store or just make sure the entire Nix store is not accessible.
Since I also use NixOS for a few days, I can imagine why it could be frustrating if things don't work out of the box like on other distros. Having had my own adventures patching things like no tomorrow, I know sometimes the effort to do this could be quite time consuming, especially the GOG games[4] you mention.
So I'd say if you frequently use software that is problematic on NixOS and don't want to go through the hoops of patching or making workarounds like eg. Docker or FHS user environments[5], I'd probably stay off NixOS.
Personally however I think it is worth going through a few hoops, since to me it shifts the frustration of "my system broke during an update" to "just want to get X to work NOW" and among other nice benefits (eg. bisecting
whole systems, rollbacks and/or using specific packages before they broke) I'd rather prefer a working and reproducible system.
I use NixOS for the same reason. Cleanliness is empowering.
I used to have diskless machines on my network set up the non-nix way: system directories full of tftp and pxe stuff; root directories constructed by an OS's installation procedure, and then customized somehow to work with an nfsroot. Later on, I wanted to make some changes but had no idea how. I hadn't taken enough notes of where everything came from and what it was doing. The files were still working, but without having documented their intent, I had to scrap it all. But documenting intent is laborious and fragile; you have to include enough detail that future you (or someone else) can follow your logic, and worse: keep all that in sync with the reality.
Since then I have fully committed to the Nix way. Now, the contents of my tftproot are built according to a declaration in my configuration.nix: the root directory in my TFTP configuration specifies a dependency on a PXE package, with some configuration applied. Not only don't I have to look through the built directories and try to remember what everything is, I never think about the built directories. The insight of declarative configuration is: if you fully document your intent, the system can take care of realizing it.
When I want to change a program I have written, I edit the source code (where all the intent is) and recompile it. NixOS is that for systems. I will no sooner go back to mutation-based system management than start changing my programs by taking a hex editor to the binary.
I've been using NixOS with home-manager and it's been a really nice experience because of this.
Now I can keep my desktop and laptop pretty much in sync by just tracking 2 small git repos instead of having a log/script of all the config tweaks on /etc that I needed to do on random files.
And it gets better over time, more projects are supporting Nix, and there's exciting things being worked on, like IPFS support for the store, and Flakes to get proper reproducibility.
On the other hand, getting some apps to work can be a bit of a pain with NixOS. Especially binaries and/or Steam games, things running through Wine can be a pain because standard libraries are in non-standard locations.
What I ended up doing since about a year or so is just make my whole root partition something I can generate with Debian debootstrap + chroot. I have a +- 250 LOC bash script which I just invoke on a free partition, and it just completely reinstalls Debian in there as if it were a Docker container.
I then rerun this about once every month, reboot, switch to the new partition (and fall back to the old one in case things went wrong, which almost never happens) and I couldn’t be happier with it. Happy middle ground.
My experience with Nix and NixPkgs is that 95% of the time it's fine. That 5% is a real PITA.
I think nix isn't as useful for developers using it to setup their workstation compared to for operations setting up deployment environments. -- I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this. (The up-to-date versions thing is nice). -- Maybe this will be more compelling for stuff like GitHub Codespaces, and other ephemeral machines?
(EDIT: and nix-shell is cool and very pure, but looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.).
NixOS itself does feel very different to other OSs. I think people discount how much trouble they run into on other OSs. Partly because other OSs have larger communities, and advice will often apply across multiple OSs. With NixOS, there's a higher requirement for understanding of what's going on; and it's not obvious that the benefit from doing this is worth it.
On the contrary, I find it super helpful to set up my workstation. I don’t use any other package manager on macOS these days, everything is Nix, fully declarative with a small script that basically does `nix-env --install` (but with the flags to replace my current environment wholly, and with some helpers around showing what changed). I can then just sync my config between my machines and run my script and get identical setups on every machine I use, and I can update all of my packages at once just by running `nix channel --update` followed by invoking my script again.
And there’s a bunch of utilities I use rarely so I don’t even keep them installed, since I know I can just `nix run nixpkgs.hello -c hello` if I ever want to run them.
And then for a work project I set up a custom derivation that I can use when I need to run the occasional scripts that require the custom ruby and python environment, so I can just run e.g. `nix run nixpkgs.my.env -c pod install`. This way I’m not even polluting my global environment with this stuff the way the work scripts expect. And I’m currently working on formalizing this into Nix derivations in the work repo directly (in an attempt to convince my coworkers that we should all use Nix).
> I think nix isn't as useful for developers using it to setup their workstation
Trust me, if your development setup is non-trivial (bunch of services maybe in different languages maybe written by different teams) it absolutely is, and is one of the areas where you can get the biggest productivity wins by using nix.
In my experience, how good of a time you’ll have developing in Nix is incredibly tied to what you program in. Last time I tried Ruby was a real nightmare, and I never did manage to get Ruby on Rails to work correctly.
I agree with most of this, but wanted to comment on the "developer environment" part. TL;DR: I feel like you're under-valuing this part?
> I think nix isn't as useful for developers using it to setup their workstation [...] I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this.
This might be idiomatic to me (i.e., the devices I use; how; my level of anxiety; etc.) but I have (historically) found OS reinstalls and system moves disruptive.
Over time, the work, documents, downloads, config changes, cruft, old apps and such on a system all congeal into a big blob of system state. To move with confidence, I ended up with a few choices: 1) have the old system runnable as a reference so that I can jump but have it as a reference every time I encounter something that's missing or misconfigured, 2) manually inventory everything on the system to triage what needs to be carried forward and what is crap, 3) copy everything on the system and pretend I'll take the time to do number #2 later (ha! in reality I'll just accumulate multiple nested copies stretching back decades!)
Adopting Nix enabled me to declare my personal essentials, and per-project essentials. This got me close enough to confident I can quickly prepare a fresh device that it motivated me to close most of the remaining gaps on macOS. Instead of feeling like it'd take me days+ to get back to full productivity on a clean device, I know I just need an hour or two.
This confidence liberates me from lot of gnawing everyday anxieties about (i.e., infinite permutations of how inconvenient it would be to lose my system at [already stressful moment where I'm under pressure to deliver something]).
> looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.
I used to be in the VM (virtualbox + vagrant/chef/shell) camp. I was net-happier with that than single-system state and things like virtualenv, but on a laptop I'm not very keen on the extra resource use and performance penalty, and over time I still found one shift or another (virtualbox/vagrant updates, chef cookbook updates, VM image updates, or a VM image that stops publishing) created a fairly regular drumbeat of unexpected, low-leverage debug time.
If you are interested in Nix but don't know too much about it, let me tell you one thing:
You can use the package manager to package, build and install software and to take advantage of their large package repo and features like nix-shell without using the OS. What the OS gives you is a full system and all of its services managed exclusively with the paradigms of the package manager.
I do run NixOS on all four of my machines and I got in OS-first package manager second. At first, like the author, I also frequently needed escape hatches like other machines or VMs, but I think if you get into the package manager first you're probably less likely to get stuck. Depending on what you want to do you get a lot of the good stuff with much less commitment that way.
You can but unless you use NixOS the experience might not be great.
A few months ago I tried migrating my development environment from Ansible to Nix. My playbooks are basically in alphabetical order and so that meant starting with Alacritty. I immediately hit two issues:
- A conflict between the version of fontconfig the package was compiled with and the version of fontconfig installed on my system.
- Nix's OpenGL problem. [0]
They're easy enough to work around but I wonder how big the list would've gotten if I hadn't stopped there.
I've been using it for 9 months on laptop. I really love the idea. But had to ditch it and use ubuntu instead, because it routinely turned a 3-minutes-long-operation into 6 hours. I had to do work, not mess with configuration and read 6 A4 pages worth of text only to install some python package.
I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it.
Don't get me wrong, NixOS is 17 years old and it still feels like alpha version.
> There, we are installing per-user packages because yes, NixOS supports that, any user can have its own packages that others users can’t access.
Other users can access those packages if they want to. Those packages won't show up in other users' $PATH, so other users will not be affected by them, but they could see what's in /nix/store if they wanted to. This matters when you're thinking of putting private data (such as an encryption key) in a package: it's vital that you don't do that on a multi-user system.
I've tried many times. I read the entire manual. I would love to use Nix.
But it's too complex.
I guess that's the result of them trying to do everything an OS does using their new arcane Nix language. I don't know how else this could be accomplished though -- but I hope there is another way.
I find it weird often I would find files written in the Nix language in minified/unreadable way fashion in parts of the system.
It's a sympton of the complexity of everything that for every weird error that I would find I would search the internet and not find a person with the same problem. It's always something slightly different and then the solutions proposed to that person would made no sense to me at all or they would introduce much more complexity.
I’ve started using it with nix-darwin on macOS and replacing various dot files tools and loosely coupled files and installed dependencies using Homebrew with clear and declarative Nix scripts has really changed how I manage my development environment.
I even went as far as coding up colour scheme configurations to synchronise colours between Kitty, Tmux, and Neovim, and added some configs to compile Neovim from source to get to some of its newer features, and I don’t think I would’ve done any of that (or rather, kept any of that around) without Nix.
You can configure NPM to install "global" packages to your user directory, and similarly PIP has `--user`.
Usually, the nuclear option to installing something on NixOS that just isn't playing along (e.g. Steam and its games) is to use buildFHSUserEnv[0] which sandboxes the directory structure you're used to on other Linux systems. Of course, this means you'll be writing a bit of Nix code – if you're lucky, steam-run[1] makes software run instead, and you could probably hackily add missing libraries[2] otherwise needed, to steam-run (just remember that this is a nuclear option and not recommended because you're moving away from NixOS purity, but it does exist).
Also, I suggest posting this to the NixOS links section[3] if you want more Nix users' eyes on this.
If you use Arch Linux, you can get some of the advantages of NixOS using aconfmgr. It maintains the property that if something is not in the configuration file, it's not on the system; but, it builds upon that in that it still allows you to mutate the system (using e.g. a package manager) and later transcribe those edits to the configuration (or revert them).
There are lots of things to be said about Nix and NixOS, and many of these things have been mentionned in this page, but there's one thing I really like with Nix : the fact the the configuration is expressed as a function that takes its own result as argument, and that the final configuration is the fixed point of that function. This is a very powerful concept, as these functions can be composed together.
I think this idea is not specific to Nix, and I wish it was used a lot more in configuration languages. For example, it was something I really missed when using Ansible. The lack of this feature means that writing the inventory is much harder than it needs to be, and I've seen horrible hacks that try to get around this.
I tried NixOS out for a while on my laptop. I loved the idea of an immutable system with all the config in one place. The implementation, though, was really a terrible user experience. I got past the weird config language, made a few contributions to Nixpkgs to get the packages I wanted, etc. The deal-breaker for me was the inability to run third-party binaries due to the departure from standard directory structure. After all the frustrations with NixOS, I was motivated to go to the opposite extreme so I could stop spending time maintaining my system and focus instead on the tasks that I wanted to use my system for. I've been [mostly] happily running Ubuntu LTS releases ever since.
> The deal-breaker for me was the inability to run third-party binaries due to the departure from standard directory structure.
Did you know know we have FHS compat environments: buildFHSUserEnv?
This is our fallback solution for huge closed-source things like steam + its game games that we agree it doesn't make sense to repackage individually with patchelf.
I'm saying we agree and if we didn't have `buildFHSUserEnv` it would be a dealbreaker for many more than you. Please give it a shot, and us a second chance!
If you're interested in just the package manager Nix check out https://nix.dev/ It guides you to get a reproducible development environment up and running with nix. This way you can get all the goodies like `nix-shell -p nodejs` without switching your OS first :)
- Having less development effort than Nix involved in packaging; some packages end up broken/out of date as a result
- Its more "pure" packaging ethos (no bundled dependencies, all dependencies must themselves be packages for Guix, etc). I like this in theory but practically it makes packaging some applications (Go/Node ones especially) effectively impossible. Debian seems to have the same issue: https://lwn.net/SubscriberLink/835599/b4de94c924ae4463/
- The build farm often doesn't have substitutes available for certain packages, which tend to be precisely the ones that take ages to build on older hardware. Cue multi-hour IceCat builds
- There's not much documentation available on packaging beyond the trivial cases. Packaging many applications is pretty simple, but for the ones that aren't it's a bit of a guessing game and trying to read through definitions of other involved packages
All that aside... these are complaints that I have as a dedicated Guix user, and I've thoroughly enjoyed my time using Guix System. It's the first distro I've ever used that I haven't felt has gotten "polluted" after over a year of tinkering with it - I've installed (and uninstalled) multiple DEs, and I know I can trust the package manager to actually remove every single thing that was installed as part of that.
And it's really nice to use a distro whose entire configuration system and package definitions are written in a single language (Guile) - I've written a few simple package definitions myself and I think the fact that it's all written in the same language has made it easier to dive deeper into how the system works after having written a few packages.
I've been running guix on my systems for about two years now. I can comment.
Generally I love guix. As a tool its very ergonomic to use, the documentation is excellent, and the mailing lists are active and informative. As for specifics:
* The CLI is way better than nix's and each command is fully documented and flags are intuitive. `guix install foo` is a lot more intuitive than `nix-env -iA foo`. Nix is in the middle of overhauling its CLI but until that task is complete I personally believe there's no contest.
* Guix has a lot more first party functionality when it comes to importing packages for some languages. If someone's project is in python, ruby, haskell, or ocaml it only takes `guix import fooRepo package` to create a package that isn't yet in guix's package repository. Also this functionality is easily discoverable thanks to guix's excellent documentation. I wish this extended to nodejs projects but that's likely never going to happen.
* There are a number of built-in ways to share guix packages with people who aren't using guix with the command `guix pack`. This has come in handy for me in a number of situations like creating singularity containers for coworkers or trying out stuff they're working on in an isolated environment.
* Speaking of containers, `guix environment` lets me run software in ad-hoc containers.
Now, all of this is great but the desktop experience still leaves much to be desired. The desktop experience has all of the problems running NixOS has except the added trouble of Guix's immaturity. Gnome is only 3.34 while most distros have already migrated to 3.38. Guix has been a pain to run on my laptop, so much so that I've resigned to only use it as a package manager and DevOps tool.
I tried NixOS in a VM a while back and I found it pretty confusing. I liked the idea of having a configuration file that describes the packages installed in the system. The first thing I did was use the CLI to install Firefox, then I found that it didn't update my nix config, nor did there seem to be a CLI command to say "install this and add it to my config".
Instead, it seemed that I had to manually update the nix config. Then, I had to learn the syntax of the language. Then when I figured out the basic, I added Firefox, but it required me to add some parameters (I don't remember the specifics) but I couldn't find any explanation about what those should be for the Firefox package.
I don't understand why they don't have tooling (or didn't at the time) to update your nix config for you.
If they want to convert people over to their way of doing things they have to lower the barriers to entry substantially.
I have a suspicion that Nix will be my secret sauce for cross-platform Haskell gamedev. There's obviously a lot of work to do, but my plan is to solve problems instead of complain so I have a good feeling about reaching that mountaintop in the long-term (3-5 years.)
I installed Guix the other day as a potential new server installation. What attracted me initially was being able to declare the services available, like Ansible. Nix is a non-starter for me as an emacs user. You will never regret using a system based on a fully-fledged, general-purpose programming language like scheme as opposed to a domain-specific one.
So far I think it's brilliant. I didn't even know about the functional aspect but once I "got it" it makes me not wish to go back to a mutable system. I say this is a long time gentoo user. It won't replace my gentoo system any time soon, but it certainly has potential.
This is a good overview of NixOS however it's very limited and barely scratches the surface of what Nix can do. I consider it a complete replacement for the "reproducible environment" problem that some programming languages solve (e.g. Python's virtualenv, Haskell's cabal repl), among others.
A simple example of this is when I want to run a Python script from the internet, I can execute
See[0] for a way to run programs without even installing them by prefixing them with a comma, e.g. `, hello`. Or what about running any Linux ELF binary by automatically getting their shared dependencies at runtime[1]? Or generating bootable ISOs from your NixOS configuration[2], cross-compiling with little effort[3], and so on.
These problems have already been solved to varying degrees in other places, but Nix lets you unify them (think of the huge amounts of libraries downloaded by cargo, cabal, node and so on scattered amongst projects and your home folder, Nix stores everything in /nix/store/) into a single framework.
I'd like to also say that the Nixpkgs repository[4] is super easy to contribute to, just open a PR on GitHub as opposed to sending patches via mailing lists, which is checked via the CI. I'm not sure if there's something analogous on other package repositories but there's also a bot[5] that opens thousands of PRs updating and testing packages automatically.
Another way you can use nix-shell: with Nix, shell scripts can declare their dependencies. For a random example, I have a script that extracts chapter information from a DVD. Its shebang looks like this:
This is the equivalent of "#!/bin/sh", but with some package dependencies. Without nix, this script would implicitly require lsdvd to be available, increasing the complexity and fragility of system administration: if you scp the script to a different machine, the script is broken there until you install lsdvd. Even on one machine, you have to keep lsdvd installed (and remember what you have it for). Nix takes care of all that: when you run the nix-empowered script, it will make sure lsdvd is available in the script's environment. I keep an extremely minimal set of packages install system-wide (and nothing installed to my user environment), and declare dependencies in the places they're actually needed. I no longer think in terms of installed-or-not; everything is available.
[+] [-] k32|5 years ago|reply
Main reason for leaving was that Nix package maintainers have to heavily patch all software. Packaging for nix is more like porting software to another operating system. Just check the amount of ad-hoc patches in nix-packages repo, and note that they have automated tools for patching the most common problems, so the problem is even worse. Now how about quality of these patches... I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much, because the original author of the derivations abandoned them.
Moreover, Nix breaks the chain of trust for the language packages. For example, Erlang and Elixir packages are signed cryptographically. Most erlang libraries come with a rebar.lock file containing hashes of the dependencies, so reproducible builds are already ensured. Unfortunately, package hashes are incompatible with Nix derivation SHA's, because they include some additional envelope data. What did Nix people do to work around this problem? They patched out the checks for rebar.lock files from the 3rd party Erlang build system. I would not dare to run a distro that contains patches like this in any kind of production environment.
Additionally, /nix directory is readable by all users, so you cannot use Nix to manage secrets, and there was no universally approved way of doing so (or at least it was the case at the time I was using it).
As for personal use... You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities, and to be honest, do you really need such degree of reproducibility for your very own dev machine?
[+] [-] pstch|5 years ago|reply
The issue of integrating with other language ecosystems is indeed very problematic (and it's a very hard problem), especially with regards to the chain of trust (by the way, it's not completely broken, you can still read the original package hash in the derivation, and evaluate this derivation to get the Nix derivation hash), and with regards to the fact that including all of the packages of every ecosystem in `nixpkgs` is not doable.
There is also the (related) problem that evaluating a configuration implies evaluating `nixpkgs` itself, which requires a good amount of available memory, and this can only get worse as `nixpkgs` grows.
[+] [-] nextos|5 years ago|reply
Another annoying thing is that NixPkgs has developed some technical debt, with some packages being perennially broken. Guix is smaller, but much cleaner in this regard. Julia can't be used in Nix, and many Bioconductor packages are broken.
However, I feel like the existence of FHSUserenvs needs to be better advertised and documented. These give you the ability to easily install unpatched software that assumes a regular (FHS) Unix filesystem layout (/bin, /lib...).
Still, I think the benefits of using Nix and NixOS surpass the drawbacks right now. I use Nix in dozens of machines. It is, along with Arch, my favorite distribution. Both sit at two local maxima of the design space. Declarative-functional and imperative with a minimal layer of tooling.
[+] [-] setheron|5 years ago|reply
The fact that Nix ditches FHS is so what's appealing about it unfortunately there's a huge body of work that assumes it.
Most of the patches though are making libraries or binaries fully referenced from nix store rather than from the PATH or some other implicit state.
[+] [-] otabdeveloper4|5 years ago|reply
It's not. As far as I can tell, it's used heavily in some corporate environments once you're faced with solving the development environment dependency hell and you need something that actually solves your problem. (This is my story too.)
> ...and now I manage my personal machines with a simple Ansible playbook
Where Nix is used you typically don't have "personal machines". And having a separate guy just doing setups of developer environments is a huge overhead.
[+] [-] foolmeonce|5 years ago|reply
With ansible, I feel like everything is poorly solved and you need to weigh decisions about when to use various hashicorp products. Worse still if you use their plugins instead of just script substitutions you get stupid behavior like not being able to fix your configuration because it is broken, or turning off the supposed advantage of these plugins such that they are almost as good as sed again.
[+] [-] Ericson2314|5 years ago|reply
But I do agree we need to deal with the language-based packaging situation much better. It's a long-standing project of mine to fix that.
[+] [-] carapace|5 years ago|reply
Oh ffs really? Yeah, that's the kind of hijinks that leave you scratching your head. Thanks for the head's up.
[+] [-] StreamBright|5 years ago|reply
[+] [-] soraminazuki|5 years ago|reply
Any widely used distros do this. Plus, the statement that you have to patch all packages is false. In many cases, all you have to do is set the right build flags and environment variables, which is handled by standard helpers in nixpkgs.
I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
> Packaging for nix is more like porting software to another operating system.
Dramatic, but again, simply not the case.
> note that they have automated tools for patching the most common problems, so the problem is even worse.
This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
> I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much
All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
> Moreover, Nix breaks the chain of trust for the language packages.
After a quick look, it seems like you can still use the unmodified erlang package manager? The patched version you've mentioned seems to be there for facilitating creation of Nix packages and it looks like the main intent was to remove the ability to download packages from the internet. If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
> /nix directory is readable by all users, so you cannot use Nix to manage secrets
Why not store secrets in a private location, just like you would on any other distros??? What is it that other distros have that Nix is missing? I'm not seeing your point here.
With that being said, note that this feature is being worked on, and systemd very recently introduced a new feature for secrets management [1].
> You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities
Matbe take a look at buildFHSEnv.
> do you really need such degree of reproducibility for your very own dev machine?
Yes, it saves me from having to do a clean install of my system every few months. I haven't done a clean install at all the last few years since I started using NixOS.
[1]: https://github.com/NixOS/rfcs/pull/59#issuecomment-624723733
[+] [-] aszlig|5 years ago|reply
Right now, I do manage my Erlang dependencies with Nix only and without using rebar/mix (particularly since I do want full release upgrades with hot code reloading), but manually managing those dependencies certainly doesn't scale well for all projects, especially if they already use rebar/mix.
I also haven't looked into newer projects like nix-elixir[2], but as another commenter here mentioned, there are typically tools available to convert between the language-specific package managers, but they all come with their own set of issues and tradeoffs (eg. duplicating dependency information or importing from other derivations at evaluation time) so they might not be suitable for your project.
The situation with secrets is a long lasting issue[3] with several attempts of solving, but so far the best practice is to just to either leave secrets out of the Nix store or just make sure the entire Nix store is not accessible.
Since I also use NixOS for a few days, I can imagine why it could be frustrating if things don't work out of the box like on other distros. Having had my own adventures patching things like no tomorrow, I know sometimes the effort to do this could be quite time consuming, especially the GOG games[4] you mention.
So I'd say if you frequently use software that is problematic on NixOS and don't want to go through the hoops of patching or making workarounds like eg. Docker or FHS user environments[5], I'd probably stay off NixOS.
Personally however I think it is worth going through a few hoops, since to me it shifts the frustration of "my system broke during an update" to "just want to get X to work NOW" and among other nice benefits (eg. bisecting whole systems, rollbacks and/or using specific packages before they broke) I'd rather prefer a working and reproducible system.
[1]: https://github.com/NixOS/nixpkgs/issues/53834
[2]: https://github.com/hauleth/nix-elixir
[3]: https://github.com/NixOS/nix/issues/8
[4]: https://github.com/openlab-aux/vuizvui/tree/0aa8064087b895d2...
[5]: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
[+] [-] thomastjeffery|5 years ago|reply
I never need to worry about a mess anywhere outside of `/home`. Ever.
Ever make a symlink to fix a broken package and forget about it?
Ever make a change to a config file and forget about it?
Ever update your system and find out something is broken, just to spend time repairing the problem?
All these things tend to add up over months and years. After a while, I usually end up reinstalling my distro to start fresh.
Never again.
[+] [-] firethief|5 years ago|reply
I used to have diskless machines on my network set up the non-nix way: system directories full of tftp and pxe stuff; root directories constructed by an OS's installation procedure, and then customized somehow to work with an nfsroot. Later on, I wanted to make some changes but had no idea how. I hadn't taken enough notes of where everything came from and what it was doing. The files were still working, but without having documented their intent, I had to scrap it all. But documenting intent is laborious and fragile; you have to include enough detail that future you (or someone else) can follow your logic, and worse: keep all that in sync with the reality.
Since then I have fully committed to the Nix way. Now, the contents of my tftproot are built according to a declaration in my configuration.nix: the root directory in my TFTP configuration specifies a dependency on a PXE package, with some configuration applied. Not only don't I have to look through the built directories and try to remember what everything is, I never think about the built directories. The insight of declarative configuration is: if you fully document your intent, the system can take care of realizing it.
When I want to change a program I have written, I edit the source code (where all the intent is) and recompile it. NixOS is that for systems. I will no sooner go back to mutation-based system management than start changing my programs by taking a hex editor to the binary.
[+] [-] dietr1ch|5 years ago|reply
And it gets better over time, more projects are supporting Nix, and there's exciting things being worked on, like IPFS support for the store, and Flakes to get proper reproducibility.
[+] [-] siraben|5 years ago|reply
[0] https://nixos.org/manual/nix/stable/#sec-nix-store
[+] [-] stingraycharles|5 years ago|reply
What I ended up doing since about a year or so is just make my whole root partition something I can generate with Debian debootstrap + chroot. I have a +- 250 LOC bash script which I just invoke on a free partition, and it just completely reinstalls Debian in there as if it were a Docker container.
I then rerun this about once every month, reboot, switch to the new partition (and fall back to the old one in case things went wrong, which almost never happens) and I couldn’t be happier with it. Happy middle ground.
[+] [-] rgoulter|5 years ago|reply
I think nix isn't as useful for developers using it to setup their workstation compared to for operations setting up deployment environments. -- I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this. (The up-to-date versions thing is nice). -- Maybe this will be more compelling for stuff like GitHub Codespaces, and other ephemeral machines?
(EDIT: and nix-shell is cool and very pure, but looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.).
NixOS itself does feel very different to other OSs. I think people discount how much trouble they run into on other OSs. Partly because other OSs have larger communities, and advice will often apply across multiple OSs. With NixOS, there's a higher requirement for understanding of what's going on; and it's not obvious that the benefit from doing this is worth it.
[+] [-] lilyball|5 years ago|reply
And there’s a bunch of utilities I use rarely so I don’t even keep them installed, since I know I can just `nix run nixpkgs.hello -c hello` if I ever want to run them.
And then for a work project I set up a custom derivation that I can use when I need to run the occasional scripts that require the custom ruby and python environment, so I can just run e.g. `nix run nixpkgs.my.env -c pod install`. This way I’m not even polluting my global environment with this stuff the way the work scripts expect. And I’m currently working on formalizing this into Nix derivations in the work repo directly (in an attempt to convince my coworkers that we should all use Nix).
[+] [-] patrec|5 years ago|reply
Trust me, if your development setup is non-trivial (bunch of services maybe in different languages maybe written by different teams) it absolutely is, and is one of the areas where you can get the biggest productivity wins by using nix.
[+] [-] ashtonkem|5 years ago|reply
[+] [-] ianai|5 years ago|reply
[+] [-] abathur|5 years ago|reply
> I think nix isn't as useful for developers using it to setup their workstation [...] I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this.
This might be idiomatic to me (i.e., the devices I use; how; my level of anxiety; etc.) but I have (historically) found OS reinstalls and system moves disruptive.
Over time, the work, documents, downloads, config changes, cruft, old apps and such on a system all congeal into a big blob of system state. To move with confidence, I ended up with a few choices: 1) have the old system runnable as a reference so that I can jump but have it as a reference every time I encounter something that's missing or misconfigured, 2) manually inventory everything on the system to triage what needs to be carried forward and what is crap, 3) copy everything on the system and pretend I'll take the time to do number #2 later (ha! in reality I'll just accumulate multiple nested copies stretching back decades!)
Adopting Nix enabled me to declare my personal essentials, and per-project essentials. This got me close enough to confident I can quickly prepare a fresh device that it motivated me to close most of the remaining gaps on macOS. Instead of feeling like it'd take me days+ to get back to full productivity on a clean device, I know I just need an hour or two.
This confidence liberates me from lot of gnawing everyday anxieties about (i.e., infinite permutations of how inconvenient it would be to lose my system at [already stressful moment where I'm under pressure to deliver something]).
> looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.
I used to be in the VM (virtualbox + vagrant/chef/shell) camp. I was net-happier with that than single-system state and things like virtualenv, but on a laptop I'm not very keen on the extra resource use and performance penalty, and over time I still found one shift or another (virtualbox/vagrant updates, chef cookbook updates, VM image updates, or a VM image that stops publishing) created a fairly regular drumbeat of unexpected, low-leverage debug time.
[+] [-] mschwaig|5 years ago|reply
You can use the package manager to package, build and install software and to take advantage of their large package repo and features like nix-shell without using the OS. What the OS gives you is a full system and all of its services managed exclusively with the paradigms of the package manager.
I do run NixOS on all four of my machines and I got in OS-first package manager second. At first, like the author, I also frequently needed escape hatches like other machines or VMs, but I think if you get into the package manager first you're probably less likely to get stuck. Depending on what you want to do you get a lot of the good stuff with much less commitment that way.
[+] [-] dsissitka|5 years ago|reply
A few months ago I tried migrating my development environment from Ansible to Nix. My playbooks are basically in alphabetical order and so that meant starting with Alacritty. I immediately hit two issues:
- A conflict between the version of fontconfig the package was compiled with and the version of fontconfig installed on my system.
- Nix's OpenGL problem. [0]
They're easy enough to work around but I wonder how big the list would've gotten if I hadn't stopped there.
[0] https://github.com/NixOS/nixpkgs/issues/9415
[+] [-] hexo|5 years ago|reply
I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it. Don't get me wrong, NixOS is 17 years old and it still feels like alpha version.
[+] [-] hvdijk|5 years ago|reply
> There, we are installing per-user packages because yes, NixOS supports that, any user can have its own packages that others users can’t access.
Other users can access those packages if they want to. Those packages won't show up in other users' $PATH, so other users will not be affected by them, but they could see what's in /nix/store if they wanted to. This matters when you're thinking of putting private data (such as an encryption key) in a package: it's vital that you don't do that on a multi-user system.
[+] [-] jaemoe|5 years ago|reply
Edit: Correction published!
[+] [-] fiatjaf|5 years ago|reply
But it's too complex.
I guess that's the result of them trying to do everything an OS does using their new arcane Nix language. I don't know how else this could be accomplished though -- but I hope there is another way.
I find it weird often I would find files written in the Nix language in minified/unreadable way fashion in parts of the system.
It's a sympton of the complexity of everything that for every weird error that I would find I would search the internet and not find a person with the same problem. It's always something slightly different and then the solutions proposed to that person would made no sense to me at all or they would introduce much more complexity.
[+] [-] philplckthun|5 years ago|reply
I’ve started using it with nix-darwin on macOS and replacing various dot files tools and loosely coupled files and installed dependencies using Homebrew with clear and declarative Nix scripts has really changed how I manage my development environment.
I even went as far as coding up colour scheme configurations to synchronise colours between Kitty, Tmux, and Neovim, and added some configs to compile Neovim from source to get to some of its newer features, and I don’t think I would’ve done any of that (or rather, kept any of that around) without Nix.
[+] [-] Shoue|5 years ago|reply
Usually, the nuclear option to installing something on NixOS that just isn't playing along (e.g. Steam and its games) is to use buildFHSUserEnv[0] which sandboxes the directory structure you're used to on other Linux systems. Of course, this means you'll be writing a bit of Nix code – if you're lucky, steam-run[1] makes software run instead, and you could probably hackily add missing libraries[2] otherwise needed, to steam-run (just remember that this is a nuclear option and not recommended because you're moving away from NixOS purity, but it does exist).
Also, I suggest posting this to the NixOS links section[3] if you want more Nix users' eyes on this.
[0]: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
[1]: https://nixos.wiki/wiki/Steam#steam-run
[2]: https://nixos.wiki/wiki/Steam#Adding_missing_dependencies
[3]: https://discourse.nixos.org/c/links/12
[+] [-] jaemoe|5 years ago|reply
[+] [-] CyberShadow|5 years ago|reply
https://github.com/CyberShadow/aconfmgr
[+] [-] pstch|5 years ago|reply
I think this idea is not specific to Nix, and I wish it was used a lot more in configuration languages. For example, it was something I really missed when using Ansible. The lack of this feature means that writing the inventory is much harder than it needs to be, and I've seen horrible hacks that try to get around this.
[+] [-] emosenkis|5 years ago|reply
[+] [-] Ericson2314|5 years ago|reply
Did you know know we have FHS compat environments: buildFHSUserEnv?
This is our fallback solution for huge closed-source things like steam + its game games that we agree it doesn't make sense to repackage individually with patchelf.
I'm saying we agree and if we didn't have `buildFHSUserEnv` it would be a dealbreaker for many more than you. Please give it a shot, and us a second chance!
[+] [-] _query|5 years ago|reply
[+] [-] jaemoe|5 years ago|reply
[+] [-] danieka|5 years ago|reply
From what I understand it’s inspired by NixOS, but instead of the DSL for configuring packages Guix uses Guile.
[+] [-] ryukafalz|5 years ago|reply
- Having less development effort than Nix involved in packaging; some packages end up broken/out of date as a result
- Its more "pure" packaging ethos (no bundled dependencies, all dependencies must themselves be packages for Guix, etc). I like this in theory but practically it makes packaging some applications (Go/Node ones especially) effectively impossible. Debian seems to have the same issue: https://lwn.net/SubscriberLink/835599/b4de94c924ae4463/
- The build farm often doesn't have substitutes available for certain packages, which tend to be precisely the ones that take ages to build on older hardware. Cue multi-hour IceCat builds
- There's not much documentation available on packaging beyond the trivial cases. Packaging many applications is pretty simple, but for the ones that aren't it's a bit of a guessing game and trying to read through definitions of other involved packages
All that aside... these are complaints that I have as a dedicated Guix user, and I've thoroughly enjoyed my time using Guix System. It's the first distro I've ever used that I haven't felt has gotten "polluted" after over a year of tinkering with it - I've installed (and uninstalled) multiple DEs, and I know I can trust the package manager to actually remove every single thing that was installed as part of that.
And it's really nice to use a distro whose entire configuration system and package definitions are written in a single language (Guile) - I've written a few simple package definitions myself and I think the fact that it's all written in the same language has made it easier to dive deeper into how the system works after having written a few packages.
[+] [-] uncletaco|5 years ago|reply
Generally I love guix. As a tool its very ergonomic to use, the documentation is excellent, and the mailing lists are active and informative. As for specifics:
* The CLI is way better than nix's and each command is fully documented and flags are intuitive. `guix install foo` is a lot more intuitive than `nix-env -iA foo`. Nix is in the middle of overhauling its CLI but until that task is complete I personally believe there's no contest.
* Guix has a lot more first party functionality when it comes to importing packages for some languages. If someone's project is in python, ruby, haskell, or ocaml it only takes `guix import fooRepo package` to create a package that isn't yet in guix's package repository. Also this functionality is easily discoverable thanks to guix's excellent documentation. I wish this extended to nodejs projects but that's likely never going to happen.
* There are a number of built-in ways to share guix packages with people who aren't using guix with the command `guix pack`. This has come in handy for me in a number of situations like creating singularity containers for coworkers or trying out stuff they're working on in an isolated environment.
* Speaking of containers, `guix environment` lets me run software in ad-hoc containers.
Now, all of this is great but the desktop experience still leaves much to be desired. The desktop experience has all of the problems running NixOS has except the added trouble of Guix's immaturity. Gnome is only 3.34 while most distros have already migrated to 3.38. Guix has been a pain to run on my laptop, so much so that I've resigned to only use it as a package manager and DevOps tool.
[+] [-] k__|5 years ago|reply
[+] [-] Osiris|5 years ago|reply
Instead, it seemed that I had to manually update the nix config. Then, I had to learn the syntax of the language. Then when I figured out the basic, I added Firefox, but it required me to add some parameters (I don't remember the specifics) but I couldn't find any explanation about what those should be for the Firefox package.
I don't understand why they don't have tooling (or didn't at the time) to update your nix config for you.
If they want to convert people over to their way of doing things they have to lower the barriers to entry substantially.
[+] [-] setheron|5 years ago|reply
I find for my laptop I get 90% utility that way in including user systemd services.
I love all the NixOS blog posts but I hate that they are always so surface level. NixOS feedback or writeups never go beyond this shallow level.
[+] [-] whateveracct|5 years ago|reply
[+] [-] globular-toast|5 years ago|reply
So far I think it's brilliant. I didn't even know about the functional aspect but once I "got it" it makes me not wish to go back to a mutable system. I say this is a long time gentoo user. It won't replace my gentoo system any time soon, but it certainly has potential.
[+] [-] siraben|5 years ago|reply
A simple example of this is when I want to run a Python script from the internet, I can execute
and now I'm in a shell where numpy is avaliable to the Python 3 interpreter. Or I could test the Haskell QuickCheck library and run See[0] for a way to run programs without even installing them by prefixing them with a comma, e.g. `, hello`. Or what about running any Linux ELF binary by automatically getting their shared dependencies at runtime[1]? Or generating bootable ISOs from your NixOS configuration[2], cross-compiling with little effort[3], and so on.These problems have already been solved to varying degrees in other places, but Nix lets you unify them (think of the huge amounts of libraries downloaded by cargo, cabal, node and so on scattered amongst projects and your home folder, Nix stores everything in /nix/store/) into a single framework.
I'd like to also say that the Nixpkgs repository[4] is super easy to contribute to, just open a PR on GitHub as opposed to sending patches via mailing lists, which is checked via the CI. I'm not sure if there's something analogous on other package repositories but there's also a bot[5] that opens thousands of PRs updating and testing packages automatically.
[0] https://github.com/Shopify/comma
[1] https://github.com/Lassulus/nix-autobahn
[2] https://github.com/nix-community/nixos-generators
[3] https://matthewbauer.us/blog/beginners-guide-to-cross.html
[4] https://github.com/NixOS/nixpkgs/
[5] https://github.com/r-ryantm
[+] [-] firethief|5 years ago|reply
[+] [-] jaemoe|5 years ago|reply
[+] [-] StreamBright|5 years ago|reply
[+] [-] thewrinklyninja|5 years ago|reply