Support for different shells (GLIBC only supports bash).
What exactly does this mean? How does a libc "support" a shell? I thought it was the other way around. Clearly tons (all?) of shells already run on glibc systems. Is this something that's only relevant for embedded systems?
Speaking as somebody who ports stuff to OpenBSD, it's a surprisingly common assumption in Linux programs that the standard shell is bash, when in fact it's not necessarily present on any other Unix. (sh, the bourne shell, is the default.)
While this sounds nitpicky, it's quite annoying to have problems testing a program because every single test case script has #!/usr/bin/bash hardcoded at the top. If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.
'If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.'
Are you sure? Bash-style functions and arithmetic subshells are pretty common. As long as they don't label the script with the Bourne interpretar (/bin/sh) then Bash scripting is fine.
I'm talking about incidental scripts included with programs for e.g. installation and regression testing, not scripts that encompass a lot of primary functionality. And, yes, it happens periodically enough to be considered a Linux-ism to watch for while porting.
Basically, glibc includes bash-specific shell scripts. You probably can't build glibc without bash, and some glibc components (like ldd, as the blog post points out) require bash.
Anything that moves power away from Ulrich Drepper and back to the community is a good thing. He is a poison to the open source community, and causes so much bad PR I'm amazed that he's still around.
Ulrich Drepper is a brilliant programmer and an expert on his field, but he cannot work with people. I figure that the former is the only reason why he's still around.
Ahhh... an unfortunate - but all too common - collection of personality traits. I propose that those people should be given lots of power but not be promoted to package maintainers. Of course, it's open source, so it's not like we can decree this or anything, but it sure would make many open source projects easier to contribute to.
Of course, it's open source, so it's not like
we can decree this or anything
He is employed by RedHat, so they're implicitly making the decision his working style is worth it.
But this is an example of open source at work -- people forked GLIBC due to, in part, dissatisfaction with Depper's (or Redhat's) working style and priorities.
Isn't that fork essentially a logical solution? If RedHat continues to pay Drepper for his work, he will still develop/maintain glibc. Meanwhile every valuable patch can be ported to eglibc (provided the licenses are compatible). It's a win-win scenario... community gains something and Drepper can still do what he does best in his sandbox.
What exactly does this mean? How does a libc "support" a shell? I thought it was the other way around. Clearly tons (all?) of shells already run on glibc systems. Is this something that's only relevant for embedded systems?