3 ms·
> 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
by 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 agoRight, 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 agoThe 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 agoThe 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.