libc decisions in future releases
When I started LessLinux I was considering uClibc as base C library, it is small and provides nearly everything that is needed for a small niche distribution like LessLinux. Unfortunately, several applications needed to be patched to compile flawlessly against uClibc. So I went with Glibc, just the BusyBox used in the first stages of the boot procedure is statically linked against uClibc.
Still there are some drawbacks when using Glibc, especially the dependence on Bash as shell and the relative big size. Now there seems to be a solution for this problem. Eglibc is a fork of Glibc that aims to be source and binary compatible with Glibc but removes the dependency to Bash as sole shell and will allow for lighter configuration. In the medium term this seems like a perfect solution: LessLinux does not need NIS and for some applications even localization might be skipped.
In the next weeks I will not have the time to play around with Eglibc, but as soon as the release of Glibc 2.10 is near, I will give Eglibc a try.