Hacker News Reader

Comment by Ericson2314 | Hacker News Reader

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 development be easier with Nix, because winning over the hearts and minds of upstream developers is the final frontier. To that end I wrote https://github.com/NixOS/rfcs/pull/92 and https://github.com/NixOS/rfcs/pull/109.

As a side benefit, autogenerating more Nix means less handwritten Nix! 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.

View on HN

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 anything not packaged by nix would be a nightmare to install and use as a user. Any niche or domain specific software would become unusable. Take for example Quartus II or Vivado (just to name the two top FPGA EDAs), those two are not packaged by nix. Yes, there are a few recipes floating around, but those honestly scare me enough to not want to do it with more obscure tools like those for other, smaller brands, FPGAs.

(disclaimer: I never used nix, but that's my understanding from the article, and my own experience running proprietary stuff)

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.

I actually added Quartus Prime in nixpkgs a couple years ago! Haven't gotten round to the 2021 update, but that should get rid of the annoying 32-bit dependencies.

[1]: https://github.com/NixOS/nixpkgs/blob/1e643a385290e54947594a...

I suspect that the FPGA EDAs should run fin under steam-run. Packaging up giant balls of binaries is a mess.

Side note: It would be nice to have a way to look up library -> package name.

> 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 fundamental abstraction that would be part of a differently designed language, so the fact that it's more like a Nixpkgs convention is not going to be clear (or particularly useful) to somebody learning Nix.

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.

Reply on news.ycombinator.com