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

161–170 of 361 posts

Re: The Curse of NixOS

#161

Post by uncletaco »

fallat wrote: post #57
dangerbird2 wrote: post #47

Earlier quoted context omitted.

How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.

IMO Guix is better but still has some work. My major pet-peeve of Guix is it's anti-proprietary software, which is a necessary compromise. The world is composed of many different people and beliefs; software should be belief-agnostic.

I think it's worth pointing out that guix will not package proprietary or binary software in the main channels but nonguix exists for those needs if one absolutely needs to have those packages in guix. At the same time guix packages flatpak which allows one to install most, if not all, of the proprietary packages they may want to use. I think the compromise from the guix maintainers is to develop and distribute free software but at the same time being silent on how a user goes about adding proprietary packages to their system. Which is fair IMO.

Re: The Curse of NixOS

#162

Post by civodul »

assbuttbuttass wrote: post #66
altgans wrote: post #56

I am a NixOS user, but am interested in Guix. Based on a cursory look I have some questions: - How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at versio…

As someone who's used Guix: They only package linux-libre, so if your device needs proprietary wifi, you're out of luck. Also they package icecat instead of firefox which is kind of cool. I tried to package slash'em a few years ago, and found it very difficult. The documentation is gigantic and it's hard to find what you're looking for. I found folks on IRC very helpful.

As with Debian, wifi devices are about the only thing you might have "troubles" with when opting for Linux-libre:

https://guix.gnu.org/manual/en/html_node/Hardware-Considerat...

Re: The Curse of NixOS

#163

Post by uncletaco »

the_duke wrote: post #81
dangerbird2 wrote: post #47

Earlier quoted context omitted.

How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.

Guix is cool but has two big drawbacks: The major one: package ecosystem. Nix has the largest and most up to date package repo of any distro [1]). Nix is already somewhat niche, but the Guix community is tiny. They also have a hard stance against proprietary software, so many things that are packaged for Nix aren't for Guix. Second: it's pretty slow. A lot of the Nix functionality is implemented in C++ . Guix is all…

> its pretty slow

Would love to see benchmarks of this if you have them.

Re: The Curse of NixOS

#164

Post by edgyquant »

light_hue_1 wrote: post #83

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…

Not being able to use it in a home directory without root was a major turn off for me. I actually started writing a python module to install packages in a way similar to nix (albeit I never got to reproducibility) but ran into problems building glibc and installing it to the home dir. I’d like to continue it one day.

https://github.com/DylanEHolland/pykgr

Re: The Curse of NixOS

#165

Post by bpye »

kstenerud wrote: post #87
ghostwriter wrote: post #28

Earlier quoted context omitted.

> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.htm...

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail. After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know…

It’s obviously anecdotal but I’ve found the Nix community extremely supportive and haven’t really had that experience when asking questions. I typically stick to IRC but I have asked my fair share of dumb questions without any replies I’d call snarky…

Re: The Curse of NixOS

#166

Post by civodul »

AshamedCaptain wrote: post #26
Throwaway194902 wrote: post #22

Earlier quoted context omitted.

NixOS and Guix do _not_ require static linking. They go even one step further and allow many versions of a dynamic object to exist at the same time and each software on your system chooses, which version of the object to link against.

You cannot change the version used by a given binary unless you rebuilt that binary, effectively making it similar to static linking (you still get sharing of DSO files & pages, though). i.e. even if I have two versions of some low-level library installed, depending installed packages still hardcode which one of the two low-level libraries to use, and if I want to switch the system from one to the other, I have to re…

Grafts in Guix support this use case: you know you're providing an ABI-compatible package replacement and don't want to rebuild everything that depends on it:

https://guix.gnu.org/en/blog/2020/grafts-continued/

We use that for security updates, but also in other situations where we know we can take advantage of it such as the new `--tune` package transformation option, which tunes a package for a specific CPU:

https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu...

Similarly, as a user, you can "graft" a replacement straight from the command line using `--with-graft`:

https://guix.gnu.org/manual/devel/en/html_node/Package-Trans...

Re: The Curse of NixOS

#167

Post by Filligree »

alpaca128 wrote: post #43
globular-toast wrote: post #7

Earlier quoted context omitted.

Is the author aware of Guix?

Apparently not, or forgot about it when writing the article: > it's so clearly the only operating system that actually gets how package management should be done

He might be one of the many, many people whose hardware isn't supported by Guix.

Re: The Curse of NixOS

#168

Post by Filligree »

rekado wrote: post #145
yewenjie wrote: post #65

Earlier quoted context omitted.

Yes, the low number of readily available packages is the primary reason I switched from Guix to Nix.

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

Well, I need CUDA so...

I'm aware of nonguix, but it seems to break a lot more than the same packages in nixpkgs.

Re: The Curse of NixOS

#169

Post by dangus »

Something that perhaps detracts from the positives of NixOS is that a lot of the tools that have the biggest issues with the need/difficulty of dealing with multiple versions and environments have long ago come up with their own solutions to the problem.

Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on.

Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server.

I wonder if some of the benefits of NixOS were either solutions looking for problems or solutions where better solutions rose to prominence.

I haven't even started talking about containerization, either!

Re: The Curse of NixOS

#170

Post by kstenerud »

aaronchall wrote: post #151
kstenerud wrote: post #87

Earlier quoted context omitted.

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail. After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know…

Maybe you should look within. I'm still a long ways from understanding everything Nix/NixOS completely, but I've never gotten these kinds of comments apart from the extremely reasonable "you should start out by reading the introduction docs" - that the directions lead with. And if you have a problem with that, I can see how you might have provoked that kind of response that seems so out of character to me. I ask ques…

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/

But eventually one gets ground down and demoralized enough to just give up. It's a real shame, because I LOVE what NixOS is trying to accomplish.

Post reply on HN