Re: If glibc had a logo what would it be?

[Rich Felker <dalias at aerifal dot cx>]

On Sat, Dec 08, 2012 at 11:04:45PM -0600, William Pitcock wrote:
> Hello,
> 
> On Sat, Dec 8, 2012 at 5:52 PM, David Miller <davem@davemloft.net> wrote:
> > From: William Pitcock <nenolod@dereferenced.org>
> > Date: Sat, 8 Dec 2012 14:04:19 -0600
> >
> >> Hello,
> >>
> >> On Sat, Dec 8, 2012 at 8:55 AM, Carlos O'Donell <carlos@systemhalted.org> wrote:
> >>>
> >>> If glibc had a logo what would it be?
> >>
> >> Honestly, I think that it would be better to spend time on integrating
> >> strlcpy() and strlcat() so that a billion programs don't have to carry
> >> stubs for them anymore due to GNU arrogance than making a logo.
> >>
> >> I also generally don't see the point in having a logo for a C library;
> >> logos make sense for GUI apps, which a C library is not.
> >
> > Wake up on the wrong side of the bed today?
> 
> No.  The arrogance is very well-documented.
> 
> If you want to "build a community of people who like GLIBC" - making
> it where GLIBC is not the odd duckling for downstream developers (you
> know, the people who write the code that GLIBC exists to run?) would
> be a great start to improving the perception of GLIBC amongst
> developers downstream of it.

I think glibc has made a lot of progress in this area since a certain
person's departure from the project. A number of longstanding WONTFIX
bugs have been reopened and some of them fixed, and the willingness to
listen to problems the "downstream" is facing has improved a lot. I
think the biggest obstacle to further progress in this area is lack of
qualified manpower. When you have a library that _everything_ depends
on, you can't just have random volunteers reviewing and integrating
patches. There need to be robust processes for avoiding regressions
and new bugs and ensuring that changes made are actually the right
changes and not just somebody's whim. My recent experience trying to
get things fixed has basically been that everybody's willing to listen
and wants the bugs to get fixed, but doesn't have the resources..

> I will be more than happy to submit patches adding strlcpy/strlcat, if
> people will accept them, but it seems a giant waste of time, because
> someone will surely say "we don't like this" or whatever.  Well, guess

I think this is another issue that should be reopened, but I'd wait to
spend the effort on patches until seeing if there's still opposition.

> But hey, logo contests are fun, right?  Guess what's not fun: having
> to have autotools macros just for finding if strlcpy/strlcat is
> supported, when it is supported on every other platform that I
> officially support.  And why is this?  Is there some reason why I must
> do this?  Well, not really considering that uClibc ships
> strlcpy/strlcat, and I am pretty sure Musl does as well.

Despite us having them in musl, I still think it would be broken for
applications to assume they exist. Officially, they're nonstandard
extension functions. The legitimate benefit of having them in libc is
not that you can drop the check from your applications, but that the
code doesn't get duplicated everywhere and that users are protected
from the (often security-critical) effects of buggy reimplementations
in applications.

> But as previously mentioned, having cute animals as a mascot, and
> contests to determine the logo are surely fun, I guess.

Sadly nobody seems to have liked my idea...

Rich