16 ms·

Nix is the ultimate DevOps toolkit

383 points by rkrzr 6y ago

bennyp101 6y ago
As an aside, I've just started trying to move my laptop to NixOS this past week, so far it seems pretty nice. I have a Macbook as well, and I think I should be able to share the Nix stuff with that - which would be cool. As for the article, I hadn't actually considered using it as a replacement for Ansible etc - but I could see why it might work better. I could pin packages etc to the versions, and get the exact same thing each time - no guarentee with ansible etc that the apt repository hasn't been updated since the last install. I think the whole Nix thing is an interesting idea, and I like the ideas behind it, I haven't played enough with it yet to dare use it in production (or on my main desktop for that matter) but it is certainly a tempting idea.
- kevincox 6y ago
  I use NixOS on my laptop as well and like it. This is where the lack of polish hurts a little because desktop environments require a lot of polish to be wired up smoothly. That being said I use GNOME and the basics just work. But on the server is where I think Nix really shines today. The biggest thing for me is that every deploy is "clean" and can be rolled back. Systems like Ansible (and basically every other config management system) only modify the part of the system that they know about and mutate global state. This means that your service might just happen to work because of a library that just happens to be installed by another service, or even on that is still installed from a service that used to run on the system. Unless you excercise Perfect Constant Vigilance and update configs to delete things instead of just removing the config to install them your configs will soon be be broken and depend on the current state of the system. I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS. I wrote a blog post on each of server NixOS and desktop NixOS if you want more of my thoughts. https://kevincox.ca/2015/12/13/nixos-managed-system/ https://kevincox.ca/2015/12/13/nixos-managed-system/ https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/ https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/
  - Galanwe 6y ago
    > I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS. Having worked with puppet for a long time, I can relate. There is this false sense of confidence that everything is reproducible "because we had the discipline to never do manual changes and always use puppet" but in real life: - dependencies between resources are forgotten, it worked the first time because luck in the order in which resources were applied, but would fail in from scratch applies. - hidden dependencies that were not specified but it worked because an other resource was installed at the time. - hell, even a failed apply could have partially installed dependencies that would make subsequent applied work. - there's always _that time_ when you had to fix something in a hurry and manually installed a package which is now a potential hidden dependency for everything else.
- pwm 6y ago
  Re Macbook, if you fancy check out my home-manager config: https://github.com/pwm/nix-home https://github.com/pwm/nix-home The readme was/is more of a short note to myself than for users, nevertheless this is how i manage my entire home env on my mac and it works beautifully.
- takeda 6y ago
  Re: using nix in place of ansible/chef/puppet/salt etc. One of things that makes it far superior to these solutions, is that while many of them try to be declarative it still an iterative hack to emulate it. For example if you use your CM to install a package on the system, or create a file in /etc. If you remove that statement the file or package will still be there. In NixOS it will be as if it was never there. The reason for it is that the existing CM work by modifying current OS, while NixOS rebuilds the entire OS every time you make a change (thanks to cacheing that operation doesn't take as long as it would normally do). As for using things in production, I generally like things that are well established. So it took many years before I got the courage to propose it, but frankly I don't think it ever let me down. As I used it always act predictable, both the NixOS as well as build (as long as you pin down nixpkgs). The only thing to worry about is if the outside environment demands a change you better know how to do it. For example application works fine, suddenly you have higher traffic and things are crapping out and maybe you need to change some settings or there was a bug in one of your dependency and a new version isn't in nixpkgs. You better know how to do those things.
leetrout 6y ago
I am very much looking forward to trying Nix I just haven’t made the time. That being said the article jogged my memory on some related thoughts... If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/ https://www.aptly.info/ If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ https://asdf-vm.com/#/ It uses pyenv under the hood for Python management AFAIK.
- bennyp101 6y ago
  asdf is awesome and if you combine it with direnv you can just cd into your project and have the versions ready to go (You can do the same with nix and direnv asdf - althrough I havent got that far yet)
  - b0afc375b5 6y ago
    What's your use case for direnv? I've been using asdf and love it, but I'm not sure what to use direnv for. Is the purpose to replace .env files?
joseluisq 6y ago
My first time seeing Nix, very promising https://nixos.org/#asciinema-demo-cover https://nixos.org/#asciinema-demo-cover Definitely Nix deserves a try.
domenkozar 6y ago
I've written a few tutorials at https://nix.dev/ https://nix.dev/, more to come in following months :)
- mkingston 6y ago
  Hey thanks for those. I hadn't noticed them as a whole, but I'd stumbled across a few of them from search results, and now I open the site and realise it looks quite familiar!
  - domenkozar 6y ago
    Thanks. I'm looking for feedback on the content - in terms of problems with it and what's missing!
- atc 6y ago
  These are really useful. Thanks.
tarkin2 6y ago
I tried to learn before. But the docs made it incredibly hard. They went into excruciating detail of how it works. I still never made my own nix package. I’m wondering as a solo dev, who uses his personal machine, and two servers, if the hard work of learning it will pay off. But it definitely looks interesting.
- domenkozar 6y ago
  What kind of tutorial would you like to read?
  - tarkin2 6y ago
    Something more like “And now you can do this” rather than “And now you know how it works “. The docs for using nix as a package manager are decent. But the rest, less so. They’re a recursive rabbit hole of confusion.
    - elbear 6y ago
      I found useful this series of articles introducing Nix by using it with Haskell: https://github.com/Gabriel439/haskell-nix https://github.com/Gabriel439/haskell-nix I hope it helps.
  - JackC 6y ago
    My dream tutorial shows how to move from what I have to the new thing, because that teaches me what new ways of thinking I need to adopt. Like right now at work we have a small team making a website with docker-compose to specify the dev environment, pip-tools to pin python dependencies, and saltstack to deploy new state to bare metal in production. How exactly, command by command, would nix solve the same problems? What would change from my current solution? How would I think differently? How would my life get better? What parts wouldn't be solved and I'd have to keep some of the old stuff around? Those are the tutorials that convince me to switch, because they get me over the hump of not getting the new paradigm, and being afraid of the downsides I don't know about yet. It's tricky because it's pretty specific to how someone's currently solving problems, but maybe knowing what I'd optimally want can help with figuring out something doable. (This blog post didn't work for me because it was too vague. I already have old boring solutions for their python pain points, like pip-tools, so I can't take their assessment of how much better things can be on faith, and they don't show me the details of the new thing.)
tazjin 6y ago
There's a lot of unexplored potential of Nix in granular build systems and displacing systems like Bazel. If applied correctly, it lets smaller organisations get much of the benefit of Google-style monorepos but without as much maintenance overhead. Some friends and I have been experimenting with this for the last year over at https://tvl.fyi https://tvl.fyi (code etc. is linked at the page bottom). We've run into some issues with the current implementation of Nix, but stay tuned on that :)
supermatt 6y ago
I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be accessible, IMHO. I simply didnt have the patience to delve any deeper.
- domenkozar 6y ago
  Did you follow the language tutorial in the manual or something else?
  - supermatt 6y ago
    I would have followed the official manual. I see that you are putting together some tutorials, so I will definitely check those out.
- throwaway894345 6y ago
  I agree. I’ve spent person-weeks looking into Nix, and I still can’t get it to work beyond the most basic of use cases. A few weeks ago I spent an entire weekend on the Nix discord channel trying to get help to configure VSCode for Rust development, and we collectively couldn’t figure it out. Nix is a great idea, and it’s goals are ambitious, but I haven’t found it to be usable yet. Almost any time I try to do anything I get mired in a tar pit and I basically end up having to give up. I’ve learned lots of tools and technologies in my career, but Nix remains elusive.
  - domenkozar 6y ago
    Do you have some examples of that? Maybe a link to discord discussion?
  - pimeys 6y ago
    I did a month, diving directly into the deep end with flakes and all. I don't know, it really is hard in the beginning. Like, really hard. But eventually I got myself a setup I could use in my two laptops and workstation. A setup, that sets my home directory, all my programs and my custom desktop just the way I want. Everything is in the github repo, and installing with the flake will give me the exact experience I have in my other machines. I tend to use lots of custom tools and commands, that are really painful to install and setup for a new machine. With NixOS all of it is just one command away. But, I agree, it is REALLY HARD in the beginning to grasp things. Here's my configs if you want to see how I approached my own setup: https://github.com/pimeys/nixos https://github.com/pimeys/nixos
alrs 6y ago
The merges-straight-to-master give me the willies. https://botsin.space/@complainingaboutmastercommits https://botsin.space/@complainingaboutmastercommits
- domenkozar 6y ago
  We've grown a lot in last few years and haven't caught up with the policies. See https://github.com/NixOS/nixpkgs/issues/118661 https://github.com/NixOS/nixpkgs/issues/118661 for details. Note that those statistics are incorrect, but pushes to master still do happen.
  - adamcstephens 6y ago
    There have been controls in GitHub to prevent this for a few years now. It’s also been awful practice to do this for as long. While I have no skin in this game, my recommendation would be to immediately block all pushes to master from everyone.
- danieldk 6y ago
  Those counts seem to be wrong. Looking at the code, they seem to count the number of merge commits (commits with >1 parent). However, some nixpkgs committers also use GitHub's rebase merge option. This means the change went through a regular PR + review, but is merged without generating a merge commits. Secondly, some PRs have multiple commits, so even if everything is merged through a merge commit, the number of non-merge and merge commits may not be balanced.
- nonameiguess 6y ago
  It's not fair at all that this is presently the most downvoted comment. Like it or not, this is a real concern, even if the count is illusory. It's not just about humans seeing this, but automated risk assessment tools use this kind of thing as a metric and showing a bunch of commits straight to master can prevent enterprise and government adoption due to policy. Maybe that doesn't matter for you, but innovators ignoring these gigantic market segments is part of why enterprise and government software development remains so far behind the innovation curve because they can't trust the security of the development models and the largest customers are all stuck with effectively no choice but Redhat.
