6 de marzo de 2011

Los parches de Red Hat

A más de uno se le han alterado los nervios cuando se ha sabido que Red Hat ya no publica en sus .SRPM del kernel los parches individuales de cada característica, driver, o fallo de seguridad solucionado, sino que solamente publica las fuentes del kernel con todos los parches ya aplicados. En mi opinión no es para tanto, incluso se podría decir que es una forma muy ocurrente de generar eso que se llama "valor añadido" sin traicionar el espíritu del software libre.

En su justificación, Red Hat da claramente a entender la motivación de este cambio: que la distro-clon Oracle no pueda hacer competencia a clientes de Red Hat fácilmente. Podrán compilar las fuentes del kernel de Red Hat y ofrecerlo como producto, pero cuando el cliente tenga un problema y pregunte qué hay de lo mio, a Oracle no le será fácil contestar, aunque tenga algunos hackers del kernel muy capaces. No es lo mismo buscar un fallo y adivinar quien lo introduce de una serie de parches perfectamente nombrados y divididos, y solucionarlo sabiendo qué partes del kernel están afectadas por el cambio, que intentar buscar el fallo entre una maraña de parche de diff de varios MB y mantener los cambios durante un periodo de soporte de 10 años. No es imposible, pero desde luego tampoco parece muy profesional.

La distro-clon de Oracle es una prueba de lo mal que Ellison entiende el funcionamiento del software libre. Básicamente fue una reacción infantil a la compra de JBoss, que Oracle creía tener en sus manos y que Red Hat le arrebató en el último momento. Tras ello la prensa quiso alimentar el fuego extendiendo el rumor de que Oracle podría comprar Red Hat, la contestación de Ellison fue: "I don't see how we could possibly buy Red Hat...I'm not going to spend $5bn, or $6bn, for something that can just be so completely wiped off the map". Seis meses después nacía "Oracle Unbreakable Linux" con ese objetivo, ofreciendo contratos de soporte un 60% más baratos que Red Hat (el dinero para él no es problema) y prometiendo recompilar los .SRPM en el preciso instante en que se hicieran públicos.

Sin embargo, Red Hat siguió ganando dinero y 5 años después sigue existiendo: el plan no funcionó. Y ahora Oracle tendrá algo más difícil ofrecer soporte, y tendrá que plantearse cada vez más el seguir siendo una distro diseñada para atraer clientes de Red Hat, o ser algo con algo más de identidad (aunque algún cliente gordo debe haber quitado Oracle a Red Hat para dar este paso).

Respecto a la comunidad, a nosotros, la medida de Red Hat tampoco es un gran problema. Todo el código que Linux tiene de los programadores de Red Hat no se incorporaba mediante esos parches, sino mediante la política "upstream first". No perderemos nada. Y Centos, por su parte, aplica la técnica de distro-clon de Oracle, pero sin importarles un carajo el soporte, por lo que no es un problema. Aquí el que sale perdiendo es nuestro enemigo favorito (Microsoft y Bill Gates ya no son un problema tan grande, creo yo).

