My gut feeling is that Nix is just not quite the right abstraction level. I can’t quite articulate this. And hell maybe I’m wrong.
I don’t want to configure a global environment. I just want a build system that works reliably in any environment and can cross-compile from any platform to any platform.
Nix does too damn much. All I want is a build system that doesn’t suck. And I want to run it on windows + Mac + Linux as a first class citizen. And I want to arbitrarily target any platform.
What this really comes down to is that Linux C/C++ toolchains are badly designed. Nix is a huge massive convoluted architecture to try and twist itself around that unfortunate reality.
At least that’s my spicy unpopular opinion that is probably wrong but is at least has elements of truth.
Shared Dynamic Libraries. Not to say they aren't useful. Keeping applications small, keeping security updates simple, sub linear ram scaling, yada-yada-yada, big wins cross the board, not debating that.
The pervasive link detection structure of effectively everything on GNU/Linux assumes is (more-or-less) objectively incorrect behavior in any sane security minded context. Binaries should be able to declare the interface/contract they expect (args/types/abi/exceptions/cryptographic signatures/digests). Then the runtime linker "match" against the local system. The current system is basically 2 levels of string equality checking.
Nix goes into the right direction by getting your runtime linker/elf-runtime & package manager "integrated". But this sort of just feels like putting 'lipstick on a pig' and dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer. Nix just manages the environment/symlinks such that `foo.exe` doesn't realize this fact.
> dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer
I’m curious if you have an opinion on how you think this should be handled?
At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
I also blame C/C++ toolchains for being very very bad on Linux.
> I’m curious if you have an opinion on how you think this should be handled?
To "totally overcomplicate things" but do it correctly
- Binary states a list of constraints (namespace:name [<|>|>=|<=|!=] semver).
- ldconf/ld.so either integrate into your package manager and/or are easier to update (I'm not writing conf files by hand and/or flakes). I should simply be able to recursively scan.
- Give the runtime linker an SMT constraint solver (when <1000 this is nearly instant)
- Cache known states to avoid solving NP hard problems every time you launch `cat`.
> At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
Honestly same.
Having the package manager <-> elf runtime <-> shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers.
> I also blame C/C++ toolchains for being very very bad on Linux.
They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries.
If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".
> They honestly aren't, it is more your pacakge manager is your library manager. Because of the absolute bullshit of shared libraries.
Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not.
I mean... a big part of that with conventional Linux distros is the idea that you can security-update a low level library and all the stuff linking to it gets the fixes "for free", a dream abandoned both by Nix and also the movement toward distribution via containers/flatpaks/VMs/whatever.
> The truth is like the sun. The light from the sun touches everything, it's bright and it's obvious... yet no one can stare directly at it.
bad analogy. It can be very painful to accept the truth, but doing so is always a good thing. Staring directly into the sun can cause permanent damage to your eyes -- not a good thing.
No this is not true. There is an evolutionary reason why people lie to themselves. Look at the world.
Almost everyone believes in religions. The world lies to themselves on an unprecedented scale. If accepting the truth had an evolutionary benefit then most of the world would not be so delusional. Delusion dominates the population because lying to oneself conveys a survival benefit such that natural selection selects for this trait.
This short infographic illustrates and proves it. But you know what else proves it? Me getting voted down as I throw the truth down in front of everyone’s faces. I’m a target for selection.
Maybe nix will one day be a tool that’s actually good. It has elements of it but complexity and usability hinder adoption. So overall nix is just shit imo. It’s shit wrapped in a dream, a dream of an ideal way to do things. How do we make that dream a reality?
By lying to ourselves. By claiming nix is already there and that other people can’t see the light such that over the years after enough improvements nix becomes an actual good tool because enough delusional people pushed the dream far enough that it actually happened. But in order to do that… people like me must be culled from the herd.
I don’t want to configure a global environment. I just want a build system that works reliably in any environment and can cross-compile from any platform to any platform.
Nix does too damn much. All I want is a build system that doesn’t suck. And I want to run it on windows + Mac + Linux as a first class citizen. And I want to arbitrarily target any platform.
What this really comes down to is that Linux C/C++ toolchains are badly designed. Nix is a huge massive convoluted architecture to try and twist itself around that unfortunate reality.
At least that’s my spicy unpopular opinion that is probably wrong but is at least has elements of truth.