Live data from Hacker News

My First Impressions of Nix

mtlynch.io

281–290 of 354 posts

Re: My First Impressions of Nix

#281
post #136

Earlier quoted context omitted.

So does this allow for different boot setups for NixOS? Say “webserver” or “office management” , “media streamer” profiles?

I'm not exactly sure what you mean. NixOS doesn't have, like, a profile switcher to let you switch between work mode and play mode on the same PC. At least not out of the box. But if you mean distinct computers, then that's just three distinct configs. And it's easy to factor out common bits and use it in all three configs, since you configure things using Nix-the-language. And if you mean all three at the same time…

> NixOS doesn't have, like, a profile switcher to let you switch between work mode and play mode on the same PC.

I thought that `sudo nixos-rebuild switch` was supposed to do exactly that; swap from whatever "state" your PC is on to the result of the nix expresison on "/etc/nixos/configuration.nix"

Re: My First Impressions of Nix

#282

Earlier quoted context omitted.

Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…

> Part of the difficulty is it means different things to different people. That's definitely how it seems to me. The pro-Nix stuff I see is generally about the theory much more than the practice. Which was also my experience with functional languages when their hype cycle was last on the rise. On the one hand, that's fine. I like ideas, and I think taking an idea and running with it can be really interesting. You can…

This is probably a pretty good read on the situation. People who have really thrived with Nix are often at the intersection of 'FP people' and 'extremely stubborn Linux people', and that's because sometimes it takes getting your hands dirty and fighting a build system that belongs to a package you've never used before to get the Big Ideas to pay out. When the footwork is already relatively familiar to you, it makes it easier to push through whatever obstacles there are to playing with those attractive Big Ideas in practice.

The Nix community's roots are definitely with FP people, partly due to the language and its inspiration and design, and partially also due to early success using Nix to solve particularly painful Haskell dependency hell problems years ago. All of the original 'marketing material' for Nix focused on principles and properties that would be attractive only to people who already knew and valued those things, which was mostly FP folks.

> Perhaps [Nix] will influence more mainstream projects, bringing the benefits to me without a lot of upheaval.

This is definitely already happening. Off the top of my head, Nix has served as inspiration for Guix, Habitat, and Spack, which are all respectable package managers that try to make things a little smoother than they are with Nix in terms of UX. The latter two are also more conventional, with a relaxed notion of 'purity', and so it may be easier to get packages to build in them when those packages are built in problematic ways. (Guix, if anything, is even stricter about packaging conventions than Nix, but it has a really nice CLI and the language might resonate more with some people, so if Nix has given you pain it's definitely still worth trying.

> Perhaps I'll have a project that really needs its particular benefits, and so I'll take on the cost of a paradigm switch. But in the meantime, I have stuff to do.

I love Nix and its fundamental design, and I want to see it flourish and grow, both in general and in my own professional life. But at work, I try to maintain the same attitude as you describe here. I use Nix for myself everywhere I can (with some escape hatches in place!), but for projects that others work with, I only use Nix where I feel that some specific aspect of the project calls for it.

All of that is just to say that even to some folks who really are drawn to Nix in substantial part due to the Big Ideas that power it, your pragmatic stance is quite understandable and entirely welcome.

Feel free to just play around with Nix in a low-stakes way and advance your usage as curiosity or new problems drive you to do so. You don't have to jump all the way in to benefit from Nix or get a taste of it.

Re: My First Impressions of Nix

#284

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

I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes is not exactly an OS, but is a notorious example), but they could make the same mess with any technology. They're just unlikely to pick Nix, NixOS or NixOps (or any alternative to it), because mainstream tutorials won't cover it [yet].

The deployment and learning process is not that different from, say, Arch Linux, or even Debian. You still learn the higher-level interactions (pacman/apt/nixos-rebuild), divert to individual programs, then dive in (.ebuild/dpkg-buildpackage/nix), then learn even finer details as you get hit with nuances. NixOS is absolutely not LFS, where you really go bottom-up. And nixpkgs is covering more and more every day.

