Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

301–310 of 361 posts

Re: The Curse of NixOS

#301

Earlier quoted context omitted.

I was definitely in the "I just dont get it" camp for a couple years before coming across a comment on HackerNews pointing to Burke Libbeys fantastic playlist on Nix [1]. It was a revelation and was what I needed to finally have the DSL click for me. Cant recommend it enough. [1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

Is there anything that explains the why and how a bit deeper? As an example, in the video "Packaging a Gem as a Nix derivation", he basically just and copies and pastes another default.nix, changes some strings and mentions he doesn't understand what 'passthrough.updateScript' does, but just changes a string there too. This doesn't really help me understand Nix.

I would watch the entire thing in order to get the "full experience" of his tutorial. This touches on things like the CLI vs just syntax.

If you are coming from the perspective of non-NixOS (e.g. HomeManager or just nixpkgs) then maybe start at his rundown of what NixOS is vs HomeManager [1].

Or if you really just want to understand the nix language itself then probably start at 'Demystifying nixpkgs' [2].

[1] - https://www.youtube.com/watch?v=IUsQt4NRCnc&list=PLRGI9KQ3_H...

[2] - https://www.youtube.com/watch?v=oWJaTb5uoT0&list=PLRGI9KQ3_H...

Re: The Curse of NixOS

#302

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…

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 likely is addressed by flakes

Re: The Curse of NixOS

#303
post #141
post #63

Earlier quoted context omitted.

I have had NixOS as my daily driver for nearly three years now and maintain a small number of packages in Nixpkgs. From my perspective, macOS support is a headache as it all of the sudden may require you to debug on a proprietary OS that you lack access to and that runs on two different hardware architectures in order to get a patch accepted. I am probably not going to make any friends for saying so, but I would much…

> My personal reasons for not going with Guix is that it is a GNU project That's a high price to pay. Look, the GNU project means different things to different people. On of the goals of the GNU project is to give users the tools to liberate themselves from arbitrary restrictions. The Hurd pretty much does away with the concept of an all-powerful root user as the only privileged account to alter settings such as netw…

First of all, you and all other of my fellow FLOSS developers have my respect. We may disagree on major or minute aspects of software design and philosophy, but ultimately we are a force for good in this world. I also admit that there are – as you say – nuances between GNU projects.

> I'm sick and tired of the religious vocabulary being applied to people who work on replacing proprietary software with free software

Well, I should have used quotes (“heresy”) to highlight the fact that I do not consider the usage to be entirely appropriate. But maybe instead of turning outwards it may be better to turn inwards and ask oneself why people such as myself, that have written less than about 10,000 lines of proprietary code in our entire lives, still draw upon such analogies to describe our GNU brethren?

One may think that following the Free System Distribution Guidelines only leads to the base system not shipping with proprietary nonsense. However, as you point out, there is also the fact that a chunk of the developer base find mentions of proprietary software offensive (?) and this necessitates shielding them with the #guix and #nonguix distinction. Perhaps naively, I find this counterproductive as I would rather have the “sinners” (sorry, I could not resist) on board and empower them to control the proprietary software that plenty of times is forced upon them because they have to make a living in a partially proprietary world. I want to allow them to transition cleanly to what we must ultimately turn into better non-proprietary alternatives. For example, I am happy that I can control and proud to have managed to keep my exceptions down to:

    nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
      # “So Nvidia, fuck you!”
      "cudatoolkit"
      "nvidia-persistenced"
      "nvidia-settings"
      "nvidia-x11"
    ];
Accommodating a user’s ability to do this, in my mind, makes us stronger as we acknowledge a reality where compromises have to be struck. Yes, one could bring out nonguix to accomplish this, but it is very clear from how Guix is structured as a project that these people and the software they rely upon is at the very best a secondary concern to the project’s goal and the software they produce. In summary I want to engage with users of proprietary software rather than to shield myself from them, as I think this is more likely to lead to long-term success of and superior free software.

