New GNU Recruits

I saw this lovely drawing over at Máirín Duffy's blog.  She works at RedHat.

Its from a post called FUDcon Lawrence: Overhauling the Fedora release model.  Note the little jumping person and the gap.  This indicates that Fedora understands that there is a barrier between using Fedora distro of GNU/Linux and contributing to it.  This is something they hope to address.

If I replace "Fedora" with "GNU" in the above picture, what happens?

• Hear about GNU
• Go to GNU website
• Download GNU
• Try out live media
• Install GNU
• Use GNU
• ???
• Contribute

Let's try it out and see what happens.

Step 1 - Hear about GNU.  Not a problem.  GNU gets mentioned fairly regularly in the press.

Step 2 - Go to GNU website.  There is a web site, www.gnu.org.  The main page is a bit cluttered, but, it exists.  There is a www.gnu.com, which is a snowboard company, but, there's little chance of confusing the two.

Step 3 - Download GNU.  From the main page, there is "What is GNU" and a big green "Download GNU Now" button.  Visually it can get lost because the page is very text-heavy and the button it is almost too big.  But overall, it is functional.  It takes you to the distros page.

This is where is gets more problematic.  First off, there is the big yellow italicized disclaimer "The FSF is not responsible for other web sites, or how up-to-date their information is".  It is highlighted so it must be important.  It sounds scary.  But what does it mean?  Up to this point, the term "FSF" has not been defined and its relationship to GNU has not been defined.

Also, there is no real distinction made between these distros or why or how one would use them.  Since they are treated equally, the first one, "BLAG" becomes the de-facto distro by virtue of its early appearance in alphabetical order.  So clicking on that takes us over to BLAG.

At the very top of Blag is a download link to Live CDs, and clicking on that link brings to an FTP server

Note that we've now implicitly answered the question of What is GNU OS?  GNU OS is Blag's 2011 fully free respin of Fedora's distro of GNU/Linux.

Step 4 - Try out live media.  So I've downloaded the live media.

Cool, but, how do I use it?  What do I do with it?  If I go back to the main Blag page and click on the documentation link, I get

This doesn't look good.  But if I allow the exception I end up at a perfectly respectable wiki.

Step 5 - Install GNU OS.  Installing GNU from live media become the same as installing Fedora from live media the way it was done back in 2011.

Step 6 - Use GNU OS.  Cool.  We're using GNU.

If I go back to the main GNU page to look for information on how to use the distro I've just downloaded, I get nothing general.  There is the documentation to many pieces of software that may or may not appear in that distro, though.

Step 7 - Contribute. 

On their part, Fedora knows that there is a big leap between using Fedora and contributing to Fedora. For GNU, it isn't just a leap from using GNU OS to contributing to GNU OS.  It is a complete disconnect.

Once someone has downloaded the Blag respin of the Fedora distro of GNU/Linux, what force is there to push them back to GNU the website, or the official GNU software projects?  What force is there to push them to contribute financially to the FSF?

Once someone had made the decision that he or she wants to contribute, he or she can end up back on gnu.org and see this.

Note the categories listed under the Take Action box or the yellow bar:  you can contribute by

• working on the FSF campaigns
• contributing to high-priority software projects
• or maintaining unmaintained software

Notice how everything on that list has either a very low or  a very high level of technical expertise required.  There isn't a good story on how to train up a programmer on the ways of free software.  It is a bit of all-or-nothing. Suppose you wanted to help with one of the technical projects: there isn't really a good tutorial story on learning how to code GNU-style.  There are projects like GNU Hello and documents like the Coding Standards and the Information for Maintainers that sketch out the concepts, but, you would have to know that they are there and where to find them, and the barrier to entry is pretty high.

So, all in all, the flow of moving people from curiosity about GNU OS to using GNU OS to eventually contributing to GNU needs work.

