> > I'm also thinking about porting glibc to *BSD. I think that would > > solve very much problems, as a lot of programs just expect to have > > glibc installed. A lot of kernel-specific things are already fixed > > because we want them to compile on Debian GNU/Hurd. But the Hurd also > > uses glibc, I expect really much trouble with that. Most people just > > don't know how to write portable or don't care about it. I don't know > > if I'm the only one thinking about porting glibc. > > Feel free. I looked at it, and I think I'd rather spend my time > elsewhere. It would be a huge help, though. Even if you're successful, I > think we'll need to have the BSD libc available for the kernel specific > utilities.
Well, porting GNU libc is definitely a Nice Thing(tm). The question is, will we want to use it? There are certainly people who think that one of the main attractions of a BSD is the sleeker, not-so-bloaty C library. Now, coexistence is certainly not the problem... the question is, which C libraries do programs use, and how much choice are we offering? Would the majority of packages be binary compatible? (/etc/alternatives/libc.a, anyone? :) Or would we have to fork into two architectures if we wanted to offer a choice, e.g. netbsd-i386-glibc and netbsd-i386-bsdlibc? Maybe we'll have to use NetBSD's linux emul after all? > As for portable code, I think that's something that needs to change. > Portable code tends to be better code. I'd rather see some of the Debian > tools like apt become more portable than have a glibc port, because I > think making those programs more portable will most likely improve them. I second this motion. :) - Michael ===== -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/MU d- s+:+ a--- C++ ULISBH+++ P+++ L++(-) E- W--(+) N o? K? w--- !O !M V?> PS+++ !PE Y+ PGP- t+(-) 5 X R+>+++ tv-- b++ DI(+) D G e->+++ h r-- y ------END GEEK CODE BLOCK------ __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
