Glibc Steering Committee Dissolves; Switches To Co-Operative Development Model 102
First time accepted submitter writes "Following years under controversial leadership which, among other things, led to a fork (which was in turn adopted by some of the major distributions) the glibc development process has been reinvented to follow a slightly more informal, community-based model. Here's hoping glibc benefits from a welcome dose of pragmatism."
Summary (Score:5, Interesting)
Re:Summary (Score:5, Insightful)
Ahahaha, really? That's hilarious. Damn, I remember Drepper. I was told "he's quite nice in person", but you'd never know it from how he acted over email.
Heh...I read through the summary and thought, "actually, we could do with less pragmatism and more with just doing what is right regardless of what the people keep requesting. Design by committee is the path to bloat. Then I clicked the links and saw this comment by Drepper in response to a bug report on arm:
It's working fine everywhere but this carp architectures. I'm not going to make the code perform worse just because of Arm. Providing your own copy of that file if you care.
That's not lack of pragmatism, that's lack of professionalism. In fact, this is a good time to point out that "nice in person" is code for "asshole, but too much of a coward to behave like one if the other person is within punching distance."
Comment removed (Score:5, Interesting)
Re: (Score:3)
For similar stupid problems (and responses) sometimes I get the impression that the Linux Desktop bunch are actually sabotaging Desktop Linux.
Re:Summary (Score:5, Funny)
Is that like the People's Front of Judea and the Judean People's Front?
Re: (Score:2)
When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player.
That's OK. It's dead anyway [slashdot.org].
Re:Summary (Score:5, Insightful)
When I wrote about pragmatism I was thinking of this problem [redhat.com] where a modification to glibc's malloc() implementation broke the Adobe flash player. It is worth contrasting the attitude of Linus Torvalds in that thread with that of the glibc maintainers. I think most reasonable people would agree there is a trade off between supporting broken applications and ensuring things are done right. In this case, it would have cost glibc nothing to make a minor concession.
I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.
I think doing things the right way is more important than getting things working for now, because it prevents things from breaking in the future. More long term planning and less short-term concessions is the way to go. That said, "this doesn't work at all on arm" problem was an actual bug on glibc's side. If he thinks the new way of doing things hurts performance in other architectures, then he can provide the different code paths with optimizations if he cares to do so.
Re: (Score:2)
Re: (Score:2)
I'm sympathetic to the idea of leaving a change in place because it renders subtle bugs in crappy code visible, but to an end user it looks like your change broke his web browser for no reason.
I think we're on the same page here. I think the way to go here, when you have a clash between high profile software such as flash and glibc would have been for the glibc developers to get in touch with adobe and explain, "look, you have a bug in your software, how long will it take you to release a fix? If you give us an estimate, we can revert our changes to get you working again for now, but be aware that we will change it again at the end of the agreed-upon time period, so you really need to have a fi
Re: (Score:2)
What? So many posts and no one makes the obvious joke about Glibc being so big and bloated that it impacts high-speed-trading platforms? Really?
Re: (Score:2, Insightful)
I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.
Sometimes there is a point to that type of thinking. This is not one of those times.
The original definition of memcpy() defined overlapping copies as "undefined" behavior not for any good API design reason which would stand the test of time (it's usually a bad idea for APIs to permit inputs which cause "undefined" behavior without returning an error code or throwing an exception or whatever), but rather because it made the implementation smaller.
That's because memcpy() is literally from the dawn of the C S
Re: (Score:2)
That's because memcpy() is literally from the dawn of the C Standard Library, when the Bell Labs hackers were trying to squeeze as much functionality as they could into machines which look pathetically small by today's standards.
No, they don't look pathetically small by today's standards. And no, we can't move on. Yesterday's minicomputer is today's microcontroller or smartcard. These 40-year-old "small" platforms aren't dead, they've just been pushed down the food chain.
That may not mean anything for the platforms that glibc (or Flash, for that matter) targets, but it's very important for the C standard.
Re: (Score:2)
I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.
If you read all Linus' comments in that bug, he actually covers that angle. He says that either the thing should "just work", or else it should make it really clear that it's broken when inappropriately used. And that's the problem with backwards copy - it doesn't fast-fail the process or anything like that, it just produces garbage output. If you're lucky, this might crash. If you're less lucky, this might output garbage to the user (as in this case), with no easy way to diagnose it. If you're particularly
Re: (Score:2)
If you read all Linus' comments in that bug, he actually covers that angle. He says that either the thing should "just work", or else it should make it really clear that it's broken when inappropriately used. And that's the problem with backwards copy - it doesn't fast-fail the process or anything like that, it just produces garbage output. If you're lucky, this might crash. If you're less lucky, this might output garbage to the user (as in this case), with no easy way to diagnose it. If you're particularly unlucky, it may actually output some private information (say, a password?), or be otherwise exploitable.
That's sound software development advice, I don't disagree with it. I'm not defending reverse memcpy, I'm merely saying that "flash doesn't work when we implement memcpy like this" isn't a good enough reason to change the implementation if the bug is on the flash side. There were other good reasons to do the copy forward pointed out in that thread, and I'm ok with that, but that's the difference between writing good code and being "practical" about it, ie, grandfathering in bad code just to make things wo
Re: (Score:3)
That's sound software development advice, I don't disagree with it. I'm not defending reverse memcpy, I'm merely saying that "flash doesn't work when we implement memcpy like this" isn't a good enough reason to change the implementation if the bug is on the flash side.
How about "Flash and some other programs in Fedora [redhat.com] don't work correctly when we implement memcpy() like this, and some of them might "not work correctly" in ways that are security holes, and we currently have no tools to reliably analyze C code to catch incorrect use of memcpy(), and the failure modes are not always obvious, so it might be quite a long time before all the code out there is fixed?
No, people shouldn't use memcpy() in calls where the source and destination regions overlap, but if it's going
Re: (Score:2)
That's the price you pay for programming in a non-managed language. I certainly agree with you in that memcpy() should check it's arguments and invoke memmove() (and print a nasty message to the console) in necessary, but ultimately, in a language like C, you can always put the runtime into an undefined state easily.
Re: (Score:2)
iOS lives quite happily without Flash. Mac users live either quite happily without Flash, or they live quite happily with Flash crashing sometimes.
Alternative history of Apple: Apple engineer speeds up memcpy implementation. Does some serious application testing for compatibility. Talks to Steve Jobs. "So wh
Re: (Score:2)
Re: (Score:2)
I hope I'm not being too pedantic, but if your OS is crashing or hanging due to Adobe Flash or any other user space application, then your OS is broken. Memory protection is not new.
You may, indeed, be inappropriately pedantic; he referred to "crashes or hangs", he did not explicitly say that the entire machine hung or crashed. Perhaps they were Safari (or Firefox or $OTHER_BROWSER_THAT_HAS_A_FLASH_PLUGIN) hangs or crashes.
Re: (Score:2)
Re: (Score:2)
Yeah, but he says "at least 80% of all crashes and hangs on my Mac" and then talks about how "iOS lives quite happily without Flash" but yeah, I'm sure he was referring to his browser and not to the whole machine.
Good, I'm glad you agree with me, and realize that neither of the two statements you cite are in any way indications that he refers to the OS crashing or hanging as a whole (given that both OS X and iOS are UN*Xes that put each process's userland code in a separate address space and protect the kernel's address space from userland code):
Re: (Score:2)
A browser shouldn't crash either even if a plugin does. Run them in a separate process, and better yet, run every tab in a separate process.
Re: (Score:2)
A browser shouldn't crash either even if a plugin does. Run them in a separate process,
Which Safari now does (I forget whether that was introduced in Safari 5 or earlier), and I suspect at least some other browsers do.
and better yet, run every tab in a separate process.
Which Safari doesn't do, although it does run the UI and the rendering/JavaScript stuff in a separate process [webkit.org] (that was introduced in Safari 5.1).
Re: (Score:2)
Alternative history of Apple: Apple engineer speeds up memcpy implementation. Does some serious application testing for compatibility. Talks to Steve Jobs. "So what have you been working on?" "I made the C library a few percent faster, which benefits all users. It makes Adobe Flash crash". Steve Jobs: Dies laughing.
Definitely an alternative [apple.com] history [apple.com]. (And, yes, memcpy() and memmove() use the same code for each of the other versions of that code - "scalar" 32-bit x86 [apple.com], SSE2 32-bit x86 [apple.com], SSE3 32-bit x86 [apple.com], SSE 4.2 32-bit x86 [apple.com], and PowerPC [apple.com]. The source to the ARM versions isn't available, so it's possible that for iOS it matters which one you use.)
But use memcpy() only where you don't have overlap, even if you're working on OS X (or, I think, most if not all of the *BSDs), anyway.
Re: (Score:2)
Ironically, it seems that this problem was the last straw for Linus to switch from Fedora to Linux Mint.
Re: (Score:2)
When I wrote about pragmatism I was thinking of this problem [redhat.com] where a modification to glibc's malloc() implementation broke the Adobe flash player.
Presumably you meant memcpy(), not malloc(). Somebody at Adobe needs a gentle reminder ("gentle" because I can't say for certain that I always remember that memcpy() is explicitly allowed not to properly copy between overlapping memory regions - "properly" meaning "as if the source region were copied to a temporary buffer and then the temporary buffer were copied to the destination region" - but memmove() is explicitly required to do so) that this is a job for memmove() Man.
So the question is whether the
Re: (Score:2)
So the question is whether the reasons for doing the backwards copy, as mentioned in the cited bug report and items to which it links, are sufficient to justify exposing the bugs in buggy programs such as the Flash player. If the performance benefits aren't large, perhaps they aren't.
...especially if the bugs in question are security bugs [redhat.com]. If it turns out that it's too easy for people to use memcpy() when they should be using memmove(), perhaps there are technically good reasons not to have separated them, as long as "technically" includes "psychologically" as well as "computer hardware and software-wise", given that much of the computer software that would use memcpy() and/or memmove() is, for better or worse, written by human beings.
Re: (Score:2)
I'll wait and see. It appears they've shed themselves of the more poisonous members but that announcement is just a pile of words that past acts do not support.
I'd prefer to have seen glibc die and eglibc take over. It is a more vibrant effort and has embraced embedded devices.
Re:Drepper and Theo are great men. Respect them. (Score:4, Insightful)
They are vilified as being "mean" or "intolerant" because they act like mean intolerant assholes.
A truly great programmer does not feel the need to belittle others' efforts. A truly great project leader does not feel the need to be rude and dismissive.
Compare Linus Torvalds, who is just as opinionated and can be just as abrupt, and yet somehow manages not to be widely perceived as a mean intolerant asshole. Consider the possibility that this is because he is also frequently observed being polite and saying nice things in public.
Re:Drepper and Theo are great men. Respect them. (Score:5, Interesting)
When I first started using Linux (about '97).. I emailed Torvalds to say that I thought Linux needed to advertise because a lot of people didn't know it existed. He actually responded and politely explained how the project is put together/why that wasn't going to happen.
Re: (Score:2)
A truly great programmer does not feel the need to belittle others' efforts. A truly great project leader does not feel the need to be rude and dismissive.
I don't think having such a psychological complex necessarily disqualifies one from being a "truly great programmer." There are plenty of utter douchbags who excel in their fields/skills. But you'd be right about project leadership, as that is an area that requires interpersonal skills and much patience and tolerance. Partly because you have to deal adeptly with highly skilled douchebags, but especially because you have to deal with the mediocre ones as well.
Re: (Score:1, Interesting)
Ulrich and Theo have both earned my respect based on their software development accomplishments. I could not care any less about what they may or may not have said to somebody on some mailing list or bug report. That is all secondary to the amazing software they're managed to produce.
I don't have exact numbers here, but Ulrich has had a massive role in producing what may very well be the most widely used C library ever. There's a very good chance that the very computer you're using right now is executing at
Re: (Score:3, Informative)
I don't have exact numbers here, but Ulrich has had a massive role in producing what may very well be the most widely used C library ever
Is this 'may be' as in the Wikipedia definition, meaning 'isn't'? FreeBSD libc - not GNU libc - is the basis of both the Android and OS X libc implementations, and either one of these uses likely dwarfs glibc installs. And that's before you get to the Microsoft one (which is crap, but is installed on every Windows system).
Re: (Score:2)
Not that have some kind of allegiance to the glibc, but what do all those Linux based GPSs, routers, TVs, etc, not to mention all those servers? Franky, I find it hard to believe that Android dwarfs all of those put together.
Re:Drepper and Theo are great men. Respect them. (Score:4, Informative)
Not that have some kind of allegiance to the glibc, but what do all those Linux based GPSs, routers, TVs, etc, not to mention all those servers?
Most embedded users don't use glibc either, they use something like newlib or uclibc, depending on the resource constraints.
Re: (Score:1)
As somebody who has worked on many embedded Linux devices in the past, and who continues to do so today, I can tell you that you're completely wrong. Even the cheapest embedded hardware we deal with today is more than powerful enough to handle Linux and glibc, and that's what almost everybody chooses to use. This has been true since about 2003-2004. In fact, it takes more work and effort to not use glibc these days! Nobody will take you seriously if you suggest having a single developer waste even a single
Re: (Score:2)
Speaking as someone who develops embedded devices: Raven64 is correct.
Many projects still require minimal hardware(less than 16KiB RAM, a barebones processor with no cache etc etc), for many different reasons, such as hardening, long battery life(speaking months or even years here, not hours or a couple of days at most), heat/cooling reasons etc, and reduced complexity, increasing reliability.
Other reasons not to use glibc include real-time requirements, with glibc being barely capable of soft real-time, me
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yeah, but the AC claimed that the hardware restraints don't exist anymore
Re: (Score:1)
It's very doubtful that all FreeBSD, Android, Mac OS X and iOS installations put together "dwarf" the number of Linux installations, as you claim. Among all of those installations or devices, including any ever manufactured (although many are no longer used, given their surprisingly short lifespan), it's unlikely that over 1 billion devices have been shipped. In reality, we're probably looking at a range of 600 million to 800 million units, if even that.
Linux is extremely prevalent, much more so than even y
Re: (Score:2)
Re: (Score:2)
I don't have exact numbers here, but Ulrich has had a massive role in producing what may very well be the most widely used C library ever. There's a very good chance that the very computer you're using right now is executing at least some of the code he's written hundreds of times each second!
There's an excellent chance that the computers that a number of people posting to Slashdot are running are executing code either in a C library from Microsoft or in one that's a combination of FreeBSD and Apple code; are you asserting that most Slashdot posters are running Linux on the machine on which they're posting (which might be correct - the Slashdot audience is different from the "owns a desktop or notebook computer" audience) or that Drepper's code is in one or both of those C libraries? The rest o
Re: (Score:2)
Respect is earned, not given.
Except in Bradford West.
Re:Drepper and Theo are great men. Respect them. (Score:4, Interesting)
Re: (Score:1)
Re: (Score:3)
I dunno; GP has actually signed his post, unlike you, and anyone can go check his Slashdot comment history. In fact, I don't even need to do that, because I see his upmodded posts often enough - and, invariably, they are informative and correct when technical matters are involved (and he doesn't post about stuff he doesn't know, either).
Drepper, on the other hand... his stubbornness when pointed out that his code is plain wrong and non-portable is enough to judge him on his merits alone, regardless of the a
Re: (Score:3)
Re: (Score:1)
now Drepper has gone to work at Goldman Sachs
I wonder if he refers to gcc users as "muppets".
fork valley (Score:3)
There are a couple of forks apparently. Why does this have to be one monolithic library?
https://en.wikipedia.org/wiki/GNU_C_Library [wikipedia.org]
Re:fork valley (Score:5, Interesting)
Excessive "modularity" can become hell. (Score:5, Informative)
Monolithic libraries are the way to go. They make software development much easier.
If you don't believe me, just look at the GNOME project. The last time I tried to build it from scratch by hand, there must have been at least 50 libraries I had to build first. That was several years ago, so there are probably many more that are needed now. Those were just libraries from the GNOME project, too! That's not including glibc, the many X libraries, Gtk+, and so forth! Don't forget that you'll need to start making sure you're using the right versions, too. Some of these libraries are released yearly, while others have a new release every week.
To realistically build something like GNOME, where they went absolutely stupid with unnecessary modularity, you need to use one of the scripts that are out there that'll do it all for you. Those scripts end up being a solution to a problem that shouldn't exist in the first place! They're only needed because what should be one monolithic library was split out into 60 smaller libraries. You'll need all of the libraries to get even a basic GNOME installation up and running, so there's no point in separating them.
It's not the 1980s any longer. We don't statically link everything using dumb linkers that can't strip out unused executable code. Modern OSes using dynamic linking and delayed loading only ever use the parts of libraries that are actually used.
Re: (Score:2, Insightful)
Agree on that. Similarly, even though GTK+ purports to be cross platform, I never use it because of the many libraries it requires, GLib, ATK, Pango, WhatEver. It's just too much pain to get them all right and distribute the stuff to somebody not running GNU/Linux. GTK+/GNOME guys suffer badly from overgeneralization. They just don't realize that nobody is going to give a shit about their complex system and want to modify its tiny little details using their wonderful module system.
Re: (Score:3)
+2 that.
The building complexity is compounded also by a project's over-specification of dependencies. That is, instead of just requiring FooLib x.y, they are requiring x.y.z. Part of the problem here is that projects use dotted-version notation inconsistently. I would never expect an API change with a .z change, and I would only expect an API change to add functionality with a .y change but never a break in current code. A change in major version means anything goes. Many projects follow this. I wish I had
Re: (Score:3)
The building complexity is compounded also by a project's over-specification of dependencies. That is, instead of just requiring FooLib x.y, they are requiring x.y.z.
Really this is a matter of not having the assets to do proper testing. A good test-driven-development and automated test environment would allow developers who are just trying to be cautious to be more confident about allowing more versions of dependencies.
Re:Excessive "modularity" can become hell. (Score:5, Interesting)
I like Qt's approach with only a couple of large libraries (QtCore, QtGui, QtXml,
Re: (Score:2)
Why does this have to be one monolithic library?
Because it is the C standard library? Something that doesn't really make much sense to have just in part, you know. If you're writing portable C code, you expect it all.
Re: (Score:2)
Be thankful it is as monolithic as it is... if you've ever had to deal with building lib + toolchain on an architecture where the triplet system (the name like armel-linux-gnu) has to be fudged between binutils, gcc, and libc, there is a lot of hair-pulling involved there. I'd hate to think what it would be like if, say, libm went out in its own independently managed branch and the build system became unsyncronized at that level. WIth modern processors available in a greater variety of configurations with
It's not a fork (Score:4, Informative)
It's clearly written in the fery first FAQ [eglibc.org]:
EGLIBC is not meant to be a fork of GLIBC.
Re: (Score:2)
The icon is wrong (Score:5, Informative)
It should be GNU, not Debian. Glibc is very much a GNU project. How do people not know GlibC is a GNU project?
Re: (Score:1)
In fairness, Debian is involved as well, as it supported the eglibc fork by adopting it.
[which is mentioned in the linked resources, but not in the summary].
I'd say the GNU icon should be added, and the Debian one could also stay, as long as the Debian side of the story is mentioned in the summary as well.
Comment removed (Score:4, Insightful)
Re: (Score:1)
That's not true at all.
#1 - glibc is a GNU project
#2 - to contribute code you do need a copyright assignment to the FSF.
You've confused something else.
For a good laugh (Score:5, Funny)
Read http://sourceware.org/bugzilla/show_bug.cgi?id=4980 [sourceware.org] or http://sourceware.org/bugzilla/show_bug.cgi?id=4403 [sourceware.org] for a good laugh. /. trolls pale in comparison. :D
Re: (Score:2)
Unfortunately, it seems that at least some of the Ulrich Drepper "don't reopen" replies were not actually him, but an impostor...
Card game (Score:2)