15 ms·

One Week of NixOS

247 points by jaemoe 6y ago

traceroute66 6y ago
Honestly, I have to say I'm in two minds about NixOS. Conceptually its a great idea, but I'm a bit worried about the possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity. Its a bit like messing around with the buzz-word-of-the-day Kubernetes compared to just getting the job done with a good old fashioned VM. Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Also, sometimes its nice to have the warm fuzzy feeling of using a software vendor's supported package build on a supported OS (e.g I'd rather run a package from the official Postgres repo then mess around getting Postgres working on NixOS).
- jaemoe 6y ago
  Yup! I see NixOS as an easy way to re-install easily my system when I get a new machine or just to sync easily packages between my laptop and desktop (so they almost have the same things installed on them). As for servers, I don't really see the point of nix as usually, pre-made and preinstalled images are already deployed. I think I'll still stick with Debian and all the usual software such as Docker for this usage.
  - ris 6y ago
    It's a shame to me how docker has come to be seen as "the usual software", as it's really just another layer of duck tape which uses OS features to pretend that arbitrary build processes are "reproducible" (when actually the way most Dockerfiles are written, they are most certainly not). As a result, working with docker images often needs special privileges which leads to complex situations involving docker-in-docker etc., which just shouldn't be necessary.
    - throwaway894345 6y ago
      Docker’s build process sucks, but that’s not the point of Docker—the point is that it’s a standard image format for containers which allows for orchestrators like Kubernetes to exist without caring about the internal details of any given container (e.g., what language it uses). It does pretty well in that regard, and you can even use Nix to build Docker images. Nix’s value proposition is reproducible builds, and while it does reproducibly build software, writing those definitions is incredibly hard (though the difficulty varies widely from package to package).
      - ris 6y ago
        No, I absolutely acknowledge the value of a "docker image" as, essentially, an interchange format. But it's also reached for as a solution for a whole heap of other things which are much better done in other ways.
        throwaway894345 6y ago
        Unfortunately today there aren’t many better options. Building images with Nix is great in theory (as Nix in general is great in theory), but it implies packaging one’s own app with Nix which is an enormous burden in most cases. There are other projects emerging that give us better image build systems than Docker, but none are well-tested at this point such that their tradeoffs are understood. This is a real pain point in the ecosystem, and it will be interesting to see how it resolves.
        ris 6y ago
        > packaging one’s own app with Nix which is an enormous burden in most cases I have not found this at all tbh.
        throwaway894345 6y ago
        I’ve tried this personally, and we attempted it as a team professionally and in both cases the juice was deemed not worth the squeeze. In particular, we were constantly packaging low-level transitive dependencies for C projects, and ultimately you had to not only know how to build your own package, but also any package for your entire dependency tree. If your dependency tree doesn’t involve any C dependencies (or if Nix definitions already exist for them) then you probably won’t run into so many issues (which is likely to be the case for Go, Haskell, etc—languages that don’t have a heavy emphasis on C dependencies and probably those that can be statically linked) but for Python, Node, etc you will probably have problems. None of this is to speak about the dearth of documentation or the difficulty using nixpkgs as a reference.
- swinglock 6y ago
  > Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Having used NixOS for more than a week, I have the same but opposite feeling. If you don't mind the hyperbole, NixOS is a solution, Salt and similar as a substitute is duct tape. :)
  - jsjohnst 6y ago
    Salt/Chef/Puppet/Ansible/etc are generally “good enough” tools and work for many needs, but over time cruft will inevitably happen (unless you frequently start from a clean base image). NixOS tries to avoid that by making it difficult to accidentally do a one-off outside your tooling and/or install things that unintentionally (or intentionally) stomp on other installed things in your system.
    - ris 6y ago
      Having worked with these tools, in comparison Salt/Chef/Puppet/Ansible are a collection of footcannons wrapped in the guise of a solution. The entire idea of trying to manage a fleet of stateful OS installations and stay on top of it all once it gains the slightest hint of complexity is a fallacy.
    - kohlerm 6y ago
      I used to manage the development environments of several hundred developers using Chef. It kind of worked, but would not very well support configuring files in the users home directory for example. Also setting up services locally needed for development (RabbitMQ, Tomcat etc) became much easier with Docker. I switched to Docker for that purpose, and most of the chef scripts became unnecessary. What the nixos package manager can easily solve is managing configuration files in the users-home (using home-manager), as well as installing different versions of different tools at the same time. You can even go as far as using direnv to automatically provide the tools (jdk, nodejs, gradle etc) when entering a given project just checked out from git. Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.