nuker 6y ago
Nice, but this is as far from devops as knitting. They covered CI, but there is CD, all the cloud stuff, containers, security and so on.
- detaro 6y ago
  "cloud stuff" and "containers" (which people also do manage using Nix) are not requirements for something to be DevOps.
  - nuker 6y ago
    Try telling it to any recruiter lol
    - fctorial 6y ago
      The problem "containers" solve does not exist in nix land. If all you've got is a hammer... Edit: removed "clouds"
      - detaro 6y ago
        Nix does not solve all problems clouds solve. But it can be a quite useful tool combined with them.
temptemptemp111 6y ago
I don't see how they've proven their extra levels of abstraction to be solving more problems than they will add. Focus on the basics. We can do everything with containers, basic init systems (without sytemD), snapshots, simplifying build systems, removing layers of abstraction, swarm mode, and a bit of custom glue & thinking...
candiddevmike 6y ago
The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.
- danieldk 6y ago
  The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. For me, the big benefit is that even though I have to read the upstream documentation, I can use the same syntax for everything and do not have to learn and use N different configuration file syntaxes.
  - whateveracct 6y ago
    And when you figure something out, you can abstract over patterns because Nix has functions!
- duijf 6y ago
  > Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern. Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine. You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code. Put those tools in your systemd service before launching your app, and you're good to go. (NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I haven't seen the final picture. I imagine it's lovely compared to what we had before) [1]: https://github.com/channable/vaultenv https://github.com/channable/vaultenv
pjmlp 6y ago
When those DevOps happen to work with GNU/Linux only.
- ruuda 6y ago
  We do manage a few tools for MacOS with Nix as well, but it’s only a select few things, not our full stack.
  - pjmlp 6y ago
    XServer has long stopped being relevant.
- domenkozar 6y ago
  There's Darwin support in Nix, but it needs to be polished: https://opencollective.com/nix-macos https://opencollective.com/nix-macos
  - pjmlp 6y ago
    macOS aren't servers for quite some time.
vindarel 6y ago
Obligatory link to its cousin: https://guix.gnu.org/ https://guix.gnu.org/ A package manager or a full distro. I use the package manager on top of Debian, it's great, it allows me to get recent package versions the most straightforward way (like the latest Emacs), in exchange of disk space (easily some GB before a `guix gc` cleanup).
- MayeulC 6y ago
  I've been running it on an older laptop to try it out. `guix pull` takes so much resources, it often takes a few hours to complete, even with binary substitutes. Documentation is a bit lacking, even though it has an excellent manual. How I am supposed to specify extra command line parameters to the kernel I boot in GRUB, for instance? Or specify multiboot targets? Get a "desktop" install without GDM? In the end, I went back to alpine on that machine. Secondly, to use it as a standalone package manager, I wish it didn't require root access, or allowed me to put it in an arbitrary directory. Guix could work as a nice substitute for conda or docker, especially when it comes to reproducibility. I also couldn't find a guix docker image.
  - snicker7 6y ago
    > I've been running it on an older laptop to try it out. `guix pull` takes so much resources, it often takes a few hours to complete, even with binary substitutes. This is being actively worked on! https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more-quickly/ https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more... > I wish it didn't require root access, or allowed me to put it in an arbitrary directory I believe `guix pack -RR guix` will do package a relocatable guix for you.
    - MayeulC 6y ago
      Thanks for both your replies! Looking forward to the first, and I'll look into the second. One of my goals would be so easily offload to a more powerful computer, even if it doesn't run guix. Edit: content-addressed guix stores delivery over a content-addressed network sounds interesting, it would be even better with rolling hashes (I think ostree/casync uses those). I dream of a yunohost-like operating system based on Guix :)
va1en0k 6y ago
Nix is slowly becoming a major point of contention. In some communities, it’s already scary to even hint that one dislikes it.
- ninjin 6y ago
  Blindly going after dissenters and/or alternative opinions is never a good thing, which communities would that be? In the ones that I frequent Nix is still a bit of a fringe phenomena reserved for nutters such as myself. From inside the Nix community it is from my perspective far more relaxed than most OS communities that I have been a part of over the last two decades.
  - va1en0k 6y ago
    It'd be probably easy to guess which communities I mean, but I'd rather not name names myself and hope someone supports me with a datapoint to offset my personal paranoia. Lately I encountered quite a lot of software - fringe and weird of course, but numerous enough - that went for having Nix as the only way to be deployed, typically with a "reproducible" script that doesn't work already after a year or two. As nix files make negative intuitive sense, not even in the smallest-scale bit-fiddling sense, so little intuitive sense that I cried once trying to just make it work - I look around for advice. One of "just take a couple of weeks to learn it, it's not that hard" is seen quickly enough, of course. It's a bit of pure loss from there: everyone who heard something like this knows that it's the moment to either invest fully or ignore and quietly move on and away. Confessing that you just don't think you'd find it in yourself to invest in it is almost a pure loss for one. However, since we're not in one of those communities, let me say why not. I'm as sure that the good idea of reproducible builds will be implemented soon enough with something intuitive, strongly-typed, easily debuggable/diagnostable and dev-friendly, as I'm sure that diesel cars will be obsolete soon enough not to even think about investing my time and money in them. Regardless of what the current usage says - e.g. in Germany one would make a mistake to follow its wisdom just a few years ago, in case of cars, I mean.
    - doyouhearu 6y ago
madjam002 6y ago
Has anyone explored CD tooling with Nix? And I don't mean the deployment of NixOS machines themselves (NixOps, deploy-rs, etc), I mean actually using Nix for deployment tooling and orchestrating deployments using the Nix language. I am yet to find any posts about this or any tools, but have had great success with a small hand rolled tool that essentially lets me decoratively describe cloud resources, parts of my application, deployment "end state", and run the tools required to materialise that (Terraform, nixos-rebuild, etc) similar to GitHub Actions. Hydra is distributed CI for nix-build but does not handle CD or is designed to handle jobs with side effects AFAIK. NixOS is great, but for me this is even more valuable, as I now have an introspect-able view of my entire deployed real estate, and can essentially `nix run ...` to deploy any part of my application in its entirety along with any dependencies.
- domenkozar 6y ago
  https://nix.dev/tutorials/deploying-nixos-using-terraform.html https://nix.dev/tutorials/deploying-nixos-using-terraform.ht... showcases how you can use terraform to provision things and Nix to describe the machine. There's also https://terranix.org/ https://terranix.org/ to configure Terraform using Nix.
- arianvanp 6y ago
  Maybe https://github.com/serokell/deploy-rs https://github.com/serokell/deploy-rs ? It's a generic deployment tool for Nix that also supports NixOS machines but can target any nix profile
- the_duke 6y ago
  In addition to the other comments, there is also nixops. [1] [1] https://github.com/NixOS/nixops https://github.com/NixOS/nixops
- ruuda 6y ago
  What we do at Channable is build our packages with Nix, push them to Cachix, and record the Nix store path. (CI does that automatically for release builds.) Then we use Ansible to declare that that is the store path that we want to realize on the appropriate servers. Our packages contain an "activate" script that updates symlinks in /usr/bin, or systemd units. Ansible calls this script after realizing the store paths. We have some functions written in Nix to help writing these activation scripts, and Nix makes it easy to import them from a Git repository, so we have it in one place and import it in all of our repos. We are now moving towards CD by automatically running Ansible in some cases.
mark_l_watson 6y ago
A few years ago I was interested in Nix to make handling multiple Haskell projects easier. I dipped my toe in the water by running NixOS in Virtualbox on my laptop. After a while I decided that improvements in stack were enough for my modest requirements, but NixOS was cool.
mitchmindtree 6y ago
Nix has a heavy learning curve and requires learning the language to feel comfortable. However, overcoming that hump is incredibly rewarding and allows for taming your system in a way that, for me at least, changed the way I look at composing software. At mindbuffer[1] we've started using it for our recent art installations. The big benefits for us are reproducibility, ease of deployment, and the ability to collaborate on the composition of the whole system. I.e. rather than sharing a README of how to install things one by one and hoping each of us has followed it correctly, we just work on the same set of config files via a git repo (like we would any other code) and can be sure we're all on the same page as a result. Very much looking forward to Nix 3.0 landing with all its UI improvements and flake support. It seems like these changes will go a long way to making Nix more accessible, and provide a smoother on-ramp to learning the language itself. https://mindbuffer.net/ https://mindbuffer.net/
- haolez 6y ago
  Where can I get info about Nix 3.0 new features?
