On Saturday 07 November 2009 07:44:59 walter harms wrote: > i foresee a > future where we have a libsposix2c with all the GNU/BSD/XYZ extensions. Any > thoughts about this ?
Since you asked, my thoughts are "oh please no". Let's not open this can of worms. Busybox is not a C library, it's not a kernel, and those are NOT OUR JOB. I am reminded that buildroot started life as a toolchain builder and uClibc test harness, but turned into a half-assed Linux distro with dozens of packages it had to maintain because they couldn't clearly state where the boundaries of the project were and thus say "no" to eternal bloat. Because of this, most of the uClibc developers circa 2003 got sucked of the uClibc project (including the then-maintainer), and the uClibc project nearly died as a result. It had 7 releases in 2003 (0.9.17 through 0.9.24), two in 2004, one in 2005, and none at all in the whole year 2006. The OLS paper on NPTL for uclibc was delivered in 2006 and _still_ hasn't shown up in a uClibc release over 3 years later. The uClibc mailing list got totally buried in buildroot traffic for a couple _years_ until I made a new buildroot list and politely kicked the traffic over there in 2006 so we'd _have_ a uClibc mailing list again. This strikes me as a case where busybox not only can say no, but _needs_ to. If the project want to avoid using extensions, and eliminate existing uses of them, that's a defensible position. If the project wants to document our requirements (SUSv4 plus X and Y and Z extensions), that's' fine too. But reinventing the C library and making this project's problem to maintain? Erik kept uClibc a separate project for a _reason_, and we _do_ work with that... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
