Re: ¿Para cuando debian 2.2? y crítica a debian
>> Miguel Gil <mgilgar@usa.net> writes:
> ¿Para cuando se publicará la debian 2.2? ¿Para el verano?
Siguiente versión de Debian: potato. Si se llama o no se llama
Debian 2.2, no está decidido.
> -¿Xfree 3.3.x?
Sí, ya hay paquetes probándose.
> -¿kernel 2.2.x?
Err... no sé honestamente. Debian 2.1 funciona con el kernel 2.2,
pocas son las cosas que no lo hacen.
> -¿postgres 6.5?
no sé.
> -¿samba 2.0?
es probable.
> -¿kde 1.1?
si cambian su dichosa licencia, sí.
> -¿una distribución de gnome decente?
[ omitiré el comentario sobre el adjetivo ]
Ya hay paquetes para GNOME 1.0.x (creo que x = 6)
> -¿Incluirá el famoso sustituto del dselect?
¿Qué es la fijación con esto? A lo mejor, a lo mejor no. Hay varios
funcionando, así que la posibilidad existe.
> -¿mozilla?
Pregúntale a la gente de Mozilla, no a Debian. Hay paquetes para
mozilla en slink.
> -¿esta pensado para funcionar con 4mb? ¿Sigue habiendo disquetes
> de instalación para sistemas con 4mb de ram?
Entiendo que Debian 2.1 arranca en estas condiciones, no veo por qué
la situación pueda cambiar.
> -Se supone que debian 2.0 se retrasó tanto, por que había
> migrar de libc
correcto.
> había que portar debian a varias arquitecturas
`había que' es un poco exagerado.
> y también por que se necesitaba un sustituto decente al dselect y
> sin embargo no salió ningún sustituto al dselect
otra vez, `necesitaba' es un poco exagerado.
> -¿por que casi todas las versiones de debian suponen un cambio
> dramático?
es la velocidad a la cual la comunidad se mueve. En potato se ha
introducido glibc 2.1, lo cual supone un trauma menos severo que la
introducción de glibc 2.0. Además, la versión de Sparc de Debian 2.1
_ya_ utiliza glibc 2.1, así que algunas de las cosas ya han sido
probadas.
Debian es un proyecto de voluntarios que trabajan en lo que les
gusta. En el momento que deje de gustarles, dejan de trabajar. Yo
he experimentado en carne propia lo que es quemarse con un paquete:
simplemente ya no te quedan ganas de seguir trabajando. Fuera del
proyecto también he visto a algunos desarrolladores perder el gusto
por lo que hacen pues por una razón u otra deja de ser divertido (por
ejemplo, cuando la gente comienza a _demandar_ que se hagan cosas)
> ¿no se podrían sacar versiones que simplemente supusieran una
> actualización de los paquetes.
Sí, se podría. Se ha discutido varias veces en debian-devel. La
pregunta siempre es ¿a qué grupo de desarrolladores le gustará ese
proyecto?
> Un problema muy gordo en debian, es que si tienes la versión 2.0 y
> quieres la última versión de un paquete y resulta que está esta
> preparada para la debian 2.1, puede que no puedas actualizar sin
> actualizar toda la debian.
Perdón, pero pongo en duda eso. Sí un paquete depende de algo, debe
declarar esa dependencia. Si no la declara, es un `bug.' Por
ejemplo, wmaker depende de `debianutils (>= 1.6)'. Esa dependencia
está allí por un motivo, y seguirá estando allí mientras el paquete
exista o yo cambie algo para eliminarla.
Ahora, si te refieres a los casos en los cuales cambiar una
biblioteca implica cambiar más de un paquete, bueno, eso es
diferente. Nosotros no controlamos lo que la gente de más arriba
hace. Si los desarrolladores de tal o cual biblioteca compartida son
suficientemente tercos como para cambiar la interface binaria sin
cambiar el nombre de la biblioteca, bueno, hay que tratar de
encontrar una solución, pero nos enfrentamos a un predicamento: ¿cuál
es la forma técnicamente correcta de hacer las cosas sin romper la
compatibilidad binaria con otras distribuciones?
> Para mi lo ideal sería comprar una distribución una vez y poco a
> poco ir bajandome las actualizaciones de los paquetes que mas uso,
En la medida que existan programadores que gustan de explorar nuevos
territorios eso no va a ocurrir. "Se me ocurrió esto, hace tal y
cual cosa" "Nos gusta, ¡lo vamos a usar!" Ni modo, a recompilar
programas se ha dicho.
> -¿Para cuando se podrá debian de acuerdo con el resto de
> distribuciones en un sistema de paquetes común, en una
> organización del sistema de ficheros comúm, etc?
Otra vez: ¿cuál es la solución ténicamente correcta para un problema
particular?
Muchos piensan que el formato .deb _es_ la solución correcta. Nadie
va a dejar botado el formato de paquetes así como así.
> ¿Tan dificil es? ¿Es que realmente las diferencias merecen la pena?
> Se supone que somos distintos a windows, en windows cambias de
> windows 3.1 a windows 95 y te dejan de funcionar las cosas, a este
> paso creo que lo mismo nos pasará al pasar de debian a redhat, de
> redhat a suse, etc.
La diversidad es riqueza. Mientras existan opciones, Linux será un
proyecto viable. En el momento que las opciones no existan, Linux
deja de existir como lo conocemos. Utilizar un formato de paquetes
común no es tan inconcebible, pero tampoco es tan fácil como suena.
Marcelo
Reply to: