7 ms·

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 bu

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.

max-privatevoid 2y ago
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.
yawaramin 2y ago
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-security-incident-12604/ https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...
- jdxcode 2y ago
  system updates causing breakages with mise tools would be news to me
Nullabillity 2y ago
> 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.
- jdxcode 2y ago
  > And where are those mystery meat binaries supposed to come from? the vendor
  - Nullabillity 2y ago
    Right, because that never goes wrong.[0,1] [0]: https://news.ycombinator.com/item?id=42351722 https://news.ycombinator.com/item?id=42351722 [1]: https://tukaani.org/xz-backdoor/ https://tukaani.org/xz-backdoor/
    - goku12 2y ago
      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.
      - Nullabillity 2y ago
        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.
nixosbestos 2y ago
I don't get it. mise and nix binaries both go somewhere that gets added to PATH.
Quiark 2y ago
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.
JamesSwift 2y ago
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).

max-privatevoid 2y ago

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.

yawaramin 2y ago

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-security-incident-12604/ https://daniel.haxx.se/blog/2024/03/08/the-apple-curl-securi...

jdxcode 2y ago
system updates causing breakages with mise tools would be news to me

Nullabillity 2y ago

> 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.

jdxcode 2y ago
> And where are those mystery meat binaries supposed to come from? the vendor
- Nullabillity 2y ago
  Right, because that never goes wrong.[0,1] [0]: https://news.ycombinator.com/item?id=42351722 https://news.ycombinator.com/item?id=42351722 [1]: https://tukaani.org/xz-backdoor/ https://tukaani.org/xz-backdoor/
  - goku12 2y ago
    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.
    - Nullabillity 2y ago
      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.

nixosbestos 2y ago

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

Quiark 2y ago

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.

JamesSwift 2y ago

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).