| |||||||||||||
That's silly. You can have strlcat() and strlcpy(), yet be compatibleThat's silly. You can have strlcat() and strlcpy(), yet be compatiblePosted May 22, 2009 11:14 UTC (Fri) by liljencrantz (subscriber, #28458)In reply to: That's silly. You can have strlcat() and strlcpy(), yet be compatible by nevyn Parent article: EGLIBC: Not a fork, but a glibc distribution
The comment I replied to specifically brought the strfry function up. So does the web page explaining why Debian has switched to eglibc. Different people have at multiple times stated that this is one of the important reasons for switching away from glibc, and I was making a direct response to one of them. Please explain to me how I am making a strawman argument.
Other then that, I agree with your comment. Drepper is by default terse to the point of approaching continuous rudeness. When people try to waste his time, he will flame them. He even perceives people as wasting his time when they are actually making valid questions sometimes. He is hard to work with. Glibc would be better of if he wasn't.
But much like Theo, Drepper is an exceptional project leader when it comes to technical aspects. The most relevant question is, would glibc be better of without him? Would it be better if an average coder with good people skills was managing the project? My guess would be no, that all the combined lost contributions from other people are smaller in value than his contributions to Glibc. Same thing with Theo. On the other hand, my guess would be that Jörg Shilling and the XFree86-people fall on the other side of that line. But that's just me guessing.
(Log in to post comments)
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 9:07 UTC (Sat) by nix (subscriber, #2304) [Link]
Er, the comment you replied to was a tongue-in-cheek joke, pointing at
aspects of Ulrich's maintainership that I really don't have any sort of problem with (hell, I don't care much about strfry() either: if only glibc's objects were sorted so strfry() wasn't pulled into memory on the majority of systems... and now with the paging-prefers-executables stuff it won't even get pushed out again.)
Did you really not see that?
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 10:04 UTC (Sat) by liljencrantz (subscriber, #28458) [Link]
I am sorry, I did not. My bad. On the other hand, I do not think the same argument was ironic when used to motivate Debians use of eglibc.
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 11:37 UTC (Sat) by nix (subscriber, #2304) [Link]
The point isn't strfry() et al. It's that Ulrich's behaviour towards
someone trying to fix a bug in that exemplifies his behaviour towards *anyone* trying to contribute *anything*, except if he's known them a long time (and sometimes not even then).
I could dig up dozens of examples but it's too depressing and it's a bank
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 9:22 UTC (Sat) by nix (subscriber, #2304) [Link] Drepper is an exceptional project leader when it comes to technical aspectsFor the record I consider this incorrect. He's an excellent hacker and virtually everything he implements is a sort of glittering jewel, perfectly designed (and perfectly undocumented and he has a habit of ignoring contributions of documentation). He'd make an excellent contributor. But unfortunately that is not his role in glibc. Maintainers' roles are higher-level, and there is where Ulrich's bad side comes out. He drops subsystems that he thinks are rarely used or that relate to architectures he merely finds unpleasant (e.g. MIPS, ARM) without listening to anyone pointing out that he might be wrong and without saying why; more than once he's rejected contributions, implemented them nearly identically himself some time later and credited himself alone in NEWS (I suspect anyone working in academe decided never to go near glibc again when that happened for the first time); he mostly refuses to give rationales for technical rejections so that people can fix whatever was wrong with their patches. Whether this is because he's scared of being convinced otherwise or just arrogant I have no idea... but can you imagine what would happen to the kernel, say, if it was run that way? 90% of the useful stuff we now have, maybe more, would simply not be there. He's such a hard maintainer to deal with that an entire mailing list was created whose sole reason for existence was that it was somewhere where people could talk about glibc without Ulrich growling at them every five minutes for 'abusing' libc-alpha@ by, uh, discussing alpha releases of glibc on it. I have never seen *that* in any other project. Developers can be in a project to scratch their own itch: but I think glibc is proof that large free software project maintainers need other goals too. First and foremost I think they have to be driven by a desire to make software that others can hack on easily and that does what users want, and in both of these areas Ulrich falls down like a lead balloon (especially when you note that glibc's users are random developers, and we've seen how he treats them when they dare to ask for help with one of his glibc-only totally-undocumented public APIs).
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 10:15 UTC (Sat) by liljencrantz (subscriber, #28458) [Link]
I think it's a pretty sane model to make the mainline version of a project only handle a small number of architectures, and force people who use rare architectures to create a «portable version». This means the maintainer doesn't have to be an expert on 20 different wonky architectures, and cleanly separates the responsibility of portability from the responsibility of development. This is what e.g. the OpenSSH people do.
As to dropping good patches and then reimplementing them himself while taking full credit, I had not heard such accusations before. Do you have any specific patch set in mind, something to validate this?
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 11:51 UTC (Sat) by nix (subscriber, #2304) [Link]
I'll have to dig it up. It didn't happen often and it was years and years
ago: I dithered about including it. It's not the real problem, to me: maybe he changed his mind and forgot the original contribution had ever existed, which is fine. The real problem is his attitude to contributions.
Rare architectures Posted May 24, 2009 10:06 UTC (Sun) by man_ls (subscriber, #15091) [Link] I'm sorry, but ARM is not a "rare" architecture. It is #4 for Debian, and would rate #3 if arm and armel were counted together.
Rare architectures Posted May 24, 2009 11:45 UTC (Sun) by nix (subscriber, #2304) [Link]
More generally, there are more ARMs made than any other processor by a
considerable margin. It's only 'rare' if you ignore the embedded space completely.
That's silly. You can have strlcat() and strlcpy(), yet be compatible Posted May 23, 2009 12:06 UTC (Sat) by nix (subscriber, #2304) [Link]
Lest this seem pointlessly nasty I think the emerging de-facto split is
pretty much ideal: it leaves Ulrich and a few others to do technical wizardly in the alleged 'upstream' where they don't have to do anything hard like interact with human beings, and everyone else can go to eglibc, where all the contributions from everyone else and all the stuff people need to actually build a glibc for the distributions (other than RH) can be added on.
This is in effect the split that has long existed anyway: it's only that
|
|||||||||||||