Some GNU mistakes

I got so used to take crap because I say that GNU is not perfect that in a sort of masochistic way, I like to try opening the eyes of those who simply don’t care about having their eyes opened.

People who “advocate” Free Software, seem to have a very hard time to come to the result that, well, GNU might not be perfect, that some other project might actual have gotten a better development model for Free Software, and is actually making something better than they have.

We reached the point where the only thing they could attack me about, in my previous criticism of forced features (which didn’t even name GNU!), was my being an atheist. I guess no advocate is atheist because they all subscribed to the Church of Emacs… well, I’m definitely not on board that.

Which is, by itself, a bit strange given that I’m the first person to say that GNU Emacs is a saviour, I love GNU Emacs, it’s one of the best pieces of software that there are out there, I have used it since I started using Linux, and even on OSX I can’t go around without Aquamacs — I’m glad that Stallman wrote it, and it should show that I’m well acquainted to praising GNU when it makes something that is better than the average!

But we also have to call out for the things that don’t make sense, but we’re still having issues with. For instance, I noted a problem with GNU tar after the upgrade to GCC (that’s the GNU Compiler Collection if you wonder). Turns out that it was GCC identifying a buffer overflow, with fortified builds, as the GNU tar developers tried to cut corners, leaving a strcpy() call to go over the boundary of a structure member and write to the one following. Thankfully, Tony had a patch that solved the issue, and GNU tar 1.22-r1 is fine with both 4.4 and 4.5.

At the same time, Tony reported a problem with gawk (which, if you don’t follow, is GNU awk). The problem was worse than a build failure as the ./configure call was remaining stuck during build, which is one of the worst things that can happen (both on a normal system and on the tinderbox) as it wastes time. It wasn’t, though, the basic gawk configure script to freeze, but rather the sub-script for the bundled libsigsegv, that in the latest version of gawk for some reason became an USE flag… Beside being another example of why bundling libraries is a bad idea, the problem here was multi-folded: the USE flag was introduced without saying why it was optional at all; it was tied to a dependency over libsigsegv that wasn’t being used, and it always used the bundled library. The quick fix would have been to patch configure.ac to allow using the system library but… gawk developers have no clue about GNU autoconf and GNU automake; they don’t generate the tarball with make dist – I can tell because the gnulib m4 files are missing – and they… commit the generated configure to their CVS repository. At the end, I simply dropped the USE flag from gawk.

And while I love GNU Emacs, it turns out that something miscompiles with the latest compiler, so I had to rebuild that with GCC 4.4.

To complete the view, we got a mere build failure on GNU lilypond

Now, I’ll admit I’m explicitly nitpicking on GNU packages, with the last two at least; they are, most definitely, something two out many other packages that will at one point or another in time, fail. The first two example, though, are two of the reasons why I say that GNU is not perfect, and we shouldn’t refrain from replacing GNU software with better Free Software (in this case my obvious suggestion would be libarchive’s tar implementation, rather than GNU tar).

The fortify-source feature is implemented by the GNU C Library and by the GNU Compiler Collection… yet the GNU tar developers felt like they could ignore that feature altogether? It doesn’t sound too sane. And what about GNU awk failing to grok the official build system of the project? (and I understand the difficulty there pretty well, given I’ve been documenting it myself… speaking of which I got a few more things to write on my guide once I have some free time I can spend in front of the monitor without crying for the tiredness.

People, grow up! GNU is not perfect, but it’s also not the only choice you have for Free Software! Let’s properly evaluate all software out there, whoever wrote it, and strive for perfection by not accepting the low quality it has today!

6 thoughts on “Some GNU mistakes

  1. @Odi: The idea is good, the problem I can see with tinderbox is that it’s quite difficult to estimate the time emerge should be allowed to live; =====genlop -t openoffice Wed Dec 2 13:34:50 2009 >>> app-office/openoffice-3.1.1 merge time: 1 hour, 20 minutes and 52 seconds.[…] Wed Mar 24 12:40:23 2010 >>> app-office/openoffice-3.2.0 merge time: 1 hour, 57 minutes and 27 seconds.=====compare it with $(genlop -t portage) :Oanyway I’ve grabbed your script for other purposes :)

    Like

  2. As Francesco said… but it gets worse, if OOo takes 2 hours, BerkDB (sys-libs/db) 4.8, with full test suite, takes over 25 hours!

    Like

  3. To be honest, these all just look like bugs, and Bugs Happen especially in large, complex collections of software.The real questions are: (1) Do these bugs get fixed quickly? (2) Are the alternatives any better (either at having fewer bugs or fixing them more quickly)?In fact, what are the alternatives? BSD utilities perhaps, even though these are fewer in number and much less featureful.

    Like

  4. Well, libarchive is definitely _more_ featureful than GNU tar… among other things it can deal with zip and cpio files transparently.The problem is that we have to distinguish user-side features (which I agree is bad to lose) and extensions to interfaces and similar that cause lock-in on the GNU version of a package that would otherwise be easy to replace.By the way, at least in the case of gawk it’s not a simple bug: it’s the whole development process being screwed up: they don’t seem to know how to use autotools (let me stress, _GNU_ autotools) nor they seem to have called upon some person who has a clue about that to help them out.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s