Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My First Impressions of Nix

mtlynch.io

Post reply on HN
Print view View original

261–270 of 354 posts

Re: My First Impressions of Nix

#261

Post by Cu3PO42 »

lolinder wrote: post #145
hamandcheese wrote: post #41

Earlier quoted context omitted.

It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpk…

Doesn't this auto-upgrade behavior punch straight through the reproducibility Nix is supposed to be giving you? It's not exactly a functional build system if the results you get depend on when you download the dependencies. (I mean, I guess you could say that time is an input to the function, but that seems to miss the point.)

Using Flakes, you can lock the version of nixpkgs (and any other repository) to a certain commit, and that commit is an input to the function. When you update that commit, of course the build changes, but I'd say that's pretty expected. If you don't upgrade it, you'll keep the prior versions.

Now this only works as long as you keep your package outside of he main nixpkgs repository, once you upstream it you're locked into the versions of packages that are "currently" in nixpkgs in the same commit. Builds are still reproducible, because you select the commit you build, but your package might break if a dependency changes in an incompatible way. If that happens, there's a problem with either the definition of the application or the dependency. In the given case it sounds like there might be an issue with the package of the application since it seems it doesn't lock down the precise version of Django that it needs.

Re: My First Impressions of Nix

#262

Post by soraminazuki »

mdaniel wrote: post #248
Cloudef wrote: post #81

Earlier quoted context omitted.

If you have OSX, it's much more reliable and better option than homebrew, so there it would pay off immediately

Just for your consideration, the network effect is very real with package managers, too: https://search.nixos.org/packages?channel=23.05&show=awscli2 is 2.11.27 (even on the "unstable" channel), versus https://formulae.brew.sh/formula/awscli#default that is 2.12.1, which correctly is the most current ( https://github.com/aws/aws-cli/tags )

This is incorrect. Nixpkgs updated to 2.12 on the same day as Homebrew.

- Nixpkgs (3 days ago): https://nixpk.gs/pr-tracker.html?pr=238031

- Homebrew (3 days ago): https://github.com/Homebrew/homebrew-core/pull/133968

Your link refers to the 23.05 stable release channel, so it'd likely stay at 2.11. Package updates don't get backported to stable channels except for fixes. Additionally, the package search page probably isn't updated in real time so the version might be slightly out of sync.

Nixpkgs is generally quick to update packages because Nix encourages automation.

Re: My First Impressions of Nix

#263

Post by ElectricalUnion »

thumbuddy wrote: post #158
SuperSandro2000 wrote: post #150

Earlier quoted context omitted.

> Extremely complicated and hard to understand That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class. > projects that use it have builds fail anyway The point of Nix/NixOS is not to have no fa…

I've never seen it actually pay off in industry. I've seen it be used as good job security while other devs just wrote docker files and got things done.

In my experience those "others" that "just wrote docker files" are exatly the ones that don't know how to build the system in a reproducible manner if their ci environment gets reset for some reason as they find out that stuff that was "supposed to be there, pinned and configured" wasn't.

Re: My First Impressions of Nix

#264

Post by troupo »

kertoip_1 wrote: post #218
troupo wrote: post #5

> A lot of Nix documentation I’ve found says things like, “Simply add these lines!” > Huh? > Which file? And where in the file do I add those lines? This issue is prevalent everywhere . Even the best documented projects fail into this trap almost immediately.

That's why I like documentation with the comment section. Even if something's missing, there is a good chance someone asked about it. Also comments section provides an instant feedback to people writing posts to that documentation.

While I wholeheartedly agree, you need a full-time moderation team if you want to enable comments.

Re: My First Impressions of Nix

#265

Post by totallywrong »

colordrops wrote: post #256
totallywrong wrote: post #214

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.

Sounds interesting. Is rpm-ostree config declarative? Can it install multiple versions of packages and libs simultaneously? Are adding custom packages to your setup a matter of a few lines of additional config, or must you learn RPM? Can you manage home directory config as well?