DISCLAIMER: I don't speak for GNU and have no influence over its policies, or management. I am only just barely a member of GNU by virtue of being the maintainer of the ncurses bindings for guile. Guile-ncurses is a project that is so niche and so obscure that it has never been packaged by any distro and never has been downloaded or used by anyone ever, other than me, as far as I can tell. I also used to be a committer on the main Guile project, during the 1.8 to 2.0 transition, but, I've retired from Guile development, mostly.

C11 for great justice

Last week I blogged a bit about the new 2011 C standard, C11, which is beginning to appear in compilers in the real world.  My basic idea was this

• While GNU uses many languages, C and Guile are the encouraged languages in GNU
• Many new projects avoid C because it is painful
• C11 has features that make it a nicer experience for the applications programmer
• Therefore, GNU should embrace C11

That post got more interest than it deserved, and I've learned quite a lot from the comments here, on HN, and on Twitter.

First, since that post, the GNU Coding Standards have been updated to mention C11.  They now read

1989 Standard C is widespread enough now that it is ok to use its features in programs. There is one exception: do not ever use the“trigraph” feature of Standard C.

The 1999 and 2011 editions of Standard C are not fully supported on all platforms. If you aim to support compilation by compilers other than GCC, you should not require these C features in your programs. It is ok to use these features conditionally when the compiler supports them.

If your program is only meant to compile with GCC, then you can use these features if GCC supports them, when they give substantial benefit.
 

In a policy sense, the modified language isn't much different to the previous version of the standards: basically, use extensions to C89 if they are beneficial, or hold to C89 if you want to be  multi-platform.  Your choice.

Second, with respect to GNOME and C89, Christian Hergert told me this,

 "One of the reasons GNOME (and primarily all the way down to GLib) use C89 is because of the Microsoft C compiler. As sad as that sounds, making sure existing software runs on Windows (things like Gobject, Gtk, Pidgin) is important"

Fine. So when will Microsoft put out a better C compiler? According to Herb Sutter, Microsoft definitely has no plans to update their C compiler: they're just maintaining it without adding new features, so it'll probably remain C89-like forever. A pity, since GCC and Clang have kept moving forward.

However, Microsoft has spent a lot of time trying to bring C++11 to their C++ compiler, and, as a side effect, their C++ compiler has picked up most of the subset of C99 that C++11 contains.  The truth is that if you want to keep native Microsoft compiler support in a free software project, you need to choose one of two strategies

1. Write C89 code forever
2. Write using the intersection of C99 and C++11, and compile using C++ on a native Microsoft build.

Third, I learned that many people really hate VLAs in C.  Odd.  But I was always the type of person that used alloca().  Sure you can error unrecoverably if you overflow the stack, but, avoiding that is simple: just don't allocate anything large enough to overflow the stack.  ;-)

In my tiny slivers of free time, I have kept plugging away at writing a game trying to use the GNOME and GNU libraries.  There's nothing to see, yet.  It is slow going because I was completely unfamiliar with GTK+ and Cairo and Glib and Pulse Audio and the very idea of how to program games. Basically I'm completely out of my paradigm. I've already erased everything and started over twice. But, I think I finally am getting the hang of it.

It is all very different from the work I do in the lab.  But writing the game does have a great advantage: with that project, unlike the code I do at my job, if I screw up it won't result in real human beings dying.  After a career of Mil-Spec and Level B, it is hard to allow myself to just make things work and avoid the perfectionism and paranoia that DO-178B entails.  It is hard to code like I did when I was young, when the joy was in hack and slash and making things work, rather than the craft and drudgery of making things that keep their operators safe from harm.

I wish I could show you some of the code I've done at my real-life job.  It is bananas.

DO178B gets into your head: everything I do in my spare time is either so ridiculously overbuilt that is never gets completed; or it is so rushed and unedited that it can bypass my Freudian super-ego.  The little bit of publicly available free software I've written is in the latter category: it is all crap.  I can't seem to work like a normal person anymore.