Nixing Technological Lock In
economicsfromthetopdown.com
economicsfromthetopdown.com
/usr was the mountpoint for the second drive, where the home directories were. Dennis and Ken started putting binaries into /usr/bin because /bin on the first drive got too full.
See the famous /usr rant by Rob Landley.
Also the idea that everything has to go into a flat /bin directory is nonsense too. My experience is chiefly with illumos, but we have inherited a number of separate trees for compatibility with different standards; e.g., /usr/xpg4/bin had some POSIX binaries where they were incompatible with the default /usr/bin binaries. There were also SunOS (BSD) compatibility binaries in /usr/ucb for a long time. Commonly different JDK versions could be installed alongside one another under /usr/jdk/$version. Unbundled software from many other places would find its way into trees in /opt. Even shared libraries can be installed alongside one another without conflicts, provided you do the right thing with ABI stability and sonames etc.
I have no doubt that other OSes have made a set of similar decisions to provide various levels of binary compatibility and evolution over time, depending on how important it has been to their respective user communities and customer bases.
There is plenty of evidence that /usr used to be the home directories, iirc it was like that in Illumos until 1988.
Edit: Evidence for "user": https://www.youtube.com/watch?v=tc4ROCJYbm0#t=13m40s
"With Nix, there is a free way to build a deterministic, exquisitely organized warehouse for managing your entire software stack."
I have had clients, especially with monorepos, that force one golden image organization wide.
This is absolutely not the correct approach. When I was helping a company move to M1 macs, when Apple killed the Intel based skus, I had fonts, where the tests in compiling them would hard reset the laptop.
But getting half a dozen teams to update the package to one that would compile was just as painful as any monolith.
It is fine to use Nix for reproducibility, but don't enforce an enterprise wide monolithic configuration.
Unfortunately the intersection of security policies and team independence results in this pattern arising organically.
It is probably best to offer this as an optional tool to avoid those issues. But provide guidance from accidentally recreating the same problem.
The python 3 isn't probably the best example as companies had over a decade to migrate. I personally migrates dozens of open source projects, almost always with the built in tools with some tests and reformating to match the projects coding style. Only once did that take me more than an afternoon per project.
Still a good argument in favour of nix though
Oh, wait a second, my bad, that's the quote on the box cover for Zork I: (
https://upload.wikimedia.org/wikipedia/en/a/ac/Zork_I_box_ar...
https://en.wikipedia.org/wiki/Zork )
What you really wanted was a link to where you could download Nix/NixOS -- and/or learn more about it!
Well, here ya go!:
"Your greatest challenge lies ahead -- and downwards..."
:-) <g> :-)
I say all of the above in the spirit of humor -- and as a NixOS user and fan!
(But yes, there is a learning curve to it, so yes, learning Nix/NixOS could be a challenge!)
((But you're a bright person (you are here reading HN, aren't you?), you have Google and ChatGPT and Internet forums to assist you, and you like challenges!))