There's the treefile [1] for declarative config, no need to learn RPM, just add package names and any extra config. As for managing home and multiple versions simultaneously, I think those are non-goals for this tool.

[1] https://coreos.github.io/rpm-ostree/treefile

Re: My First Impressions of Nix

#266

Post by thumbuddy »

justinhj wrote: post #173
ParetoOptimal wrote: post #149

Earlier quoted context omitted.

> In my opinion the problem it attempts to solve doesn't really exist. It does, but some people are good at numbing themselves to it. So they block losing a day or half day from lack of reproducibility out of their memory or recall it as "no big deal".

Nobody loses time on Nix issues?

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.

Re: My First Impressions of Nix

#267

Post by ElectricalUnion »

duped wrote: post #186
lillecarl wrote: post #146

Earlier quoted context omitted.

You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is n…

> Run the nix installer Ok and this requires root access, sets up some global directories under root, and a new user. Me as the administrator: why the hell do I need a new user and what is the nix store and what are the conditions that mutate it? (I know the answers to this question, but it's a barrier for people who give a shit). > Enable flakes What the fuck is a flake? Reads a bit... what the fuck is a derivation?…

> > Run the nix installer

> Ok and this requires root access

On a tangent: I wonder why this is still the default.

The nixStatic binary has, since quite a while, support to as a non-root user create a "${XDG_DATA_HOME:-${HOME}/.local/share}/nix/root/nix" -> "/nix" unshare chroot before running the rest of the command if "/nix" is missing.

It's only a real issue if you really need to run something as root, or something else that needs unshare chroot itself, but in that case, I guess you could just have a /nix store folder anyways.

Re: My First Impressions of Nix

#268

Post by thumbuddy »

skulk wrote: post #172
thumbuddy wrote: post #158

Earlier quoted context omitted.

I've never seen it actually pay off in industry. I've seen it be used as good job security while other devs just wrote docker files and got things done.

Then you're not paying enough attention. There are plenty of companies using nix to distribute a reproducible environment (if you don't believe me, why not go search GitHub for "flake.nix" and see how many "industry" repos you find). I think it would be more productive for you to sit down and give it a fair chance than posting little rebukes all over this thread.

I gave it a fair chance and it was a deciding factor in why I left a company believe it or not. Only one person could maintain and fix deployments. Not from lack of trying from seasoned experts and no new comers. It was the worst user experience I have probably ever encountered. Meanwhile I was able to pick up terraform and docker in a matter of days...

Re: My First Impressions of Nix

#269

Post by mtlynch »

hamandcheese wrote: post #210
mtlynch wrote: post #116

Earlier quoted context omitted.

Author here. Thanks for the clarification! I'm still new to Nix, so I'm trying to share useful things I'm learning without overstepping my expertise and saying wrong things. My mental model of Nix was that if I'm in system state A, which is the result of performing task X + Y, and I want to get to system state B, which is the result of task X + Y + Z, then Nix would recognize that it's already in state A, so it only…

That's largely correct! To use more precise language, let's discuss two distinct phases: building and activation. Nix will always "build" x, y, and z. But x and y might turn into a no-op by being cached in the nix store. System activation is when all those things are symlinked into place. If x, y, and z are, say, systemd services, then there might be some logic that checks if x and y have changed and if the services…

Ah, okay. That makes sense. Thanks!

I've updated the post based on your feedback.

Re: My First Impressions of Nix

#270

Post by thumbuddy »

ElectricalUnion wrote: post #263
thumbuddy wrote: post #158

Earlier quoted context omitted.

I've never seen it actually pay off in industry. I've seen it be used as good job security while other devs just wrote docker files and got things done.

In my experience those "others" that "just wrote docker files" are exatly the ones that don't know how to build the system in a reproducible manner if their ci environment gets reset for some reason as they find out that stuff that was "supposed to be there, pinned and configured" wasn't.

In my experience the months required to get a handle on Nix is not worth the benefit(which is shakey in my opinion) compared to competing technologies. We don't have to agree, but that's my take...
Post reply on HN