12 comentarios:

  1. Pues menudo marrón les deja...

    Pero mientras sigan liberando el código y trabajando upstream, sin problemas por mi parte.

    ResponderEliminar
  2. "Microsoft y Bill Gates ya no son un problema tan grande, creo yo"

    Jeje, hace algunos años, esa frase hubiera sido impensable, y eso de favorito pus no se si es la palabra, la diferencia con Ellison es que precisamente ha procurado ser lo más odioso y gandalla posible hacia el movimiento del software libre

    ResponderEliminar
  3. Anónimo1:13 a. m.

    Como habéis dicho en otra entrada, igual Microsoft intenta atraer a parte de los programadores para que trabajen en una "nueva" infraestructura adquirida por ellos como pudiera ser el Qt de Nokia. ¿Descabellado?

    ResponderEliminar
  4. Algunos comentarios:

    - Para la mayoría de usuarios/desarrolladores el cambio es totalmente transparente, muestra de ello es que la noticia ha saltado 5 meses después de la salida de RHEL-6 y en una entrevista al desarrollador que mantiene el kernel de Debian (semanas después ha salido la nota de prensa). Personalmente la primera noticia la leo en blog de Diego.

    - Como se apunta en varios comentarios: los parches seguirán disponibles en el portal de clientes.

    - El cambio afecta a todos los kernels de RHEL-6, incluidos los testing, en la rama de Linville se puede leer "I no longer have RHEL6 test kernels available here. I apologize for any inconvenience". En LWN se apunta a comentarios de empleados de Red Hat que muestran su descontento con el cambio.

    - Nadie pone en duda el compromiso de Red Hat con el software libre, pero en cierto modo Red Hat hace lo mismo que Oracle: ganar dinero empaquetando el trabajo de otros, insisto, no pongo en duda la intachable trayectoria y compromiso de Red Hat.

    - El camino que han tomado ha sido el menos malo para sus clientes y el que afecta directamente a Oracle, cumpliendo la GPL podrían haber tomado otros caminos peores (no sé hasta qué punto está obligada a publicar los .spec).

    - La nota de prensa no deja lugar a dudas, pero en varios comentarios leo que SuSE está haciendo lo mismo simplemente por sencillez, a priori resulta mas fácil publicar lo que tienes en Git que publicar los fuentes y todos sus parches.

    Mi conclusión es negativa, la solución que ha tomado Red Hat no me parece preocupante, pero si su lectura: algunos clientes ven más valor en la solución distro-clon de Oracle que en el producto original de RHEL; pensaba que estos clientes serían minoría pero ver a Red Hat mover ficha para defenderse y no pasar del tema como han venido haciendo durante años hace ver que consideran a la competencia un problema real y que afecta a su modelo de negocio.

    Espero que no se extienda al resto de paquetes, soy usuario habitual del FTP de Red Hat y me descargo SRPMs para analizarlos, comprobar parches, etc.; con este cambio para mi la distribución perdería valor y parte de su esencia. Sería un pena y muchos proyectos se verían afectados, en mi caso particular puedo hablar de un proyecto personal, PowerStack, donde parte del trabajo se basa en los .spec extraídos del FTP, si Red Hat “ofusca” su trabajo posiblemente el proyecto desaparecería.

    ResponderEliminar
  5. Peor, ahora Red Hat anuncia que usar codigo o parte de el distribuido por Red Hat esta en contra de los terminos de servicio de este.

    http://www.binplay.com/2011/03/red-hat-should-have-invested-in-bsd.html

    Red Hat le gusta tomar el trabajo de los demas, pero cuando alguien toma su trabajo no lo toleran. Simplemente no comprenden que es Software Libre.

    ResponderEliminar
  6. Jairly: Lo que dices, y lo que dice ese enlace, es francamente una tontería. Red Hat no esconde sus cambios a nadie.

    ResponderEliminar
  7. ¿Estamos leyendo el mismo articulo? Por que no se trata de esconder, se trata de violar términos de la GPL al prohibir distribuir software de Red Hat a cualquier compañía tercera.

    Citando a Maximilian Attems, miembro del kernel Debian, "They released their linux-2.6 as one big tarball clashing with the spirit of the GPL". La fuente se encuentra en el enlace que di.

    y "Secondly, the fact that Red Hat is now placing restrictions on redistribution of GPL-ed sources appears to violate the licence under which the kernel is distributed."

    ResponderEliminar
  8. Algunos comentarios:

    - Para la mayoría de usuarios/desarrolladores el cambio es totalmente transparente, muestra de ello es que la noticia ha saltado 5 meses después de la salida de RHEL-6 y en una entrevista al desarrollador que mantiene el kernel de Debian (semanas después ha salido la nota de prensa).

    - Como se apunta en varios comentarios: los parches seguirán disponibles en el portal de clientes.

    - El cambio afecta a todos los kernels de RHEL-6, incluidos los testing, en la rama de Linville se puede leer "I no longer have RHEL6 test kernels available here. I apologize for any inconvenience". En LWN se apunta a comentarios de empleados de Red Hat que muestran su descontento con el cambio.

    - Nadie pone en duda el compromiso de Red Hat con el software libre, pero en cierto modo Red Hat hace lo mismo que Oracle: ganar dinero empaquetando el trabajo de otros, insisto, no pongo en duda la intachable trayectoria y compromiso de Red Hat.

    - El camino que han tomado ha sido el menos malo para sus clientes y el que afecta directamente a Oracle, cumpliendo la GPL podrían haber tomado otros caminos peores (no sé hasta qué punto está obligada a publicar los .spec).

    - La nota de prensa no deja lugar a dudas, pero en varios comentarios leo que SuSE está haciendo lo mismo simplemente por sencillez, a priori resulta mas fácil publicar lo que tienes en Git que publicar los fuentes y "extraer" los parches.

    Mi conclusión es negativa, la solución que ha tomado Red Hat no me parece preocupante, pero si su lectura: algunos clientes ven más valor en la solución distro-clon de Oracle que en el producto original de RHEL; pensaba que estos clientes serían minoría pero ver a Red Hat mover ficha para defenderse y no pasar del tema como han venido haciendo durante años hace ver que consideran a la competencia un problema real y que afecta a su modelo de negocio.

    Espero que no se extienda al resto de paquetes, soy usuario habitual del FTP de Red Hat y me descargo SRPMs para analizarlos, comprobar parches, etc.; con este cambio para mi la distribución perdería valor y parte de su esencia. Sería un pena y muchos proyectos se verían afectados, en mi caso particular puedo hablar de un proyecto personal, PowerStack, donde parte del trabajo se basa en los .spec extraídos del FTP, si Red Hat "ofusca" su trabajo posiblemente el proyecto desaparecería.

    ResponderEliminar
  9. Jairly: Insisto, son chiquilladas. Es de notar que los de Centos, que se dedican a recompilar SRPMs de Red Hat, diga que para ellos no es ningún problema y que todo está bien. Todo el código que Red Hat pone en su distro (todo) es mandado al kernel principal de Linus, de hecho su política es de "upstream first", desarrollan nuevas cosas en primer lugar para el repositorio de Linus, y sólo después se atreven a incluirlo en el suyo. Ponen su trabajo en las manos de los demás antes que en las de sus clientes, es totalmente absurdo de acusarles de romper la GPL, en forma o espíritu. Los únicos parches que no incluyen en el kernel de Linus son los que son producto de backportear características a kernels antiguos, y esos se publican en el tarball de todas maneras.

    A los de Debian, por supuesto, les fastidia mucho no poder mirar los parches individuales de Red Hat para mantener sus propios kernels, pero eso no es problema de Red Hat. Pueden intentar pedir a Linus reestablecer las antiguas políticas de kernels estables, o coordinarse con otras distros para mantener una determinada versión de kernel durante varios años (es sorprendente que aun no lo hayan hecho). O currárselo y buscarse financiación para contratar a gente, en vez de pretender que se puede tener la misma calidad de soporte que una multinacional sin invertir un duro.

    ResponderEliminar
  10. La mayor cagada de Oracle para que no despegue su Unbreakable Linux es seguir cerrandose en banda a no certificar sus productos en otras plataformas, especialmente en lo que a virtualización se refiere, y a la par no molestarse en certificar productos de terceros fabricantes para su linux. Y eso agrabado por el hecho de que el roadmap de su producto se lo marque Red Hat y vaya siempre por detrás hace que su linux sólo se instale para BBDD Oracle y ya que casí siempre lo regalan.

    ResponderEliminar
  11. Para mi, Oracle es a Red Hat como Canonical es a Debian. Software Libre en su maxima expresion.

    ResponderEliminar
  12. @JairJy: Canonical intenta destruir a Debian?

    ResponderEliminar