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

271–280 of 361 posts

Re: The Curse of NixOS

#271

Post by Ericson2314 »

tuetuopay wrote: post #246
Ericson2314 wrote: post #224

I understand the first complaint but not the second > The second flaw is that NixOS does not actually provide real isolation. I thought this would going to be about security, but then it was about having to repackage the world. But Nixpkgs is current the biggest and most up to date package repository in the world (we finally beat AUR). Packaging enough stuff is emphatically not the problem. What I want to see is deve…

I think you missed the key point. Software needs to be altered to run on Nix, and it needs to do so _systematically_. Grab a script from the internet? Edit the shebang! Download some prebuilt software? Good luck finding /lib/ld-linux.so.2! Need to use some proprietary software you cannot edit? HALP! Of course there must be some tooling to get around this, since stuff like steam is available (at least I hope), or else…

Hehe Quartus II is terrifying. It is like 10s of gigs of basically it's own distro. I have seen it showhorned into Nix but at the end of data it's a garbage heap of a "package".

Nice example :)

Yeah for me it's just more interesting to attack the problem at the root: developer UX, autogenerating packages from things like Cargo.toml, etc.. Prebuilt binaries is not something I really care about that much, and are existing tools do handle it quite well surprisingly automatically .

It's linux, if you are using some rando prebuilt binaries (not your distro's, or other trusted build artifacts cache) it's always a tragedy.

Re: The Curse of NixOS

#272

Post by ghostwriter »

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…

> The other problem is the condescending replies from the higher tier nix folks while everyone else struggles.

You may not like the reply, but the fact remains: the comment I replied to was a lie. It says there's hardly anything but Wiki pages and Nix Pills and that there's no "easy to find, documentation of its "standard library". And the exact document has been two clicks away from them for a long time.

> I just stopped bothering.

Another problem is your impatience and inability to perform searching and research for necessary information without anyone's help. The lack of focus and motivation to spend a little extra time to discover, learn, and build an intuition around a new toolchain is on you. How much time have you spent on useless media content on youtube or netflix lately instead having another try with the tool?

Re: The Curse of NixOS

#273

Post by haolez »

Is NixOps still a thing? It might be cool unifying nixpkgs with cloud infra, although Terraform and friends seem to already provide 80% of the value of such a solution.

Re: The Curse of NixOS

#274

Post by fwip »

tadfisher wrote: post #200
edgyquant wrote: post #164

Earlier quoted context omitted.

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

Yeah, one of the consequences of purity is that packages can't/shouldn't refer to paths outside of the nix store (/nix/store), so it needs to be hardcoded. Otherwise you end up not being able to match hashes against a binary cache. The glibc issue you ran into is actually a prime example of this problem, and the version shipped in nixpkgs is patched to allow multiple instances by changing various hardcoded paths to t…

I've never understood why Nix cannot simply rewrite those paths to "look like" the canonical ones when calculating hashes. Surely a pre-processing rule could transform "/home/me/nix" to "/nix", based on my Nix configuration.

Re: The Curse of NixOS

#275

Post by ghostwriter »

HotHotLava wrote: post #88
ghostwriter wrote: post #50

Earlier quoted context omitted.

> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri ... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

It's one thing to look at the source, it's another thing to know that you have to look inside `pkgs/build-support/trivial-builders.nix` to find the documentation. One of the main advantages of reference documentation is a central place to look up what things do.

`writeScriptBin` is the second topmost link on Google search that leads directly to that file in a central repository of nixpkgs. Unique function names have the advantage of being transparent references that you can find either via google, or github search, or grep on your local checkout of nixpkgs.

Re: The Curse of NixOS

#276

Post by dannyobrien »

eadmund wrote: post #121
valyagolev wrote: post #64

Earlier quoted context omitted.

as much respect as I have for Guile, I'd love the nix configuration language to have at least partially enforced types...

It really is a pity that Guix didn't go for Common Lisp instead — it does allow for gradual typing. And it has standardised a ton of stuff that Guile had to implement on an ad hoc basis.

Honestly, I kind of like how Guix and Guile have been growing together. Like Rust and Servo (and the Rust compiler), I think the constraint of having a general-purpose language, but a general purpose language that is also responsive to a bigger project, has been beneficial to both.

Re: The Curse of NixOS

#277

Post by ghostwriter »

darkarmani wrote: post #149
ghostwriter wrote: post #50

Earlier quoted context omitted.

> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri ... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

> Is it too much to ask from developers in 2022? It's not too much to ask for non-production ready software. If nixos is supposed to be production ready, then yes.

NixOS is production ready, productive teams that care about reproducibility use it in a variety of production environments already.

Re: The Curse of NixOS

#278

Post by Ericson2314 »

tikhonj wrote: post #244
Ericson2314 wrote: post #224

I understand the first complaint but not the second > The second flaw is that NixOS does not actually provide real isolation. I thought this would going to be about security, but then it was about having to repackage the world. But Nixpkgs is current the biggest and most up to date package repository in the world (we finally beat AUR). Packaging enough stuff is emphatically not the problem. What I want to see is deve…

> I do think people give the language itself to much grief when the problem is more the library side with the copious override shenanagins and other stuff. I sympathize with this, honestly—the separation between Nix the language and Nixpkgs the library/codebase is just an implementation detail from the point of view of the user. This is especially true for core constructs like overrides—overriding is a pretty fundame…

I think you have the mindset right, so thanks for elucidating that. I would still push back.

Ultimately library + language is serving a single goal here, but "means to an end" != mere implementation detail!

As a user of a language, it's incumbent upon you to learn the difference between library vs langauge in what you write. Full stop. I do wish Nixpkgs would be less rediculous. I wish there was a GUI too! But people who are going to write some code still need to learn the difference between language and library way.

Ultimately I don't think a more mainstream language would even help with the override soup problem, and we will need a logic programming type thing, but that's a separate point.

Re: The Curse of NixOS

#279

Post by amelius »

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…

> Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything.

Does that mean we get downloadable precompiled binary packages too? If not, why not?

Re: The Curse of NixOS

#280

Post by bob406 »

Absolutely agree that "isolated installations" are the future. Plan9 was way ahead of their time when they used their version of chroot and mounting to achieve basically something like that. And now the Fuchsia team is making this a pillar of their architecture even going so far that all installs are transparent: almost like running an app directly from an URL. And sandboxing it like a webpage, even when it's a native app. Ooops, I digress. But I really see this as a trend and NixOs one of the systems which are used to collect experience on the concept of isolation and refine it.
Post reply on HN