This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [libc-alpha] Re: [open-source] Re: Wish for 2002
- From: tb at becket dot net (Thomas Bushnell, BSG)
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: Roland McGrath <roland at frob dot com>, Kaz Kylheku <kaz at ashi dot footprints dot net>, Russ Allbery <rra at stanford dot edu>, <libc-alpha at sources dot redhat dot com>
- Date: 09 Jan 2002 17:51:00 -0800
- Subject: Re: [libc-alpha] Re: [open-source] Re: Wish for 2002
- References: <Pine.LNX.4.33.0201091742460.1109-100000@penguin.transmeta.com>
Linus Torvalds <torvalds@transmeta.com> writes:
> Let's see now, the upgrade cycle for glibc right now is on the order of 2
> years or so, and we still have stragglers that haven't even upgraded to
> glibc _at_all_.
Right. It takes time; but thinking for the long term is important.
> > But that's an argument for *never* adding functions to glibc. After
> > all, any really useful function is already going to be carried around
> > just in case its absent.
>
> Agreed.
>
> I think glibc is a bloated piece of software already. The more arguments
> people can come up with for not making it even bigger and slower, the
> better.
Adding functions to glibc does not make it *slower*. Nor is "bloated"
a substantive criterion. Libraries do not work like programs. They
do not require the careful integration and understanding of all their
parts together.
> So the arguments _for_ adding to it have to be damn strong.
Bullshit. The arguments for adding to a *library* are whether they
help programmers. Adding functions in common use is the *job* of
glibc. The effect of systematically excluding new BSD functions will
simply be the creation of a special separate BSD library, which would
be a pointless waste.
> I don't think they have been so far.
Given that the function is necessary for some programs, the fact of
the matter has always been that it is a Very Good Thing to have string
functions implemented once, as efficiently as possible. Glibc is able
to spend time and effort on the most efficient implementations for
each architecture, which is quite important, and we should not expect
packages to have to have these functions.
If your stance is that you don't want glibc improved and developed in
the future, then please, don't bother trying to participate with it.