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

> When you have to patch things at the level of ELF, your basic architecture needs work.

May I ask why? It might sound uncommon, but that doesn't mean it's wrong. Nix only patches pre-built binaries targeting other distros. It patches the expected path of shared libraries so that the patched binaries can use versions of libraries that work best.

This is not even a Nix thing. It's standard practice when packaging pre-built binaries. You can see this for yourself in Debian code search:

https://codesearch.debian.net/search?q=patchelf&literal=1

All Nix does is automate the process that other distros end up doing anyways.

> The project management of Nix feels like a disaster

That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.

https://github.com/NixOS/nix/pulse/monthly




> May I ask why?

Because it breaks the universe?

https://github.com/NixOS/nixpkgs/issues/24744

https://discourse.nixos.org/t/using-mold-as-linker-prevents-...

And presumably this rattles into glibc vs musl, too.

patchelf is a working hack short term, but what's the long term solution? There is no long term plan as far as I can tell.

> That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.

That's just the most visible to newbies and one of the most popular of the errors. When a Nix tutorial has to go out of it's way to point out the inscrutable error message as well (see: https://fasterthanli.me/series/building-a-rust-service-with-...) and it's still not fixed--well, that speaks volumes.

When flakes can't get either killed, fixed, or stabilized after how long, that speaks volumes.

Nix has more than a few deficiencies. Nix flakes also has a quite a few deficiencies. And the most recent announcement just simply kicks the can down the road.

The problem is that project management doesn't seem to be able to corral things sufficiently to make progress rather than just gaining more problems on a rewrite (flakes and the new command line).

I mean, if a simple error message change can sit open for more than a year, is there really any hope for fixing anything truly substantial?


> Because it breaks the universe?

It does not. People use packages that has binary patches applied all the time, and they work just fine.

The issues you linked to refers to a fixable issue that's completely unrelated to binary patching. It's what happens when you directly use the linker without supplying the required flags.

> patchelf is a working hack short term, but what's the long term solution?

Patching binaries isn't a short term solution. It's the only solution for retargeting proprietary binaries to make it run on distros it wasn't built for. Besides, making a few edits to ELF metadata isn't the end of the world. It's the universally accepted solution across distros.

> I mean, if a simple error message change can sit open for more than a year, is there really any hope for fixing anything truly substantial?

My point still stands. All software other than the most trivial ones has non-zero number of unresolved issues at any given moment in time. This is true even for software made by multi-billion dollar companies. Yet you seem to expect much more from a volunteer-run project with limited resources.

You have a legitimate point regarding flakes, except that issues are constantly being fixed. It's just that some issues you happen to care about are receiving less attention than you'd like given the limited amount of resources available.




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

Search: