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

The Curse of NixOS

blog.wesleyac.com

Post reply on HN
Print view View original

331–340 of 361 posts

Re: The Curse of NixOS

#331

Post by octoberfranklin »

patrec wrote: post #328
octoberfranklin wrote: post #306

Earlier quoted context omitted.

Fair enough, but prepending an adjective to "build script" would still have been a much better choice. Like "elaborated build script". Or "transitively-hashed build script".

I think derivation as a new term of art is reasonable, because it's something that did previously not exist. In particular it's not an "elaborate build script. The actual derivation is basically just a json file¹ with a path-name that's a function of its contents that includes specifying everything that goes into the build (env-var settings and arguments, the input sources, other required derivations, the build scrip…

"elaborated", not "elaborate"

The former means "with all the details spelled out explicitly". The latter means "intricate".

And, I've yet to see a .drv file that contains absolutely 0% shell script. Let's be honest, nix is used mainly as a metaprogramming language for bash.

Re: The Curse of NixOS

#332

Post by ratorx »

jonringer117 wrote: post #247
ratorx wrote: post #201

Earlier quoted context omitted.

> you get to run `nix-collect-garbage` manually If you mean running NixOS (the distro), rather than just Nix (the package manager), then there’s an option for this `nix.gc.automatic`. You may also want to look at `nix.optimise`. When using just Nix however, I don’t know if they bundle the timers.

`nix.gc.automatic` is implemented as a systemd timer to run `nix-collect-garbage` periodically. `nix.optimise` is just a nix conf option. Meaning anytime nix creates a store path, it will automatically dedup files by hardlinking them to a `/nix/store/.links/` path. There's no timer involved with `nix.optimise`. You can manually force existing paths to be "optimised" by doing `nix-store --optimise`

That might be true, but the config would suggest otherwise.

`nix.optimise.automatic` is an option which creates a systemd timer. The existence of an option that creates a timer suggests that it is not automatically deduping the files (or the option is outdated).

Re: The Curse of NixOS

#333

Post by StreamBright »

jonringer117 wrote: post #238
StreamBright wrote: post #213

> The first is relatively simple: they developed their own programming language to do configuration Exactly this. I do not understand why did they do that.

Because it's a domain-specific-language, optimized for packaging software. The relevant passage: > Its only purpose is to describe components and compositions. A component is created through the derivation primitive operation, which accepts all information necessary to build the component. This includes its dependencies, which are other derivations or sources. Full phd thesis: https://edolstra.github.io/pubs/phd-thes…

I understand that but I do not think that packaging is such a difficult subject that justifies a DSL as a new language.

Re: The Curse of NixOS

#334

Post by otabdeveloper4 »

dimsuz wrote: post #290
tikhonj wrote: post #146

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user pac…

Whenever Nix/NixOS gets discussed I always see same points being brought up again and again. And again. I've never seen anything which is discussing solutions or the roadmap (however distant) to solve those issues. Can it be that nothing is happening in this regard or is that really so that people only list same cons over and over again? :)

It's like complaining about C++. It will always be there. Ignore it, it's just people venting about the fact that solving hard problems is hard.

Re: The Curse of NixOS

#335

Post by rekado »

light_hue_1 wrote: post #321
rekado wrote: post #144

Earlier quoted context omitted.

Wow. Not true. You're not kicked out if you "dare" (how brave!) ask a question about it. You're welcome to chat about it on #nonguix. Is it really that hard to accept that #guix is not #nonguix and that we don't discuss proprietary software on the main channels?

> You're not kicked out if you "dare" (how brave!) ask a question about it. You're welcome to chat about it on #nonguix. Is it really that hard to accept that #guix is not #nonguix and that we don't discuss proprietary software on the main channels? So... if I go to the official channel to discuss guix and I said the forbidden word "CUDA" I get kicked off? You wrote a sentence in a tone that implies it disagrees with…

"CUDA" is not a forbidden word. Where does that idea come from?

Here: CUDA, CUDA, CUDA!

If you go to the official channels and ask about CUDA people like me will likely tell you that CUDA is proprietary software, so we don't cater to it in Guix. If you then acted all offended and angry that would be the end of my interactions with you; otherwise I'd tell you the right venue to ask for help with CUDA without starting a discussion of proprietary software on our main channels.

If that's not good enough for you then we're working on incompatible assumptions of how communities work. If you think you're entitled to discuss whatever you want on the community's channels then you're going to have a bad time. Life must be hard demanding of other people to humor you when they really don't want to.