mikepurvis 6y ago
A lot of this sounds familiar to me— I maintain a hodgepodge build tool/pipeline at my org whose current output is a monolithic mega-deb file which is becoming unwieldy on several fronts (storage, transfer, compression time). I'm really interested in the nix philosophy of separate paths and versioning by hash rather than number, but unfortunately my needs are quite specific, and not having actual experienced nix experts around is a barrier. The temptation right now is to roll our own solution which generates nix-style hash debs that otherwise cooperate with the larger Debian ecosystem we're already very familiar with, but I could probably be sold on giving nix itself a closer look if I could hear from folks (or get pointers to documentation) on a few key points: - What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? (think not just a nightly build, but builds corresponding to unmerged feature branches, etc) - Does the nix hash account for dependencies only changing the hash for ABI-impacting changes such as when a header file changes? Or does it change dependent hashes always? Or never? - I have an existing system for managing packaging metadata which I don't want to migrate from. How much trouble will I get into if I want to generate the metadata on the fly each time (as I currently do for my debs)? - How much pain is it to roll a nix package "by hand" (basically with the dpkg-deb equivalent tool rather than the dpkg-buildpackage equivalent tool)? - Nix isn't supported in Artifactory (RTFACT-19998 has been open since 2019). Nominally, I can use the dumb WebDAV option, but is that going to affect my user experience and/or will it be a maintenance headache? - What is the apt/nix interop story? I would likely need it to be bidirectional, so that my nix workspace could depend on system debs that I don't want to port over, but also potentially have "gateway" debs which able to do the opposite, of depending on the nix workspace from a deb shim, and installing/updating it in the postinst. I've researched all of these in the past at various points and had a lot of trouble finding clear, straight answers on them. I'd love to hear from other users or nix experts, though, who could help calm our fears on this.
- q3k 6y ago
  > What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? A Nix derivation (a.k.a. 'packaging unit') can be built from sources either fetched remotely, or from a local directory, or a combination of both; plus any other derivation that it depends on. Any version semantics come from how you implement them, abstracted and formalized in any way you want. Nix is a programming language, you are free to do what you want. > Does the nix hash account for dependencies only changing the hash for ABI-impacting changes such as when a header file changes? Or does it change dependent hashes always? Or never? By default, any change to any dependency will cause all dependent derivations to be rebuilt, and their hashes to also change. You can 'break' this by introducing stable ABI barriers preventing rebuilds and performing runtime loads of dependencies from .so (or whatever, executing some binaries from $PATH). This is for instance how my firefox can handle any OpenGL library that it can use at runtime, without having a firefox rebuilt for every possible GPU driver out there. > I have an existing system for managing packaging metadata which I don't want to migrate from. How much trouble will I get into if I want to generate the metadata on the fly each time (as I currently do for my debs)? You will have to generate nix source code, or importable nix source code, from that system, and pull that into your local nix source tree. All nix evaluation is done from purely defined locally available sources, or sources fetched from remote resources, but marked with some consistent hash. > How much pain is it to roll a nix package "by hand" (basically with the dpkg-deb equivalent tool rather than the dpkg-buildpackage equivalent tool)? Nix does not work this way. Nix derivations are a recipe on how to build a package, you have to specify that in one way or another so that Nix can perform the build for you, and reason about its status within a larger build graph. You can 'cheat' building derivations by eg. importing binary builds and only patching them up to work under Nix(OS), but generally you shouldn't. > Nix isn't supported in Artifactory (RTFACT-19998 has been open since 2019). Nominally, I can use the dumb WebDAV option, but is that going to affect my user experience and/or will it be a maintenance headache? You will need to run a Nix cache, that CI will push into and other consumers (all having a checkout of your nix definitions) will pull from instead of building everything from scratch themselves. > What is the apt/nix interop story? I would likely need it to be bidirectional, so that my nix workspace could depend on system debs that I don't want to port over, but also potentially have "gateway" debs which able to do the opposite, of depending on the nix workspace from a deb shim, and installing/updating it in the postinst. Not aware of anything out of the box. Nix builds only run on Nix (as they all need dependencies from /nix/store/..., and that is populated by Nix itself), so don't expect to easily run them on Debian as normal dpkgs without some disgusting home-rolled hacks. You could technically consume binary .debs from Debian within nix derivations (see previous point), but that's ugly. Generally, just install Nix on all your hosts.
root_axis 6y ago
I love nix as a concept, but in my experience it isn't practical on systems without a ton of memory. I regularly get build errors due to oom errors.
- kaba0 6y ago
  That’s strange, are you actually compiling packages or the evaluation itself ooms? Because if the former, you may help it by limiting concurrent builds.
  - raxi 6y ago
    Evaluating/compiling packages is not greedy. Memory is eaten by lazy evaluation of NixOS modules. It can be optimized, but it is not a low-hanging fruit. It is still waiting for its hero. I'd compare it with creating the V8 for JavaScript.
- trulyrandom 6y ago
  Yeah, it's clear that Nix has not been optimized to run on resource constrained devices. I run NixOS on a Raspberry Pi with 1GB of RAM and had to enable swap to prevent Nix from running into OOM situations. Any system with more memory than 1GB is usually fine in my experience though.
- ris 6y ago
  To run it on systems with low memory, I suggest performing any custom builds on a separate machine. In "normal" circumstances you don't generally have to do any builds at all - (almost?) everything should come from the binary cache. To be doing all these rebuilds it sounds like you're customizing packages, which is already something other distributions don't tend to let you do at all.
- taktoa 6y ago
  you're probably mistakenly using nix-env -i, rather than nix-env -iA
  - root_axis 6y ago
AzzieElbab 6y ago
I like nix, but it is hard as hell to switch to from yaml driven world. If the path was more gradual nix would see more adoption
- siraben 6y ago
  What systems are you referring to in the "YAML driven world"?
  - AzzieElbab 6y ago
    ansible, k8 - anything, circle, everting else
- ris 6y ago
  Y'know, Nix can generate json/yaml quite easily.