Note that all of this is regardless of whether you are a card carrying FSF member and my general dislike for the law-based approach that the GPL takes to free us from proprietary software.

Re: The Curse of NixOS

#304

Earlier quoted context omitted.

> the Nix language is about as straightforward as "JSON plus functions". Except that they concoct weird custom terminology for everything . It's not a hashmap, or a map, or an object. No. It's an attrset . Riiiiight. It's not a build script, it's a derivation . Etc, etc.

> It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight. This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support. > It's not a build script, it's a derivation.…

[deleted]

Re: The Curse of NixOS

#305
I gave up on NixOS years ago.

It doesn't matter how many nice ideas you have, even revolutionary ones, when the core experience is just such a giant PITA.

Re: The Curse of NixOS

#306
post #264

Earlier quoted context omitted.

> the Nix language is about as straightforward as "JSON plus functions". Except that they concoct weird custom terminology for everything . It's not a hashmap, or a map, or an object. No. It's an attrset . Riiiiight. It's not a build script, it's a derivation . Etc, etc.

Yeah, naming a key-value data structure `set` was a really poor choice. A derivation isn't really a build script though.

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".

Re: The Curse of NixOS

#307

Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed. The problem is that Nix the language is the worst of all worlds: - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are saf…

> - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging. `lib.deepSeq` can be used to fully evaluate a thunk. `lib.trace` can be used to emit a log each time a value gets evaluated. > - Everything in Nix is recursive, datastructures contain cop…

No post body was provided.

Re: The Curse of NixOS

#308

Earlier quoted context omitted.

> the Nix language is about as straightforward as "JSON plus functions". Except that they concoct weird custom terminology for everything . It's not a hashmap, or a map, or an object. No. It's an attrset . Riiiiight. It's not a build script, it's a derivation . Etc, etc.

> It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight. This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support. > It's not a build script, it's a derivation.…

> > It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight.

> This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys.

Then it's an ordered map.

Since you're creating a new language, you can say right up front "in Nix, all maps are ordered maps" and then just refer to them as maps.

There is existing terminology for all of this stuff, and it should have been reused.

Re: The Curse of NixOS

#309

Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed. The problem is that Nix the language is the worst of all worlds: - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are saf…

> You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging. I don’t quite follow the conclusion. Forcing values will not result in random operations on the store. Forcing values can only ever create store derivations, which is an internal representa…

Yes. So, if I force a value, like say, I very naively do what I would do in any other programming language, I try to print something I don't understand (How are all of the python derivations stored, I wonder if I can print them?), the result is that I create endless garbage and .. sit there pointlessly looking at an empty screen. Evaluating derivations shouldn't result in work being performed. It should result in derivations being printed to the screen.

But.. it doesn't really matter that much because half of the datastructures in Nix are so circular that you couldn't print them out anyway.

Re: The Curse of NixOS

#310

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…

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…

> (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible

this is most painful, because a lot of packages do tons of tricks that make it very difficult to get reproducibility. Like downloading dependencies at build time, non standard places of installing things hardcoded paths etc.

If you are tried cross compile arbitrary packages it might be familiar. A lot of projects don't know how to do things correctly, or doesn't care and just want their code to work.

To that, other environments have their own quirks. For example the way most nodejs applications work they do expect their dependencies in current working or parent directory.

All those things require some patching. If you can get the patch upstream that's awesome, otherwise you'll have to maintain it.

What is great about other distros, is that if you try to use some exotic library, you can just try things randomly until you get it compiled and installed in /usr/local :)

Imagine if you had RedHat installed, and it would impose that you can't run anything unless it's packaged in rpm. If you would have to prepare a .spec file and run rpmbuild command. I bet experience wouldn't be far off.

Unlike RedHat Nix does force this and this is a double edged sword. It creates this pain, but on the other hand it forces some kind of order.

BTW: if you want it hard enough you can still install packages the traditional way (but likely would have to specify --prefix to somewhere inside /home than /usr/local)

Post reply on HN