- diggan 6y ago
  I'm running NixOS in a VM, trying to evaluate if it's worth switching from Arch to NixOS before making the leap. > possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity In the end, I think all distributions ends up with similar layers of abstractions and complexity, mostly regarding packaging, but sometimes also other components. What I've found when using NixOS compared to Arch, is that if I screw up my Arch installation I either need to sacrifice my time to try to fix the screw up (which sometimes adds spending time just learning/reading about some concept I don't know about) or I need to recover from backups, so I can get back to work. With NixOS screw ups, I simply choose the previous version on boot and I'm "recovered". Leads to me getting back to what I was doing faster, but missing the opportunity to learn my own personal stack better. But not every moment needs to be "understand everything 100%", which in Arch-land, tends to happen, otherwise you continue to screw up. Although I'm still on the fence of upgrading to NixOS because the OS as an concept + it's own language is still not easy to learn, especially for more advanced usage, it's getting closer each day to just dump Arch and start using NixOS full time. Mostly because the reproducible nature of the OS.
  - jaemoe 6y ago
    I too was using Arch before and a friend convinced me to do the leap and I don't really regret it. One of the advantages is that packages just works on the contrary of the AUR where I had lots of problems for lots of packages that wouldn't just not build or work.
    - eepp 6y ago
      how do you break Arch so bad these days? last major issue I had was when everything moved from /bin to /usr/bin.
      - jaemoe 6y ago
        The issue wasn't the system broke, in fact, my system was doing pretty much alright. The problem was: in the AUR, lots of packages didn't built or launch, and even in the official repos, some packages were missing libraries or just not having the right versions. I was tired of tinkering to get everything to work as I wanted.
- exo762 6y ago
  > failures caused by adding the extra layer of abstraction and complexity I perceive nix as a tool that removes a layer of abstraction and complexity - the FHS. Having an app working is easy. Having multiple apps share the same FHS is complex because of conflicting requirements. Without FHS, there is no shared dependency resource thus no conflicts. Multiple applications are just as easy as a single application.
fiatjaf 6y ago
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.
- k__ 6y ago
  I don't think the problem is really complexity. It's just the config language. If you come from a Haskell background its nice, otherwise it's "arcane". Try Guix-SD.
  - sigzero 6y ago
    I am pretty sure moving from a DSL based on Haskell to Guile isn't a "step up" for most people.
  - fiatjaf 6y ago
    The language doesn't matter. It is actually very simple and nice (I read the manual, did the tutorial). You still have to learn all the thousands of obscure schemas each thing expects and supports. Could be written in JavaScript and you would still not know what is going on and would have to waste months in documentation and support forums. Or maybe the documentation is just very incomplete, I don't know.
  - patrec 6y ago
    Actually, unlike most DSLs, the nix language itself is pretty great and can be learned in an afternoon by any competent programmer, no Haskell background needed. The problem absolutely is complexity, and there is a lot of stuff you need to grok to be able to use nix productively in anger and sadly that includes a lot of stuff that really ought to be much more straightforward. Also, IMO you don't do anyone a favor by recommending they try Guix-SD over NixOS unless you also make it pretty clear that Guix is quite fringe even compared to Nix. For example Nix can and is being used for Real Work by well known companies. It as a steep learning curve but also, for certain tasks, an enormous payoff that justifies this effort.
danieka 6y ago
Any users of Guix here, and what is your experience? From what I understand it’s inspired by NixOS, but instead of the DSL for configuring packages Guix uses Guile.
- k__ 6y ago
  It's also free software, which is a pro for some and a con for others.
  - ris 6y ago
    Hold on there, let's not blur any definitions - Nix is also Free software, with the tools chiefly licensed as LGPL. The difference comes in the maintained software distribution, nixpkgs, being less strict in its package inclusion criteria than its guix equivalent.
    - k__ 6y ago
      Sorry, yes. That's what I wanted to say.
- ryukafalz 6y ago
  Guix is very nice, but suffers a bit from: - 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/ 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.
mschwaig 6y ago
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.
- dsissitka 6y ago
  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. [0] https://github.com/NixOS/nixpkgs/issues/9415 https://github.com/NixOS/nixpkgs/issues/9415
  - throwaway894345 6y ago
    Using Nix to write packages sucks, but I think the parent is talking about using it as a package manager (I.e., to install packages that others have written), which is usually a pretty good experience.
    - dsissitka 6y ago
      I was too. :) Those issues occurred when using Nix on Ubuntu 20.04.
      - throwaway894345 6y ago