exdsq 6y ago
The language and documentation is pretty awful, however I use NixOS (and therefore Nix) on my work desktop and still absolutely love it. The ability to create reproducible builds, test out tools without installing them permanently, and roll the OS back if you break something is just excellent. For example I spent ages this morning trying to get a gRPC Rust environment working and battled the nix file for a good two hours but now it works I know it will always work and never have to do it again.
- bamboozled 6y ago
  Do you truly understand how it works though? I was similar. I loved my setup and it did mostly just "work" but I found it unnerving that eventually when it does break, I wouldn't know how to fix it.
  - exdsq 6y ago
    I have a very minimal nix.configuration, write very small shell.nix files, and try to only use things I know or understand. So I’m definitely only using 1% of Nix right now but I’m comfortable with it! Edit: I should clarify Nix is the build tool at work for Haskell and some of my colleagues are contributors so I know I can get help if stuck. I’m a noob though.
  - gmfawcett 6y ago
    What kind of breaks were you having that you couldn't simply roll back? Database upgrades, or something?
    - tnzm 6y ago
      The latest version of something failing to build. Like when the Tor project removes a Tor Browser package from its servers and `tor-browser-bin` hasn't yet been updated in nixpkgs.
    - camehere3saydis 6y ago
      Can't upgrade Deno from 1.3.3 to 1.8.3 by updating the sources and hashes in the derivation, as is normal procedure. `fetchFromGitHub` and friends fail to recursively fetch commits that are not visible from `HEAD` (`git clone` works), and I'm completely at a loss about how to debug this. This kind of breaks. For people like myself who already spend a lot of time debugging dependency and compatibility issues in less sound package ecosystems (scripting languages I'm looking at you), Nix alternates between enlightening and maddening. Which I like.
jpe90 6y ago
I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself from version "nix-2.3.10" to "nix-2.3.10-x86_64-unknown-linux-musl" because it saw that package's version string as a version bump. The suggestion in the github issue was to instead use an unofficial third party package for basic package management because this was a known, long-standing issue that is not likely to be fixed. https://github.com/NixOS/nixpkgs/issues/118481 https://github.com/NixOS/nixpkgs/issues/118481 The experience came across as a massive red flag and I decided not to pursue it further.
- siraben 6y ago
  FYI nix-env operations are atomic and can be rolled back instantly, including upgrades. $ nix-env --rollback > The suggestion in the github issue was to instead use an unofficial third party package for basic package management. Specifically the suggestion is referring to home-manager, which is community supported (being in nix-community) and is the recommended way to install packages rather than imperatively doing it with nix-env.
  - danieldk 6y ago
    the recommended way to install packages rather than imperatively doing it with nix-env The problem is: recommended by whom? The Nix Manual presents nix-env as the main way to install Nix packages. So, as long as the manual centers around nix-env, newcomers will try to use nix-env and get bitten by it. The same is true for the NixOS Manual, it suggests that people install packages with nix-env before talking about declarative package management. Also, I love home-manager, but it is perhaps too much for people who just want to dabble in Nix a bit. It would be nice if a simpler declarative way of managing packages was presented first. Perhaps surprisingly, another way is documented but it is deep in the nixpkgs manual: https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
jherdman 6y ago
We're using Nix packages at Precision Nutrition to manage our dev environments: https://github.com/PrecisionNutrition/pndev/ https://github.com/PrecisionNutrition/pndev/. It's been enormously successful. I highly recommend it.
cazim 6y ago
This reminds me -> https://xkcd.com/927/ https://xkcd.com/927/
- snicker7 6y ago
  That link needs to be blocklisted from HN.
- takeda 6y ago
  I don't think this is relevant. It's not a new standard is a complete paradigm shift. Some tools might need to be used slightly different, others might no longer be needed. Because it requires change the way you think about things is why so many people have problem with getting into it.
quyse 6y ago
I participate in development of the cross-platform indie video game written in C++ called Insatia [1]. We switched our CI server to building almost all the binaries using Nix. With Nix we have proper Clang with libc++/etc for latest C++ features, cross-compiling Clang (for building Windows binaries from Linux), static linking of any 3rd party libraries (useful for portable builds), Wine-based environment for building Xbox binaries (sounds crazy, but yes, it is faster and more stable in Linux than in Windows VM), and all sorts of hacks and tricks, all laid out in .nix files in a quite comprehensible, self-documented way. Now, given a clean Linux machine with only Nix installed and our game repo checked out, I can run a single nix-build command to build our game for Windows, Linux and Xbox. It will take quite a bit of time (hours) and disk space (tens of Gb), because it builds custom compilers and temporary VMs, but it will be cached in Nix store and only has to be done once. Before that I used giant Docker image with all sorts of build tools installed/built, plus persistent VMs which had to be maintained manually, and Nix made it so much easier. Nixpkgs provides a good foundation - it has almost all software you may need and all the utilities to modify it or add new software. Need to patch or switch to custom version some obscure dependency of a compiler building another compiler building a library you use? Override a derivation, and all the dependent stuff will be rebuilt automatically. For building software Nix can be seen as a kind of super-Docker - Nix store allows for more granular caching than just layers, so incremental improvements can be done much faster. Essentially Nix turns files and packages into values in a programming language, so instead of hacky bash scripts trying to imperatively maintain a file dump, you just compose immutable packages by writing expressions. That said, Nix is really hard to understand at first, comparable to Haskell/monad tutorials. I remember I made a few unsuccessful attempts at it over a ~6 month period, every time becoming more desperate, and then it finally clicked after careful reading of Nix pills [2] for a few consecutive days. To me, the most interesting thing to discover was that while Nix/nixpkgs do necessarily use some "hard" concepts like fixed point, it is in fact quite "old-school" and mostly about Unix, executables, linking, string templating, contains a lot of bash scripts, etc, so it's not really another Haskell. In fact, traditional building of C/C++ software with autotools is supported in Nixpkgs better than building modern stuff like Rust or Go, due to reliance of the latter on own package managers. [1] https://insatia.kozinaka.com/ https://insatia.kozinaka.com/ [2] https://nixos.org/guides/nix-pills/index.html https://nixos.org/guides/nix-pills/index.html
tomlin 6y ago
Odd choice for a name, since Nix is a registered trademark of another tech company.
- domenkozar 6y ago
  Link?
johndoe42377 6y ago
No. Unnecessary, redundant abstractions and wrapping is never the answer. Standardized interfaces and protocols are. Erlang and Go got it right.
codethief 6y ago
A few days ago, I came across RobotNix[0] which uses Nix to deterministically build custom Android images. Since I really want to adapt Android to my needs but have always struggled with building it on my own (what a shitty and complicated build system), I'm now very inclined to learn Nix. I'm not sure I like the syntax but hopefully I'll get used to it. Another reason I'm quite excited about Nix is that in my team we're currently using a whole bunch of tools like pip, Conda, npm all at the same time to manage our dependencies and it's starting to become really cumbersome to set up the dev and production environments correctly across different operating systems and architectures. For instance, Conda doesn't exist on arm64, lots of pip packages have to be compiled by hand on arm64 etc. etc. It's a mess that I'd love to get rid of. [0]: https://github.com/danielfullmer/robotnix/ https://github.com/danielfullmer/robotnix/
__jem 6y ago
I've gotten into NixOS for my personal daily driver, but I'd love to see more resources about how to orchestrate CI/CD flows with Nix. It's not totally clear how I'd move from the simple single machine configuration I have now to packaging a large monorepo and deploying it.
grandinj 6y ago
Nix sounds like SELinux. A great idea in theory, but in practice just too hard. There is a great deal of genius in coming up with these ideas. There is just as much genius in finding the 80-90% solution that incorporates most of the original, but in a workable way. Looking forward to seeing where stuff like Nix ends up.
- fctorial 6y ago
  You'd be surprised how well a nixos system works. Every other distro looks like a meme in comparison, for development work at least.
llaolleh 6y ago
Nix sounds great in theory, but it's just not there yet unfortunately. I tried it out but there were just too many workaround to setup my work environment.
bpiv400 6y ago
Great post! I'm working on a project called Flox that's trying to make Nix easier to use for beginners and easier to scale for enterprises. If that sounds interesting, you can sign up for the public beta: https://www.floxdev.com/ https://www.floxdev.com/ Here's an announcement blog post about our initial release: https://discourse.nixos.org/t/introducing-flox-nix-for-simplicity-and-scale/11275/9 https://discourse.nixos.org/t/introducing-flox-nix-for-simpl...
bfrog 6y ago
I use nix today for ci/cd to build a large C++ project for a variety of architectures using cross-compiles. While it could be done with adhoc scripts, some cross compiler tool environment tool + conan, or something else, I effectively wrote my nix expression once to package up everything, and simply changed the target arch and libc and got what I wanted. It's not perfect, but it works, its fast, and its better than the alternatives. I'm interested in rying Guix at somepoint instead as I think using Guile might be easier than learning the Nix language, cli tools, and more. I think guix could do much what I do now as well. I can't see myself using guix as an OS though, since they seem to think systemd is evil or something, and really systemd is quite nice in practice in my experience.
- lfam 6y ago
  Hey, we're glad to hear you're interested in Guix :) I just wanted to say that Guix doesn't hate systemd, or think of itself as an anti-systemd project or anything like that. Systemd was not chosen because GNU already had a (quite simplistic) init system written in Guile Scheme, and we want to use Guile for the entire system. Eventually, our goal is to offer a fully integrated interface for managing the system, just like systemd. We are not there yet :)
  - kaba0 6y ago
    Is it really wise to go against such important/widely-used part of the linux userspace? I do find Guix as cool as NixOS, but this decision seems like a self-inflicted wound. Nonetheless, I should definitely get to know the project more, because it was some time ago I tried it last. So, Good luck with the project! :)
    - lfam 6y ago
      I agree, it could be seen as a self-inflicted wound. I'm a Guix developer but I still use Guix on Debian for important deployments, mainly because of systemd / journald. But, we could also think of it as an opportunity. Well, I hope you'll find Guix useful and enjoyable, and maybe even help us improve it :)
skratlo 6y ago
Even though the article sounds like it's written by educated person, it puzzles me that the author: > Installing packages with APT is not atomic: APTs updates files in-place one by one. Because we start Python processes many times per second, if one started during a deployment, it could import a mix of the old and new code. This regularly lead to puzzling bugs Don't you stop all your services in preinstall and start them again in postinstall? Or, if you're packaging your python libs in deb pkgs, just stop the services before upgrading the system and start them again once you're done.
- ruuda 6y ago
  This part is about batch jobs that we start, not about daemons. The APT package would take about a minute to install, but some of these batch jobs are started by a user interaction, and we can't delay them for that long.
jarvuschris 6y ago
Chef's Habitat is a really powerful nix-like system that I find to be a bit more practical. Like nix though it suffers from being a complete paradigm shift that people coming in from the imperative OS world struggle trying to map their existing patterns into It's kind of sad because it's a far better way to manage deployments and environments...but it takes 1-2 years of practice to really get proficient at
aszen 6y ago
To truly appreciate what nix provides, take a look at this example script that uses nix-shell as interpreter and marvel at the fact that running it is as simple as running a binary after you have nix installed. ``` #!/usr/bin/env nix-shell #!nix-shell -p "(pkgs.haskellPackages.ghcWithPackages (ps: [ ps.text ]))" #!nix-shell -i runghc {-# LANGUAGE OverloadedStrings #-} import Data.Text.IO main :: IO () main = Data.Text.IO.putStrLn "Hello, World!" ``` While nix is sometimes hard to learn, it is often a much simpler solution and it works for all languages so learning it is well worth it.
Wazzymandias 6y ago
Nothing should be labeled as the ultimate devops toolkit when its documentation is as atrocious as nix People can commend it as much as they want, but the steep learning curve is largely self inflicted because of their resistance to writing clean, comprehensive, up to date docs It has also led to the community being filled with a lot of arrogance and pretentiousness I wouldn't run nix in production because of the lack of accessibility and toxic community. There are other ways to get reproducibility, etc without using an arcane and poorly documented toolkit
- hinkley 6y ago
  > It has also led to the community being filled with a lot of arrogance and pretentiousness I would conjecture that you have cause and effect reversed. When people think they're doing you a favor, the ego protects itself from hearing how their help is not actually that helpful. See aid to Africa in the 80's and 90's for example.
- kaba0 6y ago
  Any concrete reason you call such a niche, but large community toxic?
  - Wazzymandias 5y ago
    It's been mostly from personal experience, though I shouldn't generalize to the community as a whole. Anecdotally my experience with nix community has been unpleasant. They're very resistant to suggestions and offer little in terms of guidance or documentation.
TobyBrull 6y ago
Not a Nix user, but I spent some time trying to understand it. One thing that I wish I would have understood earlier is that "Nix Pills" is a decent, bottom-up Nix tutorial and probably a good place to start. Initially I thought "Nix Pills" was just a collection of recipes ("Nix By Example"), but it is not.
earthboundkid 6y ago
I think it's interesting that the motivating usecase is Python. Python's dependency management is extremely bad and many tools exist just to try to cover up how bad it is without solving the core problems. Would Docker have ever become popular without Python?
brunojppb 6y ago
The article is very interesting. Although until the middle of the article I could make little sense of it because I had no clue what Nix was (have never heard of it), until I reach the part where Nix was introduced. Seems to be a very interesting tool.
camehere3saydis 6y ago
Reading some of the comments here, it feels like one needs to lay out a lot of context before being able to describe their Nix experience. (Is that Conway's law in reverse, or just Occam's beard? I can't help but wonder.) And I gotta get back to trying to build Deno from Git with Mozilla's overlays. Thankfully, Nix pairs well with git submodules...
mrtweetyhack 6y ago
"The Nix programming language" as if I needed to learn yet another language
timka 6y ago
I feel like I'm a veteran looking at my stack overflow question from 2009. Basically we had our own approach to the problem using FreeBSD. Also, Nix is among the proposed solutions. https://stackoverflow.com/questions/1316716/reproducible-custom-distribution-build-system-for-linux https://stackoverflow.com/questions/1316716/reproducible-cus...
nwmcsween 6y ago
Well mix was a no go for me for a few technical reasons: * No multihost support, I want to share / between many hosts, nixos ideas support this but the implementation doesn't (and no I don't want to just share the nixstore) * No package security, ideally package deps chains should have a per user/group created which won't allow broken programs from rm -rf / or worse. * Nixos treats a filesystem as an object store, this goes against how most Unix tooling works (e.g how many Unix tools take a s3 obj?) Things that might be incorrect on my part: * No config validation, minor and hard though it would be nice if nixos had config validation. * Single hash for store objects(?), it would be nice to use something like TLSH, etc in addition to a crypto hash

