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

271–280 of 354 posts

Re: My First Impressions of Nix

#271

Post by thumbuddy »

SuperSandro2000 wrote: post #191
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.

If you have something easy to deploy like a go binary you can just write a dockerfile but for big python projects that start to compile dependencies that is quickly no longer true. The dockerfile likely is also not matching the software you run and test on your local machine, so sometimes debugging is not as easy. Ofcourse you can debug inside the container but then you are missing all your tooling and need to bring…

Most people would opt to not apply patches to their dependencies in my experience. Seems kinda sketchy if that's something you have to do on a regular basis. I'd chalk that up as a possibly serious business concern depending on the magnitude of the fixes, the importance of the dependency, and the frequency.

Re: My First Impressions of Nix

#272

Post by pxc »

Great writeup of your first impressions! Looks like your questions are mostly answered, or at least you have starting points for most of them, so I'll leave those aside.

Thanks for giving such a detailed writeup of your early experiences with Nix!

Re: My First Impressions of Nix

#273

Post by tadfisher »

kaba0 wrote: post #230
xxpor wrote: post #219

Earlier quoted context omitted.

Almost everything here is valid, but iirc the last time I ran the nix installer I thought it offered a home directory based install now that doesn't require root.

You can use in theory something other than /nix, but then you have to recompile everything yourself. So not many people do if, not sure about it’s state.

I think this is only true if your distro doesn't have user namespaces enabled, and many popular ones do not for security reasons.

Re: My First Impressions of Nix

#274

Post by tadfisher »

omnicognate wrote: post #208
dezgeg wrote: post #96

Earlier quoted context omitted.

> The solution was to tell nix to disregard the nix store, in order to force the local build. If this actually led to avx512 being enabled in the package, then that's a bug. Nix builds should not be dependant on the machine doing the compilation, all such autodetection should be disabled via configure flag or patched out. Then, the right way to enable avx512 would be to pass some 'enable avx512 please' flag to the pa…

It is, but the possibility of such bugs is a downside to the approach (not saying it's a showstopper but it is a negative). Some of the nastiest software problems to track down are the ones that cause some fundamental assumption everything rests on (often a cache keying assumption!) to be broken, making everything behave wrong, including the tools you're supposed to use to track down problems. If you're going to buil…

There is work being done to address outputs by their content hash instead of xor-ing their input hashes, which in theory should eliminate this problem.

Re: My First Impressions of Nix

#275

Post by raffraffraff »

thumbuddy wrote: post #107
adamgordonbell wrote: post #92

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…

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

A friend of mine said that he is currently using it instead of packer at his current gig. He can use the same code to build any type of output, AMI, docker image, VM etc. I dig that. But I'm still not gonna learn nix because I don't do enough of that stuff to warrant the pain of learning nix.

Re: My First Impressions of Nix

#276

Post by pxc »

thumbuddy wrote: post #266
justinhj wrote: post #173

Earlier quoted context omitted.

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.

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, learn how the sausage gets made in the upstream package, make some choices about if/where to compromise, and then spend some time tweaking and debugging. That can be a pain and can definitely take a day or two.

I've only had 'maintenance' issues with Nix itself on macOS, where OS upgrades routinely nuke Nix's hooks into the OS or add restrictions that break things. (But they do that to other package managers as well.)

Re: My First Impressions of Nix

#277

Post by colordrops »

totallywrong wrote: post #265
colordrops wrote: post #256

Earlier quoted context omitted.

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

I meant creating an entirely new package from scratch.

Regarding non-goals - I think that exposes the fundamental difference. rpm-ostree isn't "better". It's trying to solve different problems. The use case you described is a very small part of what Nix makes possible. Nix isn't just trying to fix or improve on existing systems - it present a fundamentally new abstraction that can be used for many purposes. Yes, you can configure and snapshot a list of packages, but that's a tiny part of it. With Nix, the capability allows you to also create any environment from scratch, isolated from other environments on your machine, e.g. for CI or development, or running some obscure python repo.

It's like the difference between SVN and git.

Re: My First Impressions of Nix

#278

Post by ParetoOptimal »

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?

They do, but the people who spend time on Nix issues don't typically notice or count the time saved because it's harder to notice.

When reproducibility issues take 16 hours every 3-4 months/12 weeks and Nix maintenance like updating pins takes 8 hours per month most will feel like the first option is less work.

Imagine if you had the data showing with Nix your build is:

- 99% likely to work

- without Nix your build is 90% likely to work, but 16 hours to fix it when it breaks.

- The non-Nix build also has a 10% chance of it breaking randomly at any time.

- The nix build initially takes 8 hours per month to maintain for 6 months, 4 hours for the next 6 months, then 1 hour per month thereafter

Which do you feel would be better? What I describe above has been what the situation seems to be in my experience.

Re: My First Impressions of Nix

#279

Post by mindslight »

SAI_Peregrinus wrote: post #164
prox wrote: post #136

Earlier quoted context omitted.

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

Yes. E.g. some guy's config with 6 different machines[1]: multiple desktops, laptops, servers, a Raspberry Pi, and a VPS. That's a rather advanced use of Nix for configuration, but definitely shows what it's capable of. [1] https://github.com/Misterio77/nix-config

I wouldn't even say that's so advanced. I've got a similar scope config (not published, sorry). All built from source, with the resulting binaries pushed to less-trusted hosts. My cloud servers, router, wifi APs, Kodi boxes, etc, all running self-hosted self-built software with config kept in git.

Previously I ran Debian across my setup (with a homemade configuration templating/distribution tool) but it feels like Nix really bundles up the accidental complexity of installing/deploying most software in a contained way, much more than a traditional distro.

I'll be much happier when Nix gains full reproducibility and functionality like Guix's `challenge`. But even now it feels like one of the closest implementations to the Free Software dream.

Re: My First Impressions of Nix

#280

Post by pxc »

fbdab103 wrote: post #233
kaba0 wrote: post #230

Earlier quoted context omitted.

You can use in theory something other than /nix, but then you have to recompile everything yourself. So not many people do if, not sure about it’s state.

I just dipped my toe into the Nix pool a couple of weeks ago, and there are instructions to use root to create a /nix and grant ownership rw to your user account. No further admin required, but everything else seems to work as if using the Nix root user method.

The installer used to have an option for this, but nowadays it's discouraged. How come you wanted a single-user install so much? And j/w, are you on macOS?
Post reply on HN