
Debian is switching back to GLIBC - tshepang
http://blog.aurel32.net/175
======
IvyMike
I was unaware that drepper had left redhat (and glibc).

He's now at Goldman Sachs.

[https://www.linkedin.com/in/ulrichdrepper](https://www.linkedin.com/in/ulrichdrepper)

~~~
general_failure
Such great news. He was single handedly impeding the project.

~~~
jedisct1
So, does glibc provide strlcat() yet?

~~~
shmerl
I also wait for strlcpy. In cases when I need it on Linux I just take OpenBSD
implementation:

* [http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/st...](http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcpy.c?rev=1.11;content-type=text%2Fplain)

* [http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/st...](http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcat.c?rev=1.13;content-type=text%2Fplain)

~~~
aktau
We use the linux kernel implementation at neovim. But a libc (and possibly asm
optimized) implementation would be nice too (it could avoid two runs over the
data). Not that it's likely to be a big improvement, strlen and memcpy are
usually some of the most optimized functions there are.

~~~
justincormack
In that case you need to change the license of neovim to GPL, as that is the
license for Linux kernel code.

~~~
fulafel
Only if the implementation details (aside from what is dictated by the spec)
of strlcpy meets the originality threshold of a copyrightable work, no?

edit: Also depends on the jurisdiction,
[http://en.wikipedia.org/wiki/Threshold_of_originality#Exampl...](http://en.wikipedia.org/wiki/Threshold_of_originality#Examples_by_country)
\- and you don't necessarily have to change your own license, a valid
resolution is also to stop distributing versions of your program that
incorporate GPL'd code.

------
JoshTriplett
This seems like a very similar situation to egcs and gcc: a fork created
because the original project proved too painful to work with, and folded back
in after sorting out the project governance issues that caused the fork in the
first place.

~~~
plorkyeran
It's not quite as drastic: with egcs they basically just killed gcc and
renamed egcs, while here it was more of a merger of the projects. Very
similar, though.

~~~
gumby
They are in a funny way opposite (and I certainly know whereof I speak: look
at who wrote this message [0]).

It's hard to remember, but back in 1997 forking was considered really terrible
and to be avoided at all costs. When we split off to form egcs the main
resistance was to the idea that there would be a fork at all. Gcc, and a bunch
of other programs, had a single person who controlled the "official" release.
The fact that Cygnus maintained its own release tree for its customers (it was
still free -- it simply wasn't identical to the mainline, and in fact advanced
a lot faster) was the cause of much angst and even some mistrust.

My reason for making this fork was because the mainline was so far behind us,
and we had a commitment to folding all our changes back into the main line.
Since the gcc maintainer was the bottleneck, we simply declared our tree a new
fork with the support and participation of other major developers. We were
trying to be the opposite of exclusivist. But even so it took me months of
mailing, calling and negotiating. Many hours on the phone with rms who of
course predicted the doom of free software if we went ahead.

And we developed a steering committee, the first as far as I know for a free
software project.

In those two ways egcs was a watershed; plenty of developers thankfully now
know no other way.

So last year glibc went the opposite way: it decided it no longer needed a
steering committee. Cool!

[0]
[https://gcc.gnu.org/news/announcement.html](https://gcc.gnu.org/news/announcement.html)

~~~
gpvos
rms was (is?) probably still traumatized from the emacs/xemacs split, which is
still there and, as far as I can see, does impede emacs development.

~~~
riffraff
as an outsider, how does the (x)emacs split impede development?

It seems emacs has been steadily, if somewhat slowly, improving (new releases
etc).

~~~
gpvos
Well, it was a bit of a hunch, based on the slowness of development. Other
commenters have maybe given better explanations.

------
chengiz
Some strong comments against Drepper. What's the back story here?

~~~
damncabbage
He was the lead maintainer for glibc that people ended up needing to work
_around_ rather than _with_ :

[https://sourceware.org/bugzilla/show_bug.cgi?id=4403](https://sourceware.org/bugzilla/show_bug.cgi?id=4403)

[https://sourceware.org/bugzilla/show_bug.cgi?id=5070](https://sourceware.org/bugzilla/show_bug.cgi?id=5070)

[https://sourceware.org/bugzilla/show_bug.cgi?id=5531](https://sourceware.org/bugzilla/show_bug.cgi?id=5531)

~~~
kawsper
This one too:
[https://sourceware.org/bugzilla/show_bug.cgi?id=4980](https://sourceware.org/bugzilla/show_bug.cgi?id=4980)

~~~
vezzy-fnord
And yet none of these hold a candle to _this_ masterpiece:
[https://sourceware.org/bugzilla/show_bug.cgi?id=12701](https://sourceware.org/bugzilla/show_bug.cgi?id=12701)

I dare you to top that.

~~~
illumen
The reporter didn't provide enough detail to begin with, and was rude as well.

No excuse for rudeness, but I understand why he may have gotten that way.

Can you imagine the number of silly bugs the glibc maintainer has to go
through? Year, after year? Especially when people don't give enough evidence.

That is bug twelve thousand seven hundred and one. Developing a way to deal
with all of those badly reported bugs quickly would be to do it like this.
Just tell the people they are wrong, and have them provide more detail to
prove their case. If you say, "Can you please provide more information", often
bug reports just sit there.

Again, I don't condone the behaviour personally, since I would put people
above the software. But I can see how maintaining glibc for many years would
warp a person.

~~~
DanBC
I am not sure why you've been so heavily downvoted, other than "lots of people
disagree".

Perhaps if bug-lists are so awful to read (and I have no doubt that they are)
then the people reading them need more [close] buttons.

[close - no ref to standard]; [close - no test example code]; etc, and these
provide templated replies that ask people for correct reports.

"We closed this bug. You MUST provide a clear reference to the specification
showing how $THING is non-compliant.

AND

you MUST provide a test example code snippet".

This would help de-stress people reading the bugs, and might prompt people
providing bugs to provide correct information.

I agree that templates are often hateful nasty things - templates on Wikipedia
are really nasty approach. But here the alternative is, well, also pretty
unpleasant for some people.

~~~
illumen
Yeah, the more information you require the less likely people are to fill it
in.

I've been a fan of "search" not categorise for bugs for this reason. People
are more likely to blog about, or tweet about a bug than put it into a bug
tracker.

The role of an issue gardener is a really useful one too. A person whose job
it is to go into issues, and make them useful for developers. To communicate
with all sides, and enhance the process for everyone.

A great example of this is when @pyalot tested out various webgl
implementations on different browsers. Then he went to all the bug trackers,
and made notes. Then linked to various specifications, and pointed to test
cases.

[http://codeflow.org/entries/2014/jun/08/some-issues-with-
app...](http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-
webgl-implementation/)

This one guy through this has done a massive service to WebGL and the web.
I've seen too often various bugs and issues go through 2-3 browser iterations
because that's how long it takes for people to seriously test out features and
report bugs.

The collaboration going on now because of open bug trackers in web browsers is
amazing.

------
vezzy-fnord
Odd. I had always been convinced that they switched back to glibc again a
while ago, but it seems they're beginning to do it only now.

A lot of people are against forks that they deem frivolous or unnecessary, but
I think it's one of the most pragmatic and important parts of free software.
It's a failsafe, a Second Amendment, if you will.

------
cryptonector
Drepper's is a caustic personality. IIRC he's the reason that Linux has pre-
linking instead of Solaris'direct binding, and so on.

~~~
malkia
Can you share some details about this - like pros & cons once vs. another?

------
captainmuon
Wow, Debian (and by extension Ubuntu) has been using eglibc for five years and
I haven't noticed?

I even compiled new versions of gcc + glibc (and installed them into $HOME, to
run new binaries on older installations). You think I should have noticed that
there was no glibc on the host system to begin with. But actually, the only
thing I noticed is that the glibc (and gcc) build system is a bit crazy, and
that it definitely will benefit from a new project lead.

~~~
tshepang
You would not notice because it's practically the same. All files have the
same names (afaik) for example. They are compatible, and eglibc was like a
drop-in replacement. I believe they share nearly all code.

------
mrmondo
Anyone got another link? I'm getting "Error establishing a database
connection"

~~~
sharth
Here's a screengrab:
[http://i.imgur.com/XUNBIh1.png](http://i.imgur.com/XUNBIh1.png)

------
chrismonsanto
Cache:
[http://webcache.googleusercontent.com/search?q=cache:VrGJCG7...](http://webcache.googleusercontent.com/search?q=cache:VrGJCG7MXq4J:blog.aurel32.net/175&client=ubuntu&hl=en&gl=us&strip=1)

------
opinionperson
whats a debian?

~~~
nemasu
I think it's a type of penguin?

