The Curse of NixOS • Hacker News Board

Re: The Curse of NixOS

#351

Post by mindslight » Tue, Jan 25, 2022, 10:10 PM UTC

rnhmjoj wrote: post #347

mindslight wrote: post #342

Earlier quoted context omitted.

Ah, I had forgotten `override` is easy. Rereading that page I still don't get the difference between `overrideAttrs` and `overrideDerivation`. `overrideAttrs` is newer and preferred, yet it doesn't spell out where you cannot use it and have to fall back to `overrideDeriviation`. And looking through my Nix code I've got various uses of `overrideDerivation`, which most likely means I tried `overrideAttrs` only to have…

I think the manual is intetionally flying over `overrideDerivation` because it shouldn't be used. To understand the difference you'd have to know that `stdenv.mkDerivation` is a library function that wraps the Nix primitive `builtins.derivation`, which is what actually makes a derivation. `overrideAttrs` changes the arguments of the former, while `overrideDerivation` changes the arguments of the latter. The reason is…

Thank you for explaining the difference! I think the manual would be better served by an explanation like that, rather than just implying that `overrideDerivation` may still need to be used for some unspecified reason. I'll have to revisit my uses and see why `overrideAttr` didn't work for me. Perhaps I was using the wrong argument name.

Re: The Curse of NixOS

#352

Post by yesbabyyes » Tue, Jan 25, 2022, 10:30 PM UTC

JamesSwift wrote: post #337

yesbabyyes wrote: post #287

Earlier quoted context omitted.

As someone who really likes the idea of declarative system configuration and management, shares the vision of nix and guix, and have been dipping my toes by using nix package management on macos (and sharing most of the experiences mentioned upthread): I do thank you for the pointer, and I think I've come across these videos before, _but_ to me, video is probably the last format I can assimilate this type of informat…

> well designed systems have a way of making sense so that documentation and understanding flows naturally from base abstractions Honestly, thats the main revelation I had when going through that playlist. Basically Nix is just attribute sets (which is sort of just a JSON object). The entire thing. Nix files are just some preamble and then they return an attribute set at the end. Understanding that will get you 90% o…

I hear you, I think I understand what you mean and I definitely want to believe you, but how come this can't be explained in a succinct written documentation, instead of a series of video tutorials by example?

I do realize it's a work of passion done by numerous volunteers, to whom I feel gratitude, but at this point, why can't this be adequately defined, in a written form, in a way that is understandable? To me, the concept of a series of projections of declarative configuration statements onto a final state is not hard to understand in itself; yet, I am somewhat struggling to create and maintain such a configuration without feeling that I am just copypasting bits and pieces from random people.

I guess I just have to bite the apple and spend a few days watching YouTube to see if I reach enlightenment - at this point, I barely understand the function names.

Re: The Curse of NixOS

#353

Post by cwp » Tue, Jan 25, 2022, 11:35 PM UTC

carlmr wrote: post #320

cwp wrote: post #263

Earlier quoted context omitted.

The trouble is that it's the foundational ideas that people find weird and difficult. Functional programming is still niche and so both immutable package installations and nix-the-language don't build on what people already know. I hope that'll change over time, because yeah, the foundations are /so/ powerful, even today.

I learned F# before ever touching Nix. And it's not the functional nature that's the issue, rather the terse syntax, sparse documentation of plenty of special functions you need, and so on that make it an issue. It's hard to find out how to do things, and often you find two examples with a partial solution that each use a very different incompatible way to get there. I think the core idea of Nix is good, but we need…

Well, if you're comfortable with functional programming, that's great. Seriously, awesome! But you're in the minority.

Hard disagree on the "decent programming language designer", though. Nix-the-language is beautiful. It's tiny, with a minimum of concepts to learn, and very simple, regular syntax. At the same time, it's not so spare as say, Lisp or Scheme. It's really good. The implementation of that language could use some work - interpreter speed and debugging tools come to mind rather quickly.

I think the problem you've encountered is nixpkgs. It's a huge, sprawling code base with a lot of legacy code and a number of paradigms that were enthusiastically adopted and then later supplanted. In contrast to the language and tools which are well documented, there's basically no documentation, and what little there is hasn't been kept up-to-date as things change.

Still though, I think the biggest issue facing nix users is that the rest of the computing world works on the assumption of mutable software installations. The way pip assumes that the python interpreter and the python packages that have been installed are locked in a death grip drives me nuts. Even if you don't go full nix-store, could we at least separate those things? Even node gets that right.

Re: The Curse of NixOS

#354

Post by JamesSwift » Wed, Jan 26, 2022, 12:29 AM UTC

yesbabyyes wrote: post #352

JamesSwift wrote: post #337

Earlier quoted context omitted.

> well designed systems have a way of making sense so that documentation and understanding flows naturally from base abstractions Honestly, thats the main revelation I had when going through that playlist. Basically Nix is just attribute sets (which is sort of just a JSON object). The entire thing. Nix files are just some preamble and then they return an attribute set at the end. Understanding that will get you 90% o…

I hear you, I think I understand what you mean and I definitely want to believe you, but how come this can't be explained in a succinct written documentation, instead of a series of video tutorials by example? I do realize it's a work of passion done by numerous volunteers, to whom I feel gratitude, but at this point, why can't this be adequately defined, in a written form, in a way that is understandable? To me, the…

