Steps to OS enlightenment

[technosaurus]

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)

[technosaurus]

To be continued... posting from my phone, so it's hard to edit.

[01micko]

This is why distros like raspbian are kinda ridiculous. The CLI version is over 400MB

I'm working on raspup buster and the zip file weighs in at ~280MB (sfs gz compressed - but am going to do some tests with zstd - raspbian's squashfs-tools supports - er - requires zstd) and that includes mucho raspbian bloat and 3 kernels with modules (~58MB) and all the overlays and boot files.

nanosaurus for the pi would be good. Possible? I guess. Any recipe?

What people forget too is code == cpu grunt == power consumption, and for many maker projects batteries are needed. How innefficient is raspbian then?

[musher0]

Just a marker to make coming back to this thread painless.

BFN.

[rockedge]

I am working on a firstrib (WeeDog) based on Void Linux built from the scripts written and provided by wiak and discussed here : http://murga-linux.com/puppy/viewtopic.php?t=116212

the beauty of it is one can easily make the OS as basic to complex and full featured as one wishes. Some of the experimental builds of the operating system are fairly well stocked, Xorg, JWM and ROX to as the graphical desktop and run in 90 megs of RAM and a straight CLI version I have had down to 27 megs of RAM and this is before any stripping.