Subject: GNU sed 4.2.2 released, and a rant from the maintainer
Newsgroups: gmane.comp.lang.smalltalk.gnu.general, gmane.comp.gnu.utils.bugs
Date: 2012-12-22 16:10:19 GMT (23 hours and 47 minutes ago)
I am pleased to announce the release of GNU sed 4.2.2. The latest release has the following bug fixes and new features: * don't misbehave (truncate input) for lines of length 2^31 and longer * fix endless loop on incomplete multibyte sequences * -u also does unbuffered input, rather than unbuffered output only * New command `F' to print current input file name * sed -i, s///w, and the `w' and `W' commands also obey the --binary option (and create CR/LF-terminated files if the option is absent) * --posix fails for scripts (or fragments as passed to the -e option) that end in a backslash, as they are not portable. * New option -z (--null-data) to separate lines by ASCII NUL characters. * \x26 (and similar escaped sequences) produces a literal & in the replacement argument of the s/// command, rather than including the matched text. GNU sed 4.2.2 can be downloaded from the following URLs: * http://ftp.gnu.org/gnu/sed/sed-4.2.2.tar.gz * ftp://ftp.gnu.org/gnu/sed/sed-4.2.2.tar.gz * http://ftp.gnu.org/gnu/sed/sed-4.2.2.tar.bz2 * ftp://ftp.gnu.org/gnu/sed/sed-4.2.2.tar.bz2 I am less pleased to announce that I am resigning from maintenance of GNU sed (after 8 years) as well as GNU grep (after 3). I have also given up commit access to Autoconf, Automake, Libtool, gnulib, libsigsegv and Bison. For fellow GNU maintainers and to some external observers, the relation between this announcement and Nikos Mavrogiannopoulos's note ("gnutls is moving", http://lwn.net/Articles/529558/) will not be a surprise. Like Nikos, I do support the ideas behind the FSF as strongly as ever; and I am grateful to the FSF staff for the support I have had since I joined the GNU project in 1999. However, like him I am in major disagreement with some decisions of the FSF and of Richard Stallman. This boils down to these three points: 1) To put it somewhat bluntly, the only way for a GNU project to be a leader in its field is to _ignore_ whatever recommendations come from the FSF. I don't think Stallman was involved when the GNU Compiler Collection switched from C to C++, or when GNOME chose JavaScript as the extension language for gnome-shell. Sometimes, having a single person take executive decisions is a good thing. It is likely not possible to convince a diverse group such as the group of GNU maintainers to agree on coding standards for C++, for example. However, all Stallman had to offer on the topic was "We still prefer C to C++, because C++ is so ugly" (sic). As a result of this, the GNU coding standards have not seen any update in years and are entirely obsolete. This is not limited to the topic of programming languages. Something like libabc (http://0pointer.de/blog/projects/libabc.html) ought to have come from the GNU community, but it didn't. There is also no mention of security in the GNU coding standards. They still say "Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead" but sometimes arbitrary limits are a necessity when dealing with possibly hostile input. 2) GNU is doing too little for the FSF, and the FSF is doing too little for GNU. Due to the huge success that free software had since the appearance of the GNU manifesto, distributing free software is absolutely not the exclusive of GNU anymore, and that's a good thing. On the other hand, the FSF is not doing anything to value the GNU "brand". Projects such as gnash are bound to have constant funding problems despite being (and having been for years) in the FSF's list of high priority projects. Other projects in the list do not exist at all, because they would require man-years of development but people who want to do the work must, again, do it on their own money. This is not enough to be relevant in a world where free software is dominating in so many fields. It is absolutely not enough if you want to remain relevant in a world where free software is called "open source" and most people actually do not care about the user's freedoms. 3) Attaching the GNU label to one's program has absolutely no attractiveness anymore. People expect GNU to be as slow as an elephant, rather than as slick as a gazelle, and perhaps they are right. Projects such as LLVM achieve a great momentum by building on the slowness of GNU's decision processes, and companies such as Apple get praise even if they are only embracing these projects to avoid problems with GPLv3. Being part of GNU is not an emblem of technical leadership anymore, either. "If it is done poorly in Unix, feel free to replace it completely with something totally different and better". Is this still true of today's GNU? Barring any large change in policy and momentum from GNU, these three reasons are bound to be the first step towards the irrelevance of GNU. And barring any such policy change, I have no reason to be part of GNU anymore. I didn't resign commit access for two projects only: GCC and GNU Smalltalk. I still have not decided what to do about GNU Smalltalk. Work and family obligations forced me away from the project that introduced me to free software back in 1996. I would like to move it within the GNOME umbrella, but again that is not possible without devoting serious development effort to it. Suggestions are welcome. For more information about the vicissitudes of gnutls, you could read the good summary at Linux Weekly News. Non-subscribers can access it at http://lwn.net/SubscriberLink/529522/854aed3fb6398b79/ (and are urged to support LWN, of course!). Thanks for reading this. Paolo