Re: Glibc-based Debian GNU/KNetBSD

[Perry E.Metzger <perry@piermont.com>]

Robert Millan <zeratul2@wanadoo.es> writes:
> On Mon, Dec 01, 2003 at 01:59:49PM -0500, Perry E.Metzger wrote:
>> If you mean that the NetBSD folks are going to abandon their libc,
>> which is really nice to work with, I think you're mistaken. It is
>> unlikely that they're ever going to do that. ("They" includes me,
>> fyi.)
>
> I'm not impressed.

Hey, you said that you would be able to avoid having to deal with
maintaining the glibc stuff yourself because the "upstream" would do
it for you. I doubt that the FSF people will do it, and I doubt that
we (NetBSD) are going to do it, so what's left?

As I said, though, it is likely that the NetBSD folks would happily
add needed stuff from glibc to the netbsd libc. I mean, who wants to
have a libc that won't run popular third party apps? Of course we'd be
amenable.

>> If you had a list of functional deficiencies in the native libc,
>> though, it would probably be possible to re-implement them and fix
>> them in the native NetBSD libc. NetBSD would like to be maximally
>> compatible with third party apps, so we add stuff we need all the time
>> and are happy to do it. It would also likely be far less work to add a
>> few dozen new functions to libc than for you to re-implement the
>> userland SA framework and debug it.
>
> Porting to a Glibc-based from another is kids play.

You aren't listening. The threads stuff is not kids play. The threads
stuff is very, very difficult work to do. It is especially cruel stuff
because you end up thinking that you've gotten things down when
another bug pops up and refuses to die. Right now, after a year of
having it integrated, it has gotten to the point where I only get one
application crash every few weeks -- which is of course already
totally unacceptable. It isn't going to be pleasant to try to maintain
your own threads package (impossible, really), and if you port ours
you're going to have to spend a huge amount of time on the port, and
then constantly try to keep up with changes in the protocols. The way
that the SA kernel infrastructure and user level infrastructure
interact is constantly getting updated to make improvements, you see.

You're also going to find stuff left and right that you didn't know
about and that won't work quite right. Most POSIX calls are trivial,
but what happens when something has weirdly different semantics
between systems? For example, we've got stuff that's implemented on
top of kqueues -- and I doubt glibc handles those...

Anyway, what's the point? If you don't use the NetBSD libc, you lose
the benefit of all the nifty NetBSD hacks that make NetBSD
worthwhile. Why not just use the Linux kernel at that point? What
results won't have any of the benefits of either Linux or of NetBSD...

> In a few months I started two ports and brought them to a stage that
> took years for a group of people to attain.

Ever hear of the 80/20 rule? I easily believe you can get the thing
very far along inside a couple of months. Trying to make it actually
bulletproof for production use -- especially with all the bells and
whistles complete -- is not the same thing.


-- 
Perry E. Metzger		perry@piermont.com