[Help-smalltalk] GNU sed 4.2.2 released, and a rant from the maintainer

[Paolo Bonzini]

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