Shoue 6y ago
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. [0]: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment... [1]: https://nixos.wiki/wiki/Steam#steam-run https://nixos.wiki/wiki/Steam#steam-run [2]: https://nixos.wiki/wiki/Steam#Adding_missing_dependencies https://nixos.wiki/wiki/Steam#Adding_missing_dependencies [3]: https://discourse.nixos.org/c/links/12 https://discourse.nixos.org/c/links/12
- jaemoe 6y ago
  I'll look into all of this! Thanks for the links!
hvdijk 6y ago
A small correction: > 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 6y ago
  I see, thanks for the message! I'll make a small correction. Edit: Correction published!
trzeci 6y ago
Still didn't get to chose between nix and silverlight
- danieldk 6y ago
  I think you mean Team Silverblue, right? They are very different, but lead to some of the same benefits. Silverblue largely follows the same system layout as traditional distributions (FHS, with packages in a global namespace). But compared to traditional distributions, it replaces the package manager with snapshots in a git-like store (OSTree). The system is immutable and provides atomic updates/rollbacks, like NixOS. They offer an mechanism on top of OSTree (rpm-ostree) to layer traditional RPMs from Yum/DNF repositories. To keep the base system lean and immutable, they encourage installing desktop applications through Flatpak and doing development through traditional, mutable containers through podman/toolbox. Silverblue is a bit strange in that it is in two worlds: on the one hand it touts the benefits of immutable systems, on the other hand it acknowledges that in their own setup, development is only really comfortable by also providing mutable systems through containers. NixOS is far less compromising than Silverblue. It chooses one model, functional package management, and that's the way of the highway (no FHS, immutable store, all packages live in their own directories in /nix/store). There are some small escape hatches like buildFHSUserEnv, but no major compromise as Silverblue has. Nix shares some benefits like atomic updates/rollbacks and an immutable system. But provides many others that Silverblue's model cannot easily provide (or has as the answer 'spin up another container'), such as permitting several different versions of packages in parallel, virtual environments (but for any package), etc. I think both approaches are very promising and not one is necessarily better than the other. Nix/NixOS' approach is more consistent and more powerful. However, Silverblue's pragmatic use and strong integration of containers, makes it much more familiar for most people. Also, much more software works out-of-the-box as a result.
hexo 6y ago
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.
- toyg 6y ago
  Damn, I was tempted by it some time ago and found it required way too much investment, so I thought “I’ll check back once they build enough stuff on top to make most of these tasks easily-manageable without being an expert”. But if it has not happened in 17 years, it probably never will...
  - Shoue 6y ago
    I'm not sure it's fair to say because it hasn't happened in the 17 years of NixOS' lifespan, that it never will, when the last 5 years of NixOS have been the most active by large: https://github.com/NixOS/nixpkgs/graphs/code-frequency https://github.com/NixOS/nixpkgs/graphs/code-frequency
    - danieldk 6y ago
      Also, there are some large recent initiatives to improve Nix and NixOS, such as Flakes (which give Nix package sets a standard layout and improves hermatic evaluation). Eelco Dolstra has also presented a proposal at NixCon 2020 to improve the module system's usability: https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s
- throwaway894345 6y ago
  Wait until you try to write your own package definitions. It’s a completely uphill battle, not least of all because nixpkgs is incredibly difficult to parse as a reference (no static types so good luck guessing what any given function takes for arguments, precious little documentation, no decipherable code organization, few if any direct imports to help you find dependency definitions, etc).
_query 6y ago
If you're interested in just the package manager Nix check out https://nix.dev/ 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 :)
- jaemoe 6y ago
  Seems interesting, thanks for the link!
rgoulter 6y ago
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.
- ianai 6y ago
  Sounds like a good OS for a computer cluster.
  - wwright 6y ago
    I think it’s interesting to compare it to Kubernetes. K8S has more functionality at the cluster level and a stronger ecosystem, but Nix has a much more well-founded “core”, IMO. Both are declarative by default and easy to reproduce. Hopefully we’ll see them converge in the future.
  - remify 6y ago
    It's how they used it at my old job. You could deploy nix with the libs needed for the compute part.
- abathur 6y ago
  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.
siraben 6y ago
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 nix-shell --run "python3 foo.py" -p "python3.withPackages (ps: with ps; [ numpy ])" 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 nix-shell --run "ghci" -p "haskellPackages.ghcWithPackages (ps: with ps; [ QuickCheck ])" 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 https://github.com/Shopify/comma [1] https://github.com/Lassulus/nix-autobahn https://github.com/Lassulus/nix-autobahn [2] https://github.com/nix-community/nixos-generators https://github.com/nix-community/nixos-generators [3] https://matthewbauer.us/blog/beginners-guide-to-cross.html https://matthewbauer.us/blog/beginners-guide-to-cross.html [4] https://github.com/NixOS/nixpkgs/ https://github.com/NixOS/nixpkgs/ [5] https://github.com/r-ryantm https://github.com/r-ryantm
- jaemoe 6y ago
  Seems really useful, thanks for the links!