Yeah like I said, I struggled for a couple _years_ on having a feeling of complete confusion when copying a shell.nix to every project I spun up. I was never able to understand _any_ of the written documentation. After that playlist I easily click through the actual nixpkgs repo itself and find almost everything I need to handroll my own derivations.

It seems like the community is just a bunch of people who have had that lightbulb go on already, so its hard to go back and view things without the lightbulb on.

Re: The Curse of NixOS

#355

Post by haolez » Wed, Jan 26, 2022, 7:24 PM UTC

jonringer117 wrote: post #316

haolez wrote: post #273

Is NixOps still a thing? It might be cool unifying nixpkgs with cloud infra, although Terraform and friends seem to already provide 80% of the value of such a solution.

terraform is more about reconciliation of a configuration, and moving a state closer to a desired end state. NixOS is congruent configuration management. There's a 1 to 1 correlation of configuration to reality, with no configuration drift.

I meant NixOps, not NixOS :)

Re: The Curse of NixOS

#356

Post by rekado » Thu, Jan 27, 2022, 10:05 AM UTC

georgyo wrote: post #265

rekado wrote: post #143

Earlier quoted context omitted.

We don't use patchelf for any official package definition. We have a package for patchelf, but it's only really useful when you have pre-built binaries that you can't rebuild from source.

The main guix monorepo may set that hard requirement the everything just be built from source, but if you want to run closed source software than your only two options are make a fake FHS or use patchelf. Both methods have pros and cons. Only patchelf makes the result work well with other closed source programs. While from a philosophical point of view guix is pure, real world usage often needs closed source software…

Yes, for pre-built binaries you can't really get around patchelf. For example, that's also how CUDA is packaged for Guix.

Re: The Curse of NixOS

#357

Post by MayeulC » Thu, Jan 27, 2022, 3:44 PM UTC

nh2 wrote: post #259

MayeulC wrote: post #114

Earlier quoted context omitted.

Guix has graft for something similar to this: https://guix.gnu.org/manual/devel/en/html_node/Security-Upda... It's one of the points where it differs from Nix.

Is this different from Nix's `system.replaceRuntimeDependencies` posted in the sibling comment?

I was hoping to get an answer to your question as well, but I've only used Guix, so I can't really tell.

Guix grafts are used to distribute updates, and they're quite easy to use, that's all I can say.

Re: The Curse of NixOS

#358

Post by carlmr » Fri, Jan 28, 2022, 7:21 AM UTC

cwp wrote: post #353

carlmr wrote: post #320

Earlier quoted context omitted.

I learned F# before ever touching Nix. And it's not the functional nature that's the issue, rather the terse syntax, sparse documentation of plenty of special functions you need, and so on that make it an issue. It's hard to find out how to do things, and often you find two examples with a partial solution that each use a very different incompatible way to get there. I think the core idea of Nix is good, but we need…

Well, if you're comfortable with functional programming, that's great. Seriously, awesome! But you're in the minority. Hard disagree on the "decent programming language designer", though. Nix-the-language is beautiful. It's tiny, with a minimum of concepts to learn, and very simple, regular syntax. At the same time, it's not so spare as say, Lisp or Scheme. It's really good. The implementation of that language could…

>he way pip assumes that the python interpreter and the python packages that have been installed are locked in a death grip drives me nuts. Even if you don't go full nix-store, could we at least separate those things? Even node gets that right.

On this I definitely agree. Like I said I do think Nix is the right thing to do, I'm just thinking the how could be better.

Re: The Curse of NixOS

#359

Post by codethief » Fri, Jan 28, 2022, 6:32 PM UTC

marcus_holmes wrote: post #326

codethief wrote: post #292

Earlier quoted context omitted.

What problems, if I may ask?

working on multiple projects with varied versions of Go from 1.16.1 to 1.17.6. Asdf would switch versions (mostly correctly) for each project, but then the VSCode tools would not and VSCode would refuse to run tests because there was a mismatch between tool version and Go version. Golangci-lint was also a nightmare around versions, and I suspect asdf was involved in this, too. We had 4 separate instances of it (the o…

Did you try teaching VScode about the right version of Go by having it call `asdf exec go` instead of `go`? (Not sure this is possible with VScode but I'd be interested in whether this might be a way out.)

In any case, aren't those issues more of an IDE problem, though? IntelliJ is the same, and the tools you set for one project might even leak into other projects. It's one of the reasons I hate IntelliJ so much.

Re: The Curse of NixOS

#360

Post by parasense » Thu, Feb 03, 2022, 7:59 PM UTC

discardedrefuse wrote: post #220

parasense wrote: post #127

I used to think the ideas of NixOS were great, but then I learned about `ostree`, and in my opinion things like Project Atomic (in Fedora), are probably more pragmatic or straightforward idiomatic implementation of those ideas. In essence the software packages resemble how git works behind the curtain. Git has a bunch of objects with cryptic names resembling hashsum's, and those are the files in your git working tree…

Not just ostree. Using butane / ignition configs to setup coreos is very nice.

Sry for the necropost, but... I just started working on coreos at $dayjob. So your comment struck a nerve, but in a totally good way! :-)

I'll checkout butane / ignition ASAP.

Thanks!