Gilbc a bug and a Joke | Hacker News Reader

Gilbc a bug and a Joke

sourceware.org

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 :)

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

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

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.

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.

In fact in the list of reasons here

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.

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.

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?

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

Ulrich Drepper thinks strlcopy and strlcat (http://www.gratisoft.us/todd/papers/strlcpy.html) are "horribly inefficient BSD crap" (http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.htm...). This IMO qualifies him as an idiot.

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.

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.

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/

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

Glib? I'll say!

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

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.

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

Reply on news.ycombinator.com