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

201–210 of 354 posts

Re: My First Impressions of Nix

#201

Post by totallywrong »

Cloudef wrote: post #79
mindwok wrote: post #30

Earlier quoted context omitted.

If you're planning on using Ansible for your job or to administer Linux systems, then stick with Ansible. Nix is very niche and you aren't going to see much return on investment until adoption is significantly higher, and I'm not sure that will happen in its current state. That being said if you want to learn Nix for its own sake or because it is awesome, which it is, then have fun!

Nix is gonna save your sanity in the long run however, compared to the ansible mess you eventually end up with.

Hard disagree. In the context of a team, just about any mainstream tool will be more manageable in the long run. There aren't that many people willing to grok Nix and its massive learning curve.

Re: My First Impressions of Nix

#202

Post by dottedmag »

mmarx wrote: post #113
rowanG077 wrote: post #63

Earlier quoted context omitted.

I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.

I guess it should rather say that NixOS provides 1 and 2, since I don't see how it would be ABI compatible to a major distribution.

Yes, that's what I meant.

Re: My First Impressions of Nix

#203

Post by hamandcheese »

jerf wrote: post #170
hamandcheese wrote: post #8

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix…

Quibbling about what is and is not state isn't particularly productive. There is intrinsic and unavoidable subjectivity in the definition of state. The common pattern is to ignore out-of-memory errors, completely ignore the fact that in the real world time-of-execution is irreducibly an observable side effect, and that whether or not a given computation completes may even depend on whether or not an entirely separate…

I'm not quibbling about what state is - the author is very much confusing Nix with something like a control-loop based approach that converges on the desired state by examining the current state. Regardless of your definition of state, that's not what Nix is.

Re: My First Impressions of Nix

#204

Post by dottedmag »

rowanG077 wrote: post #114
mmarx wrote: post #113

Earlier quoted context omitted.

I guess it should rather say that NixOS provides 1 and 2, since I don't see how it would be ABI compatible to a major distribution.

With FHS I'd say it does 3 also.

FHS makes it more similar, but not compatible.

I'll quote from my blog post linked above:

> Different distributions make different choices, and therefore they are closely related operating systems, but not a single OS. Even Linux syscall interface subtly changes from distribution to distribution, as they pick and choose options to build their kernels.

> Every niche Linux distribution that does not follow the interface of a larger one is a unique OS, closely related but not compatible with other Linux OSes. This means the applications have to be ported.

> Application developers have to choose what targets their applications support. With Linux distributions being just a blip on the graph of operating systems popularity, the application developers may not invest significant amount of resources into porting and testing.

Basically, NixOS = zero QA effort from application developer -> nothing works.

Re: My First Impressions of Nix

#205

Post by xwowsersx »

Seeing a tweet like the one from Mitchell makes me want to try Nix. Or at least I want to want to try Nix. Then I read the comments here and am reminded that no one can even succinctly explain what Nix is. I've read dozens of comments here and I still don't have a clear idea!

Re: My First Impressions of Nix

#206

Post by marcosdumay »

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…

> In my opinion the problem it attempts to solve doesn't really exist.

Almost all of Docker use-cases are for solving that same problem, but badly and with partial completeness. The lack of adoption is really not caused by lack of value.

Re: My First Impressions of Nix

#208

Post by omnicognate »

dezgeg wrote: post #96
henrydark wrote: post #40

Earlier quoted context omitted.

I agree with everything but the last statement. This all comes down to: do you consider memoization to be state. I predict people's answers to this question will come from experience with memoization. Here's mine: I kept trying to get nix to build tensorflow locally, so that I would get the avx512 benefits of the big, but gpu-less machine I had. I hadn't realized some other derivation had already downloaded tensorflo…

> 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 build an entire system on an assumption of referential transparency you want to be able to guarantee that everything really is referentially transparent, and one valid criticism of nix is that it can't really enforce that in all cases.

Re: My First Impressions of Nix

#209

Post by ParetoOptimal »

ruuda wrote: post #61
scandinavian wrote: post #43

Earlier quoted context omitted.

I get what you are saying, but nothing you said works in practice for python packages, so not sure that I actually learned anything. Is it fair to summize that python applications with python dependencies do not really work well as nix packages and shouldn't be used?

No, that is not a fair summary; Nix is the nicest way to manage Python packages that I have found thus far.

I'm assuming you try to keep all dependencies on the nixpkgs version?

Re: My First Impressions of Nix

#210

Post by hamandcheese »

mtlynch wrote: post #116
hamandcheese wrote: post #8

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix…

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 are already running and decide what to do -- this is probably the most similar to how Ansible works. But this is also a small part of the big picture. Activation is pretty fast even starting from nothing.

Post reply on HN