- firethief 6y ago
  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: #!/usr/bin/env nix-shell #!nix-shell -i /bin/sh -p ffmpeg_4 lsdvd python3 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.
thomastjeffery 6y ago
My favorite feature of NixOS is cleanliness. 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.
- siraben 6y ago
  And even when you do screw things up, like accidentally deleting things in the Nix store, it's quite easy to recover as well.[0] [0] https://nixos.org/manual/nix/stable/#sec-nix-store https://nixos.org/manual/nix/stable/#sec-nix-store
- dietr1ch 6y ago
  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.
- stingraycharles 6y ago
  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.
  - 6y ago
emosenkis 6y ago
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.
- Ericson2314 6y ago
  > 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!
  - xyzzy_plugh 6y ago
    The pain I run into is that I very frequently need to use buildFHSUserEnv and it's just cumbersome enough that it's almost easier to not use Nix at all. It would be nice if there was a way to make this "just work". steam-run feels very hacky and I am loathe to use it in production, though I admit I've used it a lot. Rewriting the library paths for a given binary also works but is cumbersome. Ideally there would be a few extra tools in Nix to say "adopt this binary" in a similar way we can install things into our environment permanently, and to transform a binary to look for dependencies in the right places.
  - deleted 6y ago
    [deleted]
  - emosenkis 6y ago
    Neat. How long has that been around? I tried NixOS in mid-2016. I don't recall what package I was trying to use at the time (likely PlatformIO/Arduino or Rust ecosystems), but the only advice I remember finding was to run some utility to rewrite the paths embedded in the binary.
setheron 6y ago
I really recommend people try Nix first without the full blown OS if they are hesitant. 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.
- jaemoe 6y ago
  I didn't went into details since I'm relatively new to Nix. I'll make a follow-up in more time (some months) and go in more details!
  - setheron 6y ago
    Not a comment on your post but the NixOS ecosystem in general Probably should've used the word "dislike" instead of hate. Apologize. As someone whose been using Nix for almost a year (not NixOS as long) I struggle that there is zero advanced write ups. Could be because it's the same experience which is good news. But there's a series of advanced concepts that deserve more love: custom Nix cache, distributed building, remote deployments , NixOps, writing eloquent derivations, secret management (please!), how to sanely use vim_configurable etc... I spent a long time documenting the Maven (Java) documentation and recently had it approved.
philplckthun 6y ago
Nix is fantastic! 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.
- siraben 6y ago
  macOS + Nix user here. How is the experience of using nix-darwin? I haven't used it yet for fear of breakage (unlike in NixOS). I still have Homebrew but only for Casks, do you know if this too can be Nixified? > 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. This sounds interesting! Are your dotfiles public?
  - philplckthun 6y ago
    I haven’t really played around with installing browsers, etc via Nix on nix-darwin yet. The experience is really good for the most part! Setting it up initially is a little confusing since the installation has to create a volume for /nix, apart from that it’s really smooth. I choose to replace Nix channels with in-code tarballs of the nixpkgs repository. Sometimes that does confuse darwin-rebuild but it could also be because I’ve set it up slightly incorrectly. My Nix files are indeed open source! There’s a colour utility and a file that uses them to create theming files. https://github.com/kitten/nix-system/blob/master/config/colors.nix https://github.com/kitten/nix-system/blob/master/config/colo...
CyberShadow 6y ago
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). https://github.com/CyberShadow/aconfmgr https://github.com/CyberShadow/aconfmgr
k32 6y ago
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?
- setheron 6y ago
  To be fair, the packages have to be patched because many applications assume FHS. 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.
  - kris-s 6y ago
    What is FHS?
pstch 6y ago
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.
globular-toast 6y ago
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.
whateveracct 6y ago
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.)
Osiris 6y ago
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.
- kaba0 6y ago
  There is a global config and a user-specific one. So every user can install (without root) their set of packages and their PATH will be changed accordingly. You probably tried to add firefox to your local one - which should be good enough. I wouldn’t really want a program to auto-update the global configurarion.nix
root_axis 6y ago
My problem with nix is that it uses way too much memory when building. It's simply impossible to install certain packages if you don't have a lot of memory to work with.
domenkozar 6y ago
I'm working on Nix tutorials at https://nix.dev https://nix.dev - let me know what's missing :)
thewrinklyninja 6y ago
Has anyone used GUIX and can give a comparison? I think they are similar ideas but GUIX standardised on Scheme. https://guix.gnu.org/ https://guix.gnu.org/

