[vinkelhake]

On binary sizes:

> Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb.

That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc).

There's also a lot of handwaving on memory usage in the FAQ.

[ploxiln]

Yeah - so your stripped and dynamically linked executable is just about as large as a statically built one... and yours still has to link glibc.

I can build busybox (a multi-call all-in-one executable, use symlinks to refer to the binary with the name of a tool and it acts like that tool), with init and bourne shell and the minimal set of command-line tools (coreutils remakes and util-linux remakes) into a 600KiB executable statically linked with uclibc. Combined with a linux kernel, I can boot with it. Meanwhile, my glibc is 2MiB.

Modern computers are really amazing. And it's also amazing that the understandable trend of letting software get bigger and slower as long as it doesn't really cause problems on current hardware has resulted in such astounding (though mostly harmless) waste.

All that said, these stali project pages have existed for years, and there's nothing interesting to show for it. Not that many people really buy into this thing (including me).

[vinkelhake]

Busybox is great and it's specifically built to be tiny. I don't really know what the stali guys are going for. Are they building something to compete with busybox or something more general? If it's the latter then a user will probably have a lot of programs that use way more of the standard library than "hello world" does.

As it stands, the FAQ entry is comparing apples and oranges. Comparing full-featured and dynamically linked programs to statically linked, but feature-limited ones is only interesting if you can get by with the feature-limited version. I suspect we're in agreement.

[mdwrigh2]

> A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc).

Is that the proportional size (binary size + glibc size / number of things using glibc), or just the size of the binary?

[vinkelhake]

It's the size of the binary. I don't understand what you mean by proportional size.

If we add more functionality to the hello world program, the dynamically linked version should increase in size slower than the statically linked.

[mdwrigh2]

The point of proportional size is to account for the size of glibc, which has to be on disk and in memory and so incurs a cost that isn't accounted for by just looking at the size of the binaries that link against it, by dividing glibc's size by the number of applications that use it.

When examining memory usage on Linux systems, one of the common measurement metrics is the Proportional Set Size (PSS), which essentially is what I was asking about (but for on-disk size, rather than just in-memory): http://lwn.net/Articles/230975/

[khc]

> There's also a lot of handwaving on memory usage in the FAQ.

Totally. Reading the FAQ reminded me of https://xkcd.com/386/