| |||||||||||||
LFCS 2012: The future of GLIBCLFCS 2012: The future of GLIBCPosted Apr 18, 2012 17:34 UTC (Wed) by pr1268 (subscriber, #24648)Parent article: LFCS 2012: The future of GLIBC
After reading PHP: A Fractal of Bad Design, I'm convinced that a vast majority of peoples' heartburn with PHP was/is caused by its haphazard design in which a large community provides input and updates. This is perhaps too much of a good thing, as this community has (obviously) a wide range of cultural and programming backgrounds, and all these different and divergent styles come together (of sorts) in the PHP language. Now, referring to the LWN article on the dissolution of the GLIBC Steering Committee, I'm wondering if GLIBC might begin to suffer the same category of issues that PHP has. I'm not necessarily trying to defend Ulrich or Roland (or maybe I am), but their tight grip on GLIBC combined with a conservative approach to accepting and incorporating patches may have been a good thing. I may just be comparing apples to oranges here; if so then don't mind me. ;-)
(Log in to post comments)
LFCS 2012: The future of GLIBC Posted Apr 18, 2012 18:13 UTC (Wed) by aliguori (subscriber, #30636) [Link]
I think it's more about extremes. Letting anyone commit random pieces of crap to a project results in a PHP.
But having a single person declare that entire architectures are broken and therefore not worth supporting in something like glibc is going to the extreme in the other direction.
There are a lot of very experienced folks now guiding the glibc community. I think it's a wonderful thing and I expect lots of goodness to come from it. I'm looking forward to dusting off some old patches and trying again to fix a few things...
LFCS 2012: The future of GLIBC Posted Apr 18, 2012 18:18 UTC (Wed) by nix (subscriber, #2304) [Link]
Likewise. I've been grinning like a maniac these last couple of months whenever I think about what's happening to glibc :)
LFCS 2012: The future of GLIBC Posted Apr 20, 2012 8:44 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] I think the crucial difference here is that the progenitors of PHP themselves had severe contempt for proper design and implementation. Worse may be better, but worst is worst. Some context -- I don't believe the C library to be the best possible library beyond reproach. GLIBC inherits from the storied C / UNIX / POSIX legacy, and has to deal with all the fun that comes with that. That said, that legacy also comes with a lot of experience and respect for proper design and implementation. I don't see any radical rejection of proper software engineering practices or proper architecture happening. I think GLIBC will be just fine. PHP, on the other hand, seemed to reject such things from the get-go, if I read Rasmus' quotes properly.
LFCS 2012: The future of GLIBC Posted Apr 20, 2012 8:46 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]
Oops... I meant to post this upthread. Hit the wrong button while editing. *d'oh*
LFCS 2012: The future of GLIBC Posted Apr 18, 2012 18:42 UTC (Wed) by dskoll (subscriber, #1630) [Link] I think PHP is an example of a badly-designed project gone horribly wrong. I don't think a project with many contributors with diverse backgrounds necessarily has to turn out as bad as PHP did.
LFCS 2012: The future of GLIBC Posted Apr 19, 2012 15:42 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
I am in awe of that PHP rant.
LFCS 2012: The future of GLIBC Posted Apr 20, 2012 8:44 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] I think the crucial difference here is that the progenitors of PHP themselves had severe contempt for proper design and implementation. It seems that in many cases worse may be better, but I believe worst is always worst. "Worse is better" doesn't imply that success is equivalent to a race to the bottom; there's a threshold of optimality backed off from perfection where real progress reaches a peak and past that you fall off a nasty cliff. I don't believe the C library to be the best possible library beyond reproach. GLIBC inherits from the storied C / UNIX / POSIX legacy, and has to deal with all the fun that comes with that. Sure, we have some self-inflicted wounds here and there, but mostly our warts are enshrined in POSIX or a C standard. (For example, gets()) That legacy also comes with a lot of experience and respect for proper design and implementation. I don't see any radical rejection of proper software engineering practices or proper architecture happening. I think GLIBC will be just fine. I'm glad to see its development get a shakeup. It reminds me a bit of EGCS vs. GCC. PHP, on the other hand, seemed to reject respect for proper engineering from the get-go, if I read Rasmus' quotes properly. I think that's the fundamental distinction to pay attention to here.
|
|||||||||||||