
Gilbc a bug and a Joke - digamber_kamat
http://sourceware.org/bugzilla/show_bug.cgi?id=4403
======
ot
Nowhere in the spec (<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
What is meant by Random? Random distribution is always uniform unless
otherwise mentioned. It means every event should be equally likely as well.

------
tzs
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).

------
gregschlom
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.

~~~
bryanlarsen
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.

~~~
ZeroGravitas
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.

~~~
groby_b
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
Both those function were added by the original creator of glibc very early on,
not by Drepper.

~~~
groby_b
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.

------
ssp
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
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.

------
bhickey
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/>

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

~~~
spooneybarger
When i read it, i saw glibc. autocorrecting brain i guess.

------
mustjoinsiiiite
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.

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

