Comment by ZeroGravitas
15 years ago
I was just googling this and it appears many of his decisions which might be considered rude or "not getting it", are actually a result of his philosophy of free software development, as outlined here:
http://udrepper.livejournal.com/7326.html
Excerpt: "[Development and testing is slowed down by trying to support every permutation of minority-interest OS/Architecture/etc.] The solution must be to restrict support to only a handful of architectures which are supported in the project. All other support must happen outside the tree and therefore all the work has to be done by the special interest groups.
I don't want to say we follow all these points perfectly, but for a big project glibc certainly comes closest to this. The only OSes supported in the tree are Linux and to some extend Hurd. The latter is certainly not a preferred target and does not hold back the development by requesting that no patch breaks the Hurd configuration. The supported architectures in the tree has been cut and probably should be cut even more. Only the architectures which are regularly tested (since they are supported in the various enterprise Linux distributions) are maintained plus a few historically supported architectures. The latter group should be cut down to the minimum. No global edits for the tree are required, they are voluntarily. I.e., fixing configurations which are negatively impacted by a patch is the duty of the people with interest in the configuration. All other configurations are maintained (or not) outside the tree. People can decide to use this additional repository at compile time to get access to the additional configurations. Nobody is robbed of the freedom but the costs are distributed fairly.
For my new projects the razor is even sharper. Only Linux is supported and only the few interesting mainstream architecture with reasonable APIs are maintained. Support for architectures with deliberately different APIs (i.e., IA-64) can be contributed. No other configuration is supported, actively or not, and people would have to exercise their right to add patches or fork the entire code to add other support.
IMO this is the only viable development model to allow free software to succeed since the remaining projects are huge in size and need concentrated efforts not diluted by diverging interests caused by a myriad of configurations."
Can't say I agree, but I can see his point to a certain degree. It's kind of like the difference between an uncaring asshole and a libertarian, he's trying to work in the interests of the greater good by fighting against unneeded complexity and unaligned incentives.
Ah, yes, must reduce complexity. That's why we have a basically useless thing like strfry() in glibc. Or memfrob()
Because nothing reduces complexity like code that's completely unusable for any real-world project.
Both those function were added by the original creator of glibc very early on, not by Drepper.
True, but I don't see him excising them, either. It's the worst of all possible choices - leave it in and don't maintain it.
> "It's kind of like the difference between an uncaring asshole and a libertarian"
It seems like he's both - if he wasn't an asshole and was simply a libertarian, he'd move to get this whole function deprecated and remove it from the codebase in due time.