The GNU C Library version 2.20
lists.gnu.org
lists.gnu.org
That's why many people are opposed to them.
And there was much rejoicing.
> And there was much rejoicing.
Could you explain why?
1) glibc supported this even if statically linked, and could encounter runtime issues if the gconv modules found did not match glibc. For instance, if you shipped a statically linked binary.
2) glibc can handle not finding these modules at all, but once it finds them, if they fail to work glibc can choke and die.
3) These modules take up quite a lot of space, and glibc installs them by default. If you're building a space-constrained or embedded system, you'd want to remove them.
I hold Torvalds in much, much higher regard than Jobs in this respect, because -- unlike Jobs who got co-operation and loyalty mostly in return for money, Torvalds has been able to do so without being the benefactor of the contributors he co-ordinates.
Torvalds can and does write the occasional scathing email, and that's what makes the news and creates the impression - but he actually does that when it's needed to drive a point (and when asked about it he explained more than once - being subtle in a mailing list read by thousands simply does not work). Most of the time, he is a nice, considerate and appreciative.
Torvalds has amazing people skills, even if occasionally he rubs some people the wrong way. I would say the same about Jobs, even if I disagree with his way. You just can't get thousands of people to do stuff, money or not, unless you have people skills.
Drepper in his capacity as libc maintainer was none of this.
When you can inspire people to push themselves harder than they would push themselves normally, you tend to see a lot of greatness. The way he did it was basically to be a sociopath however, which is unfortunate for all who worked directly with him.
That's not really accurate. Other companies paid developers far more without getting the same results. Jobs also inspired people, if not as person (e.g could be a jerk) surely as someone with a specific vision people wanted to be part of.
People skills != being polite and beloved by all.
(Plus, Jobs didn't have much programming skills, if any, mostly business, understanding markets and knowing how to build products that matter skills).
If you don't feel comfortable turning all warnings into errors, then use -Werror=some-warning and -Werror=some-other-warning to turn specific warnings into errors, to make sure those particular warnings never get into the project.
I'm using clang's -Werror -Weverything, which is obviously rather brittle. Building without -Werror is done via
make NOWARN=error-Werror is much too fragile for production releases, stop foisting it on unsuspecting users.
If you mean the fraction of software depending on glibc-specific features: probably less than 50%, much less if you only count software that meant to depend on glibc-specific features.