This is the mail archive of the
mailing list for the glibc project.
Re: [open-source] Re: Wish for 2002 ...
Thomas Bushnell, BSG <firstname.lastname@example.org> writes:
> So, to summarize:
> 1) We should not add these functions because it will make glibc a tiny
> bit slower. (Linus)
> 2) We should not add these functions because we don't really care
> about tiny improvements in speed. (Kaz)
> Can you pick a single story and keep it straight?
I believe that if you think about it for while longer, you'll realize that
both of those points are consistent and do not contradict each other.
You should not add those functions because it will make glibc a tiny bit
slower for every other program that doesn't use them and the speed benefit
for the programs that do use them is almost nonexistent and not worth the
additional glibc maintenance load and potential speed hit for every other
program that uses the library.
One of the significant problems with free software and open source
development in my opinion, and possibly with closed source development as
well although I have less experience there and can't be sure, is that the
cost of new features is underestimated because only the initial
development costs are considered. Every single time you add a line of
code to glibc, and particularly an external function, you're incurring a
long-term cost. There's a cost in documentation, in maintenance of that
code, in reading that code to understand the library, in dealing with user
questions about that code, and in dealing with things like future
standardization conflicts with the code. That's even apart from the
library speed issues that Linus raises and which are frequently discussed
on the linux-kernel list, and apply whether you believe in those costs or
Personally, I think that the previous decision to make glibc the be-all,
end-all library of anything that people find useful was at least partly
misguided; there is quite a lot of stuff in glibc that I think would have
been better implemented and maintained independently. For example, since
that portion of the library was previously mentioned, I would have found
it cleaner to have a separate BSD compatibility library that contained
those BSD functions that weren't part of the standard and that showed
little sign of every being standardized; one of the advantages of that
approach is that it encourages package maintainers to actually update
their code to the standard library APIs rather than relying on the
existence of old, now-obsolete interfaces. Water under the bridge at this
point; now that it's in the library, it can't be easily removed, and
doubtless there were good arguments both ways. But one can at least not
add anything new that doesn't meet a more rigorous standard.
Yes, the functions are extremely small and simple, but that argument cuts
both ways; they're small enough and simple enough that including them with
those applications that wish to use them is relatively painless and incurs
no great cost in binary size or distribution size, and as part of a
separate software package many of the costs glibc would face do not have
to be paid (for example, as internal functions in a separate program, one
doesn't have to worry about future standardization and potential
conflicts, one doesn't need to document the functions to the same level of
rigorousness, and one doesn't have to answer user questions about the
And death by a thousand pinpricks isn't any more pleasant than death by
sword impalement, in the end.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>