On Monday 03 May 2010 13:11:38 Laurent Bercot wrote: > > because you want avoid 10 times bigger binary? (alpine linux's > > apk-tools is 90k dynamic and 900k static due to libcrypto for > > hashing/signing) > > So what? libcrypto obviously wasn't designed for embedded > environments. In fact, it's probably the most bloated free crypto > library around. If the Alpine Linux guys need a smaller static > executable, they can use a smaller crypto library, that does not > pull the whole plate of spaghetti plate, glibc-style, when you > yank at a single noodle. > > Do not blame extra bloat on static linking. Blame it on people > who can't design lean software. > > > Still i think beeing able to set ABI_VERSION is a good idea. > > (...) > > But the price is that extra bloat for libcrypto, libz and uclibc dupe > > code in there. I do understand that some people are willing to pay > > that price. No problem. Current git is good. Everyone is happy. Lets > > move on. > > That's fine, as long as the support for ABI_VERSION does not impact > code that does not use it. If statically linked code is somehow made less > efficient by adding dynamic ABI_VERSION support, not everyone's happy. > If the libc.so dynamic code is somehow made bigger by adding dynamic > ABI_VERSION support and users don't need it, not everyone's happy. > > In embedded environments, RAM is expensive, but storage memory is > getting cheaper by the second.
Not just expensive in terms of money but in terms of power consumption. Persistent storage doesn't consume power for refresh cycles. DRAM does. I'm under the impression that reducing the size of the cells actually increases the required refresh rate (and increases transistor leakage current), so shrinking the die isn't quite the panacea here you'd expect... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
