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

321–330 of 361 posts

Re: The Curse of NixOS

#321

Post by light_hue_1 »

rekado wrote: post #144
light_hue_1 wrote: post #85

Earlier quoted context omitted.

Oh yeah, nonguix. What a mess. An unsupported pile of packages that break regularly. And if you dare ask a question about it in any official forum you're kicked out. Nix has its issues, but guix is ideologically radical in a extremist "We don't care if your machine is unusable, enjoy your freedom", kind of way.

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 what I said, but it just restates my point.

Guix puts ideology over the welfare of its users.

Re: The Curse of NixOS

#322

Post by light_hue_1 »

jonringer117 wrote: post #319
light_hue_1 wrote: post #307

Earlier quoted context omitted.

Quoted post unavailable.

Impressive trolling. > deepSeq is basically useless because of how almost every datastructure is ciruclar Circular references will cause "infinite recursion", and these will cause evaluation errors. So valid nix code will not contain circular references. Compositions of derivations create merkel DAGs. There are also fixed points, but deepSeq can still handle those scenarios. > trace is almost useless because you can…

No post body was provided.

Re: The Curse of NixOS

#323

Post by rnhmjoj »

mindslight wrote: post #30
rgoulter wrote: post #6

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…

The semantics are simple and necessary, yes. The syntax is kind of crap in some ways (in others it's awesome and I wish other languages were as lightweight). Syntax in general is a bikeshed, but that doesn't mean we can't objectively critique things like having function definition being a mere ":". That one on its own is probably responsible for much of the indecipherability. Also some of the higher level constructs…

> overrideDerivation/overrideAttrs/override, I still don't fully get

Packages are implemented as functions that take dependencies as arguments, do some stuff and ultimately output the result of calling mkDerivation (i.e. a derivation).

`override` allows you to change the arguments of the package, while `overrideAttrs` allows you to change the arguments of mkDerivation: the implementation of the package itself. `overrideDerivation` is essentially a deprecated `overrideAttrs` version.

https://nixos.org/manual/nixpkgs/stable/#chap-overrides for a better explenation.

Re: The Curse of NixOS

#324

Post by kaba0 »

kaba0 wrote: post #256
rgoulter wrote: post #6

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…

Seeing that the nix language was influenced heavily by haskell, perhaps Dhall would be an interesting “port”/change for the project - it is a deliberately non-Turing complete configuration language with types (but heavy type inference) and functions. Because let’s be honest, types are user documentation as well, and the project would benefit greatly from the latter.

Can’t edit anymore but this more or less exists already: dhall-nix can convert from dhall to nix, but unfortunately not everything done in nixpkgs can be converted clearly into dhall (due to nixpkgs’s use of some non-strongly typed parts and general recursion)

Re: The Curse of NixOS

#325

Post by rekado »

michaelmrose wrote: post #266
rekado wrote: post #145

Earlier quoted context omitted.

The default channel of Guix has more than 21,000 packages. Is that what counts as a "low number" these days?

People don't care about 21000 packages they care about say 5. An environment which has 5 has excellent software availability for that user. One that has 3 it has for that user poor availability. Debian has far more packages but pure numbers are hard to compare when packages are broken up in different fashions and missing 1 package that 30% of users desire is more problematic than missing 1000 package that collectivel…

> Elsewhere you tout that RMS wasn't allowed to remove clang from the package collection as if it were proof of value. Other distributions don't have benevolent dictators trying to remove useful free software for ideological reasons.

My point was that neither does Guix. But you do you.

Re: The Curse of NixOS

#326

Post by marcus_holmes »

codethief wrote: post #292
marcus_holmes wrote: post #72

Earlier quoted context omitted.

I just switched away from asdf (primarily developing Go on Mac) because of the problems it caused.

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 one VSCode used on save, the globally-installed version we could invoke from the CLI, a dockerised version that supposedly emulated what the CI engine would do, and the CI engine itself). None of these ran the same versions of the linters with the same config and the same version of tools.

I uninstalled asdf and used a more conventional version manager. Although there was some pain about remembering to manually switch versions, it actually didn't matter that much. Go's backwards compatibility guarantee meant that I bumped into way less problems from working on a 1.16 project using Go 1.17 than I did from asdf trying to match versions. The important bit was that the tools and the Go version used matched.

Re: The Curse of NixOS

#327

Post by kstenerud »

aaronchall wrote: post #262
kstenerud wrote: post #170

Earlier quoted context omitted.

This is a pretty good example the kind of victim blaming I'm talking about. It's a kind of insidious toxicity that permeates certain communities, although I've not been able to put my finger on what exactly brings it out, or why it's so tightly clung to as an acceptable behavior in some places. I actually tried to help for awhile, and even started a help guide https://github.com/kstenerud/nixos-beginners-handbook/ Bu…

I'm not trying to judge you harshly. I'm trying to understand. In your first post in this thread, "high tier" NixOS users were called condescending sadists. This is a libel as far as I can tell based on my own experience. Then was a list of disliked phrases, and second to last in that list was the instruction to read the manual. I believe in reading manuals, as difficult and time-consuming as the effort may be. This…

Yes what you say absolutely all makes sense. My main gripe is that of culture, not substance.

It's understood and well communicated that the project is not mature enough to be an easy experience for a new user, and that's perfectly fair. But unfortunately, there's a degree of gatekeeperism going on in this community that is making the environment toxic for newcomers.

I've only seen it a few times before, but in every case, the longtimers seem unable to see it, and dismiss complaints by newcomers out of hand. Of course it's to be expected that a certain cohort of newcomers will be toxic and entitled, in which case one would absolutely be justified in dismissing them.

But that is not the case here, especially judging from the sheer number of upvotes my comments on this matter have received, and the number of blog posts in the wild about this very topic.

This is not a problem of maturity, but one of culture. And this is what exhausted me and made me give up on my attempt to make things better.

Re: The Curse of NixOS

#328

Post by patrec »

octoberfranklin wrote: post #306
patrec wrote: post #264

Earlier quoted context omitted.

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

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 script, the standard environment -- all with transitively hashed paths) as well as what comes out of it.

They could maybe have called it build-spec, or something like that, but I think giving a novel thing a novel name is in fact novel is less confusing than trying to repurpose some existing terminology and trick people into thinking it's something they are already familiar with when actually it isn't.

¹ It's not actually json, but that's just some historical accident; `nix show-derivation ...` will actually output the derivation as pretty-printed json. But the key thing is that it's just simple data, not an executable script.

Re: The Curse of NixOS

#330

Post by throwaway22032 »

The main issue with NixOS is not NixOS itself but software which sometimes has an insanely complicated build process.

An example that's hitting me at the moment is Anki. The build process was changed by the developers a while ago and became some sort of Bazel mess. There's a GH issue that was opened and closed by the developer because, well, it works for them.

https://github.com/ankitects/anki/issues/1378

Since then Anki has been broken on Nix and the only way to get it working is to either run the binary in a bubblewrap container (which has issues like breaking IME support) or just use a VM.

Could I fix this? Probably, yeah, if I spent enough time, but really the way to fix it would be to do it upstream, and getting a project to change their build process (particularly once they've recently changed it) is basically a full time job.

It's a bit similar to working with reproducible builds. The ecosystem is there, but you very often run into an upstream that just thinks "yo mate, it's not military software, why do I care". And really, they're probably not wrong, this is OSS, no-one is paying you.

Post reply on HN