Hacker News Reader

Comment by jdxcode | Hacker News Reader

I think the entire concept of nix is a broken model not fixable by docs and better DX. Precompiled, portable binaries are the way to go which is what mise is built on. Trying to maintain this separate build chain where everything is compiled in a sandbox gives your system a "split-brain" problem where you have the "nix world" and the "macos (or whatever) world". Ultimately, this just causes problems. Of course I'm ignoring NixOS but that's a sledgehammer for this supposed "problem" nix is trying to solve in the first place.

mise is for the 90% of developers that just want things to be fast and work and don't care about the nuts and bolts.

View on HN

Nothing in nix says you have to compile something from source. Just that the resulting artifact needs to be reproducible hermetically. You can download any random blob from the internet as a nix derivation, as long as you tell nix what the resulting hash should be after you download it. Sure, it might have unmet runtime dependencies, but thats orthogonal.

What you are really butting up against is that the nix store is a bit of a split-brained runtime environment. Its not easy to e.g. `gem install` to your system while running a nix-managed ruby. This has nothing to do with the binaries (well... sometimes it does because nix will patch paths to point to the readonly store, but again thats orthogonal).

Don't you kinda need to separate the worlds to avoid borking your system when you update? Eg macOS decides to ship some customizations in its curl,[1] and now you need your own curl because Apple's customization is breaking your project?

[1] https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...

system updates causing breakages with mise tools would be news to me

I've been using nixpkgs on macos (and without brew) for 3 years now and not sure what kind of split brain problem you're talking about? I also have no idea about the problems with multiple anaconda and other python builds complain about.

I don't get it. mise and nix binaries both go somewhere that gets added to PATH.

> Precompiled, portable binaries are the way to go which is what mise is built on.

And where are those mystery meat binaries supposed to come from? What do you do if the provided binaries aren't enough? (Wrong version, wrong build flags, what you want isn't even packaged, don't support your platform, etc, etc, etc.)

Binary package managers have been tried over and over, and never work out well.

> gives your system a "split-brain" problem where you have the "nix world" and the "macos (or whatever) world".

Yeah no, that's inherent as soon as you bring in any kind of secondary package manager. Including pyenv or mise or whatever else.

> And where are those mystery meat binaries supposed to come from?

the vendor

Right, because that never goes wrong.[0,1]

[0]: https://news.ycombinator.com/item?id=42351722

[1]: https://tukaani.org/xz-backdoor/

The xz example does not support your case. Not only was every downstream build infected until it was discovered, it also needed a distro-specific modification (to openssh in Debian and Fedora, IIRC) to work at all.

The xz backdoor relied on a discrepancy between the development repository and the released (source) artifact.

While skipping the released tarballs wouldn't have prevented the problem entirely, it would have made it much harder to hide.

If only they were actually portable. As it stands, mise is just another half-solution, and you can't solve the other half of the problem by ignoring it.

Reply on news.ycombinator.com