247 points by jaemoe 6y ago

Honestly, I have to say I'm in two minds about NixOS. Conceptually its a great idea, but I'm a bit worried about the possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity. Its a bit like messing around with the buzz-word-of-the-day Kubernetes compared to just getting the job done with a good old fashioned VM. Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Also, sometimes its nice to have the warm fuzzy feeling of using a software vendor's supported package build on a supported OS (e.g I'd rather run a package from the official Postgres repo then mess around getting Postgres working on NixOS).

jaemoe 6y ago
Yup! I see NixOS as an easy way to re-install easily my system when I get a new machine or just to sync easily packages between my laptop and desktop (so they almost have the same things installed on them). As for servers, I don't really see the point of nix as usually, pre-made and preinstalled images are already deployed. I think I'll still stick with Debian and all the usual software such as Docker for this usage.
- ris 6y ago
  It's a shame to me how docker has come to be seen as "the usual software", as it's really just another layer of duck tape which uses OS features to pretend that arbitrary build processes are "reproducible" (when actually the way most Dockerfiles are written, they are most certainly not). As a result, working with docker images often needs special privileges which leads to complex situations involving docker-in-docker etc., which just shouldn't be necessary.
  - throwaway894345 6y ago
    Docker’s build process sucks, but that’s not the point of Docker—the point is that it’s a standard image format for containers which allows for orchestrators like Kubernetes to exist without caring about the internal details of any given container (e.g., what language it uses). It does pretty well in that regard, and you can even use Nix to build Docker images. Nix’s value proposition is reproducible builds, and while it does reproducibly build software, writing those definitions is incredibly hard (though the difficulty varies widely from package to package).
    - ris 6y ago
      No, I absolutely acknowledge the value of a "docker image" as, essentially, an interchange format. But it's also reached for as a solution for a whole heap of other things which are much better done in other ways.
      - throwaway894345 6y ago
        Unfortunately today there aren’t many better options. Building images with Nix is great in theory (as Nix in general is great in theory), but it implies packaging one’s own app with Nix which is an enormous burden in most cases. There are other projects emerging that give us better image build systems than Docker, but none are well-tested at this point such that their tradeoffs are understood. This is a real pain point in the ecosystem, and it will be interesting to see how it resolves.
        ris 6y ago
        > packaging one’s own app with Nix which is an enormous burden in most cases I have not found this at all tbh.
        throwaway894345 6y ago
        I’ve tried this personally, and we attempted it as a team professionally and in both cases the juice was deemed not worth the squeeze. In particular, we were constantly packaging low-level transitive dependencies for C projects, and ultimately you had to not only know how to build your own package, but also any package for your entire dependency tree. If your dependency tree doesn’t involve any C dependencies (or if Nix definitions already exist for them) then you probably won’t run into so many issues (which is likely to be the case for Go, Haskell, etc—languages that don’t have a heavy emphasis on C dependencies and probably those that can be statically linked) but for Python, Node, etc you will probably have problems. None of this is to speak about the dearth of documentation or the difficulty using nixpkgs as a reference.
swinglock 6y ago
> Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Having used NixOS for more than a week, I have the same but opposite feeling. If you don't mind the hyperbole, NixOS is a solution, Salt and similar as a substitute is duct tape. :)
- jsjohnst 6y ago
  Salt/Chef/Puppet/Ansible/etc are generally “good enough” tools and work for many needs, but over time cruft will inevitably happen (unless you frequently start from a clean base image). NixOS tries to avoid that by making it difficult to accidentally do a one-off outside your tooling and/or install things that unintentionally (or intentionally) stomp on other installed things in your system.
  - ris 6y ago
    Having worked with these tools, in comparison Salt/Chef/Puppet/Ansible are a collection of footcannons wrapped in the guise of a solution. The entire idea of trying to manage a fleet of stateful OS installations and stay on top of it all once it gains the slightest hint of complexity is a fallacy.
  - kohlerm 6y ago
    I used to manage the development environments of several hundred developers using Chef. It kind of worked, but would not very well support configuring files in the users home directory for example. Also setting up services locally needed for development (RabbitMQ, Tomcat etc) became much easier with Docker. I switched to Docker for that purpose, and most of the chef scripts became unnecessary. What the nixos package manager can easily solve is managing configuration files in the users-home (using home-manager), as well as installing different versions of different tools at the same time. You can even go as far as using direnv to automatically provide the tools (jdk, nodejs, gradle etc) when entering a given project just checked out from git. Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.
diggan 6y ago
I'm running NixOS in a VM, trying to evaluate if it's worth switching from Arch to NixOS before making the leap. > possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity In the end, I think all distributions ends up with similar layers of abstractions and complexity, mostly regarding packaging, but sometimes also other components. What I've found when using NixOS compared to Arch, is that if I screw up my Arch installation I either need to sacrifice my time to try to fix the screw up (which sometimes adds spending time just learning/reading about some concept I don't know about) or I need to recover from backups, so I can get back to work. With NixOS screw ups, I simply choose the previous version on boot and I'm "recovered". Leads to me getting back to what I was doing faster, but missing the opportunity to learn my own personal stack better. But not every moment needs to be "understand everything 100%", which in Arch-land, tends to happen, otherwise you continue to screw up. Although I'm still on the fence of upgrading to NixOS because the OS as an concept + it's own language is still not easy to learn, especially for more advanced usage, it's getting closer each day to just dump Arch and start using NixOS full time. Mostly because the reproducible nature of the OS.
- jaemoe 6y ago
  I too was using Arch before and a friend convinced me to do the leap and I don't really regret it. One of the advantages is that packages just works on the contrary of the AUR where I had lots of problems for lots of packages that wouldn't just not build or work.
  - eepp 6y ago
    how do you break Arch so bad these days? last major issue I had was when everything moved from /bin to /usr/bin.
    - jaemoe 6y ago
      The issue wasn't the system broke, in fact, my system was doing pretty much alright. The problem was: in the AUR, lots of packages didn't built or launch, and even in the official repos, some packages were missing libraries or just not having the right versions. I was tired of tinkering to get everything to work as I wanted.
exo762 6y ago
> failures caused by adding the extra layer of abstraction and complexity I perceive nix as a tool that removes a layer of abstraction and complexity - the FHS. Having an app working is easy. Having multiple apps share the same FHS is complex because of conflicting requirements. Without FHS, there is no shared dependency resource thus no conflicts. Multiple applications are just as easy as a single application.

fiatjaf 6y ago

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.

k__ 6y ago
I don't think the problem is really complexity. It's just the config language. If you come from a Haskell background its nice, otherwise it's "arcane". Try Guix-SD.
- sigzero 6y ago
  I am pretty sure moving from a DSL based on Haskell to Guile isn't a "step up" for most people.
- fiatjaf 6y ago
  The language doesn't matter. It is actually very simple and nice (I read the manual, did the tutorial). You still have to learn all the thousands of obscure schemas each thing expects and supports. Could be written in JavaScript and you would still not know what is going on and would have to waste months in documentation and support forums. Or maybe the documentation is just very incomplete, I don't know.
- patrec 6y ago
  Actually, unlike most DSLs, the nix language itself is pretty great and can be learned in an afternoon by any competent programmer, no Haskell background needed. The problem absolutely is complexity, and there is a lot of stuff you need to grok to be able to use nix productively in anger and sadly that includes a lot of stuff that really ought to be much more straightforward. Also, IMO you don't do anyone a favor by recommending they try Guix-SD over NixOS unless you also make it pretty clear that Guix is quite fringe even compared to Nix. For example Nix can and is being used for Real Work by well known companies. It as a steep learning curve but also, for certain tasks, an enormous payoff that justifies this effort.

danieka 6y ago

Any users of Guix here, and what is your experience? From what I understand it’s inspired by NixOS, but instead of the DSL for configuring packages Guix uses Guile.

k__ 6y ago
It's also free software, which is a pro for some and a con for others.
- ris 6y ago
  Hold on there, let's not blur any definitions - Nix is also Free software, with the tools chiefly licensed as LGPL. The difference comes in the maintained software distribution, nixpkgs, being less strict in its package inclusion criteria than its guix equivalent.
  - k__ 6y ago
    Sorry, yes. That's what I wanted to say.
ryukafalz 6y ago
Guix is very nice, but suffers a bit from: - 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/ 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.

mschwaig 6y ago

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.

dsissitka 6y ago
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. [0] https://github.com/NixOS/nixpkgs/issues/9415 https://github.com/NixOS/nixpkgs/issues/9415
- throwaway894345 6y ago
  Using Nix to write packages sucks, but I think the parent is talking about using it as a package manager (I.e., to install packages that others have written), which is usually a pretty good experience.
  - dsissitka 6y ago
    I was too. :) Those issues occurred when using Nix on Ubuntu 20.04.
    - throwaway894345 6y ago

Shoue 6y ago

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. [0]: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment... [1]: https://nixos.wiki/wiki/Steam#steam-run https://nixos.wiki/wiki/Steam#steam-run [2]: https://nixos.wiki/wiki/Steam#Adding_missing_dependencies https://nixos.wiki/wiki/Steam#Adding_missing_dependencies [3]: https://discourse.nixos.org/c/links/12 https://discourse.nixos.org/c/links/12

