Well, that's exactly the job of competent package managers, to make sure that packages fully stated their dependencies (so that the package manager would forbid you from getting into an illegal state wherein a required dependency was not installed or the wrong version of the dependency was installed), and installed correctly according to the LFHS so that there would be no conflicts.
/opt isn't new. Plenty of people decided that they could throw everything into a folder under /opt, including copies of all dependencies, with no references outside of that folder, and that would be enough. And it might have been enough if it wasn't for sysadmins in charge of uptime tearing their beards out over /opt constantly filling up and causing multi-product outages when it did.
The whole point of the LFHS is that it represented a contract along the boundary between developers (who needed to bundle libraries, save state, have access to a cache, etc.) and operators (who worried about disks and associated costs - why would you ever spend a dime backing up /var/cache? Why would you ever use a fast disk for /etc?). When this contract was followed, systems worked splendidly. When the contract was broken, the people who broke the contract shot themselves in the foot just about the same as anybody writing C code knows how many footguns are in the C language.
Of course, today, with the price of resources having crashed through the floor, and containerization having more or less reached maturity, this is all more or less an academic, historical, moot point. But dynamically linked libraries weren't stupid, they were an artifact of an age where statically linking libraries was horrendously uneconomical and the idea of namespacing anything was enough to get laughed out of the room by people wondering how you would expect to pay for any of it.
Package managers are an over-engineered solution to a problem that only really exists if you rely on package managers. Ever had your apt database break on you? It's a joy, let me tell you. Nothing ever gets installed or removed again. Blowing up your system and requiring your OS to be reinstalled is ridiculous. Especially since that was a problem that didn't even used to exist. OSs were once stored on roms.
> /opt isn't new. Plenty of people decided that they could throw everything into a folder under /opt, including copies of all dependencies, with no references outside of that folder, and that would be enough.
Sure, as long as you never move it from opt. UNIX devs' addiction to hard-coding fixed paths is difficult to break.
> And it might have been enough if it wasn't for sysadmins in charge of uptime tearing their beards out over /opt constantly filling up and causing multi-product outages when it did.
Is that really a problem outside of Linux, which famously defined its base-system as "the kernel" and therefore necessitated that any such install would need to bring along all its own dependencies because it couldn't rely on anything existing except the kernel?
> Of course, today, with the price of resources having crashed through the floor, and containerization having more or less reached maturity, this is all more or less an academic, historical, moot point. But dynamically linked libraries weren't stupid, they were an artifact of an age where statically linking libraries was horrendously uneconomical and the idea of namespacing anything was enough to get laughed out of the room by people wondering how you would expect to pay for any of it.
Yet we still live with this bullshit today anyway and the Linux community especially eschews any attempt to move on. This despite some of the same people who created UNIX creating Plan 9, which rejected dynamically linking and embraced namespacing over twenty years ago!
this only happens if one isnt aren't managing applications coherently (e.g binary only packages managed haphazardly, like most linux binary packagers)
on systems where there is a clear base+add-ons distinction (e.g. source based ports), these things happen much less often - all packages are built from a coherent source tree, and read only root is often feasable because packages only install reference files into their respective '/usr/share' area and don't muck with the 'real system' in /etc - the latter being an administrative action (e.g. package installation is a separate action from service configuration / execution)
The OS should be a platform. I should be able to build an application and distribute it to users and have it just run on that platform without involving third party middlemen and regardless of other software they have. You know what OSs accomplished this? The original Macintosh, RiscOS, DOS, and (mostly) Windows 3.1. Why is it that we can't accomplish today something we did 30 years ago?
a platform for 'building your system', or a platform for 'distributing and executing binaries'?
the binary only distribution mentality comes from microcomputer culture, which postdates unix/mini culture and is rooted in non-technical users installing purchased 'application' programs from vendors rather than computer users (read: programmers) building their systems to suit their own personal data processing tasks. you highlight this in your choice of platforms 'getting this right', but really, these are two different mentalities, cultures, and modes of operation.
not saying one is superior to the other, but square peg, round hole.
and besides:
many proprietary programs for unix just ship with static executables. problem solved.
These are not mutually exclusive goals.
> the binary only distribution mentality comes from microcomputer culture, which postdates unix/mini culture and is rooted in non-technical users installing purchased 'application' programs from vendors rather than computer users (read: programmers) building their systems to suit their own personal data processing tasks.
"Non-technical". Elitist bullshit. Woz was non-technical? He was clearly a micro guy. People got work done with micros. They made things with micros. Like your glorious programmer master-race, they configured their environment into something that enhanced their lives. They bought and used software the way you import 10000 dependencies. Excel is still by far the most used programming environment in the world, with entire businesses run on tooling never touched by programmer-master-race hands.
Besides, programmers should want it this way too. Which makes more sense to you? A constantly mutating state where changes in seemingly unrelated portions can wreck havok on the whole, or a collection of immutable components which can be swapped in and out at will? A system so complicated it needs sophisticated management software and a database of conflicts and dependencies to keep it all running, or one so simple that 'copy' and 'install', and 'delete' and 'uninstall' are synonymous?
If the UNIX model is so damn great, why the fuck does Docker exist!? If development is so damn great on UNIX, why are people building and distributing dev environments in containers!?
> you highlight this in your choice of platforms 'getting this right', but really, these are two different mentalities, cultures, and modes of operation.
> not saying one is superior to the other, but square peg, round hole.
I disagree. I think one is clearly objectively superior to the other.
> many proprietary programs for unix just ship with static executables. problem solved.
Ha! Yeah. Problem solved. Even for proprietary software with a native Linux version I've almost always had better luck running the Windows version under WINE.
Anyway, the fix is pretty obvious: put each application in its own namespace, thus its view of "/usr" isn't the same as the immutable OS "/usr" and it is free to write whatever it wants without causing any trouble.