383 points by rkrzr 6y ago

As an aside, I've just started trying to move my laptop to NixOS this past week, so far it seems pretty nice. I have a Macbook as well, and I think I should be able to share the Nix stuff with that - which would be cool. As for the article, I hadn't actually considered using it as a replacement for Ansible etc - but I could see why it might work better. I could pin packages etc to the versions, and get the exact same thing each time - no guarentee with ansible etc that the apt repository hasn't been updated since the last install. I think the whole Nix thing is an interesting idea, and I like the ideas behind it, I haven't played enough with it yet to dare use it in production (or on my main desktop for that matter) but it is certainly a tempting idea.

kevincox 6y ago
I use NixOS on my laptop as well and like it. This is where the lack of polish hurts a little because desktop environments require a lot of polish to be wired up smoothly. That being said I use GNOME and the basics just work. But on the server is where I think Nix really shines today. The biggest thing for me is that every deploy is "clean" and can be rolled back. Systems like Ansible (and basically every other config management system) only modify the part of the system that they know about and mutate global state. This means that your service might just happen to work because of a library that just happens to be installed by another service, or even on that is still installed from a service that used to run on the system. Unless you excercise Perfect Constant Vigilance and update configs to delete things instead of just removing the config to install them your configs will soon be be broken and depend on the current state of the system. I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS. I wrote a blog post on each of server NixOS and desktop NixOS if you want more of my thoughts. https://kevincox.ca/2015/12/13/nixos-managed-system/ https://kevincox.ca/2015/12/13/nixos-managed-system/ https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/ https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/
- Galanwe 6y ago
  > I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS. Having worked with puppet for a long time, I can relate. There is this false sense of confidence that everything is reproducible "because we had the discipline to never do manual changes and always use puppet" but in real life: - dependencies between resources are forgotten, it worked the first time because luck in the order in which resources were applied, but would fail in from scratch applies. - hidden dependencies that were not specified but it worked because an other resource was installed at the time. - hell, even a failed apply could have partially installed dependencies that would make subsequent applied work. - there's always _that time_ when you had to fix something in a hurry and manually installed a package which is now a potential hidden dependency for everything else.
pwm 6y ago
Re Macbook, if you fancy check out my home-manager config: https://github.com/pwm/nix-home https://github.com/pwm/nix-home The readme was/is more of a short note to myself than for users, nevertheless this is how i manage my entire home env on my mac and it works beautifully.
takeda 6y ago
Re: using nix in place of ansible/chef/puppet/salt etc. One of things that makes it far superior to these solutions, is that while many of them try to be declarative it still an iterative hack to emulate it. For example if you use your CM to install a package on the system, or create a file in /etc. If you remove that statement the file or package will still be there. In NixOS it will be as if it was never there. The reason for it is that the existing CM work by modifying current OS, while NixOS rebuilds the entire OS every time you make a change (thanks to cacheing that operation doesn't take as long as it would normally do). As for using things in production, I generally like things that are well established. So it took many years before I got the courage to propose it, but frankly I don't think it ever let me down. As I used it always act predictable, both the NixOS as well as build (as long as you pin down nixpkgs). The only thing to worry about is if the outside environment demands a change you better know how to do it. For example application works fine, suddenly you have higher traffic and things are crapping out and maybe you need to change some settings or there was a bug in one of your dependency and a new version isn't in nixpkgs. You better know how to do those things.

leetrout 6y ago

I am very much looking forward to trying Nix I just haven’t made the time. That being said the article jogged my memory on some related thoughts... If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/ https://www.aptly.info/ If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ https://asdf-vm.com/#/ It uses pyenv under the hood for Python management AFAIK.

bennyp101 6y ago
asdf is awesome and if you combine it with direnv you can just cd into your project and have the versions ready to go (You can do the same with nix and direnv asdf - althrough I havent got that far yet)
- b0afc375b5 6y ago
  What's your use case for direnv? I've been using asdf and love it, but I'm not sure what to use direnv for. Is the purpose to replace .env files?

joseluisq 6y ago

My first time seeing Nix, very promising https://nixos.org/#asciinema-demo-cover https://nixos.org/#asciinema-demo-cover Definitely Nix deserves a try.

domenkozar 6y ago

I've written a few tutorials at https://nix.dev/ https://nix.dev/, more to come in following months :)

mkingston 6y ago
Hey thanks for those. I hadn't noticed them as a whole, but I'd stumbled across a few of them from search results, and now I open the site and realise it looks quite familiar!
- domenkozar 6y ago
  Thanks. I'm looking for feedback on the content - in terms of problems with it and what's missing!
atc 6y ago
These are really useful. Thanks.

tarkin2 6y ago

I tried to learn before. But the docs made it incredibly hard. They went into excruciating detail of how it works. I still never made my own nix package. I’m wondering as a solo dev, who uses his personal machine, and two servers, if the hard work of learning it will pay off. But it definitely looks interesting.

domenkozar 6y ago
What kind of tutorial would you like to read?
- tarkin2 6y ago
  Something more like “And now you can do this” rather than “And now you know how it works “. The docs for using nix as a package manager are decent. But the rest, less so. They’re a recursive rabbit hole of confusion.
  - elbear 6y ago
    I found useful this series of articles introducing Nix by using it with Haskell: https://github.com/Gabriel439/haskell-nix https://github.com/Gabriel439/haskell-nix I hope it helps.
- JackC 6y ago
  My dream tutorial shows how to move from what I have to the new thing, because that teaches me what new ways of thinking I need to adopt. Like right now at work we have a small team making a website with docker-compose to specify the dev environment, pip-tools to pin python dependencies, and saltstack to deploy new state to bare metal in production. How exactly, command by command, would nix solve the same problems? What would change from my current solution? How would I think differently? How would my life get better? What parts wouldn't be solved and I'd have to keep some of the old stuff around? Those are the tutorials that convince me to switch, because they get me over the hump of not getting the new paradigm, and being afraid of the downsides I don't know about yet. It's tricky because it's pretty specific to how someone's currently solving problems, but maybe knowing what I'd optimally want can help with figuring out something doable. (This blog post didn't work for me because it was too vague. I already have old boring solutions for their python pain points, like pip-tools, so I can't take their assessment of how much better things can be on faith, and they don't show me the details of the new thing.)

tazjin 6y ago

There's a lot of unexplored potential of Nix in granular build systems and displacing systems like Bazel. If applied correctly, it lets smaller organisations get much of the benefit of Google-style monorepos but without as much maintenance overhead. Some friends and I have been experimenting with this for the last year over at https://tvl.fyi https://tvl.fyi (code etc. is linked at the page bottom). We've run into some issues with the current implementation of Nix, but stay tuned on that :)

supermatt 6y ago

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be accessible, IMHO. I simply didnt have the patience to delve any deeper.

domenkozar 6y ago
Did you follow the language tutorial in the manual or something else?
- supermatt 6y ago
  I would have followed the official manual. I see that you are putting together some tutorials, so I will definitely check those out.
throwaway894345 6y ago
I agree. I’ve spent person-weeks looking into Nix, and I still can’t get it to work beyond the most basic of use cases. A few weeks ago I spent an entire weekend on the Nix discord channel trying to get help to configure VSCode for Rust development, and we collectively couldn’t figure it out. Nix is a great idea, and it’s goals are ambitious, but I haven’t found it to be usable yet. Almost any time I try to do anything I get mired in a tar pit and I basically end up having to give up. I’ve learned lots of tools and technologies in my career, but Nix remains elusive.
- domenkozar 6y ago
  Do you have some examples of that? Maybe a link to discord discussion?
- pimeys 6y ago
  I did a month, diving directly into the deep end with flakes and all. I don't know, it really is hard in the beginning. Like, really hard. But eventually I got myself a setup I could use in my two laptops and workstation. A setup, that sets my home directory, all my programs and my custom desktop just the way I want. Everything is in the github repo, and installing with the flake will give me the exact experience I have in my other machines. I tend to use lots of custom tools and commands, that are really painful to install and setup for a new machine. With NixOS all of it is just one command away. But, I agree, it is REALLY HARD in the beginning to grasp things. Here's my configs if you want to see how I approached my own setup: https://github.com/pimeys/nixos https://github.com/pimeys/nixos

alrs 6y ago

The merges-straight-to-master give me the willies. https://botsin.space/@complainingaboutmastercommits https://botsin.space/@complainingaboutmastercommits

domenkozar 6y ago
We've grown a lot in last few years and haven't caught up with the policies. See https://github.com/NixOS/nixpkgs/issues/118661 https://github.com/NixOS/nixpkgs/issues/118661 for details. Note that those statistics are incorrect, but pushes to master still do happen.
- adamcstephens 6y ago
  There have been controls in GitHub to prevent this for a few years now. It’s also been awful practice to do this for as long. While I have no skin in this game, my recommendation would be to immediately block all pushes to master from everyone.
danieldk 6y ago
Those counts seem to be wrong. Looking at the code, they seem to count the number of merge commits (commits with >1 parent). However, some nixpkgs committers also use GitHub's rebase merge option. This means the change went through a regular PR + review, but is merged without generating a merge commits. Secondly, some PRs have multiple commits, so even if everything is merged through a merge commit, the number of non-merge and merge commits may not be balanced.
nonameiguess 6y ago
It's not fair at all that this is presently the most downvoted comment. Like it or not, this is a real concern, even if the count is illusory. It's not just about humans seeing this, but automated risk assessment tools use this kind of thing as a metric and showing a bunch of commits straight to master can prevent enterprise and government adoption due to policy. Maybe that doesn't matter for you, but innovators ignoring these gigantic market segments is part of why enterprise and government software development remains so far behind the innovation curve because they can't trust the security of the development models and the largest customers are all stuck with effectively no choice but Redhat.