> Guix puts ideology over the welfare of its users.

No.

light_hue puts ideology over the welfare of the community.

PS: CUDA!

Re: The Curse of NixOS

#336

Post by PoignardAzur »

nextos wrote: post #270
throwaway894345 wrote: post #198

Earlier quoted context omitted.

I've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixp…

Have you looked into Guix? In some ways it's a bit simpler and cleaner because it is a much more recent effort and Scheme is somewhat easier. It might help with the learning process in case you disliked Nix. GuixSD does have some other drawbacks. I'm personally running NixOS but both are very cool. Nix certainly has a steep curve, but simple things are not that hard. I got committed to migrate to Nix one Monday. I sp…

> Nix certainly has a steep curve, but simple things are not that hard. I got committed to migrate to Nix one Monday. I spent the whole morning reading about it. In the afternoon, my workstation was already up and running. On the same evening, I packaged two exotic things I need which weren't on NixPkgs. Next day, I fixed my favorite window manager, which was broken on NixPkgs. I maintain all these on NixPkgs now.

I mean... it's great that you did all that, but you do realize that going that far makes you a power user, right?

Most users are going to give up if they can't figure out how to install their window manager or other essential software (eg installing Docker or Steam is ridiculously hard if you don't know that they have special hard-coded config values; it's almost like a game you can only beat if you find the cheat codes).

> With that said, declarative stuff is poised to be harder for non-trivial stuff. Just like Haskell is harder than C, NixOS is harder than ArchLinux or Alpine. I still very much find it worth the effort for simple workflows. I can now update remote machines without fearing breakdowns and state is very explicit.

Hard disagree. I could totally see a world where NixOS is as easy to install as any other distribution. But the developers are going to have to put a lot of work into smoothing out wrinkles before it gets there.

Re: The Curse of NixOS

#337

Post by JamesSwift »

yesbabyyes wrote: post #287
JamesSwift wrote: post #214

Earlier quoted context omitted.

I mentioned it already below, but just to emphasize: I think Burke Libbeys playlist on Nix [1] is that missing piece. It lays down a solid foundation of understanding on what Nix is both conceptually and syntactically. You are then able to derive the rest of the needed understanding by clicking through the nix source of whatever it is you are trying to figure out. [1] - https://www.youtube.com/playlist?list=PLRGI9KQ3…

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% of the way there in terms of understanding the syntax and being able to cut through the "weirdness".

At that point its about understanding actual concepts like overlays, derivations, etc but its much easier now that you understand the attrset concept.

Re: The Curse of NixOS

#338

Post by otabdeveloper4 »

mikepurvis wrote: post #69
otabdeveloper4 wrote: post #15

Earlier quoted context omitted.

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages. I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pre…

> The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages.

No, I'm talking about things like classes, abstract data types, modules, type checking and docstrings.

"Programming in the large".

Nixpkgs and NixOS does its own hand-rolled versions of these for each subproject. Eventually (a long time from now in a galaxy far away) we'll have some sort of standard Nix++ language and standard library.

Re: The Curse of NixOS

#339

Post by 3836293648 »

mikepurvis wrote: post #223
tomberek wrote: post #187

Earlier quoted context omitted.

You can't get rid of all state. The pros/cons of a Nix approach is that it is far more explicit about what is pure/impure. This experience is similar to going from a dynamically typed language to a stronger type system; it can be frustrating to be told that something is not allowed. Nix's usability difficulties often come from trying to build or use software that violates purity in some way (reading HOME directories…

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself. Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocopro…

And now that PR is merged...

Re: The Curse of NixOS

#340

Post by klarkc »

takeda wrote: post #302
lallysingh wrote: post #255

Earlier quoted context omitted.

The problems are twofold: 1. The language is a significant problem. If you get everything right, it will do what you want. That's the only nice thing I can say about it. Almost every error it will give you will be misleading. I haven't had such a hard time figuring out errors since early C++ template metaprogramming. And frankly, that was easier. It needs real diagnostics, and that frankly, that means it needs real t…

Looks like these things are being addressed, although from past of experience it probably will take several years :( (when I started using Nix, 3 years there was a talk about this new thing called flakes, now the version 2.4 already contains it, but it is still locked behind experimental features) 1. https://github.com/tweag/nickel - it is a typed language, that might in the future replace nix language 2. looks like…

There is also https://github.com/purenix-org/purenix
Post reply on HN