jaemoe 6y ago
I'll look into all of this! Thanks for the links!

hvdijk 6y ago

A small correction: > 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 6y ago
I see, thanks for the message! I'll make a small correction. Edit: Correction published!

trzeci 6y ago

Still didn't get to chose between nix and silverlight

danieldk 6y ago
I think you mean Team Silverblue, right? They are very different, but lead to some of the same benefits. Silverblue largely follows the same system layout as traditional distributions (FHS, with packages in a global namespace). But compared to traditional distributions, it replaces the package manager with snapshots in a git-like store (OSTree). The system is immutable and provides atomic updates/rollbacks, like NixOS. They offer an mechanism on top of OSTree (rpm-ostree) to layer traditional RPMs from Yum/DNF repositories. To keep the base system lean and immutable, they encourage installing desktop applications through Flatpak and doing development through traditional, mutable containers through podman/toolbox. Silverblue is a bit strange in that it is in two worlds: on the one hand it touts the benefits of immutable systems, on the other hand it acknowledges that in their own setup, development is only really comfortable by also providing mutable systems through containers. NixOS is far less compromising than Silverblue. It chooses one model, functional package management, and that's the way of the highway (no FHS, immutable store, all packages live in their own directories in /nix/store). There are some small escape hatches like buildFHSUserEnv, but no major compromise as Silverblue has. Nix shares some benefits like atomic updates/rollbacks and an immutable system. But provides many others that Silverblue's model cannot easily provide (or has as the answer 'spin up another container'), such as permitting several different versions of packages in parallel, virtual environments (but for any package), etc. I think both approaches are very promising and not one is necessarily better than the other. Nix/NixOS' approach is more consistent and more powerful. However, Silverblue's pragmatic use and strong integration of containers, makes it much more familiar for most people. Also, much more software works out-of-the-box as a result.

hexo 6y ago

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.

toyg 6y ago
Damn, I was tempted by it some time ago and found it required way too much investment, so I thought “I’ll check back once they build enough stuff on top to make most of these tasks easily-manageable without being an expert”. But if it has not happened in 17 years, it probably never will...
- Shoue 6y ago
  I'm not sure it's fair to say because it hasn't happened in the 17 years of NixOS' lifespan, that it never will, when the last 5 years of NixOS have been the most active by large: https://github.com/NixOS/nixpkgs/graphs/code-frequency https://github.com/NixOS/nixpkgs/graphs/code-frequency
  - danieldk 6y ago
    Also, there are some large recent initiatives to improve Nix and NixOS, such as Flakes (which give Nix package sets a standard layout and improves hermatic evaluation). Eelco Dolstra has also presented a proposal at NixCon 2020 to improve the module system's usability: https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s https://www.youtube.com/watch?v=7sQa04olUA0&t=1h24m18s
throwaway894345 6y ago
Wait until you try to write your own package definitions. It’s a completely uphill battle, not least of all because nixpkgs is incredibly difficult to parse as a reference (no static types so good luck guessing what any given function takes for arguments, precious little documentation, no decipherable code organization, few if any direct imports to help you find dependency definitions, etc).

_query 6y ago

If you're interested in just the package manager Nix check out https://nix.dev/ 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 :)

jaemoe 6y ago
Seems interesting, thanks for the link!

rgoulter 6y ago

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.

ianai 6y ago
Sounds like a good OS for a computer cluster.
- wwright 6y ago
  I think it’s interesting to compare it to Kubernetes. K8S has more functionality at the cluster level and a stronger ecosystem, but Nix has a much more well-founded “core”, IMO. Both are declarative by default and easy to reproduce. Hopefully we’ll see them converge in the future.
- remify 6y ago
  It's how they used it at my old job. You could deploy nix with the libs needed for the compute part.
abathur 6y ago
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.

siraben 6y ago

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 nix-shell --run "python3 foo.py" -p "python3.withPackages (ps: with ps; [ numpy ])" 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 nix-shell --run "ghci" -p "haskellPackages.ghcWithPackages (ps: with ps; [ QuickCheck ])" 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 https://github.com/Shopify/comma [1] https://github.com/Lassulus/nix-autobahn https://github.com/Lassulus/nix-autobahn [2] https://github.com/nix-community/nixos-generators https://github.com/nix-community/nixos-generators [3] https://matthewbauer.us/blog/beginners-guide-to-cross.html https://matthewbauer.us/blog/beginners-guide-to-cross.html [4] https://github.com/NixOS/nixpkgs/ https://github.com/NixOS/nixpkgs/ [5] https://github.com/r-ryantm https://github.com/r-ryantm