nuker 6y ago

Nice, but this is as far from devops as knitting. They covered CI, but there is CD, all the cloud stuff, containers, security and so on.

detaro 6y ago
"cloud stuff" and "containers" (which people also do manage using Nix) are not requirements for something to be DevOps.
- nuker 6y ago
  Try telling it to any recruiter lol
  - fctorial 6y ago
    The problem "containers" solve does not exist in nix land. If all you've got is a hammer... Edit: removed "clouds"
    - detaro 6y ago
      Nix does not solve all problems clouds solve. But it can be a quite useful tool combined with them.

temptemptemp111 6y ago

I don't see how they've proven their extra levels of abstraction to be solving more problems than they will add. Focus on the basics. We can do everything with containers, basic init systems (without sytemD), snapshots, simplifying build systems, removing layers of abstraction, swarm mode, and a bit of custom glue & thinking...

candiddevmike 6y ago

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.

danieldk 6y ago
The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. For me, the big benefit is that even though I have to read the upstream documentation, I can use the same syntax for everything and do not have to learn and use N different configuration file syntaxes.
- whateveracct 6y ago
  And when you figure something out, you can abstract over patterns because Nix has functions!
duijf 6y ago
> Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern. Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine. You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code. Put those tools in your systemd service before launching your app, and you're good to go. (NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I haven't seen the final picture. I imagine it's lovely compared to what we had before) [1]: https://github.com/channable/vaultenv https://github.com/channable/vaultenv

pjmlp 6y ago

When those DevOps happen to work with GNU/Linux only.

ruuda 6y ago
We do manage a few tools for MacOS with Nix as well, but it’s only a select few things, not our full stack.
- pjmlp 6y ago
  XServer has long stopped being relevant.
domenkozar 6y ago
There's Darwin support in Nix, but it needs to be polished: https://opencollective.com/nix-macos https://opencollective.com/nix-macos
- pjmlp 6y ago
  macOS aren't servers for quite some time.

vindarel 6y ago

Obligatory link to its cousin: https://guix.gnu.org/ https://guix.gnu.org/ A package manager or a full distro. I use the package manager on top of Debian, it's great, it allows me to get recent package versions the most straightforward way (like the latest Emacs), in exchange of disk space (easily some GB before a `guix gc` cleanup).

MayeulC 6y ago
I've been running it on an older laptop to try it out. `guix pull` takes so much resources, it often takes a few hours to complete, even with binary substitutes. Documentation is a bit lacking, even though it has an excellent manual. How I am supposed to specify extra command line parameters to the kernel I boot in GRUB, for instance? Or specify multiboot targets? Get a "desktop" install without GDM? In the end, I went back to alpine on that machine. Secondly, to use it as a standalone package manager, I wish it didn't require root access, or allowed me to put it in an arbitrary directory. Guix could work as a nice substitute for conda or docker, especially when it comes to reproducibility. I also couldn't find a guix docker image.
- snicker7 6y ago
  > I've been running it on an older laptop to try it out. `guix pull` takes so much resources, it often takes a few hours to complete, even with binary substitutes. This is being actively worked on! https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more-quickly/ https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more... > I wish it didn't require root access, or allowed me to put it in an arbitrary directory I believe `guix pack -RR guix` will do package a relocatable guix for you.
  - MayeulC 6y ago
    Thanks for both your replies! Looking forward to the first, and I'll look into the second. One of my goals would be so easily offload to a more powerful computer, even if it doesn't run guix. Edit: content-addressed guix stores delivery over a content-addressed network sounds interesting, it would be even better with rolling hashes (I think ostree/casync uses those). I dream of a yunohost-like operating system based on Guix :)

va1en0k 6y ago

Nix is slowly becoming a major point of contention. In some communities, it’s already scary to even hint that one dislikes it.

ninjin 6y ago
Blindly going after dissenters and/or alternative opinions is never a good thing, which communities would that be? In the ones that I frequent Nix is still a bit of a fringe phenomena reserved for nutters such as myself. From inside the Nix community it is from my perspective far more relaxed than most OS communities that I have been a part of over the last two decades.
- va1en0k 6y ago
  It'd be probably easy to guess which communities I mean, but I'd rather not name names myself and hope someone supports me with a datapoint to offset my personal paranoia. Lately I encountered quite a lot of software - fringe and weird of course, but numerous enough - that went for having Nix as the only way to be deployed, typically with a "reproducible" script that doesn't work already after a year or two. As nix files make negative intuitive sense, not even in the smallest-scale bit-fiddling sense, so little intuitive sense that I cried once trying to just make it work - I look around for advice. One of "just take a couple of weeks to learn it, it's not that hard" is seen quickly enough, of course. It's a bit of pure loss from there: everyone who heard something like this knows that it's the moment to either invest fully or ignore and quietly move on and away. Confessing that you just don't think you'd find it in yourself to invest in it is almost a pure loss for one. However, since we're not in one of those communities, let me say why not. I'm as sure that the good idea of reproducible builds will be implemented soon enough with something intuitive, strongly-typed, easily debuggable/diagnostable and dev-friendly, as I'm sure that diesel cars will be obsolete soon enough not to even think about investing my time and money in them. Regardless of what the current usage says - e.g. in Germany one would make a mistake to follow its wisdom just a few years ago, in case of cars, I mean.
  - doyouhearu 6y ago

madjam002 6y ago

Has anyone explored CD tooling with Nix? And I don't mean the deployment of NixOS machines themselves (NixOps, deploy-rs, etc), I mean actually using Nix for deployment tooling and orchestrating deployments using the Nix language. I am yet to find any posts about this or any tools, but have had great success with a small hand rolled tool that essentially lets me decoratively describe cloud resources, parts of my application, deployment "end state", and run the tools required to materialise that (Terraform, nixos-rebuild, etc) similar to GitHub Actions. Hydra is distributed CI for nix-build but does not handle CD or is designed to handle jobs with side effects AFAIK. NixOS is great, but for me this is even more valuable, as I now have an introspect-able view of my entire deployed real estate, and can essentially `nix run ...` to deploy any part of my application in its entirety along with any dependencies.

domenkozar 6y ago
https://nix.dev/tutorials/deploying-nixos-using-terraform.html https://nix.dev/tutorials/deploying-nixos-using-terraform.ht... showcases how you can use terraform to provision things and Nix to describe the machine. There's also https://terranix.org/ https://terranix.org/ to configure Terraform using Nix.
arianvanp 6y ago
Maybe https://github.com/serokell/deploy-rs https://github.com/serokell/deploy-rs ? It's a generic deployment tool for Nix that also supports NixOS machines but can target any nix profile
the_duke 6y ago
In addition to the other comments, there is also nixops. [1] [1] https://github.com/NixOS/nixops https://github.com/NixOS/nixops
ruuda 6y ago
What we do at Channable is build our packages with Nix, push them to Cachix, and record the Nix store path. (CI does that automatically for release builds.) Then we use Ansible to declare that that is the store path that we want to realize on the appropriate servers. Our packages contain an "activate" script that updates symlinks in /usr/bin, or systemd units. Ansible calls this script after realizing the store paths. We have some functions written in Nix to help writing these activation scripts, and Nix makes it easy to import them from a Git repository, so we have it in one place and import it in all of our repos. We are now moving towards CD by automatically running Ansible in some cases.

mark_l_watson 6y ago

A few years ago I was interested in Nix to make handling multiple Haskell projects easier. I dipped my toe in the water by running NixOS in Virtualbox on my laptop. After a while I decided that improvements in stack were enough for my modest requirements, but NixOS was cool.

mitchmindtree 6y ago

Nix has a heavy learning curve and requires learning the language to feel comfortable. However, overcoming that hump is incredibly rewarding and allows for taming your system in a way that, for me at least, changed the way I look at composing software. At mindbuffer[1] we've started using it for our recent art installations. The big benefits for us are reproducibility, ease of deployment, and the ability to collaborate on the composition of the whole system. I.e. rather than sharing a README of how to install things one by one and hoping each of us has followed it correctly, we just work on the same set of config files via a git repo (like we would any other code) and can be sure we're all on the same page as a result. Very much looking forward to Nix 3.0 landing with all its UI improvements and flake support. It seems like these changes will go a long way to making Nix more accessible, and provide a smoother on-ramp to learning the language itself. https://mindbuffer.net/ https://mindbuffer.net/

haolez 6y ago
Where can I get info about Nix 3.0 new features?

mikepurvis 6y ago

A lot of this sounds familiar to me— I maintain a hodgepodge build tool/pipeline at my org whose current output is a monolithic mega-deb file which is becoming unwieldy on several fronts (storage, transfer, compression time). I'm really interested in the nix philosophy of separate paths and versioning by hash rather than number, but unfortunately my needs are quite specific, and not having actual experienced nix experts around is a barrier. The temptation right now is to roll our own solution which generates nix-style hash debs that otherwise cooperate with the larger Debian ecosystem we're already very familiar with, but I could probably be sold on giving nix itself a closer look if I could hear from folks (or get pointers to documentation) on a few key points: - What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? (think not just a nightly build, but builds corresponding to unmerged feature branches, etc) - Does the nix hash account for dependencies only changing the hash for ABI-impacting changes such as when a header file changes? Or does it change dependent hashes always? Or never? - I have an existing system for managing packaging metadata which I don't want to migrate from. How much trouble will I get into if I want to generate the metadata on the fly each time (as I currently do for my debs)? - How much pain is it to roll a nix package "by hand" (basically with the dpkg-deb equivalent tool rather than the dpkg-buildpackage equivalent tool)? - Nix isn't supported in Artifactory (RTFACT-19998 has been open since 2019). Nominally, I can use the dumb WebDAV option, but is that going to affect my user experience and/or will it be a maintenance headache? - What is the apt/nix interop story? I would likely need it to be bidirectional, so that my nix workspace could depend on system debs that I don't want to port over, but also potentially have "gateway" debs which able to do the opposite, of depending on the nix workspace from a deb shim, and installing/updating it in the postinst. I've researched all of these in the past at various points and had a lot of trouble finding clear, straight answers on them. I'd love to hear from other users or nix experts, though, who could help calm our fears on this.

