Historias
Slashboxes
Comentarios
 

Publicado sed 4.2.2 y dimisión de su mantenedor

Entrada escrita por BitBoy y editada por nettizen el Lunes, 24 Diciembre de 2012, 10:43h   Printer-friendly   Email story
desde el dept. todo-llega-bueno-malo-y-regular
Ayer fuer publicada la versión 4.2.2 del software sed (stream editor). Su mantenedor, desarrollador y miembro del proyecto GNU Paolo Bonzini, aprovechó este evento para renunciar a continuar con su labor como mantenedor de sed y grep, tareas que había asumido desde hace 8 y 3 años, respectivamente. Al parecer, debido a discrepancias con la deriva de la F.S.F., de la que es miembro desde 1999, y con su fundador Richard Stallman. La explicación completa de su decisión, así como de sus impresiones personales sobre la situación actual del software libre, pueden leerse en la nota de publicación de sed 4.2.2.

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Pena

    (Puntos:3, Interesante)
    por Mu (11278) el Lunes, 24 Diciembre de 2012, 08:00h (#1327312)
    ( http://press.asqueados.net/ | Última bitácora: Viernes, 28 Diciembre de 2012, 09:05h )
    Siempre he estado con Stallman en un plano moral, pero está claro que su testarudez y su falta de mano izquierda están perjudicando el proyecto de GNU actualmente.

    Por lo que se lee en los enlaces, el proyecto GNU necesita hacerse mucho más participativo para los miembros de los proyectos que los componen. Espero que Stallman y la FSF terminen comprendiéndolo.
    --
    Envíos descartados por Mu [barrapunto.com]
    [ Responder ]
    • Re:Pena de svalk (Puntos:2) Martes, 25 Diciembre de 2012, 20:02h
      • Re:Y eso está pasando de svalk (Puntos:3) Miércoles, 26 Diciembre de 2012, 09:22h
      • Re:Y eso está pasando

        (Puntos:4, Informativo)
        por svalk (4919) el Miércoles, 26 Diciembre de 2012, 15:21h (#1327418)
        ( Última bitácora: Viernes, 14 Septiembre de 2012, 13:12h )
        tambien se hacia cargo de grep

        a lo mejor las discrepancias no eran precisamente con RMS sino que su "afan de innovacion"(hacia donde?) choca frontalmente con esto(s pesados elefantes sic):

        http://lists.freebsd.org/pipermail/freebsd-current /2010-August/019310.html [freebsd.org]

        why GNU grep is fast

        Mike Haertel mike at ducky.net
        Sat Aug 21 03:00:30 UTC 2010

        Hi Gabor,

        I am the original author of GNU grep. I am also a FreeBSD user,
        although I live on -stable (and older) and rarely pay attention
        to -current.

        However, while searching the -current mailing list for an unrelated
        reason, I stumbled across some flamage regarding BSD grep vs GNU grep
        performance. You may have noticed that discussion too...

        Anyway, just FYI, here's a quick summary of where GNU grep gets
        its speed. Hopefully you can carry these ideas over to BSD grep.

        #1 trick: GNU grep is fast because it AVOIDS LOOKING AT
        EVERY INPUT BYTE.

        #2 trick: GNU grep is fast because it EXECUTES VERY FEW
        INSTRUCTIONS FOR EACH BYTE that it *does* look at.

        GNU grep uses the well-known Boyer-Moore algorithm, which looks
        first for the final letter of the target string, and uses a lookup
        table to tell it how far ahead it can skip in the input whenever
        it finds a non-matching character.

        GNU grep also unrolls the inner loop of Boyer-Moore, and sets up
        the Boyer-Moore delta table entries in such a way that it doesn't
        need to do the loop exit test at every unrolled step. The result
        of this is that, in the limit, GNU grep averages fewer than 3 x86
        instructions executed for each input byte it actually looks at
        (and it skips many bytes entirely).

        See "Fast String Searching", by Andrew Hume and Daniel Sunday,
        in the November 1991 issue of Software Practice & Experience, for
        a good discussion of Boyer-Moore implementation tricks. It's
        available as a free PDF online.

        Once you have fast search, you'll find you also need fast input.

        GNU grep uses raw Unix input system calls and avoids copying data
        after reading it.

        Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking
        for newlines would slow grep down by a factor of several times,
        because to find the newlines it would have to look at every byte!

        So instead of using line-oriented input, GNU grep reads raw data into
        a large buffer, searches the buffer using Boyer-Moore, and only when
        it finds a match does it go and look for the bounding newlines.
        (Certain command line options like -n disable this optimization.)

        Finally, when I was last the maintainer of GNU grep (15+ years ago...),
        GNU grep also tried very hard to set things up so that the *kernel*
        could ALSO avoid handling every byte of the input, by using mmap()
        instead of read() for file input. At the time, using read() caused
        most Unix versions to do extra copying. Since GNU grep passed out
        of my hands, it appears that use of mmap became non-default, but you
        can still get it via --mmap. And at least in cases where the data
        is already file system buffer caches, mmap is still faster:

        $ time sh -c 'find . -type f -print | xargs grep -l 123456789abcdef'
        real 0m1.530s
        user 0m0.230s
        sys 0m1.357s
        $ time sh -c 'find . -type f -print | xargs grep --mmap -l 123456789abcdef'
        real 0m1.201s
        user 0m0.330s
        sys 0m0.929s

        [workload was a 648 megabyte MH mail folder containing 41000 messages]
        So even nowadays, using --mmap can be worth a >20% speedup.

        Summary:

        - Use Boyer-Moore (and unroll its inner loop a few times).

        - Roll your own unbuffered input using raw system calls. Avoid copying
        the input bytes before searching them. (Do,
      • 1 respuesta por debajo de tu umbral de lectura actual.
    • Re:Pena de Mu (Puntos:2) Lunes, 24 Diciembre de 2012, 12:09h
      • Re:Pena

        (Puntos:4, Inspirado)
        por frames (37950) el Lunes, 24 Diciembre de 2012, 18:45h (#1327349)
        Te refieres a mano izquierda como la de Torvalds?

        Porque está muy extendido el mantra de que Stallman está loco ... y luego siempre acierta. Y de que es un hijo de su madre intransigente ... mientras que otros hacen lo mismo o peor, pero sin muchas razones.
        • Re:Pena de Mu (Puntos:3) Martes, 25 Diciembre de 2012, 08:21h
          • Re:Pena de Mu (Puntos:2) Martes, 25 Diciembre de 2012, 08:32h
      • Re:Pena de Mu (Puntos:2) Lunes, 24 Diciembre de 2012, 12:43h
      • 1 respuesta por debajo de tu umbral de lectura actual.
    • Re:Pena de pobrecito hablador (Puntos:1) Lunes, 24 Diciembre de 2012, 12:29h
      • Re:Pena de frames (Puntos:3) Lunes, 24 Diciembre de 2012, 18:51h
      • Re:Pena de svalk (Puntos:2) Miércoles, 26 Diciembre de 2012, 16:04h
      • 3 respuestas por debajo de tu umbral de lectura actual.
    • Re:Pena de frames (Puntos:2) Lunes, 24 Diciembre de 2012, 18:53h
    • 2 respuestas por debajo de tu umbral de lectura actual.
  • por frames (37950) el Lunes, 24 Diciembre de 2012, 18:58h (#1327352)
    Yo tampoco lo pillo, pero es ver esa consecución de caracteres y ponerme a pensar dos tazas de té [google.com] (advertencia: NO ver con el jefe o la parienta detrás ;-)).
  • Re:Que cierre al salir

    (Puntos:1, Informativo)
    por pobrecito hablador el Lunes, 24 Diciembre de 2012, 19:05h (#1327355)
    En una primera lectura, es un identificador numérico que se insertó en algún case().

    En una segunda lectura, 0xBI6B00B5 es la trasliteración a grafía "hácker/juáquer" de la frase inglesa "big boobs", que en lenguaje de Cervantes son "tetas grandes"/"tetazas"/"melones" o similar.

    O sea, que se insertó "tetas grandes" dentro del código del kernel.

    Y alguien lo consideró de pésimo gusto.
    http://news.ycombinator.com/item?id=4270393 [ycombinator.com]
  • 3 respuestas por debajo de tu umbral de lectura actual.