No announcement yet.

GNU Grep & Sed: Fallout Within The GNU FSF Camp

  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by gens View Post
    by all means bash on
    i'm just saying a license has nothing to do with the organization that made it
    Who's bashing? You have two instances in a short time of people becoming fed up with the bureaucracy that surrounds one man. Normal organizations would examine and rectify the situation, but as it's Richard Milhous Stallman, nothing will be done.

    im also the first to say that the FSF way (american way) of doing things is bad for everybody
    at least from what i see is their way
    pretty much


    • #42
      Do grep and sed require much upkeep these days? I figured the code base was pretty much set by now.


      • #43
        Originally posted by vsteel View Post
        Do grep and sed require much upkeep these days? I figured the code base was pretty much set by now.
        Yea, I had the same impression. Those are basic tools that have been around for a long, long while, why do they need that much maintenance? Does /bin/true also require that much of it?


        • #44
          Originally posted by pingufunkybeat View Post
          Remove all GNU software from your computer (not GPL-licensed, not FSF-endorsed, only the "GNU operating system" stuff) and see how far you get with that Seriously, try it, just for a laugh.

          Anyway, as was commented elsewhere, this is a tempest in a teapot. A maintainer stepped down, but made it clear that he still supports the goals of the project. Big deal...

          real GNU software? What about those things which are only gnu by name? Like glibc? gcc? gnutls? Grub?

          That said, you can go really far without gnu. Xorg is not gnu, KDE is not gnu, Qt is not gnu, Linux, perl, python is not gnu. Zsh, busybox, syslinux not gnu.


          • #45
            Originally posted by energyman View Post
            real GNU software? What about those things which are only gnu by name? Like glibc? gcc? gnutls? Grub?
            Ehh? GCC and Glibc most definately are official GNU software.


            • #46
              especially glibc is only gnu by name.


              • #47
                Originally posted by XorEaxEax View Post
                Ehh? GCC and Glibc most definately are official GNU software.
                Check the popular quote by Drepper, IIRC it was from the 2.3.2 release notes, where he says any code he wrote is not GNU.


                • #48
                  Paolo Bonzini, the sed maintainer who stepped down, has published a clarification:

                  Originally posted by
                  What to do about GNU?
                  By Paolo Bonzini - Posted on February 2nd, 2013

                  About a month ago, I released GNU sed version 4.2.2 and included in the release a "rant" (more of a criticism, perhaps?I'm not a native speaker) about the state of the GNU project.

                  I made it clear that I had no philosophical disagreement with FSF; in fact, that's likely the reason why almost no one took my post as an occasion to attack the FSF and Richard Stallman. To the few that did: guys, you clearly missed the point. I wrote that text because I want free software and the FSF to be successful. My concern is that if GNU loses, the FSF loses?even if some other piece of free software happens to win.

                  Anyhow, these people were clearly a minority. I was surprised by the positive reactions to my post. All of the flames mostly concentrated on the virtues and sins of the C++ programming languages. I was most pleasantly surprised by the amicable reactions from fellow GNU hackers and from Stallman himself.

                  In fact, Richard clearly understood the difference between quitting maintainership, and quitting the GNU project completely; the difference between not contributing any more code, and rescinding all links with GNU. Resigning commit access meant I'll be contributing less code to GNU, but if there are other compelling ways to help, count me in.

                  So, here are some proposals to fellow hackers. Some of them may work out, some of them may not. It is even possible some of them are inapplicable because of U.S. law for non-profits. But I'm sure that they are welcome by the FSF, and that's already a good motivation to write them.

                  First of all, let's talk about GNU. GNU needs updated coding standards, and coding standards are about much more than brace positioning. The GNU coding standards should summarize best practices into a free document that people can refer to; everyone, not just GNU developers. Most importantly, such an update should focus on existing best practices. If you don't like something in D-Bus or pkg-config or the Autotools, fix it upstream (and be prepared to be told you're wrong). That's how it works with free software.

                  GNU also has a maintainer guide. The maintainer guide should document the services that GNU makes available. For example, a short guide to debbugs and the Hydra continuous integration server, both of which are used by many GNU projects. As an aside, it would be great if some of the infrastructure put in place for GNOME and other large GNU projects could be reused by all of them. Regardless of personal opinions about desktop environments, the GNOME project is clearly a successful community, and we all should learn from it!

                  Second, let's talk about what GNU is. There are too many projects in GNU. Micromanagement is impossible at this scale, therefore nobody really tracks them. This has many problems: the signal-to-noise ratio in the list of GNU software projects is low, the different projects are not as coherent as they could be, there is little or no mentoring for new GNU maintainers, and so on.

                  GNU should be reorganized around a few high-profile umbrella projects: for example the development environment (GCC, binutils, gdb, glibc, etc.), the build system (comprising Autotools but also gnulib), the POSIX environment, and GNOME. Everything else should either integrate itself with such a meta-project, or find another home. For example, as I mentioned in my December post, GNU Smalltalk could become a GNOME project.

                  Third, what about the FSF? The FSF could be the home for some of these projects. GNU MediaGoblin is an obvious example, and could perhaps be a "pilot" for more projects to follow. The FSF would donate help with bureaucracy, including copyright assignment. FSF and the projects it endorses could mutually benefit in terms of branding. Similarly, organizing a donation process for FSF-endorsed projects will likely bring members to the FSF.

                  FSF projects would be vetted quite strictly, and not judged as parts of a system---but rather, for their contribution to the advancement of software freedom. Such projects are often tied to academic work. It would be great if the FSF gave exposure to research that advances freedom. Perhaps even get access to funding from the National Science Foundation (in the U.S.) or the European Framework Programmes, and use it to hire developers for FSF projects.

                  GNU has been producing free software for almost 30 years now, and there's no reason why it should stop. Join us now and share the software; you'll be free, hackers, and we'll do our best to make it fun!
                  Apparently Michael was one of those "few guys who missed the point", along with few other members on this forum.
                  Paolo article was a nice groundhog detector. I hope somebody pushes more, its awesome way to reveal the backstabbers.


                  • #49
                    The FSF would donate help with bureaucracy