Wow. Just wow. So these guys don't understand UNIX. Like they're going to do it better than the fathers of UNIX at AT&T (who came up with the specification on which the FHS is based). Yeah, OK.
Achieve better performance than any other x86_64 or arm distribution, as only statically linked binaries are used
Wow. So not only do they not understand UNIX, but now every process will have memory allocated for every symbol in the ELF header, and any application linking with the same set of libraries will have their own copy of the same machine code, and the startup will be longer, because every application will be larger. Any patching which will need done, all affected applications will need recompiled. Why does this remind me of Windows?
Achieve better memory footprint than heavyweight distros using dynamic linking and all its problems
Yeah, of course! Why try to rack your brains designing versioned interfaces and making sure libraries are backward compatible, when you can just statically link everything and create tremendous overhead in terms of maintenance and security? No point in writing linker map files and having the runtime linker present the correct version of the API to the application, riiiggghhhttt?
Is this a case of more Windows people getting onto the Linux bandwagon, and just completely not getting it, or what?
They're plan9 elitists. They're frankly a lot like you, except their system of choice is plan9, not solaris.
And on Linux, the FHS does kind of suck: there's no difference between /lib and /usr/lib, or /share and /usr/share, because we don't have a separation between OS userland and external userland, /sbin is rarely used for its intended purpose, and /opt is just weird. Honestly, you should just kill most of the cruft, symlink /<whatever>
to /usr/<whatever> or vice versa, so we only have one of all of them, and leave /usr/local as it is, because we need it for software installed outside the package manager.
My Windows system currently has 21 copies of zlib1.dll on it, each shipped by a different program. While I have no doubt that Windows programmers have heard of DLLs, they clearly haven't grasped the idea of shared libraries.
The problem in that case is developers not putting their DLLs in a system directory! Windows will use WinSXS to avoid problems with different versions (DLL hell).
But no one uses them like that any more. Because we remember back when people dropped all kinds of shit into system directories, and the result was awful.
This hasn't seen an airing in a while, because it became accepted wisdom years ago. You're encouraging a bad design that the world has learned better than to employ.
This way, the DLL will be somewhere (usually a "Bin" subdirectory) within the application's own subtree rooted at "\Program Files\company\product\".
This plainly shows just how poorly thought-out Windows is, to paraphrase:
we didn't design a directory tree like UNIX, and we don't have a proper runtime linker like UNIX, so we are going to swipe using the bin/ directory like on UNIX because we don't know where else to put stuff, and while we're at it, we will rename bin/ to Bin/ because we don't know any better, and also while we're at it, we'll dump all the dynamically linked libraries which the application needs into that mis-named Bin/ directory.
Because Windows doesn't have a proper operating system structure, nor does it have a clean structure (case in point C:\Program Files (x86)\, even if your Windows is 64-bit), nor does it have a runtime linker with the functionality equivalent to ld.so.1 (the only way to get anything close to -Wl,-R/opt/local/lib/64 out of LINK.EXE is to use an XML manifest(!!!), and $ORIGIN keyword's functionality of ld(1) is science fiction for LINK.EXE).
How amateurishly bad can one get? Wintendo is a gift that just keeps on giving...
Wow. Just wow. So these guys don't understand UNIX. Like they're going to do it better than the fathers of UNIX at AT&T (who came up with the specification on which the FHS is based). Yeah, OK.
Achieve better performance than any other x86_64 or arm distribution, as only statically linked binaries are used
Wow. So not only do they not understand UNIX, but now every process will have memory allocated for every symbol in the ELF header, and any application linking with the same set of libraries will have their own copy of the same machine code, and the startup will be longer, because every application will be larger. Any patching which will need done, all affected applications will need recompiled. Why does this remind me of Windows?
Achieve better memory footprint than heavyweight distros using dynamic linking and all its problems
Yeah, of course! Why try to rack your brains designing versioned interfaces and making sure libraries are backward compatible, when you can just statically link everything and create tremendous overhead in terms of maintenance and security? No point in writing linker map files and having the runtime linker present the correct version of the API to the application, riiiggghhhttt?
Is this a case of more Windows people getting onto the Linux bandwagon, and just completely not getting it, or what?