GNU sed 4.2.2 released, and a rant from the maintainer

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

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini scripsit:

> 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).

If no new maintainer can be found, and especially for sed, I hope you
will fork the projects.  Forking is a last resort, but it has been known
to get the FSF's attention.

> 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.

Now that Squeak and Pharo are FSF-free, I do not think it makes sense to
put a lot of investment into GNU Smalltalk.  It can always be forked if
someone wants to do something truly innovative with it.

--
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      http://ccil.org/~cowan

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

I did not realise that Paolo also took care of GNU sed and GNU grep.  Job
well done.

Squeak and Pharo are good, but GNU Smalltalk does serve a purpose.  It is
intended for scripting purposes, which neither Squeak and Pharo, as far as
I know, can do since they are tightly bound to full blown GUI environments.
 Paolo also provides lots of help for newbies (like myself), so I hope he
doesn't give up on GNU Smalltalk.  Forking I don't believe would be
the right way to go.  Jenkins/Hudson ?   OpenOffice/LibreOffice ?    Nah, I
wouldn't want that for GNU Smalltalk.


cheers,

      mehul


On Sun, Dec 23, 2012 at 2:30 PM, John Cowan <[hidden email]> wrote:



--
Mehul N. Sanghvi
email: [hidden email]
_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 23/12/2012 23:58, Mehul Sanghvi ha scritto:
> Squeak and Pharo are good, but GNU Smalltalk does serve a purpose.  It
> is intended for scripting purposes, which neither Squeak and Pharo, as
> far as I know, can do since they are tightly bound to full blown GUI
> environments.

Squeak and Pharo's FSF-freeness is undoubtedly a good thing, but a
Smalltalk like gst still has its place.  The Javascript-based Amber
Smalltalk is much more similar to gst and perhaps could grow enough
functionality to be a replacement.

Paolo

> Paolo also provides lots of help for newbies (like
> myself), so I hope he doesn't give up on GNU Smalltalk.  Forking I don't
> believe would be
> the right way to go.  Jenkins/Hudson ?   OpenOffice/LibreOffice ?  
>  Nah, I wouldn't want that for GNU Smalltalk.


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini <[hidden email]> writes:

Paolo,

You see Amber being a replacement of GST? I really don't think so,
Amber's primary goal is to bring a Smalltalk language and environment to
the web.

GST has its place and purpose, please do not let it die :)

Cheers,
Nico

>
> Paolo
>
>> Paolo also provides lots of help for newbies (like
>> myself), so I hope he doesn't give up on GNU Smalltalk.  Forking I don't
>> believe would be
>> the right way to go.  Jenkins/Hudson ?   OpenOffice/LibreOffice ?  
>>  Nah, I wouldn't want that for GNU Smalltalk.
>

--
Nicolas Petton
http://nicolas-petton.fr

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk