4 ms·

Gilbc a bug and a Joke

68 points by digamber_kamat 16y ago

gregschlom 16y ago
This story, and the story about the change in memcpy that broke Flash on Fedora, gives me a really bad impression of the people that maintain glibc. Seems like they really don't welcome comments and contributions.
- deleted 16y ago
  [deleted]
- bryanlarsen 16y ago
  It's not 'people', it's just Ulrich Drepper. It's so bad that Debian switched to eglibc just so they wouldn't have to deal with Ulrich. Sure, they publicly give other reasons, but everybody knows it's because of Ulrich.
  - arundelo 16y ago
    In fact in the list of reasons here http://blog.aurel32.net/?p=47 http://blog.aurel32.net/?p=47 has a "More friendly upstream" list item which gives four "as opposed to" examples, all of which involve Drepper.
  - ZeroGravitas 16y 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 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.
    - groby_b 16y ago
      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.
      - ZeroGravitas 16y ago
        Both those function were added by the original creator of glibc very early on, not by Drepper.
        groby_b 16y ago
        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.
    - potatolicious 16y ago
      > "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.
  - nddrylliog 16y ago
    So how do we solve this problem in the OSS world? I've had my share of problems when leading open-source projects, and I remember a few particularly troublesome contributors, who made many others run away and generally decreased the quality as a whole of software, but Drepper seems to be of a considerably greater magnitude. Is there any proper way to deal with this?
    - MattJ100 16y ago
      Perhaps http://producingoss.com/en/difficult-people.html http://producingoss.com/en/difficult-people.html could give you some insight. I much recommend this book as a guide to the basics and best practices of running an open-source project - it certainly helped me when I started. I don't necessarily agree with everything there, and in reality every case is different - but it's always good to read the experiences of others.
  - sedachv 16y ago
    Ulrich Drepper thinks strlcopy and strlcat (http://www.gratisoft.us/todd/papers/strlcpy.html http://www.gratisoft.us/todd/papers/strlcpy.html) are "horribly inefficient BSD crap" (http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.htm...). This IMO qualifies him as an idiot.
unwind 16y ago
The title should be "glibc", not "gilbc".
- dangrover 16y ago
  Glib? I'll say!
- spooneybarger 16y ago
  When i read it, i saw glibc. autocorrecting brain i guess.
ot 16y ago
Nowhere in the spec (http://linux.die.net/man/3/strfry http://linux.die.net/man/3/strfry) it's written that the permutation is uniformly random, it just says > The strfry() function randomizes the contents of string by using rand(3) to randomly swap characters in the string. The result is an anagram of string. It doesn't even say that every permutation can be produced. So the code is already compliant to the spec. The difference with the memcpy issue is that nobody is really using strfry, especially nobody expecting an uniform permutation (rand() has ridiculously little entropy, and the space of permutations is huge). Still, put in context this bug report is very funny :)
- digamber_kamat 16y ago
  What is meant by Random? Random distribution is always uniform unless otherwise mentioned. It means every event should be equally likely as well.
bhickey 16y ago
If you're interested in why this sort of approach fails, I wrote a brief post on the subject: http://www.bhickey.net/2011/02/naive-algorithmic-shuffling/ http://www.bhickey.net/2011/02/naive-algorithmic-shuffling/
ssp 16y ago
Drepper is being more than reasonable in this bug. The strfry() function is a joke that only exists for historical reasons; it wouldn't be added today. He is 100% correct that fixing "bugs" in it is a waste of time.
- sausagefeet 16y ago
  The thing is though, he did put a minimal amount of effort into patching it, but rather than use the patch provided to him which completely solves the issue he did his own broken one. If you're going to complain that it's a joke and doesn't need fixing, don't fix it. If you are going to put a small amount of effort in, just use the free patch.
tzs 16y ago
Drepper was correct to close the bug, but for the wrong reason. The correct reason to close the bug is that the original version (the one that produces the non-uniform distribution of permutations) is how the function is documented as working. From the strfry man page: strfry creates a pseudorandom anagram of a string, replacing the input with the anagram in place. For each position in the string, strfry swaps it with a position in the string selected at random (from a uniform distribution). This only produces a uniform distribution of permutations if n^n/n! is an integer, where n is the length of the string. This is only true for n = 1 and n = 2. (At least that is what the current man page says...I don't know if it said that in 2007 when the bug was filed).
burke 16y ago
There are very few people that make me as angry as Ulrich Drepper does.
mustjoinsiiiite 16y ago
In my humble opinion, if the function is worth having in libc as a joke, then it's worth reviewing a properly submitted patch. If he can't be bothered, then it should be deprecated and removed.

This story, and the story about the change in memcpy that broke Flash on Fedora, gives me a really bad impression of the people that maintain glibc. Seems like they really don't welcome comments and contributions.

deleted 16y ago
[deleted]
bryanlarsen 16y ago
It's not 'people', it's just Ulrich Drepper. It's so bad that Debian switched to eglibc just so they wouldn't have to deal with Ulrich. Sure, they publicly give other reasons, but everybody knows it's because of Ulrich.
- arundelo 16y ago
  In fact in the list of reasons here http://blog.aurel32.net/?p=47 http://blog.aurel32.net/?p=47 has a "More friendly upstream" list item which gives four "as opposed to" examples, all of which involve Drepper.
- ZeroGravitas 16y 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 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.
  - groby_b 16y ago
    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.
    - ZeroGravitas 16y ago
      Both those function were added by the original creator of glibc very early on, not by Drepper.
      - groby_b 16y ago
        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.
  - potatolicious 16y ago
    > "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.
- nddrylliog 16y ago
  So how do we solve this problem in the OSS world? I've had my share of problems when leading open-source projects, and I remember a few particularly troublesome contributors, who made many others run away and generally decreased the quality as a whole of software, but Drepper seems to be of a considerably greater magnitude. Is there any proper way to deal with this?
  - MattJ100 16y ago
    Perhaps http://producingoss.com/en/difficult-people.html http://producingoss.com/en/difficult-people.html could give you some insight. I much recommend this book as a guide to the basics and best practices of running an open-source project - it certainly helped me when I started. I don't necessarily agree with everything there, and in reality every case is different - but it's always good to read the experiences of others.
- sedachv 16y ago
  Ulrich Drepper thinks strlcopy and strlcat (http://www.gratisoft.us/todd/papers/strlcpy.html http://www.gratisoft.us/todd/papers/strlcpy.html) are "horribly inefficient BSD crap" (http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.htm...). This IMO qualifies him as an idiot.

unwind 16y ago

The title should be "glibc", not "gilbc".

dangrover 16y ago
Glib? I'll say!
spooneybarger 16y ago
When i read it, i saw glibc. autocorrecting brain i guess.

ot 16y ago

Nowhere in the spec (http://linux.die.net/man/3/strfry http://linux.die.net/man/3/strfry) it's written that the permutation is uniformly random, it just says > The strfry() function randomizes the contents of string by using rand(3) to randomly swap characters in the string. The result is an anagram of string. It doesn't even say that every permutation can be produced. So the code is already compliant to the spec. The difference with the memcpy issue is that nobody is really using strfry, especially nobody expecting an uniform permutation (rand() has ridiculously little entropy, and the space of permutations is huge). Still, put in context this bug report is very funny :)

digamber_kamat 16y ago
What is meant by Random? Random distribution is always uniform unless otherwise mentioned. It means every event should be equally likely as well.

bhickey 16y ago

If you're interested in why this sort of approach fails, I wrote a brief post on the subject: http://www.bhickey.net/2011/02/naive-algorithmic-shuffling/ http://www.bhickey.net/2011/02/naive-algorithmic-shuffling/

ssp 16y ago

Drepper is being more than reasonable in this bug. The strfry() function is a joke that only exists for historical reasons; it wouldn't be added today. He is 100% correct that fixing "bugs" in it is a waste of time.

sausagefeet 16y ago
The thing is though, he did put a minimal amount of effort into patching it, but rather than use the patch provided to him which completely solves the issue he did his own broken one. If you're going to complain that it's a joke and doesn't need fixing, don't fix it. If you are going to put a small amount of effort in, just use the free patch.

tzs 16y ago

Drepper was correct to close the bug, but for the wrong reason. The correct reason to close the bug is that the original version (the one that produces the non-uniform distribution of permutations) is how the function is documented as working. From the strfry man page: strfry creates a pseudorandom anagram of a string, replacing the input with the anagram in place. For each position in the string, strfry swaps it with a position in the string selected at random (from a uniform distribution). This only produces a uniform distribution of permutations if n^n/n! is an integer, where n is the length of the string. This is only true for n = 1 and n = 2. (At least that is what the current man page says...I don't know if it said that in 2007 when the bug was filed).

burke 16y ago

There are very few people that make me as angry as Ulrich Drepper does.

mustjoinsiiiite 16y ago

In my humble opinion, if the function is worth having in libc as a joke, then it's worth reviewing a properly submitted patch. If he can't be bothered, then it should be deprecated and removed.