> And if these binaries were for the user, then the ‘bin’ folder got put in a super-folder called ‘usr’. Hence, we get ‘/usr/bin’ — the folder housing the user’s binaries.
/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.
Much of this article is bullshit, to be honest. There's a lot of wailing and gnashing of teeth about how you can only have one version of python installed at a time, but obviously that's patent nonsense: lots of OSes shipped a python2 and a python3 binary for many years, and some are only just giving up the former now as it it's all totally EOL.
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.
"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.
"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!))
/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.