Just an anecdote example: I've started with run-of-the-mill tutorial approach on setting up NixOS on single machine, and ran than for a while. Then I've realized my configs are a non-DRY mess and I want to manage my systems in organized fashion, so I've spent a significant amount of time unifying the configurations so I could manage and deploy it with deploy-rs (thinking of switching to colmena now, but that's not relevant). And only at that point I've realized that I'm missing some fundamental bits like signing (aka why nix-copy may fail, and how to deal with this without the trusted-users "see-no-evil" hack), or exact operation of substituters (aka, essentially, binary caches). Because with local nixos-rebuild it's all sort of hidden and I never had any issues.

What makes Nix/NixOS different are its fundamental principles, not how one approaches it. Starting somewhat more low-level than with "just works" tools is just a popularity issue: more rough edges, so one needs to learn how to polish them.

Re: My First Impressions of Nix

#285

Now that we have another Nix post, maybe someone can enlighten me about something I've been wondering about. I'm one of the maintainers of a popular django application. Someone made a nix package of the project, but we've now twice gotten invalid bug reports from people using the package because the package depends on "django_4" and whenever someone updates that nix package, the package for our project breaks. Of cou…

It sounds like the package is implemented improperly. If the input from your repo to the package is not targetting a specific commit, it should be.

Building from "latest" is really not how nix is ever meant to operate. In that case, when you update your requirements.txt, it is now out of sync with the package definition; the inputs _have_ changed and your guarantees are gone.

When your project repo is updated, that should never result in a change to what gets installed by nixpkgs until you also update the package to point at that commit and do any work necessary to fix breaking changes. Once you do that work, that version of your package picks up a guarantee to always be producable.

Like another comment mentioned, this is all much easier to accomplish with flakes as they have a lockfile that sits next to the flake, both of which reside in your repo and can be updated atomically with your releases instead of also needing to make a PR for nixpkgs.

I've actually been working on learning how to better package python with nix and found the historical information on python packaging infrastructure in this talk incredibly enlightening (I think this landed on HN a few days back): https://www.youtube.com/watch?v=ADSM4vR2EQ0

Re: My First Impressions of Nix

#286
post #19

If you want to install a package, search for it at https://search.nixos.org The gnome system monitor is gnome.gnome-system-monitor for example https://search.nixos.org/packages?channel=23.05&show=gnome.g...

> If you want to install a package, search for it at https://search.nixos.org

And if this doesn't work, go to https://github.com/NixOS/nixpkgs/issues and search for the name (in both open and closed issues and PRs).

Re: My First Impressions of Nix

#287
post #276

Earlier quoted context omitted.

I can say from personal experience I've seen many days devoted exclusively to Nix upkeep and maintenance. That was from junior people to people who had spent half a decade or so deeply in the community and using Nix for their daily driver.

I've never had to do much for Nix itself, but packaging something to build from source can often require quite some effort. Applications that use a pretty unconstrained build/install process upstream may expect to do a lot of things that are not allowed in the Nix build sandbox, like unconstrained network access and or overwriting files in existing packages on the system. To deal with that you really have to dive in,…

You can mitigate this to some extent by approaching it as described here:

https://www.haskellforall.com/2022/08/incrementally-package-...

I think Graham Christensen had a blog post along these lines... I'll see if I can find it.

Edit: I couldn't find it... but I thought someone made a blog post about gradual adoption of Nix into a codebase.

Re: My First Impressions of Nix

#288

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

How about configuration management? Getting the packages is half the story.

Re: My First Impressions of Nix

#289

Earlier quoted context omitted.

Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?

Not really, unfortunately. In my opinion, Nix is more like using Haskell instead of whatever language your team is using to write software.

> Nix is more like using Haskell instead of whatever language your team is using to write software.

In my professional experience, this has worked well :)

Re: My First Impressions of Nix

#290

Earlier quoted context omitted.

This matches my experience with it so far. Extremely complicated and hard to understand, projects that use it have builds fail anyway except now with very hard to debug errors.

When a nix build fails it'll fail with errors from the build system the package uses. The upside is that your failure is now reproducible.

Good point. I'm much more likely to help others because I know I can get to the exact state they are in and reproduce their issue with a simple `nix build`.
Post reply on HN