jaemoe 6y ago
Seems really useful, thanks for the links!
firethief 6y ago
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: #!/usr/bin/env nix-shell #!nix-shell -i /bin/sh -p ffmpeg_4 lsdvd python3 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.

thomastjeffery 6y ago

My favorite feature of NixOS is cleanliness. 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.

siraben 6y ago
And even when you do screw things up, like accidentally deleting things in the Nix store, it's quite easy to recover as well.[0] [0] https://nixos.org/manual/nix/stable/#sec-nix-store https://nixos.org/manual/nix/stable/#sec-nix-store
dietr1ch 6y ago
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.
stingraycharles 6y ago
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.
- 6y ago

emosenkis 6y ago

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.

Ericson2314 6y ago
> 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!
- xyzzy_plugh 6y ago
  The pain I run into is that I very frequently need to use buildFHSUserEnv and it's just cumbersome enough that it's almost easier to not use Nix at all. It would be nice if there was a way to make this "just work". steam-run feels very hacky and I am loathe to use it in production, though I admit I've used it a lot. Rewriting the library paths for a given binary also works but is cumbersome. Ideally there would be a few extra tools in Nix to say "adopt this binary" in a similar way we can install things into our environment permanently, and to transform a binary to look for dependencies in the right places.
- deleted 6y ago
  [deleted]
- emosenkis 6y ago
  Neat. How long has that been around? I tried NixOS in mid-2016. I don't recall what package I was trying to use at the time (likely PlatformIO/Arduino or Rust ecosystems), but the only advice I remember finding was to run some utility to rewrite the paths embedded in the binary.

setheron 6y ago

I really recommend people try Nix first without the full blown OS if they are hesitant. 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.

jaemoe 6y ago
I didn't went into details since I'm relatively new to Nix. I'll make a follow-up in more time (some months) and go in more details!
- setheron 6y ago
  Not a comment on your post but the NixOS ecosystem in general Probably should've used the word "dislike" instead of hate. Apologize. As someone whose been using Nix for almost a year (not NixOS as long) I struggle that there is zero advanced write ups. Could be because it's the same experience which is good news. But there's a series of advanced concepts that deserve more love: custom Nix cache, distributed building, remote deployments , NixOps, writing eloquent derivations, secret management (please!), how to sanely use vim_configurable etc... I spent a long time documenting the Maven (Java) documentation and recently had it approved.

philplckthun 6y ago

Nix is fantastic! 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.

siraben 6y ago
macOS + Nix user here. How is the experience of using nix-darwin? I haven't used it yet for fear of breakage (unlike in NixOS). I still have Homebrew but only for Casks, do you know if this too can be Nixified? > 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. This sounds interesting! Are your dotfiles public?
- philplckthun 6y ago
  I haven’t really played around with installing browsers, etc via Nix on nix-darwin yet. The experience is really good for the most part! Setting it up initially is a little confusing since the installation has to create a volume for /nix, apart from that it’s really smooth. I choose to replace Nix channels with in-code tarballs of the nixpkgs repository. Sometimes that does confuse darwin-rebuild but it could also be because I’ve set it up slightly incorrectly. My Nix files are indeed open source! There’s a colour utility and a file that uses them to create theming files. https://github.com/kitten/nix-system/blob/master/config/colors.nix https://github.com/kitten/nix-system/blob/master/config/colo...

CyberShadow 6y ago

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). https://github.com/CyberShadow/aconfmgr https://github.com/CyberShadow/aconfmgr

k32 6y ago

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?

setheron 6y ago
To be fair, the packages have to be patched because many applications assume FHS. 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.
- kris-s 6y ago
  What is FHS?

pstch 6y ago

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.

globular-toast 6y ago

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.

whateveracct 6y ago

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.)

Osiris 6y ago

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.

kaba0 6y ago
There is a global config and a user-specific one. So every user can install (without root) their set of packages and their PATH will be changed accordingly. You probably tried to add firefox to your local one - which should be good enough. I wouldn’t really want a program to auto-update the global configurarion.nix

root_axis 6y ago

My problem with nix is that it uses way too much memory when building. It's simply impossible to install certain packages if you don't have a lot of memory to work with.

domenkozar 6y ago

I'm working on Nix tutorials at https://nix.dev https://nix.dev - let me know what's missing :)

thewrinklyninja 6y ago

Has anyone used GUIX and can give a comparison? I think they are similar ideas but GUIX standardised on Scheme. https://guix.gnu.org/ https://guix.gnu.org/