q3k 6y ago
> What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? A Nix derivation (a.k.a. 'packaging unit') can be built from sources either fetched remotely, or from a local directory, or a combination of both; plus any other derivation that it depends on. Any version semantics come from how you implement them, abstracted and formalized in any way you want. Nix is a programming language, you are free to do what you want. > Does the nix hash account for dependencies only changing the hash for ABI-impacting changes such as when a header file changes? Or does it change dependent hashes always? Or never? By default, any change to any dependency will cause all dependent derivations to be rebuilt, and their hashes to also change. You can 'break' this by introducing stable ABI barriers preventing rebuilds and performing runtime loads of dependencies from .so (or whatever, executing some binaries from $PATH). This is for instance how my firefox can handle any OpenGL library that it can use at runtime, without having a firefox rebuilt for every possible GPU driver out there. > I have an existing system for managing packaging metadata which I don't want to migrate from. How much trouble will I get into if I want to generate the metadata on the fly each time (as I currently do for my debs)? You will have to generate nix source code, or importable nix source code, from that system, and pull that into your local nix source tree. All nix evaluation is done from purely defined locally available sources, or sources fetched from remote resources, but marked with some consistent hash. > How much pain is it to roll a nix package "by hand" (basically with the dpkg-deb equivalent tool rather than the dpkg-buildpackage equivalent tool)? Nix does not work this way. Nix derivations are a recipe on how to build a package, you have to specify that in one way or another so that Nix can perform the build for you, and reason about its status within a larger build graph. You can 'cheat' building derivations by eg. importing binary builds and only patching them up to work under Nix(OS), but generally you shouldn't. > Nix isn't supported in Artifactory (RTFACT-19998 has been open since 2019). Nominally, I can use the dumb WebDAV option, but is that going to affect my user experience and/or will it be a maintenance headache? You will need to run a Nix cache, that CI will push into and other consumers (all having a checkout of your nix definitions) will pull from instead of building everything from scratch themselves. > What is the apt/nix interop story? I would likely need it to be bidirectional, so that my nix workspace could depend on system debs that I don't want to port over, but also potentially have "gateway" debs which able to do the opposite, of depending on the nix workspace from a deb shim, and installing/updating it in the postinst. Not aware of anything out of the box. Nix builds only run on Nix (as they all need dependencies from /nix/store/..., and that is populated by Nix itself), so don't expect to easily run them on Debian as normal dpkgs without some disgusting home-rolled hacks. You could technically consume binary .debs from Debian within nix derivations (see previous point), but that's ugly. Generally, just install Nix on all your hosts.

root_axis 6y ago

I love nix as a concept, but in my experience it isn't practical on systems without a ton of memory. I regularly get build errors due to oom errors.

kaba0 6y ago
That’s strange, are you actually compiling packages or the evaluation itself ooms? Because if the former, you may help it by limiting concurrent builds.
- raxi 6y ago
  Evaluating/compiling packages is not greedy. Memory is eaten by lazy evaluation of NixOS modules. It can be optimized, but it is not a low-hanging fruit. It is still waiting for its hero. I'd compare it with creating the V8 for JavaScript.
trulyrandom 6y ago
Yeah, it's clear that Nix has not been optimized to run on resource constrained devices. I run NixOS on a Raspberry Pi with 1GB of RAM and had to enable swap to prevent Nix from running into OOM situations. Any system with more memory than 1GB is usually fine in my experience though.
ris 6y ago
To run it on systems with low memory, I suggest performing any custom builds on a separate machine. In "normal" circumstances you don't generally have to do any builds at all - (almost?) everything should come from the binary cache. To be doing all these rebuilds it sounds like you're customizing packages, which is already something other distributions don't tend to let you do at all.
taktoa 6y ago
you're probably mistakenly using nix-env -i, rather than nix-env -iA
- root_axis 6y ago

AzzieElbab 6y ago

I like nix, but it is hard as hell to switch to from yaml driven world. If the path was more gradual nix would see more adoption

siraben 6y ago
What systems are you referring to in the "YAML driven world"?
- AzzieElbab 6y ago
  ansible, k8 - anything, circle, everting else
ris 6y ago
Y'know, Nix can generate json/yaml quite easily.

exdsq 6y ago

The language and documentation is pretty awful, however I use NixOS (and therefore Nix) on my work desktop and still absolutely love it. The ability to create reproducible builds, test out tools without installing them permanently, and roll the OS back if you break something is just excellent. For example I spent ages this morning trying to get a gRPC Rust environment working and battled the nix file for a good two hours but now it works I know it will always work and never have to do it again.

bamboozled 6y ago
Do you truly understand how it works though? I was similar. I loved my setup and it did mostly just "work" but I found it unnerving that eventually when it does break, I wouldn't know how to fix it.
- exdsq 6y ago
  I have a very minimal nix.configuration, write very small shell.nix files, and try to only use things I know or understand. So I’m definitely only using 1% of Nix right now but I’m comfortable with it! Edit: I should clarify Nix is the build tool at work for Haskell and some of my colleagues are contributors so I know I can get help if stuck. I’m a noob though.
