Weekly Edition
Return to the Front page
| |||||||||||||||||||||||||||||||||||||||||||
A turning point for GNU libc
The kernel may be the core of a Linux system, but neither users nor
applications deal with the kernel directly. Instead, almost all
interactions with the kernel are moderated through the C library, which is
charged with providing a standards-compliant interface to the kernel's
functionality. There are a number of C library implementations available,
but, outside of the embedded sphere, most Linux systems use the GNU C
library, often just called "glibc." The development project behind glibc
has a long and interesting history which took a new turn with the
dissolution of its steering committee on March 26.
In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs. Once the core was in place, though, the developers realized they would need a few other components to build their new system; a C library featured prominently on that list. So, back in 1987, Roland McGrath started development on the GNU C library; by 1988, it was seen as being sufficiently far along that systems could be built on top of it. By the time the Linux kernel came around in 1991, GNU libc was, like many other GNU components, the obvious choice for those working to build the first distributions. But, while GNU libc was a good starting point, it quickly became clear that (1) it still needed a lot of work, and (2) the GNU project's management style was, in typical fashion, making it hard to get that work done and merged. So, early on in the history of Linux, the GNU C library was forked and a Linux-specific version ("Linux libc") was maintained and shipped with Linux distributions. The GNU project was rather slow to come around to the idea that Linux was the system that they had been trying to build all these years; they continued to develop their C library on their own, despite the fact that Linux was not using it. Early on most of the work came from Roland, but, slowly, other contributors appeared; the first contribution from Ulrich "Uli" Drepper appears to have been made in September, 1995. Early 1997 saw the first glibc 2.0 release; by then, most commits were made by Ulrich (though the code sometimes came from others). While Linux libc had been adequately maintained, it had not seen vast amounts of new development work. There came a point where it became clear that, in fact, glibc 2 was a better C library in many ways. Distributors of Linux came to the conclusion that the time had come to switch back to the GNU library and, for all practical purposes, simply abandon the Linux libc project. Those of us who lived through the subsequent transition (as seen in the Red Hat 5.0 and Debian 2.0 releases) still tend to shudder; it was a time when programs would not build and bugs abounded. But things eventually settled down and glibc has been the standard C library for most Linux distributions since. Glibc has continued to evolve up to the present at varying speeds; during most of this time, the bulk of the work has been done by Ulrich Drepper. Of the nearly 19,000 commits found in the project's git repository (which contains changes back to 1995), over 12,000 were made by Ulrich. Never known for a willingness to defer to others, Ulrich quickly became the decision maker for glibc. The project's steering committee was formed by the FSF in 2001 as a way of asserting some control over the project, but, to a great extent, that control remained in Ulrich's hands. In 2008, Roland described the situation this way:
drepper, roland have blanket discretion to commit. (This means
that Uli gets to go upside my head after I commit something he
doesn't like. It doesn't mean you get to lobby me to commit
something that Uli has refused.)
Four other developers (Andreas Jaeger, Jakub Jelinek, Richard Henderson, and Andreas Schwab) had the ability to commit "after approval." But that approval, in the end, had to come from Ulrich. One need not look far to find complaints about how Ulrich managed the glibc project. He was never one to suffer fools, and, evidently, he saw himself surrounded by a lot of fools. Attempts to get changes into glibc often resulted in serious flaming or simply being ignored. Developers often despaired of getting things done and simply gave up trying. It is easy to criticize Ulrich's attitude at times, but one should also not lose track of all the work he got done. This includes steady improvements to glibc, big jumps in functionality (as with the Native POSIX Thread Library work done with Ingo Molnar) and lots of fixes. Ulrich's work has made all of our systems better. That work notwithstanding, Ulrich is widely seen as, at best, an unpleasant maintainer who has turned the glibc project into an unwelcoming place. One need not challenge that characterization to point out that glibc actually had a number of problems associated with highly cathedral-style projects: a well-ensconced priesthood, a lack of interest in or awareness of the wider world's needs, etc. At some point, it seemingly became clear to a number of developers associated with glibc that it needed to become a more open project with more than a single point of control. A number of changes have been made to prod it in that direction. The switch to Git for source code management in May, 2009 was one such change. At that time, the repository was made slightly more open so that non-core maintainers could keep branches there. Ulrich opposed that decision, but Roland responded:
Please don't stand in the way of minor matters the rest of the
community wants to improve collaboration, on vague grounds of
conservatism or a default of mistrust.
The project started creating separate release branches and putting maintainers other than Ulrich in charge of them. The restricted-access "libc-hackers" mailing list fell into disuse and has been closed down. The use of Fedora as a sort of private testing ground has been halted after things broke one too many times. And a strong effort has been made to encourage more developers and to merge more code. The result is a release history that looks like this:
(The 2.15 date is when the release was tagged; the announcement was, for whatever reason, not sent out for a few months). The 2.15 release suggests that development activity is on the increase after a sustained low point. Indeed, it is at its highest point since semi-regular releases began in 2006. Activity since 2.15 (483 commits, as of this writing) continues to be high by recent historical standards; perhaps more tellingly, only about 25% of those commits came from Ulrich. Given that he accounts for over 60% of the changes from 2.10 to 2.14, that suggests that a significant shift has taken place. Also significant is the fact that Ulrich left Red Hat in September, 2010; according to his LinkedIn page, he is now "VP, Technology Division at Goldman Sachs." One can easily imagine that his new position might just have requirements that are unrelated to glibc maintenance. So a drop in participation is not entirely surprising; what is significant is that a growing community is more than taking up the slack. The culmination of these trends came on March 26, when Roland announced that there was no longer any need for a glibc steering committee:
With the recent reinvigoration of volunteer efforts, the community
of developers is now able to govern itself. Therefore, the
Steering Committee has decided unanimously to dissolve. The
direction and policies of the project will now be governed directly
by the consensus of the people active in glibc development.
Glibc will remain a project under the GNU umbrella; Roland, along with Joseph Myers and Carlos O'Donell, will be the official GNU maintainers. But that role will give them no special decision-making powers; those powers are meant to be exercised by the project's development community as a whole. David Miller (an active glibc contributor) was quick to celebrate this change:
If you've tried to contribute to glibc in the past and were rudely
treated and therefore gave up, I encourage you to come and try
again, things are much different now. I promise.
David also hinted that one other possible obstacle to contribution - the requirement to assign copyrights to the Free Software Foundation - is also being worked on, though the form the solution might take is unclear. Other developers are already talking about working to merge at least some of the changes from the EGLIBC fork back into the glibc mainline and reopening old bugs and change requests. So the GNU C library project has moved into a new phase, one where, for the first time in its long history, it will not be under the control of a single developer. It will be interesting to watch where things go from here. If the project succeeds in building robust community governance and shedding its hostile-to-contributors image, the pace of development could pick up considerably. Given the crucial position occupied by glibc on so many systems, these changes are almost certainly a good thing. (Log in to post comments)
A turning point for GNU libc Posted Mar 28, 2012 16:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Can we finally get better interface, not limited to POSIX crap?
Can we:
Please?
A turning point for GNU libc Posted Mar 28, 2012 16:19 UTC (Wed) by cmorgan (subscriber, #71980) [Link]
And along this line, can we deprecate strcat/strcpy and get http://www.gratisoft.us/todd/papers/strlcpy.html in place? Some of us still have to write c code and would welcome string functions that were less dangerous.
A turning point for GNU libc Posted Mar 28, 2012 16:25 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] If you want to use strlcpy/strlcat, you already can; you just have to link with a different library (libbsd). If your project standards forbid strncat, #define it to DONT_USE_strncat_YOU_IDIOT in some widely-included header.
A turning point for GNU libc Posted Mar 28, 2012 16:47 UTC (Wed) by nix (subscriber, #2304) [Link]
Deprecating strcat/strcpy is vanishingly unlikely. They're unpleasant functions, but they are ubiquitous. Adding __attribute__((deprecated)) to them or making the linker warn at link time (as is done for e.g. gets()) would do nothing other than cause those warnings to be universally ignored.
A turning point for GNU libc Posted Mar 29, 2012 2:05 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
Is there an ANSI C alternative to strcat and friends? Because if not, such warnings will greatly irritate programmers who compile with -Werror (as well as the usual -W -Wall -Wextra and friends) and -ansi.
Plus, these sorts of pedantic programmers are certainly capable of using strcat safely (which is possible to do, unlike with gets()).
A turning point for GNU libc Posted Jan 1, 2013 13:25 UTC (Tue) by shentino (guest, #76459) [Link]
They are here to stay, just like the win32 api, x86 architecture, and the qwerty keyboard layout.
anyone trying to replace them will do nothing more than just rock the boat.
A turning point for GNU libc Posted Mar 28, 2012 17:17 UTC (Wed) by arjan (subscriber, #36785) [Link]
there's nothing wrong with strcpy and co.
seriously, everyone who wants to outright ban them does not think it through.
(and btw the glibc version of strcpy and co actually do buffer overflow checks with the help of the gcc compiler for various cases)
A turning point for GNU libc Posted Mar 28, 2012 17:47 UTC (Wed) by jzbiciak (subscriber, #5246) [Link] I guess you passed over the extensive, erm, discussion over here: https://lwn.net/Articles/488032/
A turning point for GNU libc Posted Mar 28, 2012 19:17 UTC (Wed) by cmorgan (subscriber, #71980) [Link]
I had missed that entirely. Thank you for the pointer to it, it was interesting.
A turning point for GNU libc Posted Mar 28, 2012 21:00 UTC (Wed) by atai (subscriber, #10977) [Link]
How can you deprecate functions in the ANSI C standard?
A turning point for GNU libc Posted Mar 29, 2012 12:38 UTC (Thu) by nix (subscriber, #2304) [Link]
Easily, if they suck, are widely considered to suck, and are rarely used. e.g. gets(), in the C standard but even there a compatibility relic of a pre-stdio I/O library, has produced a link warning for the entire lifespan of glibc 2 (RTH added the warning in 1996). To my knowledge nobody sane has ever complained about it, because gets() usage is rare, always considered a bug, and easily replaced with something else in the standard library. None of these things are true of strcpy().
A turning point for GNU libc Posted Mar 29, 2012 12:57 UTC (Thu) by mina86 (subscriber, #68442) [Link]
gets() is actually removed in C11. The difference between gets() and strcpy() though is that in the letter you can validate the length before the call, while in the former you have no way of knowing in advance how long the line you are about to read from stdin is.
A turning point for GNU libc Posted Mar 29, 2012 20:30 UTC (Thu) by nix (subscriber, #2304) [Link]
Agreed... but gets() was in C89, and C99, and is in C++11, and the deprecation warning was present long before C99 or C++11 existed. So we *do* deprecate stuff in ANSI C, but only if it really does suck (like gets()).
A turning point for GNU libc Posted Mar 29, 2012 0:02 UTC (Thu) by Richard_J_Neill (subscriber, #23093) [Link]
While we're at it, could we please get rid of the broken behaviour that leading zeros make strings into Octal? This behavior is implemented so fundamentally in eg atoi() that many other programming languages, even those that do dynamic typing, inherit the bug. If I write "064", I generally don't mean "52"!
A leading zero practically NEVER means the user intentionally wants to work in base 8, it just means they did something naive with string-splitting or data-entry. Perhaps the user entered the reading from a digital-scale, complete with leading zero. Or they took a string such as $7.09 and parsed it as "trim off the leading '$', split at the decimal point, multiply the first number by 100, and add the two together, to get a result in cents".
I'd consider that leading-zero-means-octal is a nasty case of technical debt that we still be causing bugs in 100 years if we don't fix it.
One way would be to support a new notation, similar to the "0x" notation. Numbers beginning "0o" (that's a letter 'o') would be recognised as octal. Then we spend 5 years transitioning the existing legitimate instances of octal numbers (file permissions) to the new syntax, then for 5 years, make the old format illegal, then in 10 years time, we can start treating leading zeros as they were meant to be treated.
[At the same time, can I plead for a "streq()" function, being defined as "!strcmp()" ]
A turning point for GNU libc Posted Mar 29, 2012 4:52 UTC (Thu) by slashdot (guest, #22014) [Link]
Are you sure about atoi supporting octal?
AFAICT POSIX 2008 forbids that, and requires atoi to support only decimal numbers.
At any rate, changing that is probably highly unwise, as it might break stuff.
A turning point for GNU libc Posted Mar 29, 2012 10:37 UTC (Thu) by Richard_J_Neill (subscriber, #23093) [Link]
D'oh! You're quite right about atoi(). I meant strtol(), but wasn't thinking straight. strtol() allows you to optionally specify the base=10, but then won't permit 0x... for hexadecimal.
I agree that we can't change it right away. That's why I suggest adding a new prefix, "0o" to be used in the very rare case where the programmer deliberately intends to use octal. That wouldn't break anything, and over perhaps 5 years, people could migrate.
A turning point for GNU libc Posted Mar 29, 2012 20:53 UTC (Thu) by cmccabe (guest, #60281) [Link]
> While we're at it, could we please get rid of the broken behaviour
> that leading zeros make strings into Octal? This behavior is > implemented so fundamentally in eg atoi() that many other programming > languages, even those that do dynamic typing, inherit the bug. If I > write "064", I generally don't mean "52"!
It's a standard, like the QWERTY keyboard and the English language. Sorry, it's not going anywhere.
> At the same time, can I plead for a "streq()" function, being defined
Why don't you define it yourself? It's a one-line function.
A turning point for GNU libc Posted Mar 29, 2012 21:03 UTC (Thu) by cmccabe (guest, #60281) [Link]
Yes, it would be nice to see strlcpy make it into the standard library (see the thread about that in the last glibc article).
However, strcpy also has its uses. Sometimes you really do know the length of the source string, and you know it fits in the destination.
strcpy() / strlcpy() / asprintf() Posted Mar 30, 2012 11:07 UTC (Fri) by abacus (guest, #49001) [Link] But why to add strlcpy() to glibc while the function asprintf() is already present in glibc since considerable time ?
strcpy() / strlcpy() / asprintf() Posted Mar 30, 2012 12:50 UTC (Fri) by nix (subscriber, #2304) [Link]
And unlike strlcpy(), asprintf() really *is* very hard to implement in terms of other functions without either reimplementing printf format string parsing, or doing some sort of hideous hack involving mmap()ed regions repeated sprintf()ing, and catching SIGSEGV to detect overruns (yes, I've done that, yes, it made me feel ill).
strcpy() / strlcpy() / asprintf() Posted Mar 30, 2012 15:56 UTC (Fri) by nybble41 (subscriber, #55106) [Link] It seems to me like asprintf() should be easy to implement in terms of two calls to vsnprintf(): int vasprintf(char **strp, const char *fmt, va_list ap)
{
va_list ap_copy;
char *str;
int bytes;
char nul;
/* Determine the amount of memory required to format the string */
/* vsnprintf() returns the space required, but only stores the NUL. */
va_copy(ap_copy, ap);
bytes = vsnprintf(&nul, 1, fmt, ap_copy);
va_end(ap_copy);
if (bytes <= 0)
return bytes;
str = (char*)malloc(bytes);
if (!str)
return -1;
/* Format the string into the destination buffer */
bytes = vsnprintf(str, bytes, fmt, ap);
if (bytes <= 0)
{
free(str);
return bytes;
}
/* No errors; store pointer to destination buffer and return its size. */
*strp = str;
return bytes;
}
int asprintf(char **strp, const char *fmt, ...)
{
int bytes;
va_list ap;
va_start(ap, fmt);
bytes = vasprintf(strp, fmt, ap);
va_end(ap);
return bytes;
}
Is there any reason this implementation wouldn't work? (Ignoring minor issues/typos; I'm making this up as I go.)
strcpy() / strlcpy() / asprintf() Posted Mar 30, 2012 17:50 UTC (Fri) by nix (subscriber, #2304) [Link]
Ah yes, of course if you had a vsnprintf() you can do it. I forgot about that. (I spent way too long on deprived platforms with either no snprintf() or none that worked.)
strcpy() / strlcpy() / asprintf() Posted Mar 31, 2012 21:10 UTC (Sat) by lacos (guest, #70616) [Link]
You can still implement it easily (but perhaps not too elegantly): vfprintf() the stuff to "/dev/null", and use the return value for allocation. Both the vfprintf() function and the /dev/null special file are mandated by SUSv1 (UNIX(R) 95) and possibly by earlier standards.
(SUSv1 doesn't have snprintf(). Once I needed to compile a glibc-oriented program on OSF/1 4.0E, which one might have consider a reference implementation of SUSv1, even though it wasn't formally certified. The program needed snprintf() and there was none, so I printed the string first to /dev/null (for the size), then fully to a malloc()'d area, then copied the bytes that had room, then free()'d the area. ... Sorry if this sounds trivial and/or retarded :))
strcpy() / strlcpy() / asprintf() Posted Apr 5, 2012 8:36 UTC (Thu) by nix (subscriber, #2304) [Link]
Never thought of using vfprintf(). That's a good idea. Ah well. It would surely be more elegant than the longjmp() thing.
A turning point for GNU libc Posted Mar 28, 2012 20:06 UTC (Wed) by josh (subscriber, #17465) [Link]
Why does any of the functionality you described belong in libc, rather than a specialized library?
glibc already contains far more than it should. Arguably, it should contain only the bare-minimum interfaces for compatibility with standard C and POSIX; anything else ought to live in another library.
A turning point for GNU libc Posted Mar 28, 2012 20:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>Why does any of the functionality you described belong in libc, rather than a specialized library?
Because libc already has to do this! glibc has to read timezone database, so it can translate between UTC and current timezones. glibc has to support all kinds of encodings for iconv to work and so on.
But every single real-world program working with Unicode has to rely on third-party libraries. Ditto for timezone handling.
>glibc already contains far more than it should. Arguably, it should contain only the bare-minimum interfaces for compatibility with standard C and POSIX; anything else ought to live in another library.
Yes, that would be one way. But it should have been done from the start, now it's just not possible because of compatibility issues.
So the next best thing is to create proper and useful interfaces so all the existing complexity is at least not wasted.
A turning point for GNU libc Posted Mar 29, 2012 12:43 UTC (Thu) by nix (subscriber, #2304) [Link]
Timezone conversion should definitely be in glibc. It requires a large database -- though this is now universally supplied by other sources, glibc still has to do the conversion, so it makes little sense not to expose it. The only caveat here is picking an appropriate name: the getline() fiasco showed the problems created when you pick a name that is already in wide use (general rule: if your API addition breaks TeX, please pick a better name, and do so before POSIX standardizes it).
I'm not sure about proper unicode handling: doing it right is very difficult. Even doing case conversion right is difficult, and you can already case-convert with iconv() with no new APIs, only a new convention for 'locales' whose only difference from the standard ones is that they transliterate case. (But doing it that way does seem like a kludge.)
A turning point for GNU libc Posted Mar 30, 2012 21:58 UTC (Fri) by justincormack (subscriber, #70439) [Link]
Why should a timezone database be in libc? I would rather a tz update i not require a libc update. And the locale support in libc is legacy and should go. I do not wnt locales in my low level libraries.
A turning point for GNU libc Posted Mar 30, 2012 23:46 UTC (Fri) by nix (subscriber, #2304) [Link]
The tz database *itself* is no longer installed by glibc as of 2.16 (but is still in the source tree for the sake of testing).
The tz-manipulation code must stay, because widely-used functions in the exported API use it (notably tzset(), gmtime() and localtime()).
The locale support is very definitely not legacy: the C library is where all the internationalization code is located (found in libintl on many other Unix platforms). It is part of the API and ABI, used by every single internationalized program (which is most of them, these days) and can never ever be removed. (And printf() needs locale support for international printing of the decimal point and thousands grouping characters, and for the I alternative-output-digit flag character.)
A turning point for GNU libc Posted Mar 31, 2012 10:01 UTC (Sat) by mpr22 (subscriber, #60784) [Link] setlocale() and strcoll() (among other locale-related things) are both defined as part of the 1990 and 1999 versions of the ISO C standard, and I am not aware of them having been removed from the 2011 version. Therefore, every compliant hosted implementation of the C programming language is obliged to provide setlocale() and strcoll(), and by saying you don't want locales in your low-level libraries you are saying you don't want a compliant hosted implementation of the C programming language.
A turning point for GNU libc Posted Apr 5, 2012 8:29 UTC (Thu) by nix (subscriber, #2304) [Link]
setlocale(), strcoll(), and for that matter localeconv() are, of course, still there in C11, just as they were in C99 and C89.
A turning point for GNU libc Posted Mar 29, 2012 13:02 UTC (Thu) by mina86 (subscriber, #68442) [Link]
Actually the DST change history may work very unreliably. In some countries, DST change is announced days in advanced on completely arbitrary dates. This means that you have no good way of knowing when the next DST change is going to happen.
As for past changes, this is doable, but I dunno if tzdata actually stores all the historical data.
A turning point for GNU libc Posted Mar 29, 2012 19:34 UTC (Thu) by Jonno (subscriber, #49613) [Link]
tzdata record historical time zones and all civil changes since 1970, as well as some older historical information where available.
A turning point for GNU libc Posted Mar 28, 2012 16:38 UTC (Wed) by nix (subscriber, #2304) [Link] In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs.Bwahaha. I suspect more significant here was that Emacs already existed (and was the trigger for the whole thing). Everything else released early on was pretty crucial infrastructural OS-core stuff.
A turning point for GNU libc Posted Mar 28, 2012 17:50 UTC (Wed) by jzbiciak (subscriber, #5246) [Link]
It's classic middle-out design: Start with EMACS. Build an entire OS userland on top of it while building a kernel and runtime libraries under it. ;-)
Now only if that system had a decent editor. ;-) ;-)
A turning point for GNU libc Posted Mar 29, 2012 12:44 UTC (Thu) by nix (subscriber, #2304) [Link]
Hey, it could be worse. At least nobody tried to put unexec() into glibc!
A turning point for GNU libc Posted Mar 30, 2012 22:32 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Being able to dump and rerun a memory image of a program would be a hugely useful thing for C programs, though. Maybe not something to put in the C standard library, but having it available would be nice.
A turning point for GNU libc Posted Mar 30, 2012 23:48 UTC (Fri) by nix (subscriber, #2304) [Link]
Yes, but... but... do it right (which probably means with kernel as well as deep libc help). Don't do it the way unexec() does it. *shiver*
A turning point for GNU libc Posted Mar 31, 2012 0:20 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
To be fair, I don't know how unexec() does it. What is it that's so ugly?
A turning point for GNU libc Posted Apr 5, 2012 8:26 UTC (Thu) by nix (subscriber, #2304) [Link]
Let me count the ways... (this is unexelf.c: the non-ELF unexecs are rather neater, probably because they don't need to cater for the requirements of more than one platform).
... dependency on section names and ordering. Dependency on symbol names (it knows the name of the sole symbol in a special object file linked in last of all). Inverse runtime linking, with a short, ugly, and inadequate hardwired list of relocations. Massive platform-specific ifdeffery. Special-cases throughout the source code for things that will be dumped into the executable and stay read-only ('pure space') versus those that will not. All the signs of code that was neat when it was written (if you believe the (C), in 1985) but has evolved since then in the ugliest imaginable fashion.
Quite like a lot of the rest of the insides of Emacs, really. (Parts of it are neater. None is uglier.)
Ew, I shouldn't have looked at that so early in the morning. I feel quite queasy now.
A turning point for GNU libc Posted May 16, 2013 15:12 UTC (Thu) by karya (guest, #71446) [Link]
Couldn't you use some checkpoint-restart package like DMTCP (http://dmtcp.sf.net/) to achieve the "unexec" functionality? Simply create a checkpoint image and restart it later.
A turning point for GNU libc Posted May 21, 2013 14:24 UTC (Tue) by nix (subscriber, #2304) [Link]
Well, yeah. That's the 'deep kernel and libc help' I was thinking of. I suspect DMTCP could do it for Emacs now, actually, since a dumped Emacs has almost no dependencies on runtime state (it can't, since unexec can't deal with them).
A turning point for GNU libc Posted Mar 30, 2012 13:04 UTC (Fri) by civodul (subscriber, #58311) [Link]
>> In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs.
> > Bwahaha. I suspect more significant here was that Emacs already existed (and was the trigger for the whole thing). > > Everything else released early on was pretty crucial infrastructural OS-core stuff.
Indeed.
It should be mentioned that FSF-paid developers, including Roland, were initially developing libc for the GNU operating system, aka. GNU/Hurd. The Linux "port" came later with the work of Ulrich Drepper and others.
A turning point for GNU libc Posted Mar 30, 2012 13:17 UTC (Fri) by nix (subscriber, #2304) [Link]
The biggest 'other' definitely has to be HJ Lu.
A turning point for GNU libc Posted Mar 28, 2012 17:24 UTC (Wed) by arjan (subscriber, #36785) [Link]
Glibc is in the unfortunate position that it gets asked to solve all the hard parts the kernel guys don't want to solve, but also it gets asked to solve a lot of hard parts that application guys do not want to solve. In many ways, it's the layer in the system where all the ugly stuff ends up going that nobody else wants to deal with.
Combine that with an absolute requirement of binary compatibility, and frankly, I appreciate greatly a set of glibc maintainers who are on the conservative side. Any new API is going to be there forever, unchangable.
That doesn't mean that progress should not be possible, and it doesn't mean that the atmosphere shouldn't be open and pleasant, but in many ways, the glibc guys and the kernel filesystem guys need to share a mindset of being extremely careful and conservative.... not one of doing wild things just because you can.
the debate about strcpy/strncpy/strlcpy is one of those messy ones. on first sight, strlcpy is an obvious right answer. however, when you look deeper at it, it's not true.... strlcpy can in fact be more dangerous. strcpy_c and co are actually better ideas, and glibc's strcpy() has a built in "abort if we know we're overflowing" logic that works together with gcc to detect many of the more simple buffer overflow case. (and it *aborts*, it does not silently continue with what is effectively corrupted data).
A turning point for GNU libc Posted Mar 28, 2012 17:35 UTC (Wed) by cmorgan (subscriber, #71980) [Link]
I googled for strcpy_c and didn't find anything.
How is strlcpy more dangerous? It behaves more like snprintf and friends in that it always adds null termination.
In any case, string handling imo is a weak and error prone area of c and anything is better than functions that sometimes null terminate, sometimes don't, don't perform bounds checking etc.
I'm not suggesting the original ones be removed, clearly that would break a lot of existing software, but lets provide some better and less error prone alternatives without getting caught in the whole "well the other functions work" or "everyone uses them" trap that seems to hold up progress.
Chris
A turning point for GNU libc Posted Mar 28, 2012 17:39 UTC (Wed) by arjan (subscriber, #36785) [Link]
the problem with strlcpy is that it truncates, and lets the program continue to operate on known-flawed data.
you really want a strcpy variant that, on overflow, zeroes out the WHOLE THING, and ideally reports a proper, easy to check error return code for it.
A turning point for GNU libc Posted Mar 28, 2012 17:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
How about a function which just does abort() in case of overflow?
A turning point for GNU libc Posted Mar 28, 2012 17:45 UTC (Wed) by slashdot (guest, #22014) [Link]
strcpy_s in the Microsoft CRT does that (unless you explicitly set an error handler).
A turning point for GNU libc Posted Mar 28, 2012 17:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Good for them. IMO, that's the only correct behavior in this case.
A turning point for GNU libc Posted Mar 28, 2012 21:45 UTC (Wed) by dashesy (subscriber, #74652) [Link] Accepting the useful strcpy_s however can open the can of worms (strncpy_s and the rest of that family)
A turning point for GNU libc Posted Mar 28, 2012 18:25 UTC (Wed) by arjan (subscriber, #36785) [Link]
that's what strcpy() does...
but yes, that's one of the options, and as default behavior it's not all that bad (it means you can have a crash dump collector detect it and send it to the developer team).
A turning point for GNU libc Posted Mar 28, 2012 17:44 UTC (Wed) by cmorgan (subscriber, #71980) [Link]
Ahh I see why that isn't a good idea either :-)
It would be handy if the libc people would see about innovating in that area a little bit. Maybe 3rd party libraries work but why get so stuck on posix as someone else mentioned?
Chris
A turning point for GNU libc Posted Mar 28, 2012 17:50 UTC (Wed) by arjan (subscriber, #36785) [Link]
letting other libraries work out what the right solution is, and when a winner emerges, pull that into glibc... doesn't sound like too bad a strategy to be honest.
A turning point for GNU libc Posted Mar 28, 2012 19:20 UTC (Wed) by wahern (subscriber, #37304) [Link]
That doesn't make any sense. Almost _all_ C routines continue on their merry way on undefined behavior.
The difference between strlcpy is that the behavior is well-defined as far as the language is concerned. The bad behavior (if truncation is undesired) is between chair and keyboard, and that's a huge step forward from the mess that traditional string routines have _actually_ made.
And truncation isn't silent: if (sizeof buf <= strlcpy(buf, str, sizeof buf)) oops("truncated!");
There, happy?
Most unix systems have strlcpy except Linux and compatriots like HP/UX. Nobody would have even questioned the utility of it if Drepper hadn't been so stubborn. And now somehow strlcpy() is faulted for supposed flaws that exist in almost all C routines, and are _especially_ egregious in the ones that Drepper proposed as alternatives. Just the other week on stackoverflow I saw someone post a memccpy() "alternative" which contained an off-by-one buffer overflow. (They apparently thought memccpy returned a pointer to the terminal character, not a pointer after the terminal character.)
Ridiculous.
And alternatives like strcpy_s from Microsoft are even more idiotic. Have you ever even tried to use them? The entire Annex K is stupid, and not even Microsoft supports the entire Annex even though they sponsored it.
People are entitled to their opinions, but this particular opinion just causes way too much headaches for too many people. You don't see systemd haters trying to keep systemd from shipping, do you? They just don't want to be _forced_ to use systemd. Nobody is forcing you to use strlcpy.
A turning point for GNU libc Posted Mar 28, 2012 20:03 UTC (Wed) by arjan (subscriber, #36785) [Link]
I would argue that the whole debate has shown that it's not a clear cut good API... and glibc, with its compat promise, does well to be conservative about adopting a solution.
(having been on the receiving end of such 'security scanner fixes' introducing more bugs than the original code had... I'm no big fan of either strncpy or strlcpy as replacement for strcpy.... especially since the linux strcpy is checking by itself in most of the critical cases already)
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 12:58 UTC (Fri) by cjcoats (guest, #9833) [Link] But see this discussion about GLIBC memcpy() changes at Version 2.11 breaking many existing executableshttps://bugzilla.redhat.com/show_bug.cgi?id=638477with Linus' performance-evaluation (proved it did not create the claimed speedup, and provided alternatives) and remarks about breaking those existing executables (turns out Flash was the most prominent culprit but there were lots of others). [Warning: there's a lot of stuff here...] And Drepper not only did not care: he said he did the right thing! FWIW
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 15:05 UTC (Fri) by khim (guest, #9252) [Link] Generally compatibility is guaranteed only if programmer follows guidelines. And in this sense Drepper has a point: the memory areas should not overlap. Use Sometimes, if there are a lot of broken programs, bug-to-bug compatibility is important enough to go further - and this is example what happened here in the end as you can see here.
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 17:37 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
that's a valid argument if the change improves something, but if (as in this case) the change doesn't give any performance improvement, the only 'advantage' of the change is that it breaks existing programs.
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 20:15 UTC (Fri) by khim (guest, #9252) [Link] that's a valid argument if the change improves something, but if (as in this case) the change doesn't give any performance improvement, the only 'advantage' of the change is that it breaks existing programs. Wow. Just… wow. I guess it's time to ask the usual question: are you an idiot or just play one on TV? You were given link - now, please go and read it. People tend to see message from Linus (which says I bothered to _measure_ the speed, and according to my measurements, glibc wasn't any faster than my trivial version and was likely slower) and immediately switch to Linus is god, GLibC developers are stupid mindset. Which is not justified at all. Because of course the very next sentence (but I only tested two cases) in the same paragraph flies right over their head and detailed explanation (At last on Core2 we gain 1.83x speedup compared with original instruction sequence and Based on our micro-benchmark small bytes from 1 to 127 bytes, we got up to 2X improvement, and up to 1.5X improvement for 1024 bytes on Corei7) is totally ignored or, at best, hand-waved with hopefully Linus has answered this one appeal to authority. This is the same never-ending fight between pragmatists and standard hairsplitters. Linus, ever the pragmatist, never rebuffed speedup claim when it was pointed out that he was incorrect (good for him: speedup is very much hardware-dependent and was just unobservable on the hardware he used, it's quite real and measurable on different hardware) but he said quite sensible thing from pragmatist's POV: new version of memcpy may be more efficient, but it's more complex as well thus the usual excuse (we have trivial and fast Note: GLibC guys rolled back change for old binaries pretty quickly when it was found that their improvement broke real programs. After that point it's no longer about “stable ABI” and “backward compatibility”, but about “doing the right thing”. I think the end result (old programs get the old behavior and new ones should finally fix the bugs in according to the documentation) makes sense in this context. You can say that this is what should have happened from the beginning, but it was not all that obvious that so many programs actually depend on the broken behavior of the old
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 20:17 UTC (Fri) by corbet (editor, #1) [Link] ...and that's my cue for the usual request: can we please be just a bit more respectful of each other? If you disagree then by all means say so and why. But we don't need to be playing elementary-school name-calling games here.
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 20:27 UTC (Fri) by paulj (subscriber, #341) [Link]
There should be a naughty chair for commentators who resort to name-calling. Maybe ½ to 1 hour of not being allowed to comment?
A turning point for GNU libc Posted Mar 31, 2012 21:35 UTC (Sat) by lacos (guest, #70616) [Link] truncation isn't silent: if (sizeof buf <= strlcpy(buf, str, sizeof buf)) oops("truncated!"); I don't like this. strlcpy() continues to find the end / length of the source string even if the target buffer has ended way earlier. And it does it every single time. Instead of this, know the length of your source string (which takes a single strlen() in the beginning), and allocate the target buffer accordingly. Or, if the target is a given, and too small, bail out before copying any characters.
A turning point for GNU libc Posted Apr 3, 2012 0:20 UTC (Tue) by gdt (subscriber, #6284) [Link]
Write the trailing 0 character which strlcpy() should have done:
char dst[DST_SIZE];
strlcpy(dst, src, DST_SIZE);
A turning point for GNU libc Posted Apr 3, 2012 6:58 UTC (Tue) by smurf (subscriber, #17840) [Link]
That code doesn't make any sense whatsoever. strlcpy does write a trailing zero.
What he wants is essentially a string copy which, when the buffer is too small, zeroes the buffer's FIRST byte, not its last.
A turning point for GNU libc Posted Apr 9, 2012 11:04 UTC (Mon) by gdt (subscriber, #6284) [Link]
You're right, I was thinking of strncpy().
A turning point for GNU libc Posted Mar 28, 2012 20:43 UTC (Wed) by HelloWorld (guest, #56129) [Link]
There *are* better and less error prone alternatives, such as GString from glib. So stop whining already.
A turning point for GNU libc Posted Mar 28, 2012 22:47 UTC (Wed) by wahern (subscriber, #37304) [Link]
By that logic, people would also be better off using C++. In many cases it'd be easier to port a C project to C++ than to adopt glib in all its monstrous glory.
Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string? Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments. Getting strlcpy into glibc would be just one less extra burden to carry when trying to write sane, simple, secure code.
And also, why do I need a dynamic string object? Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters? Are DNS labels magically going to become longer than 63 characters, or domains longer than 255 characters? Do my enum-to-human-readable-string mappings need an indefinite buffer?
Most people who code in C aren't doing unbounded string operations. Not every C application or library is an editor or a text processor. In fact, very few are. Don't confuse "C-strings" with "strings". People don't use strcpy or strlcpy to manipulate "strings" (the abstract computer science concept); they use them to manipulate C-strings, a very narrow and well-defined data type which in practice is almost always bounded by a rather small limit.
A turning point for GNU libc Posted Mar 29, 2012 0:48 UTC (Thu) by geofft (guest, #59789) [Link] Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string?Because it's a saner way to do _everything_. If you just want strings, you can go use the Better String Library (bstring), but then you need to go find a better everything else library, too. Besides, you're cargo-culting a one million SLoC library called glibc, and arguing for the inclusion of more functions in it... if you like "plain, vanilla C", you're welcome to copy strings without glibc. :) (Or with another standard library like dietlibc.)
A turning point for GNU libc Posted Mar 29, 2012 11:47 UTC (Thu) by jnareb (subscriber, #46500) [Link]
> Because it's a saner way to do _everything_. If you just want strings, you can go use the Better String Library (bstring), but then you need to go find a better everything else library, too.
Nb. Git went the way of creating own 'strbuf' micro-library for string manipulation.
A turning point for GNU libc Posted Mar 29, 2012 7:13 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters? Absolutely - PATH_MAX is a totally meaningless value.
A turning point for GNU libc Posted Mar 30, 2012 3:55 UTC (Fri) by wahern (subscriber, #37304) [Link]
Fair enough. I was listing common buffer size macros off the top of my head. But that's beside the point. The others, and many more, are meaningful. Programming, like life, is full of arbitrary limits, and programming as if you'll ever need to meaningfully store a 1MB path name often leads to needless complexity, and complexity breeds bugs.
But let people continue to use strcpy, and let the exploits continue to roll in. Fortunately they've slowed down over the years, thanks to alternatives like snprintf and people copy+pasting strlcpy, and not so much because people are passing glib string objects to library routines.
A turning point for GNU libc Posted Mar 29, 2012 16:12 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string?
Glib provides a hell of a lot more than just a sane (well, sane by C standards) string implementation.
> Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments.
> Do my enum-to-human-readable-string mappings need an indefinite buffer?
A turning point for GNU libc Posted Mar 30, 2012 22:24 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>Glib provides a hell of a lot more than just a sane (well, sane by C standards) string implementation.
I agree - it has utterly pointless typedefs like gchar (char is standardized by C, you know). Hiding an indirection (behind gpointer) is not nice either.
A turning point for GNU libc Posted Apr 5, 2012 15:32 UTC (Thu) by welinder (guest, #4699) [Link]
> char is standardized by C, you know
Really?
What, exactly, is standardized about char in C?
* it's a numeric type.
char c = 0; /* valid */
A turning point for GNU libc Posted Apr 5, 2012 16:33 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
True, but gchar is defined as a typedef for char, so it adds no additional guarantees. Why not just use char? At least "guchar" is shorter than "unsigned char"; I see no benefit at all in using gchar.
If you want guaranteed ranges, uint8_t and int8_t are standardized in C99 as integer types with exactly eight bits and (in the signed case) two's-complement representation. Both definitions are required unless the implementation has no compatible integer type.
A turning point for GNU libc Posted Mar 28, 2012 21:51 UTC (Wed) by jcm (subscriber, #18262) [Link]
Right. I also believe that critical system libraries with binary compatibility requirements do need to be very conservative. That said, I think the more open development model will be a good thing. Still, now is not the time to collectively call for glibc to shake things up /too/ much :)
A turning point for GNU libc Posted Mar 28, 2012 17:40 UTC (Wed) by slashdot (guest, #22014) [Link]
It seems that there is work to get rid of the absurd and detrimental copyright assignment requirement.
Linus Torvalds on Google+:
David Miller replies:
Planning for decades Posted Mar 28, 2012 18:43 UTC (Wed) by mcoleman (guest, #70990) [Link]
It's worth noting that the copyright assignment stuff is not there just to be obsessive. The FSF is trying to build something that will stand for decades, if not forever, and so some of their preparations are with that in mind.
Planning for decades Posted Mar 28, 2012 20:14 UTC (Wed) by jzbiciak (subscriber, #5246) [Link]
While that may be true, I don't think the kernel hackers consider the Linux kernel to be a short term hack any longer, Linus' original release announcement nonwithstanding. The kernel thus far has survived without copyright assignment, and indeed many consider that a feature.
My understanding is that the FSF wants copyright assignment so that it can unilaterally determine its destiny. It can, for example, decide to begin releasing it under an entirely new license at some point. While it won't eradicate older versions under older licenses, it does make it easy to relicense the whole thing even if the original author didn't submit code with a "version X or later" clause.
I seem to recall that the FSF also argues that it makes it easier to litigate on behalf of the code, although I would counterargue that the critical mass of code that's already there is likely sufficient for litigation purposes. I guess the only sticky points would come down to litigation around a specific contribution that hasn't been assigned to the FSF. I suppose with all the lawsuits out there, that's not outside the realm of possibility. And, to further poke holes in my reasoning, more recent code is more likely to trigger lawsuits than code that's been there for many years, especially if it's based on newer techniques. Older code is more likely to have been vetted against legal issues.
Planning for decades Posted Mar 28, 2012 20:23 UTC (Wed) by mcoleman (guest, #70990) [Link] The FSF designed the GPL explicitly to disallow anyone from unilaterally determining the destiny of the code it is applied to. This seems clear from their words and actions.Once you apply the GPL to code you write, you give up almost all possibility of unilateral control of the code. In return, you get that same grant from all future contributors.
Planning for decades Posted Mar 29, 2012 1:53 UTC (Thu) by smurf (subscriber, #17840) [Link]
You need to distinguish past and future releases.
True, the copyright holder can do nothing whatsoever about the code that's already out there.
But as the FSF has the copyright on the whole code, the only thing that'd prevent it from releasing proprietarylibc tomorrow is their promise not to do that, which they gave by way of their past policies and activities.
Other organizations which required copyright assignment either never did so (Canonical) or even explicitly state that there's a commercial version (mysql).
Planning for decades Posted Mar 31, 2012 19:28 UTC (Sat) by giraffedata (subscriber, #1954) [Link] You need to distinguish past and future releases. The distinction is not between past and future releases, but between the code and the project. GPL's provision for forking means the distributor can't control future releases, because anyone can make one. And that's central to GPL's purpose. But GPL isn't meant to give the public control of a project such as the GNU libc project, and that control is what the copyright assignment is designed to prevent.
Planning for decades Posted Apr 5, 2012 20:02 UTC (Thu) by Wol (guest, #4433) [Link]
Actually, I believe there IS something that would stop them releasing proprietarylibc.
It's called a contract.
aiui, the standard contract assigning copyright to the FSF places some restrictions on what they can do, and that's one of them.
Cheers,
Planning for decades Posted Mar 29, 2012 1:55 UTC (Thu) by jzbiciak (subscriber, #5246) [Link] Disallow anyone except the FSF, you mean. The FSF has very carefully set things up such that they trust themselves with unilateral action, but no one else. Anyone who has released code under a "GPL version X or later" has left themselves open to whatever the FSF decides the next version of the GPL would say. If the FSF decided tomorrow that GPL v4 will read exactly as the 3-clause BSD license (minus references to UCB, of course), suddenly vast mountains of GPL software would be available under a BSD license (effectively) with no feedback or input from the software's authors. If that's not unilateral, what is it? We only trust that the FSF wouldn't do that. They've earned it, but let's face it: They wield a fair bit of unilateral power here. The power above derives from their special status as the only source of future versions of the GPL. But that isn't the issue at hand. Copyright assignment was. I'm getting there... So, assume the GPL is a fixed thing, and let's move on to copyright assignment. When the FSF talks of "unilateral action" in a negative light, they mean by anyone but themselves. That doesn't mean that the FSF doesn't want to engage in unilateral actions. Their own reasons for copyright assignment page makes it plain that they want to be able to litigate unilaterally with respect to the software, and they can do that only if they own all the copyrights. If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors. In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect . . . . I read the highlighted "we" as meaning "the FSF and its legal team," not "the community at large." That sounds pretty unilateral to me. So there you have it, two axes of unilaterality:
What the GPL effectively prevents is proprietary forks and unilateral action against a project by anyone else. Nobody else can release a new GPL license. And if folks assign their copyrights to FSF for FSF-maintained code, that grants no rights to anyone who isn't FSF. How is it not clear that the FSF is in the cat bird seat here? FWIW, I release all my software either under a GPL v2 (or GPL v2 and later) license, or I release it to the public domain if it's small enough to be inconsequential. I'm not against the GPL or the FSF. But, please understand that the FSF does have some special unilateral powers with respect to certain GPL uses, and for code submitted to an FSF-maintained project they ask for a few more unilateral powers.
Planning for decades Posted Mar 29, 2012 2:04 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]
And, there's smurf's observations upthread. Point is, the only point of assigning your copyright to the FSF is to allow them to act with respect to your code without consulting you or anyone else, period.
Planning for decades Posted Mar 29, 2012 2:09 UTC (Thu) by mcoleman (guest, #70990) [Link]
You're talking about the power of the FSF to unilaterally give away my code under a license that is less restrictive than the original. That's not a contingency that keeps me up nights.
The real problem would be if the FSF could unilaterally restrict access to my code when I did not intend it. They cannot.
Planning for decades Posted Mar 29, 2012 3:12 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
some people would get really upset if their code was released under a license that allowed it to be put in proprietary code.
the FSF has the ability to allow that (make GPLv4 equivalent to BSD, proprietary company takes code and moves it to it's own license)
and before you protest and say that they have promised to never do anything like that, remember that they made a special clause in the license to allow GPL documents that were in wikipedia before a specific date to be moved to a GPL incompatible license.
They have the ability, the only question is will they.
I am not saying that they will, only that they have the ability to do so.
Planning for decades Posted Mar 29, 2012 3:39 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]
That's pretty much my point. Thank you for providing additional examples.
The FSF is in a unique position of power with respect to the GPL (at least the "ver X or later" variant). And because they ask you assign copyrights for anything you contribute to the FSF, they're in a unique position of power over that. Both give the FSF various (and differing) unilateral powers over your code, should you elect to extend those powers to the FSF. Those powers can be used in ways you do or do not agree with.
We trust that FSF won't disappoint us. They've earned a lot of trust from the community over the years, but that vague yet pervasive sense of trust is not a legal construct. As you say, "They have the ability; the only question is 'Will they?'"
The most likely answer is "They will not." But, it _is_ a potential single point of failure if I ever saw one...
Planning for decades Posted Mar 29, 2012 4:08 UTC (Thu) by xtifr (subscriber, #143) [Link]
If you're really paranoid about the "or later" thing, you can always say something like "or any later version which has similar requirements to always provide full source code when distributing derivatives", etc. Heck, now that I think about it, I might actually change some of my code to say that.
Planning for decades Posted Mar 29, 2012 4:17 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]
I'm not really all that paranoid myself. But to deny that the FSF is in a unique position and seeks to retain that unique position belies the facts. That's the only point I'm trying to make.
Planning for decades Posted Mar 29, 2012 11:06 UTC (Thu) by smurf (subscriber, #17840) [Link] Legally, "any later version" might well be interpreted as "… which intends to convey essentially the same rights". If I had intended to publish my code under a 3-BSD license, ten years ago, I would have done so; therefore the FSF has no right to publish a 3-BSD-equivalent and label it "GPLv4". Again, this is about the stated intent of both the FSF (what does it stand for? what are their goals?) and me (did I agree with these, when I chose that license?). It's not about the text "or any later version" with an implied "… whatever that says, decided unilaterally by the FSF". Whatever your opinion about legal beagles in general, give them some credit.
Planning for decades Posted Mar 29, 2012 11:16 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
remember that in some people's eyes, GPLv3 breaks the "… which intends to convey essentially the same rights" criteria compared to v2
in the opinion of the FSF it doesn't, in the opinion of many others, it does.
Planning for decades Posted Mar 29, 2012 12:25 UTC (Thu) by wookey (subscriber, #5501) [Link]
"in the opinion of the FSF and many others it doesn't, in the opinion of many others, it does."
Would be a more even statement of the situation. (Your original suggests that it is FSF's opinion versus 'many people'. Opinion is more evenly divided than that.)
Planning for decades Posted Mar 29, 2012 12:50 UTC (Thu) by jzbiciak (subscriber, #5246) [Link] 3-BSD conveys fewer restrictions on the recipient of the code than GPL v2. So are you saying future GPL licenses can only be more restrictive? Let's consider the spectrum of freedom from the perspective of the recipient of the code, not the author. Public domain code is the most free of all. 3-BSD is a step back from public domain, but not by much. GPL v2 is more restrictive than 3-BSD, with all its wording about derivative works and the like, source redistribution requirements, and so on. GPL v3 is more restrictive yet. And then there's the default state of "copyrighted work," where the recipient has very few default rights. Are you suggesting that the only arc future GPL licenses can take is toward less freedom for the recipient? Ok, so perhaps I was leading you down a rhetorical garden path with those questions. And, since you're well steeped in Free Software, you're not persuaded to follow. But, imagine arguments constructed along those lines in court. Such arguments could be much more persuasive to a less deeply invested judge and/or jury. If someone used your code with an imagined GPL v5 that let them make a proprietary package that you didn't approve of, good luck winning over the court if you try to sue. I realize that the FSF is trying to maximize the freedom of the ecosystem as a whole. But realize that it does so by limiting the freedom of individuals to appropriate the code and take it private. It lays that all out in the preamble, saying that to protect your rights, it puts limits on what you (or anyone using the software) can do, and places on you certain responsibilities in order for you to use the licensed software. That subtle, tricky and almost counter-intuitive balance of "protecting your rights by limiting your actions" can be a lot for folks to wrap their heads around. What if the FSF decides that it's in the greater interest of the ecosystem to place fewer restrictions on the recipients of the software, thinking that yes, there will be some that abuse the additional privilege, but it's entirely likely be more new contributors that will not. There are those who find the GPL legally risky and don't contribute, and maybe someday the FSF will try to meet them in the middle to bring them into the fold. (Probably not as long as St. Ignucious is still kicking, but hey, there's an awful lot of future ahead of us. And don't think that I'm advocating that the FSF should do this. I'm only arguing about the potential range of outcomes here.) The GPL v2 states: The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. "Similar in spirit" is rather wide open to interpretation. The overriding theme is "freedom", and as we've all seen, there are many, many differing interpretations of what constitutes freedom. A license that shifts the balance of freedoms toward the recipient (ie. a move toward something more like 3-BSD, if not moving entirely to 3-BSD) would not necessarily be incompatible in spirit with the GPL in many peoples' eyes. In any case, the only truly legally binding phrase in that clause is this one: If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. Sure, the preceding paragraph said "similar in spirit," but the FSF alone gets to define what their spirit is. After all, they wrote the license.
Planning for decades Posted Mar 29, 2012 13:03 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]
Here's a thought experiment for you: Suppose someone releases a software package under "GPL v3 or later", with all its new requirements to prevent tivoization. They do this because they like the additional guarantees their software will remain free, and they really don't want their software tivoized.
Now the FSF releases the GPL v4 that reverts the changes in GPL v3, and reads identical to GPL v2.
Theoretically, the GPL v3 was similar in spirit to the GPL v2. So, this imagined GPL v4 should also be similar in spirit to GPL v3. Now what?
Really, the "or later" clause cedes an awful lot of control to the FSF. That's been my point all along. The punch line is that if you care that much about the specific semantics of the license that covers your code, you really shouldn't put a wildcard in the license that you don't control.
Planning for decades Posted Mar 29, 2012 16:45 UTC (Thu) by khim (guest, #9252) [Link] The punch line is that if you care that much about the specific semantics of the license that covers your code, you really shouldn't put a wildcard in the license that you don't control. Yup. The irony here is that it looks like FSF is the only organization which understands that. GPL is the only popular copyleft license which gives program author the right to refuse delegation of “autoupgrade” rights to license “stewards”. Note that such liberty was given to authors by all versions of GPL, including the first one. All these other licenses were created after GPL was created - yet they cede “an awful lot of control” unconditionally. It's funny that the very people who are bashing FSF for the “or later” clause are often advocating MPL or CC-BY-SA as an alternative despite the fact that they are obviously more problematic in this regard.
Planning for decades Posted Mar 29, 2012 4:45 UTC (Thu) by slashdot (guest, #22014) [Link]
I guess that as long as Stallman is in charge, it's a reasonably safe bet that he won't release a non-copyleft GPL.
The more worrisome thing is what happens after him.
Planning for decades Posted Mar 29, 2012 12:45 UTC (Thu) by mcoleman (guest, #70990) [Link] Right now, it looks like the FSF is more stable over time than the legal and social systems that it is embedded in, so it seems kind of pointless to worry about them. Could they go Komen? Sure, it could happen. Nothing is forever.If you're really worried about them making your code less restricted under a "or later" clause, just leave it out.
Planning for decades Posted Mar 29, 2012 23:50 UTC (Thu) by xtifr (subscriber, #143) [Link]
The problem with simply removing the "or later" clause is that each version of the GPL is pretty-much inherently incompatible with other versions. The GPL basically allows no exceptions to any of its terms (ignoring some of the explicitly-allowed-variations in the GPLv3), so GPLv4 will be incompatible with GPLv3 and GPLv2. If you use the "or later" clause, this doesn't matter, because GPLv2-or-later code can be used in a GPLv4 (with or without "or later") project, so all the "or later" versions are compatible. But without the "or later", you get a combinatorial explosion of license incompatibilities as the number of versions of the GPL increases. Which I think is probably a very bad thing.
That's why I suggested above: if you don't trust the FSF to do the right thing, then, instead of simply removing the "or later" clause, replace it with something that says "or any later version that meets [list of criteria I consider indispensable]". For example, if you're a big fan of Tivoization, you could say, "GPLv2 or any later version that allows [tivoization]". Then, if the FSF had a change of heart and decided to allow tivozation (perhaps as an option) in the GPLv4, your code would automatically be compatible with v4 (or at least with v4 projects that exercised the tivoization option).
Bottom line: "the FSF might do things I don't like in the future" is a mostly-hypothetical bad thing, while removing the "or later" clause is license proliferation, which is a right-now bad thing.
Planning for decades Posted Mar 30, 2012 0:14 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> Bottom line: "the FSF might do things I don't like in the future" is a mostly-hypothetical bad thing, while removing the "or later" clause is license proliferation, which is a right-now bad thing.
you've obviously missed all the people (including a large number of linux kernel developers) who consider GPLv3 a perfect example of the FSF doing something that they didn't like with a future license change.
for them this is not a hypothetical thing, it's the reality, and they especially don't like being bullied into changing the license on their code because not doing so leads to license proliferation, especially as they made their concerns (including the problem of license proliferation) very clear before the GPLv3 was published.
I'm not saying that you are doing the bullying, but there are others who are doing so.
Planning for decades Posted Mar 30, 2012 6:12 UTC (Fri) by xtifr (subscriber, #143) [Link] No, I had them in mind when I said mostly. And, while I've heard a lot of people bitch about the GPLv3, in my experience, the majority of the bitching boils down to "wah, it's so long and complicated--v2 was so much simpler and more elegant!" The people I've heard complain about actual terms of the GPLv3 are...well, greater than zero, but not a whole lot greater. The main thing among the actual terms I've heard people complain about is the anti-tivoization stuff, which is why I explicitly covered that in my earlier post. (In fact, if enough people followed my earlier advice, it might actually make my improbable hypothetical come true, and persuade the FSF to conditionally allow tivoization in a future version.) (Also, a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published. The GPLv3 wouldn't prevent the Linux kernel from being Tivoized even if the kernel were "v2 or later", because anyone can still continue to use the code under the terms of v2. But I'm trying to ignore idiotic arguments, even though it's hard when this topic has generated so much heat and so little light.) In any case, you seem to be ignoring the fact that my solution works for both sides! It minimizes the license proliferation problem, while preventing the FSF from adding conditions you don't like to your code. It's not necessarily perfect (you have to have guess which terms might turn out to be important), but I think it's good enough that I'll probably try using it myself.
Planning for decades Posted Mar 30, 2012 6:27 UTC (Fri) by sfeam (subscriber, #2841) [Link] "a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published." Only if you are talking about a standalone bit of code. If someone takes my GPLv2orlater code and incorporates it in a larger GPL3 program, then the result cannot be used under GPL2, only under GPL3. If I don't want that to happen then GPL2orlater is not an option.
Planning for decades Posted Mar 30, 2012 6:59 UTC (Fri) by xtifr (subscriber, #143) [Link] Once again, you're completely ignoring what I actually said in order to argue with some straw man. If there's some change in the GPLv3 you don't like, then say "GPLv2 or any later version which has [the GPLv2 version of that feature]". That doesn't make you more any more compatible with v3, but allows you compatibility if the FSF rethink their position and add the feature as an option in v4. (And even puts some pressure on them to do so, if your program is widespread and popular enough.)
Planning for decades Posted Mar 30, 2012 9:03 UTC (Fri) by paulj (subscriber, #341) [Link]
A likely problem with "GPLv2 or any later version which has [feature list]" is that then the "[feature list]" itself turns into a licence, with attendant complexity of text etc..
A simpler solution perhaps, if you don't fully trust the FSF, would be to add additional authorities as to which later versions are blessed? E.g.: "GPLv2 or any later version approved by [authority]", where authority could be, say, Linus Torvalds, or some cabal. ??
Planning for decades Posted Mar 31, 2012 3:05 UTC (Sat) by xtifr (subscriber, #143) [Link]
yes, that could definitely work too.
Planning for decades Posted Mar 30, 2012 15:21 UTC (Fri) by mcoleman (guest, #70990) [Link] ...then the result cannot be used under GPL2, only under GPL3Of course. Why would you expect to be able to use someone else's code in a manner that they forbid? Microsoft won't let you do that either...
Planning for decades Posted Mar 31, 2012 10:13 UTC (Sat) by mpr22 (subscriber, #60784) [Link] Part of the point of the GPL is "share and share alike" (or so it seems to me). GPLv3+'ing a derivative of a GPLv2+ project is, at best, shockingly rude, since it amounts to saying "I don't want to share with you" to the upstream maintainer.
Planning for decades Posted Mar 31, 2012 11:41 UTC (Sat) by jzbiciak (subscriber, #5246) [Link] Ah, but what if a GPL v3+ project decides to integrate a non-trivial part of your GPL v2+ code base into the larger GPL v3+ project, as sfeam suggested a few comments up? For example, I'm making a GPL v3/v3+ paint program, and you wrote a nice chunk of GPL v2+ code for handling the whizzy new Frobnitz N-dimensional drawing tablet. Now I integrate your Frobnitz handling code into my paint program. The resulting application is GPL v3+. What's the point of GPL v2+ if not to allow such forward compatibility? Sure, if I were to release a GPL v3/v3+ only application that was created by taking someone else's GPL v2+ app and adding only a little bit of GPL v3 code, that would be somewhat rude (unless I had the author's blessing), but entirely legit by the license. But sfeam's example had the sizes the other way around -- smaller GPL v2+ code subsumed into a larger GPL v3 / v3+ project. I don't think anyone should find that rude. (I almost said "I don't think anyone would find that rude," but I thought better of it. The Internet is a big place.) I imagine it happens with large GPL v3 projects somewhat regularly. Speaking of which, aside from GCC, what are some somewhat large GPL v3 projects out there? Or did most everyone hang back with GPL v2/2+?
Planning for decades Posted Mar 31, 2012 15:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
Looking through a repoquery on Rawhide, some of note (ignoring GNU projects):
- audacious
Planning for decades Posted Mar 31, 2012 15:57 UTC (Sat) by jzbiciak (subscriber, #5246) [Link]
Cool. Looks like it has picked up at least a little steam outside GNU. I guess we'll see in 20 years whether it becomes as popular as GPL v2 did in its ~20 year run as the leading GNU license.
Planning for decades Posted Apr 5, 2012 11:03 UTC (Thu) by njs (guest, #40338) [Link]
The Samba project enthusiastically supports GPLv3; IIUC their experiences with messy court cases, license enforcement, etc., were strong influences on GPLv3's design.
Planning for decades Posted Apr 5, 2012 20:10 UTC (Thu) by Wol (guest, #4433) [Link]
What you should do then (if you can) is to treat the GPL2 code like a LGPL2 library - keep it in its own section of the source tree, and leave it at GPL2+.
If you make major changes you can then decide whether to move it into the main GPL3 tree or not.
Cheers,
Planning for decades Posted May 29, 2012 12:31 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
This is actually wrong.
The combined work can be shared under GPLv3 only. (The act of running the program, coll. using, is not restricted by the GNU GPL.)
But if your original source code is still intact (and copyright law apparently – IANAL, TINLA – forbids removing copyright notices) within the combined work and a visibly separate entity, you can still take that (possibly patched) file under GPLv2+ as it originally was, because the GNU GPL in no version has the power of actually changing *other* peoples’ copyright licences.
Planning for decades Posted Mar 30, 2012 1:11 UTC (Fri) by jzbiciak (subscriber, #5246) [Link] Perhaps a safer course would just to replace "or any later version" with "or later versions approved by <name of authority here>." That approval could even extend to another version of the license with a different named authority, should you care to pass the torch. Note that the named authority need not be an individual. It could be a committee, such as the Frobnitz Steering Team or what-have-you.
Planning for decades Posted Mar 29, 2012 13:13 UTC (Thu) by mina86 (subscriber, #68442) [Link]
> My understanding is that the FSF wants copyright assignment so that it can unilaterally determine its destiny. It can, for example, decide to begin releasing it under an entirely new license at some point. While it won't eradicate older versions under older licenses, it does make it easy to relicense the whole thing even if the original author didn't submit code with a "version X or later" clause.
Sorry, but this is BS.
The theory behind copyright assignment is that it's easier with litigations as you pointed later.
FSF could change GPL if they really wanted to, and the easy solution for authors that do not submit with a “or later” clause is to not accept such patches.
Planning for decades Posted Mar 29, 2012 18:02 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the litigation need may have been a valid argument at one time, but given that there has been so much successful GPL enforcement by people who don't have exclusive copyright assignment (gpl-violations.org, busybox to name two high profile projects), that argument doesn't really fly anymore
Planning for decades Posted Mar 29, 2012 19:19 UTC (Thu) by mina86 (subscriber, #68442) [Link]
Maybe it's not a valid argument, I'm not arguing that. What I'm saying is that the reason why FSF requires assignments for some projects is because of the litigation need, and not because they wish to have full control over the licensing of the code (which, as have been pointed out, they have quite of lot of anyway).
Planning for decades Posted Mar 29, 2012 18:06 UTC (Thu) by smurf (subscriber, #17840) [Link]
> The theory behind copyright assignment is that it's easier with litigations
This does not make sense. You can do the same thing with an agreement authorizing the FSF (or, more specifically, their lawyer) to act on your behalf, should a license violation involving your code come to their attention.
Planning for decades Posted Mar 29, 2012 18:14 UTC (Thu) by mcoleman (guest, #70990) [Link]
IANAL, but this sounds like something that would open you up to all sorts of liability. Merely giving away copyright is much more benign.
(Compare: "I authorize the FSF to use my bat as they see fit." versus "I give the FSF my bat.")
A turning point for GNU libc Posted Mar 28, 2012 19:54 UTC (Wed) by marcH (subscriber, #57642) [Link]
So, Goldman Sachs can sometimes do good?
A turning point for GNU libc Posted Mar 30, 2012 0:26 UTC (Fri) by man_ls (subscriber, #15091) [Link] Apparently. One can only wonder what a high-profile hacker can do as VP in such an organization (apart from getting filthy rich). But, if Alan Cox got his MBA, I suppose anything can happen. Torvalds for Governor?
A turning point for GNU libc Posted Mar 30, 2012 2:36 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
I can see Linus' "I'm always right" statements fitting right in with politics these days. Though he tends to have actual results/arguments to substantiate his claims, so maybe it's not so similar…
trading Posted Mar 30, 2012 6:40 UTC (Fri) by marcH (subscriber, #57642) [Link]
> One can only wonder what a high-profile hacker can do as VP in such an organization
Short-term trading is not performed by humans nowadays; it's done by algorithms implemented by mathematicians and *software engineers*.
That's why it's called the "virtual/unreal economy": it's performed on a time scale far away from any human time scale and no one has any clue about what they're actually trading.
trading Posted Mar 30, 2012 7:09 UTC (Fri) by man_ls (subscriber, #15091) [Link] I suppose that Drepper might fit in as a senior master super duper engineer or something, but being a VP entails a lot of political responsibilities, at least in the organizations I have seen. I cannot imagine someone with a long history of conflicts (on the negative side) and who is able to write documents in such an excruciating detail (on the positive) being a good politician.Perhaps Goldman Sachs maintains a large internal library for short-term trading and they don't want it to grow any larger...
trading Posted Mar 30, 2012 11:28 UTC (Fri) by jwakely (subscriber, #60262) [Link] being a VP entails a lot of political responsibilities, at least in the organizations I have seenIn US investment banks everyone's a VP. Goldman Sachs have nearly 12000 of them, out of 33000 staff. [source]
trading Posted Mar 30, 2012 12:33 UTC (Fri) by man_ls (subscriber, #15091) [Link] Weird! And even weirder that I haven't read anything about this in my favorite source of corporate knowledge.
A turning point for GNU libc Posted Mar 30, 2012 19:00 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
I wondered that when I first heard about his new job. However, in the wake of recent news reports about the resignation letter of a 'VP' it turned out that this is an extreme case of title inflation: about 40% of GS employees have that title! It appears that what normal companies call a VP is an 'Executive VP'.
A turning point for Drepper Posted Mar 30, 2012 20:00 UTC (Fri) by man_ls (subscriber, #15091) [Link] I understand that customers prefer to be contacted by a VP than by an underling, and thus the inflation. But 40% of VPs is a bit too much... Nowadays unless GC employees present themselves as "Ultimate Grand Chamberlain and Patron Saint", I guess customers spit at them.
A turning point for GNU libc Posted Mar 28, 2012 21:44 UTC (Wed) by jcm (subscriber, #18262) [Link]
Had to get in an emacs jab, huh? Not that I disagree at all, it's just *hilarious* (happy vim user).
A turning point for GNU libc Posted Mar 28, 2012 22:54 UTC (Wed) by xtifr (subscriber, #143) [Link]
Actually, the Debian transition to glibc was amazingly smooth! After hearing all the screaming coming from the RH camp, I was downright scared when I did the update, but amazingly, everything just worked. Granted, it took them a lot longer to engineer a solid, safe transition, so us Debian users were among the last to make the transition, but that was a case where I was more than happy to wait!
A turning point for GNU libc Posted Mar 28, 2012 23:22 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Not surprising. The trail blazing distros can't expect to always have a smooth transition. Conservative distros have a higher success rate in doing that and they owe some of that credit to the former although incrementally solid improvements and especially long term maintenance is a difficult feat to pull off and that requires credit by itself as well.
A turning point for GNU libc Posted Mar 29, 2012 6:31 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
I already asked in the comments to the previous article, but I think this article has made it obsolete: does anyone (Joe? Nix?) have a feeling for whether there are chances that glibc will become more friendly to static linking in the mid-term future?
A turning point for GNU libc Posted Mar 30, 2012 19:10 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries, doesn't 'more friendly' imply relicencing?
Would it not be more useful for the libc headers to support a macro specifying the intended minimum required run-time version? (I seem to recall that the Win32 SDK supports something like this.) Various definitions would then be disabled or modified to match the old version, and symbol version selection would be modified too. Of course ithis would further complicate the nest of #ifdefs in the headers.
A turning point for GNU libc Posted Mar 30, 2012 21:30 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
BenHutchings wrote:
> Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries, doesn't 'more friendly' imply relicencing?
If that is what you (generic you!) want to do the LGPL lets you link statically with proprietary applications as long as you provide object files and what-not so that you can relink the application against a rebuilt version of the LGPLed code.
A turning point for GNU libc Posted Mar 31, 2012 12:32 UTC (Sat) by kleptog (subscriber, #1183) [Link]
GLIBC has extraordinary backward compatibility to ensure that each program runs with the versions of the symbols it was compiled against (see objdump -T on libc). If you really want to you can also choose to link against a specific version of a symbol.
http://www.trevorpounds.com/blog/?p=103
If other libraries paid as much attention to library backward compatibility the world you be a lots nicer place (you could copy binaries around between distributions and they would work).
A turning point for GNU libc Posted Apr 1, 2012 1:54 UTC (Sun) by BenHutchings (subscriber, #37955) [Link] If you want a program to run on older versions of glibc, you need to use the old interface definitions and the old symbol versions. Just overriding the symbol versions will generally result in your program corrupting data or crashing.
A turning point for GNU libc Posted Apr 5, 2012 8:34 UTC (Thu) by nix (subscriber, #2304) [Link]
You'll also need the versions of libc_nonshared.a and libpthread_nonshared.a that belong to the version of glibc you're trying to use those versioned symbols from (this is one reason why arbitrary .o files are not safe to keep across glibc upgrades). All told it is sufficiently hard to make this work that it's not really worth bothering.
A turning point for GNU libc Posted Apr 5, 2012 15:06 UTC (Thu) by khim (guest, #9252) [Link] Actually this is what LSB is doing and it works fine AFAICS.
A turning point for GNU libc Posted Apr 8, 2012 11:21 UTC (Sun) by nix (subscriber, #2304) [Link]
Yeah. I was talking about doing it by hand, yourself. :)
A turning point for GNU libc Posted Apr 2, 2012 13:20 UTC (Mon) by jwakely (subscriber, #60262) [Link]
> Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries
Not every company distributes software. I can't remember the last time I wrote anything in my day job which wasn't for purely in-house use. The arguments in the "static linking considered harmful" piece simply don't apply in some cases.
A turning point for GNU libc Posted Apr 2, 2012 13:28 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> Not every company distributes software. I can't remember the last time I wrote anything in my day job which wasn't for purely in-house use. The arguments in the "static linking considered harmful" piece simply don't apply in some cases.
I suppose that assuming that the new team is less unfriendly to static linking it will also be a question of whether there are enough people actively interested in it to get the necessary changes in.
A turning point for GNU libc Posted Mar 29, 2012 8:48 UTC (Thu) by cyperpunks (subscriber, #39406) [Link]
This is good news.
I have seen several projects where the whole projects seems to be dependent of one single person. However when this person was gone, the opposite was true. He was more a obstacle than a driving force.
Benevolent loners Posted Mar 30, 2012 0:30 UTC (Fri) by man_ls (subscriber, #15091) [Link] Stating the obvious: I have seen many projects where the whole project was indeed driven by a single person, and the project languished after this person was gone.Your statement is probably true mostly for high profile projects such as glibc.
A turning point for GNU libc Posted Mar 29, 2012 10:24 UTC (Thu) by dgm (subscriber, #49227) [Link]
> The 2.15 release suggests that development activity is on the increase after a sustained low point.
It's too early to say that. If you have a look at the patches/day ratio you get the following numbers:
release: patches per day
The 2.7 release was busier than 2.15, and 2.11 amd 2.12 were not that far behind. But by far the most active period was that leading to 2.4.
If you plot that data, you can convince your self that the project had moved ahead at an almost steady rate of about 2 patches per day.
PS: Is there a sane way to enter tabular data in a comment?
A turning point for GNU libc Posted Mar 29, 2012 16:53 UTC (Thu) by cortana (subscriber, #24596) [Link] You can use <pre> in an HTML comment. 2 2.4: 4.2208 2.5: 1.6811594203 2.6: 1.5657894737 2.7: 2.858974359 2.8: 1.5875706215 2.9: 1.3627906977 2.10: 1.9435028249 2.11: 2.3448275862 2.12: 2.1027027027 2.13: 1.0077220077 2.14: 1.9104477612 2.15: 2.8252427184
My favourite glibc annoyance Posted Mar 29, 2012 13:08 UTC (Thu) by saffroy (subscriber, #43999) [Link]
Aaaah, at last some hope of bringing good fixes to silly problems.
A few years ago, my biggest gripe was that glibc and RedHat-based systems would not allow an admin to tune the behaviour of bindresvport in the glibc, thus forcing users to use ugly (and IIRC insufficient) hacks such as portreserve. Some sane distributors patched their glibc properly (implementing a configurable blacklist for bindresvport), but they were never allowed to upstream their changes, and users of RH and its derivatives distros are still punished.
I'm sure many others have their own war stories...
My favourite glibc annoyance Posted Mar 31, 2012 21:55 UTC (Sat) by lacos (guest, #70616) [Link] and users of RH and its derivatives distros are still punished I don't think so, see ip_local_reserved_ports; it's in RHEL-6 and upstream keeps polishing it.
|
|||||||||||||||||||||||||||||||||||||||||||