Steps to OS enlightenment
Posted: Sat 30 Jun 2018, 20:49
For many Linux developers, exposure to antiquated "truths" has brought about an ecosystem of build systems that require gigabytes of RAM and approaching terabytes of disk space just to compile a single program (see chromium). Much of this it is due to the large number of dependencies that often do similar things with their own dependencies that may do the same things as another dependency.
With the recent proliferation of various forms of containers such as LXC and various derivatives like docker, flatpack, etc... a double performance penalty is realized because of the large number of duplicate dependencies. Yay! We have ported DLL-hell to Linux. To be truly portable, each container has its own shared library version of libc, libxcb, etc...
To reduce the duplication across containers, various projects started requiring a base system, so it's now only semi-portable.
This approach is exacerbated by the "truth" that static builds are considered harmful (sarcastic thanks to Ulrich Drepper) so that containers. If each container were built as a static build using link time optimization, only the necessary functions would be included, the container would be significantly smaller, faster and safer. Why? Because all of the beneficial parts of shared library builds go away and all of its shortcomings are amplified.
Then the zealots will say "but some containers need multiple programs with similar dependencies so we still need shared library builds" ... nope multicall binaries like busybox already solved that.
Unfortunately many libraries including GNU libc are not built with static builds in mind and programs need some tweaks to work in a multicall binary. Then you have to consider license compatibility - all the GPL licenses make it a nightmare.
To add insult to injury, gtk is no longer usable for static builds and development is controlled by entities that care little about portability, general usefulness or size if it doesn't affect their own use cases.
To combat this, many developer's have started making single file header libraries and single file programs that use them.
Thus far no one has coordinated with the developer's of these programs to allow them to be easily built into multicall binaries but it's usually only 1 line of sed.
Most of the requirements for a basic desktop system will fit in less than half a mb multicall binary (see pupngo thread) That was without any coordinated development to share code. The gtk1 mcb had dillo, beaver and many other programs in just over 1 mb.
That was as far as I got though, because moving forward requires a gui that will work on X, wayland or some useful alternative to wayland (I'm still not convinced that wayland is an improvement)
With the recent proliferation of various forms of containers such as LXC and various derivatives like docker, flatpack, etc... a double performance penalty is realized because of the large number of duplicate dependencies. Yay! We have ported DLL-hell to Linux. To be truly portable, each container has its own shared library version of libc, libxcb, etc...
To reduce the duplication across containers, various projects started requiring a base system, so it's now only semi-portable.
This approach is exacerbated by the "truth" that static builds are considered harmful (sarcastic thanks to Ulrich Drepper) so that containers. If each container were built as a static build using link time optimization, only the necessary functions would be included, the container would be significantly smaller, faster and safer. Why? Because all of the beneficial parts of shared library builds go away and all of its shortcomings are amplified.
Then the zealots will say "but some containers need multiple programs with similar dependencies so we still need shared library builds" ... nope multicall binaries like busybox already solved that.
Unfortunately many libraries including GNU libc are not built with static builds in mind and programs need some tweaks to work in a multicall binary. Then you have to consider license compatibility - all the GPL licenses make it a nightmare.
To add insult to injury, gtk is no longer usable for static builds and development is controlled by entities that care little about portability, general usefulness or size if it doesn't affect their own use cases.
To combat this, many developer's have started making single file header libraries and single file programs that use them.
Thus far no one has coordinated with the developer's of these programs to allow them to be easily built into multicall binaries but it's usually only 1 line of sed.
Most of the requirements for a basic desktop system will fit in less than half a mb multicall binary (see pupngo thread) That was without any coordinated development to share code. The gtk1 mcb had dillo, beaver and many other programs in just over 1 mb.
That was as far as I got though, because moving forward requires a gui that will work on X, wayland or some useful alternative to wayland (I'm still not convinced that wayland is an improvement)
