Este artículo fue enviado por Rubén González vía correo electrónico, por lo tanto no es de mi autoría, solamente le hago el favor de publicarlo
Opinión: Debian se pierde entre sus ramas
Este es mi primer artículo en DesdeLinux, y me gustaría comenzar haciendo algo poco usual en el mundo GNU/Linux: atizar a tu propia distribución. Podría hablar de otras distribuciones que de hecho me han ido peor (en serio, estamos en 2014 y hay distribuciones que simplemente no arrancan), ¿pero que voy a ganar con ello salvo polémica estéril?
Prefiero hablar sobre la distribución que voy a seguir utilizando con la esperanza de que la comunidad se haga eco y llegue a los desarrolladores de Debian; muy probablemente no vaya a suceder, pero no puedo quedarme quieto y simplemente tragar con decisiones que no me parecen acertadas.
El modelo de Debian siempre (o casi, hay gente para todo) ha sido elogiado: divide en tres sus ramas de trabajo, estable, en pruebas e inestable, y deja que el usuario elija atendiendo a la fórmula de que contra más atrás se esté, menos errores tendrá el sistema pero también se dispondrá de aplicaciones más antiguas.
Con las ramas en pruebas e inestable Debian va puliendo su próxima versión estable, corrigiendo los errores reportados por sus usuarios. Creo que esto merece un respeto: Red Hat y SuSE no tienen reparos en crear sus distribuciones experimentales y hacer que la “comunidad” y el “open source” arreglen sus distribuciones comerciales. Debian lo integra en su sistema, advirtiendo de qué va el asunto.
Esas tres ramas existen junto con otra llamada experimental, cuya existencia no acabo de ver demasiado clara, pero al parecer sirve de puente a aplicaciones que se actualizan con asiduidad para poder ser instalado en una rama inferior a la inestable. Yo por ejemplo lo he visto en Audacious, donde se podía acceder a la nueva versión desde un sistema en pruebas ya que las dependencias eran las mismas. Xfce 4.10 también estuvo un tiempo en experimental antes y durante la congelación de Wheezy.
Estamos ya con cuatro ramas. Para la versión Wheezy el equipo de Debian decidió incluir los backports en los repositorios oficiales. Los paquetes provenientes de backports van en gran mayoría bien, pero no siempre es así. Yo por ejemplo solo tengo un ordenador, un portátil con tecnología NVidia Optimus, y con las actualizaciones 3.13 y 3.14 del kernel los drivers privativos de NVidia (instalados desde el repositorio oficial de Debian) no funcionan. Un error ya reportado y aparentemente solventado, pero que aún sigue vigente.
Irónicamente, yendo mal va mejor que con nouveau dejando que el kernel maneje las dos gráficas (no sé si es una regresión del kernel o un problema de Debian con el nuevo kernel, pero antes de 3.13 la cosa iba bien). Y Debian Jessie no reconoce mi tarjeta inalámbrica, luego estoy atrapado en este error.
El problema puede venir en la forma de manejar los backports: no siempre son los desarrolladores oficiales de Debian quienes hacen los backports, sino para paquetes no tan importantes son terceros que, con la ayuda de patrocinadores que prueban los paquetes, suben el nuevo contenido a los repositorios. Esto hace que no sea un desarrollador oficial quién responde por los errores en backports, y por lo tanto en ocasiones eso es un descontrol.
Por ejemplo, VLC en backports lleva con un problema de dependencias desde febrero. Y yo lo reporté. ¿Pero quién lo va a solucionar? Por ahora nadie: el mantenedor de VLC no entra en las listas de correo de backports y no estoy seguro de que el usuario que mandó el paquete ni su patrocinador lo haga.
Hay un problema mucho más peligroso en este proceso: los backports no tienen actualizaciones de seguridad, al no estar dentro de las ramas que vigila el equipo de seguridad de Debian. Mirad el ejemplo de Qemu: esta vulnerabilidad en el sistema de hace casi dos meses fue resuelta en todas las ramas principales de Debian, pero en el changelog del paquete en backports no se habla de cambios desde hace tres meses (de hecho no los ha habido: yo tenía ese paquete y no se actualizó hasta que decidí desinstalarlo hace unos días).
También ha pasado con, atención, el kernel. De hecho Debian ofrece el kernel 3.12 sin que el changelog muestre una actualización de seguridad para éste error. Entramos aquí en un punto peliagudo: Debian ofrece en su repositorio oficial paquetes potencialmente peligrosos y al ser en su mayoría open-source, en la red también esta publicada cuál es su vulnerabilidad. Estamos hablando de Debian, no de una distro de medio pelo.
A esto hay que añadir que los backports no se actualizan por medios normales. Las posibilidades son hacer apt-pinning con los paquetes instalados desde backports o decirle manualmente que quieres actualizar esos paquetes desde backports, poniendo en ambos cada paquete individualmente (tanto los que quieres como las dependencias actualizadas… si es que las sabes). Otro método es hacer un archivo de preferencias con todos los paquetes apuntando a backports directamente. Ninguna es una opción buena, la verdad. Y la wiki de Debian promete esclarecer el asunto, pero yo no veo la respuesta…
Con los backports son cinco ramas. Pero hay más. Queda aún oldstable, que ahora además es lts (long time support), pero ojo: los paquetes de lts siguen un sistema parecido a los backports, siendo en ocasiones terceras personas quienes se encargan de ellos y no los desarrolladores que trabajan en estable, en pruebas e inestable. Y también hay backports para oldstable. Son tres ramas más para un total de ocho.
Pues bien, con la probable llegada de Debian Jessie el año que viene, Debian llegará a las ¡¡¡10!!! ramas. En teoría estos serán los repositorios oficiales: squeeze, squeeze-backports, squeeze-lts, oldstable (Wheezy), oldstable-backports, estable (Jessie), estable-backports, en pruebas, inestable y experimental. Y es aquí donde creo que se han pasado: Debian quiere ser un sistema universal y soporta once arquitecturas (las que aparecen en Distrowatch: amd64, armel, armhf, i386, mips, mipsel, powerpc y s390x, más hurd-i386, kfreebsd-i386 y kfreebsd-amd64), imaginaros lo que debe ser para un desarrollador mantener un paquete en tres o seis ramas y once arquitecturas.
Es una locura cuando tienes más de 20000 paquetes (tirando ya a 30000) en tus repositorios que deben funcionar entre sí. Y es imposible lograr un producto tan bien pulido como cuando había menos ramas oficiales. Sin ir más lejos yo he tenido varios problemas con Xfce en Wheezy, como comenté con mi pésimo inglés aquí, mientras que Squeeze no me dio problemas en el breve tiempo que lo utilicé (bien es cierto que Squeeze no sufrió la era del nuevo paradigma del escritorio…).
También ayuda a que los desarrolladores cada vez estén más hartos de los problemas: yo hasta hoy he reportado como diez bugs y han pasado de mí como… diez veces. Quizá lo más irritante fue cuando el equipo de seguridad decidió darle prioridad a la rama en pruebas y quitó el soporte para gstreamer de la rama estable. A día de hoy no puedo reproducir vídeos con html5 en Iceweasel, de un día a otro, por una actualización de seguridad que nada tenía que ver con gstreamer. Y volvieron a pasar de mí, por partida doble.
Y aquí estoy. No soy nadie para pedirle cosas a Debian, pero me permitiré este consejo: no se puede abarcar tanto. Quieres ser un sistema universal: bien, mantén todas las arquitecturas que puedas, pero elimina ramas entonces. Si quieres competir con las distribuciones de largo recorrido, no saques versiones estables cada dos años, sino cada cuatro. Y quién quiera aplicaciones nuevas y Debian, que instale la rama en pruebas.
Pero bueno, ya digo que no estoy en el día a día de Debian, ni tampoco colaboro activamente, así que supongo que no puedo opinar rotundamente.
PD: No pretendo que me recomienden distribuciones a las que cambiar; insisto, para mí Debian es la mejor, creo que con eso digo bastante. Seguiré utilizando GNU/ Linux hasta que FreeBSD soporte NVidia Optimus, si lo hace algún día. Ya veremos si es un viaje rápido de ida y vuelta…
La entrada Opinión: Debian se pierde entre sus ramas aparece primero en Desde Linux.
Continúar leyendo...
Opinión: Debian se pierde entre sus ramas
Este es mi primer artículo en DesdeLinux, y me gustaría comenzar haciendo algo poco usual en el mundo GNU/Linux: atizar a tu propia distribución. Podría hablar de otras distribuciones que de hecho me han ido peor (en serio, estamos en 2014 y hay distribuciones que simplemente no arrancan), ¿pero que voy a ganar con ello salvo polémica estéril?
Prefiero hablar sobre la distribución que voy a seguir utilizando con la esperanza de que la comunidad se haga eco y llegue a los desarrolladores de Debian; muy probablemente no vaya a suceder, pero no puedo quedarme quieto y simplemente tragar con decisiones que no me parecen acertadas.
El modelo de Debian siempre (o casi, hay gente para todo) ha sido elogiado: divide en tres sus ramas de trabajo, estable, en pruebas e inestable, y deja que el usuario elija atendiendo a la fórmula de que contra más atrás se esté, menos errores tendrá el sistema pero también se dispondrá de aplicaciones más antiguas.
Con las ramas en pruebas e inestable Debian va puliendo su próxima versión estable, corrigiendo los errores reportados por sus usuarios. Creo que esto merece un respeto: Red Hat y SuSE no tienen reparos en crear sus distribuciones experimentales y hacer que la “comunidad” y el “open source” arreglen sus distribuciones comerciales. Debian lo integra en su sistema, advirtiendo de qué va el asunto.
Esas tres ramas existen junto con otra llamada experimental, cuya existencia no acabo de ver demasiado clara, pero al parecer sirve de puente a aplicaciones que se actualizan con asiduidad para poder ser instalado en una rama inferior a la inestable. Yo por ejemplo lo he visto en Audacious, donde se podía acceder a la nueva versión desde un sistema en pruebas ya que las dependencias eran las mismas. Xfce 4.10 también estuvo un tiempo en experimental antes y durante la congelación de Wheezy.
Estamos ya con cuatro ramas. Para la versión Wheezy el equipo de Debian decidió incluir los backports en los repositorios oficiales. Los paquetes provenientes de backports van en gran mayoría bien, pero no siempre es así. Yo por ejemplo solo tengo un ordenador, un portátil con tecnología NVidia Optimus, y con las actualizaciones 3.13 y 3.14 del kernel los drivers privativos de NVidia (instalados desde el repositorio oficial de Debian) no funcionan. Un error ya reportado y aparentemente solventado, pero que aún sigue vigente.
Irónicamente, yendo mal va mejor que con nouveau dejando que el kernel maneje las dos gráficas (no sé si es una regresión del kernel o un problema de Debian con el nuevo kernel, pero antes de 3.13 la cosa iba bien). Y Debian Jessie no reconoce mi tarjeta inalámbrica, luego estoy atrapado en este error.
El problema puede venir en la forma de manejar los backports: no siempre son los desarrolladores oficiales de Debian quienes hacen los backports, sino para paquetes no tan importantes son terceros que, con la ayuda de patrocinadores que prueban los paquetes, suben el nuevo contenido a los repositorios. Esto hace que no sea un desarrollador oficial quién responde por los errores en backports, y por lo tanto en ocasiones eso es un descontrol.
Por ejemplo, VLC en backports lleva con un problema de dependencias desde febrero. Y yo lo reporté. ¿Pero quién lo va a solucionar? Por ahora nadie: el mantenedor de VLC no entra en las listas de correo de backports y no estoy seguro de que el usuario que mandó el paquete ni su patrocinador lo haga.
Hay un problema mucho más peligroso en este proceso: los backports no tienen actualizaciones de seguridad, al no estar dentro de las ramas que vigila el equipo de seguridad de Debian. Mirad el ejemplo de Qemu: esta vulnerabilidad en el sistema de hace casi dos meses fue resuelta en todas las ramas principales de Debian, pero en el changelog del paquete en backports no se habla de cambios desde hace tres meses (de hecho no los ha habido: yo tenía ese paquete y no se actualizó hasta que decidí desinstalarlo hace unos días).
También ha pasado con, atención, el kernel. De hecho Debian ofrece el kernel 3.12 sin que el changelog muestre una actualización de seguridad para éste error. Entramos aquí en un punto peliagudo: Debian ofrece en su repositorio oficial paquetes potencialmente peligrosos y al ser en su mayoría open-source, en la red también esta publicada cuál es su vulnerabilidad. Estamos hablando de Debian, no de una distro de medio pelo.
A esto hay que añadir que los backports no se actualizan por medios normales. Las posibilidades son hacer apt-pinning con los paquetes instalados desde backports o decirle manualmente que quieres actualizar esos paquetes desde backports, poniendo en ambos cada paquete individualmente (tanto los que quieres como las dependencias actualizadas… si es que las sabes). Otro método es hacer un archivo de preferencias con todos los paquetes apuntando a backports directamente. Ninguna es una opción buena, la verdad. Y la wiki de Debian promete esclarecer el asunto, pero yo no veo la respuesta…
Con los backports son cinco ramas. Pero hay más. Queda aún oldstable, que ahora además es lts (long time support), pero ojo: los paquetes de lts siguen un sistema parecido a los backports, siendo en ocasiones terceras personas quienes se encargan de ellos y no los desarrolladores que trabajan en estable, en pruebas e inestable. Y también hay backports para oldstable. Son tres ramas más para un total de ocho.
Pues bien, con la probable llegada de Debian Jessie el año que viene, Debian llegará a las ¡¡¡10!!! ramas. En teoría estos serán los repositorios oficiales: squeeze, squeeze-backports, squeeze-lts, oldstable (Wheezy), oldstable-backports, estable (Jessie), estable-backports, en pruebas, inestable y experimental. Y es aquí donde creo que se han pasado: Debian quiere ser un sistema universal y soporta once arquitecturas (las que aparecen en Distrowatch: amd64, armel, armhf, i386, mips, mipsel, powerpc y s390x, más hurd-i386, kfreebsd-i386 y kfreebsd-amd64), imaginaros lo que debe ser para un desarrollador mantener un paquete en tres o seis ramas y once arquitecturas.
Es una locura cuando tienes más de 20000 paquetes (tirando ya a 30000) en tus repositorios que deben funcionar entre sí. Y es imposible lograr un producto tan bien pulido como cuando había menos ramas oficiales. Sin ir más lejos yo he tenido varios problemas con Xfce en Wheezy, como comenté con mi pésimo inglés aquí, mientras que Squeeze no me dio problemas en el breve tiempo que lo utilicé (bien es cierto que Squeeze no sufrió la era del nuevo paradigma del escritorio…).
También ayuda a que los desarrolladores cada vez estén más hartos de los problemas: yo hasta hoy he reportado como diez bugs y han pasado de mí como… diez veces. Quizá lo más irritante fue cuando el equipo de seguridad decidió darle prioridad a la rama en pruebas y quitó el soporte para gstreamer de la rama estable. A día de hoy no puedo reproducir vídeos con html5 en Iceweasel, de un día a otro, por una actualización de seguridad que nada tenía que ver con gstreamer. Y volvieron a pasar de mí, por partida doble.
Y aquí estoy. No soy nadie para pedirle cosas a Debian, pero me permitiré este consejo: no se puede abarcar tanto. Quieres ser un sistema universal: bien, mantén todas las arquitecturas que puedas, pero elimina ramas entonces. Si quieres competir con las distribuciones de largo recorrido, no saques versiones estables cada dos años, sino cada cuatro. Y quién quiera aplicaciones nuevas y Debian, que instale la rama en pruebas.
Pero bueno, ya digo que no estoy en el día a día de Debian, ni tampoco colaboro activamente, así que supongo que no puedo opinar rotundamente.
PD: No pretendo que me recomienden distribuciones a las que cambiar; insisto, para mí Debian es la mejor, creo que con eso digo bastante. Seguiré utilizando GNU/ Linux hasta que FreeBSD soporte NVidia Optimus, si lo hace algún día. Ya veremos si es un viaje rápido de ida y vuelta…
La entrada Opinión: Debian se pierde entre sus ramas aparece primero en Desde Linux.
Continúar leyendo...