Re: Best place to discuss other lightweight libraries?

[Rich Felker <dalias@aerifal.cx>]

On Mon, Apr 22, 2013 at 07:54:55PM -0500, Rob Landley wrote:
> On 04/22/2013 06:31:10 PM, Rich Felker wrote:
> >On Mon, Apr 22, 2013 at 06:24:06PM -0500, Rob Landley wrote:
> >> Many moons ago I started a thread on here (or was it on freenode?)
> >> asking about lightweight alternatives to stuff and the need for a
> >> wiki page tracking them.
> >>
> >> I believe that at the time, the musl wiki was insufficiently
> >> combobulated, but it has since been fixed. The
> >> http://busybox.net/tinyutils.html page is old is stale and never
> >> really had good coverage, http://elinux.org/System_Size is sort of
> >> adjacent to the topic. If we do come up with anything, can we put it
> >> on a wiki page?
> >
> >That would be a perfectly acceptable topic for the wiki.
> 
> Obviously I'd nominate toybox. (And busybox.) If only so you have a
> context for "ok, what do these NOT cover".

Of course. My proposed criteria would just be:

1. Must be free software.

2. Duplicates a significant portion of the usage cases of a program or
library that's widely perceived as bloated or otherwise problematic
for systems musl might be used on, in a way that fixes some or all of
these problems. Reasons other than bloat might be waking up every
second to eat battery (non-Busybox ntpd does this!), requiring dynamic
linking, etc.

3. Non-criterion: the software doesn't have to be perfect or lack any
bloat problems itself; it just has to be better than the mainstream
solution in at least one way that might be significant to our users.

4. Not by Lennart Poettering. :-)

Does this sound reasonable?

> There's an existing "musl vs uClibc" page but we might want a
> sentence or two on "musl: obviously the best", "uClibc: tried really
> hard but buildroot squished it in 2005 and it never recovered".
> "dietlibc: widely mocked for not-a-but-thats-a-feature disease",
> "klibc: official libc of the postminimalist art movement".)

If such changes are going to be made, I think they should be done by
somebody who's not going to word them in that way... :-)

> "There's always room for dropbear". And polarssl, and so on.

cyassl looked promising too. I would probably mention tomcrypt too
even though it's not sufficient to do SSL; it has the most slim,
clean, portable implementations of crypto algorithms I've seen.

> I know we discussed more stuff (rxvt, xcfe and lxde...)

These are a bit more borderline, but I wouldn't call them
unacceptable.

Rich