Hacker News new | past | comments | ask | show | jobs | submit login

What gets me is the contradicting documentation.

How are you meant to install a piece of software and keep it up to date?

Is it a channel or flake? Are flakes stable or only for testing? So what's homemanager for?

Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here".

I really like the idea of Nix, but the communities priorities leave a lot to be desired of.




Regarding your questions, they seem to be about NixOS, which is a Linux distro that is centered around Nix.

I usually recommend this guide for newcomers to Nix: https://zero-to-nix.com/

I don’t think there’s a beginner-friendly guide to NixOS. I personally learned it (and continue to!) through a number of blog posts and examples on Github. The NixOS manual is a key reference to rely on, but not really a tutorial: https://nixos.org/manual/nixos/stable/


Flakes = combine explicit refs to deps as well as a build description for anything you're making (which can be a lib, app, or entire machine). IMO if you're starting now, use this.

Channel = group of named deps. 'Traditional' nix tracks a channel so when you update it, anything pointed to it also updates.

Home Manager = NixOS lite. Good option to define your preferred environment deterministically if you like another OS.


Was does "explicit ref" and "named dep" mean?


A dependency at a particular version vs. the latest version of that dependency. The latter relies on a „channel“ snapshotting all available dependencies at a particular version. This is considered to be a mistake in hindsight, hence flakes


The idea of Nix is great, implementation not so much. If everything you need is within their package/ecosystem then things will go fine. But God help you if you want to run some binary that isn't in their package manger, the amount of time in effort and struggle to get a simply binary to run is absolutely insane.


> Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here".

I experienced a similar situation last week with git-hooks.nix[1], a pre-commit integration for Nix.

I wanted to run biome[2] checks on my repository during pre-push so I wrote a custom hook because git-hooks.nix has pre-defined integrations with prettier and rome, but not biome.

Or that's what I thought. I eventually found out that the rome hook is actually referred as "rome" everywhere but calls biome instead[3]. This wasn't documented anywhere, so I opened an issue[4] suggesting to rename the hook to "biome" and keep the former for backwards compatibility reasons.

As of today, this has been acknowledged by one of the maintainers, whose sole feedback has been to "thumb down" the issue.

TL;DR: It's not just the documentation, but also the code not doing what you would expect. It also seems there's no means to improve the situation other than just forking the project since there's also clearly some kind of communication problem.

[1] https://github.com/cachix/git-hooks.nix [2] https://biomejs.dev/ [3] https://github.com/cachix/git-hooks.nix/blob/40e6053ecb65fcb... [4] https://github.com/cachix/git-hooks.nix/issues/428


Yes, that's been my experience too.

I've not seen such hilariously bad communication since trying to talk to my thesis advisor.

Guix might use a scheme, but at least it has good documentation and seems more open to accepting contributions.


> As of today, this has been acknowledged by one of the maintainers, whose sole feedback has been to "thumb down" the issue.

Looks like the OP, domenkozar, is that maintainer. Perhaps they'll reply to this thread :)


That was a mistake, for some reason it left a thumbs down instead of thumbs up.


No biggie, I was mostly worried about having proposed something undesired without receiving any feedback about it. I'm glad this wasn't the case.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: