Live data from Hacker News

Nix is the ultimate DevOps toolkit

tech.channable.com

81–90 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#81

Obligatory link to its cousin: 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).

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.

Re: Nix is the ultimate DevOps toolkit

#82
post #46

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 h…

I’m in the same boat. Love using it day to day (dropping into nix-shell to try something e.g.). Love administering the systems when I need to make small changes or do things I already know how to do.

Absolutely dread having to figure out something new.

Re: Nix is the ultimate DevOps toolkit

#83
post #59
post #51

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 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…

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.

Hear hear! The desire to make the experience "familiar" for users of apt causes way more confusion once you start actively using it.

Re: Nix is the ultimate DevOps toolkit

#84
post #36
post #26

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

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.

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.

Re: Nix is the ultimate DevOps toolkit

#85
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/

[2] https://nixos.org/guides/nix-pills/index.html

Re: Nix is the ultimate DevOps toolkit

#86
post #77
post #60

Earlier quoted context omitted.

Could you elaborate what you mean by this? Nix has lazy evaluation so as Nixpkgs grows it doesn't perceptibly change how long package installations, building, etc. take.

When I run `nixos-rebuild switch --verbose`, it does seem to go through the entirety of nixpkgs. Especially noticeable on a RPi with its slow I/O.

It's not true that it pulls in everything. It's just that a nixos installation pulls in a lot of transitive code =). It actually pulls all of this in lazily and lazily evaluates it; but it's just a lot of code and nix evaluator isn't that fast.

Re: Nix is the ultimate DevOps toolkit

#87
post #55
post #51

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 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…

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 i…

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

Re: Nix is the ultimate DevOps toolkit

#88
post #44
post #32

Earlier quoted context omitted.

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?…

> How exactly, command by command, would nix solve the same problems? This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. I could show you a `nix-build -A deploy.som…

>This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier.

That's the entire point of a tutorial like GP describes. Yes, Nix works on a higher level of abstraction than existing tools, but it solves the same problem, and comparing it to "alien technology" doesn't help.

Nix is simply:

* a large corpus of work (nixpkgs; which contains build instructions for source code that can combine all the way to an operating system or a service image)

* organized in a particular way (using the Nix language; used to declare the expected results of all the different build strategies out there)

* and coupled to the tools that let you turn a description of a process into the result of that process (nix-build, etc).

This is abstract but hopefully less handwavy? The concrete details of the Nix paradigm really lie in the syntax itself so what you're saying about "same tools with different syntax" doesn't make much sense to me, as every programming tool is defined by its syntax.

The on-ramps to becoming fluent with the Nix language are, admittedly, subpar. I got nearly nothing out of "nix-pills" and cringe every time someone recommends that tutorial which takes 10 chapters to build your first package in the most roundabout way possible.

What Nix needs is a single page specifying what goes in a Nix derivation. Like the Compose YML reference but simpler. Also the nixpkgs manual is quite central but impenetrable for casual reading. Also how about someone writing a tutorial for generating a static HTML site with Nix, then deploying it, then incrementally adding dynamic backend services to it?

Re: Nix is the ultimate DevOps toolkit

#89
post #71

Earlier quoted context omitted.

Agreed, but perhaps they should officially adopt home-manager then? It felt strange to me that the best way to be using nix was a separate community project.

I don't use nix-env or home-manager. On my NixOS workstation everything (outside of nix-shells) is installed via environment.systemPackages. And I do wish there was an easy way to add stuff to install packages without rebuilding the whole system - I guess that's what nix-env is for but if I went with that I would the "single editable config file that you can put in VCS" aspect. I think nix-env uses profiles, which ar…

https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...

Re: Nix is the ultimate DevOps toolkit

#90
post #59
post #51

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 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…

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.

That's the long term plan, once the new command line stabilizes.
Post reply on HN