Login Barrapunto
Shuttleworth invita a las distribuciones a compartir el mantenimiento de paquetes clave
Un pobrecito hablador nos pasa el artículo de Viva Linux, Mark Shuttleworth invita a las distribuciones a compartir el mantenimiento de paquetes clave: «Mark Shuttleworth tenía un sueño: congelar la versión estable de Debian "Squeeze" el pasado Diciembre para que la próxima versión con soporte extendido (LTS) de Ubuntu, y de hecho también todos sus derivados (de ambas), se beneficiaran con ese temprano lanzamiento. Pero como sabemos, finalmente no ocurrió así, con todo indicado que "Squeeze" llegará recién a mediados de este año. Sin embargo, Shuttleworth tiene ahora otra idea, más modesta pero también más realista: cada distribución tiene sus propios calendarios y prioridades, pero también pueden tener, eventualmente, algunos paquetes comunes en cada una de sus versiones (como GCC, Python, OpenOffice.org, Perl, etc.). Para esos casos, si muchas distribuciones eligen los mismos paquetes, todos podrían colaborar con su mantenimiento compartido. El plan involucraría seleccionar una versión base de varios proyectos de reconocida reputación y luego las distribuciones se comprometan soportarlas en sus futuros lanzamientos, por lo menos por 2 años o con "2 años de cadencia", como prefiere llamarla. Artículo completo en The H Open Source(en inglés)».
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Shuttleworth invita a las distribuciones a compartir el mantenimiento de paquetes clave
|
Log in/Crear cuenta
| Top
| 26 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

No puede funcionar
(Puntos:1, Inspirado)La política en lo que es válido empaquetar en cada distro es distinta, y dónde y como se despliegan las cosas, y *qué* empaquetan (cuando un fabricante de hw certifica RHEL o SLES y no lo hace con Debian, no es capricho: el kernel empaquetado es distinto, no es simplemente el que se descarga de kernel.org).
Además Shuttleworth habla de RHEL / SLES, ¿por qué no se refiere a Fedora y OpenSuSE?
Me parece una propuesta un poco ingénua viniendo de quien viene.
Software libre Unido
(Puntos:3, Interesante)( Última bitácora: Lunes, 15 Noviembre de 2010, 20:14h )
Divide y vencerás. El software libre unido, jamás será vencido, y sólo puede hacerlo si existe una compatibilidad total y absoluta en este sentido.
Creo que es lo lógico
(Puntos:3, Inspirado)( http://www-etsi2.ugr.es/alumnos/mu01/guerraSoftware.html | Última bitácora: Viernes, 03 Diciembre de 2010, 10:41h )
Sin embargo no empezaría con los paquetes priotarios, sino que escogería unos pocos paquetes simplemente importantes y que no tengan muchas dependencias a bajo nivel para empezar a probar el mantenimiento conjunto.
Usaría esa experiencia para mejorar el proceso o decidir si se debe seguir con él o no.
Gdado dice roller [sourceforge.net]
Re:Creo que es lo lógico
(Puntos:4, Inspirado)( http://www-etsi2.ugr.es/alumnos/mu01/guerraSoftware.html | Última bitácora: Viernes, 03 Diciembre de 2010, 10:41h )
El modelo del bazar se refiere al trabajo que hacen los desarrolladores de aplicaciones. Pero justamente la función de las distros es poner organizar el caos creativo de éstos.
Para seguir con la metáfora, las distros son unos señores que se pasan el día recorriendo las tiendas del bazar, comprando los mejores productos y vendiéndolos en una tienda grande bien organizada. Esto no tiene tanto que ver con el modelo de desarrollo.
Lo que se propone no es coartar el "caos creativo" sino colaborar en la tarea de "ordenar" que es el trabajo de las distros.
Por otro lado, en mi propuesta no entraba molestar a los chicos de Linux, sino escoger paquetes importantes sin ser prioritarios y que no tengan muchas dependencias, y sólo unos pocos, para ir probando el modelo.
Los desarrolladores principales de las aplicaciones o bibliotecas escogidas no tendrían por qué enterarse, aunque posiblemente les fuera más fácil incorporar los cambios si se hacen en común que los hace cada aplicación. La dependencia entre distros tampoco sería tan complicada, en las principales sería quién quisiera unirse, y las derivadas simplemente tomarían de la principal o la modificarían si lo necesitan, como hacen ya.
Gdado dice roller [sourceforge.net]
Me resulta familiar
(Puntos:1)( http://www.thewayfarer.info/ | Última bitácora: Lunes, 20 Septiembre de 2010, 15:16h )
Ah, sí: Linux Standard Base [wikipedia.org]
-- Wayfarer
La Bitácora del Caminante - www.thewayfarer.info [thewayfarer.info]
Kernel
(Puntos:2)( http://www.festuc.info/ | Última bitácora: Jueves, 14 Febrero de 2008, 17:56h )
Luego, que trabaje más y hable menos
mai güeb paix [festuc.info]
Re:Otro paso más
(Puntos:4, Divertido)( http://barrapunto.com/ | Última bitácora: Lunes, 16 Noviembre de 2009, 23:33h )
Marcos (cualquier parecido con la coincidencia es pura realidad)
Re:Difícil
(Puntos:5, Inspirado)( Última bitácora: Miércoles, 19 Mayo de 2010, 18:32h )
Linux no debe basar su seguridad en la fragmentación del sistema si no en un trabajo bien hecho. Cuanto más compatibilidad mejor a mi modo de ver y el trabajo ahorrado por un mantenimiento común se puede usar para mejorar la seguridad u otros aspectos en los que el sistema pueda flaquear.
JulioSAO xD.
Re:Otro paso más
(Puntos:1)Siento no citar fuentes (si las buscas estarán por ahi) pero mark a dicho desde el principio (tras la tercera o cuarta release que se hizo si no recuerdo mal) en las entrevistas que la idea es que la comunidad lleve el peso de ubuntu y canonical llevar un 10% o 20%
No es algo que diga ahora, ni creo que a esto se le pueda llamar quiebra súbita...
La idea era dar un empujoncito a linux en temas de usabilidad, ayudar a la comunidad -si tu te lo crees, yo, en mi caso sí me lo creo- y de paso crearse un mercado -cosa que me parece muy bien- para pillar un pellizco a largo plazo con sus soluciones propias...
Es uno de los modelos de negocio con el SL, no todo el mundo puede hacerlo. Él tenia la pasta y las ganas y si pudo. Ole sus huevos!!
VRMS: free as in beer, beeaaaach!