- gmfawcett 6y ago
  What kind of breaks were you having that you couldn't simply roll back? Database upgrades, or something?
  - tnzm 6y ago
    The latest version of something failing to build. Like when the Tor project removes a Tor Browser package from its servers and `tor-browser-bin` hasn't yet been updated in nixpkgs.
  - camehere3saydis 6y ago
    Can't upgrade Deno from 1.3.3 to 1.8.3 by updating the sources and hashes in the derivation, as is normal procedure. `fetchFromGitHub` and friends fail to recursively fetch commits that are not visible from `HEAD` (`git clone` works), and I'm completely at a loss about how to debug this. This kind of breaks. For people like myself who already spend a lot of time debugging dependency and compatibility issues in less sound package ecosystems (scripting languages I'm looking at you), Nix alternates between enlightening and maddening. Which I like.

jpe90 6y ago

I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself from version "nix-2.3.10" to "nix-2.3.10-x86_64-unknown-linux-musl" because it saw that package's version string as a version bump. The suggestion in the github issue was to instead use an unofficial third party package for basic package management because this was a known, long-standing issue that is not likely to be fixed. https://github.com/NixOS/nixpkgs/issues/118481 https://github.com/NixOS/nixpkgs/issues/118481 The experience came across as a massive red flag and I decided not to pursue it further.

siraben 6y ago
FYI nix-env operations are atomic and can be rolled back instantly, including upgrades. $ nix-env --rollback > The suggestion in the github issue was to instead use an unofficial third party package for basic package management. Specifically the suggestion is referring to home-manager, which is community supported (being in nix-community) and is the recommended way to install packages rather than imperatively doing it with nix-env.
- danieldk 6y ago
  the recommended way to install packages rather than imperatively doing it with nix-env The problem is: recommended by whom? The Nix Manual presents nix-env as the main way to install Nix packages. So, as long as the manual centers around nix-env, newcomers will try to use nix-env and get bitten by it. The same is true for the NixOS Manual, it suggests that people install packages with nix-env before talking about declarative package management. Also, I love home-manager, but it is perhaps too much for people who just want to dabble in Nix a bit. It would be nice if a simpler declarative way of managing packages was presented first. Perhaps surprisingly, another way is documented but it is deep in the nixpkgs manual: https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...

jherdman 6y ago

We're using Nix packages at Precision Nutrition to manage our dev environments: https://github.com/PrecisionNutrition/pndev/ https://github.com/PrecisionNutrition/pndev/. It's been enormously successful. I highly recommend it.

cazim 6y ago

This reminds me -> https://xkcd.com/927/ https://xkcd.com/927/

snicker7 6y ago
That link needs to be blocklisted from HN.
takeda 6y ago
I don't think this is relevant. It's not a new standard is a complete paradigm shift. Some tools might need to be used slightly different, others might no longer be needed. Because it requires change the way you think about things is why so many people have problem with getting into it.

quyse 6y ago

I participate in development of the cross-platform indie video game written in C++ called Insatia [1]. We switched our CI server to building almost all the binaries using Nix. With Nix we have proper Clang with libc++/etc for latest C++ features, cross-compiling Clang (for building Windows binaries from Linux), static linking of any 3rd party libraries (useful for portable builds), Wine-based environment for building Xbox binaries (sounds crazy, but yes, it is faster and more stable in Linux than in Windows VM), and all sorts of hacks and tricks, all laid out in .nix files in a quite comprehensible, self-documented way. Now, given a clean Linux machine with only Nix installed and our game repo checked out, I can run a single nix-build command to build our game for Windows, Linux and Xbox. It will take quite a bit of time (hours) and disk space (tens of Gb), because it builds custom compilers and temporary VMs, but it will be cached in Nix store and only has to be done once. Before that I used giant Docker image with all sorts of build tools installed/built, plus persistent VMs which had to be maintained manually, and Nix made it so much easier. Nixpkgs provides a good foundation - it has almost all software you may need and all the utilities to modify it or add new software. Need to patch or switch to custom version some obscure dependency of a compiler building another compiler building a library you use? Override a derivation, and all the dependent stuff will be rebuilt automatically. For building software Nix can be seen as a kind of super-Docker - Nix store allows for more granular caching than just layers, so incremental improvements can be done much faster. Essentially Nix turns files and packages into values in a programming language, so instead of hacky bash scripts trying to imperatively maintain a file dump, you just compose immutable packages by writing expressions. That said, Nix is really hard to understand at first, comparable to Haskell/monad tutorials. I remember I made a few unsuccessful attempts at it over a ~6 month period, every time becoming more desperate, and then it finally clicked after careful reading of Nix pills [2] for a few consecutive days. To me, the most interesting thing to discover was that while Nix/nixpkgs do necessarily use some "hard" concepts like fixed point, it is in fact quite "old-school" and mostly about Unix, executables, linking, string templating, contains a lot of bash scripts, etc, so it's not really another Haskell. In fact, traditional building of C/C++ software with autotools is supported in Nixpkgs better than building modern stuff like Rust or Go, due to reliance of the latter on own package managers. [1] https://insatia.kozinaka.com/ https://insatia.kozinaka.com/ [2] https://nixos.org/guides/nix-pills/index.html https://nixos.org/guides/nix-pills/index.html

tomlin 6y ago

Odd choice for a name, since Nix is a registered trademark of another tech company.

domenkozar 6y ago
Link?

johndoe42377 6y ago

No. Unnecessary, redundant abstractions and wrapping is never the answer. Standardized interfaces and protocols are. Erlang and Go got it right.

codethief 6y ago

A few days ago, I came across RobotNix[0] which uses Nix to deterministically build custom Android images. Since I really want to adapt Android to my needs but have always struggled with building it on my own (what a shitty and complicated build system), I'm now very inclined to learn Nix. I'm not sure I like the syntax but hopefully I'll get used to it. Another reason I'm quite excited about Nix is that in my team we're currently using a whole bunch of tools like pip, Conda, npm all at the same time to manage our dependencies and it's starting to become really cumbersome to set up the dev and production environments correctly across different operating systems and architectures. For instance, Conda doesn't exist on arm64, lots of pip packages have to be compiled by hand on arm64 etc. etc. It's a mess that I'd love to get rid of. [0]: https://github.com/danielfullmer/robotnix/ https://github.com/danielfullmer/robotnix/

__jem 6y ago

I've gotten into NixOS for my personal daily driver, but I'd love to see more resources about how to orchestrate CI/CD flows with Nix. It's not totally clear how I'd move from the simple single machine configuration I have now to packaging a large monorepo and deploying it.

grandinj 6y ago

Nix sounds like SELinux. A great idea in theory, but in practice just too hard. There is a great deal of genius in coming up with these ideas. There is just as much genius in finding the 80-90% solution that incorporates most of the original, but in a workable way. Looking forward to seeing where stuff like Nix ends up.

fctorial 6y ago
You'd be surprised how well a nixos system works. Every other distro looks like a meme in comparison, for development work at least.

llaolleh 6y ago

Nix sounds great in theory, but it's just not there yet unfortunately. I tried it out but there were just too many workaround to setup my work environment.

bpiv400 6y ago

Great post! I'm working on a project called Flox that's trying to make Nix easier to use for beginners and easier to scale for enterprises. If that sounds interesting, you can sign up for the public beta: https://www.floxdev.com/ https://www.floxdev.com/ Here's an announcement blog post about our initial release: https://discourse.nixos.org/t/introducing-flox-nix-for-simplicity-and-scale/11275/9 https://discourse.nixos.org/t/introducing-flox-nix-for-simpl...

bfrog 6y ago

I use nix today for ci/cd to build a large C++ project for a variety of architectures using cross-compiles. While it could be done with adhoc scripts, some cross compiler tool environment tool + conan, or something else, I effectively wrote my nix expression once to package up everything, and simply changed the target arch and libc and got what I wanted. It's not perfect, but it works, its fast, and its better than the alternatives. I'm interested in rying Guix at somepoint instead as I think using Guile might be easier than learning the Nix language, cli tools, and more. I think guix could do much what I do now as well. I can't see myself using guix as an OS though, since they seem to think systemd is evil or something, and really systemd is quite nice in practice in my experience.

lfam 6y ago
Hey, we're glad to hear you're interested in Guix :) I just wanted to say that Guix doesn't hate systemd, or think of itself as an anti-systemd project or anything like that. Systemd was not chosen because GNU already had a (quite simplistic) init system written in Guile Scheme, and we want to use Guile for the entire system. Eventually, our goal is to offer a fully integrated interface for managing the system, just like systemd. We are not there yet :)
- kaba0 6y ago
  Is it really wise to go against such important/widely-used part of the linux userspace? I do find Guix as cool as NixOS, but this decision seems like a self-inflicted wound. Nonetheless, I should definitely get to know the project more, because it was some time ago I tried it last. So, Good luck with the project! :)
  - lfam 6y ago
    I agree, it could be seen as a self-inflicted wound. I'm a Guix developer but I still use Guix on Debian for important deployments, mainly because of systemd / journald. But, we could also think of it as an opportunity. Well, I hope you'll find Guix useful and enjoyable, and maybe even help us improve it :)

skratlo 6y ago

Even though the article sounds like it's written by educated person, it puzzles me that the author: > Installing packages with APT is not atomic: APTs updates files in-place one by one. Because we start Python processes many times per second, if one started during a deployment, it could import a mix of the old and new code. This regularly lead to puzzling bugs Don't you stop all your services in preinstall and start them again in postinstall? Or, if you're packaging your python libs in deb pkgs, just stop the services before upgrading the system and start them again once you're done.

ruuda 6y ago
This part is about batch jobs that we start, not about daemons. The APT package would take about a minute to install, but some of these batch jobs are started by a user interaction, and we can't delay them for that long.

jarvuschris 6y ago

Chef's Habitat is a really powerful nix-like system that I find to be a bit more practical. Like nix though it suffers from being a complete paradigm shift that people coming in from the imperative OS world struggle trying to map their existing patterns into It's kind of sad because it's a far better way to manage deployments and environments...but it takes 1-2 years of practice to really get proficient at

aszen 6y ago

To truly appreciate what nix provides, take a look at this example script that uses nix-shell as interpreter and marvel at the fact that running it is as simple as running a binary after you have nix installed. ``` #!/usr/bin/env nix-shell #!nix-shell -p "(pkgs.haskellPackages.ghcWithPackages (ps: [ ps.text ]))" #!nix-shell -i runghc {-# LANGUAGE OverloadedStrings #-} import Data.Text.IO main :: IO () main = Data.Text.IO.putStrLn "Hello, World!" ``` While nix is sometimes hard to learn, it is often a much simpler solution and it works for all languages so learning it is well worth it.

Wazzymandias 6y ago

Nothing should be labeled as the ultimate devops toolkit when its documentation is as atrocious as nix People can commend it as much as they want, but the steep learning curve is largely self inflicted because of their resistance to writing clean, comprehensive, up to date docs It has also led to the community being filled with a lot of arrogance and pretentiousness I wouldn't run nix in production because of the lack of accessibility and toxic community. There are other ways to get reproducibility, etc without using an arcane and poorly documented toolkit

hinkley 6y ago
> It has also led to the community being filled with a lot of arrogance and pretentiousness I would conjecture that you have cause and effect reversed. When people think they're doing you a favor, the ego protects itself from hearing how their help is not actually that helpful. See aid to Africa in the 80's and 90's for example.
kaba0 6y ago
Any concrete reason you call such a niche, but large community toxic?
- Wazzymandias 5y ago
  It's been mostly from personal experience, though I shouldn't generalize to the community as a whole. Anecdotally my experience with nix community has been unpleasant. They're very resistant to suggestions and offer little in terms of guidance or documentation.

TobyBrull 6y ago

Not a Nix user, but I spent some time trying to understand it. One thing that I wish I would have understood earlier is that "Nix Pills" is a decent, bottom-up Nix tutorial and probably a good place to start. Initially I thought "Nix Pills" was just a collection of recipes ("Nix By Example"), but it is not.

earthboundkid 6y ago

I think it's interesting that the motivating usecase is Python. Python's dependency management is extremely bad and many tools exist just to try to cover up how bad it is without solving the core problems. Would Docker have ever become popular without Python?

brunojppb 6y ago

The article is very interesting. Although until the middle of the article I could make little sense of it because I had no clue what Nix was (have never heard of it), until I reach the part where Nix was introduced. Seems to be a very interesting tool.

camehere3saydis 6y ago

Reading some of the comments here, it feels like one needs to lay out a lot of context before being able to describe their Nix experience. (Is that Conway's law in reverse, or just Occam's beard? I can't help but wonder.) And I gotta get back to trying to build Deno from Git with Mozilla's overlays. Thankfully, Nix pairs well with git submodules...

mrtweetyhack 6y ago

"The Nix programming language" as if I needed to learn yet another language

timka 6y ago

I feel like I'm a veteran looking at my stack overflow question from 2009. Basically we had our own approach to the problem using FreeBSD. Also, Nix is among the proposed solutions. https://stackoverflow.com/questions/1316716/reproducible-custom-distribution-build-system-for-linux https://stackoverflow.com/questions/1316716/reproducible-cus...

nwmcsween 6y ago

Well mix was a no go for me for a few technical reasons: * No multihost support, I want to share / between many hosts, nixos ideas support this but the implementation doesn't (and no I don't want to just share the nixstore) * No package security, ideally package deps chains should have a per user/group created which won't allow broken programs from rm -rf / or worse. * Nixos treats a filesystem as an object store, this goes against how most Unix tooling works (e.g how many Unix tools take a s3 obj?) Things that might be incorrect on my part: * No config validation, minor and hard though it would be nice if nixos had config validation. * Single hash for store objects(?), it would be nice to use something like TLSH, etc in addition to a crypto hash