3 ms·
So some guy complains that a code path in libc is slow, but refuses to actually do anything to fix it. What's noteworthy here? Besides, this particular complain
by dima55 11y ago
So some guy complains that a code path in libc is slow, but refuses to actually do anything to fix it. What's noteworthy here? Besides, this particular complaint is 7 years old. Poster: is this still an issue?
- Qwertious 11y agoWhy are you automatically obliged to fix it JUST because you mentioned it? If they just didn't know in the first place then everyone would have benefited, and if they did then something was clearly seriously broken in that development community.
- TimSchumann 11y agoAnd from what I've heard, not that I would know, you've just described the rise of LLVM.
- the_why_of_y 11y agoBecause in FLOSS, nobody is entitled to a pony. Besides, the glibc developers did optimize memory and string operations, and the result was that people moaned because their buggy Adobe Flash players crashed because they were relying on particular implementation details of previous un-optimized implementations of memcpy that were explicitly not guaranteed by C99. http://lwn.net/Articles/414467/ http://lwn.net/Articles/414467/
- anon1385 11y agoI think you must be unfamiliar with the glibc maintainers during that period. They were hostile to outside contributions, to put it mildly. The only way to fix it would have been to make a fork. Which is what actually happened in the end with eglibc. A lot of the big distros dropped glibc and switched to eglibc because they didn't want to deal with the glibc maintainers and their refusal to fix things anymore: http://blog.aurel32.net/47 http://blog.aurel32.net/47