Re: ¿Para cuando debian 2.2? y crítica a debian
On Thu, 22 Apr 1999, Marcelo E. Magallon wrote:
>>> 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.
¿Para el verano?
> > -¿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 ]
Me refiero a que hasta hace bien poco no
había paquetes debian de gnome y por tanto no lo podías
probar de una forma fácil. Con kde no paso eso y los
usuarios pudimos disfrutar de versiones alpha lo que
seguramente ayudo mucho a los de kde a descubrir errores.
> 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.
Ya lo comenté en el mensaje, cuando tienes que elegir entre
1500 paquetes y además tienes el interface del dselect, sea
hace muy pesado elegir los programas. ¿Por que no utilizar
el mismo sistema que utiliza la propia debian para elegir los
modulos?
> > -¿mozilla?
>
> Pregúntale a la gente de Mozilla, no a Debian. Hay paquetes para
> mozilla en slink.
Visto así, no podría preguntar por ningún paquete ni por
nada: Todo esta relacionado y nada o casi nada es solamente
especifico de debian.
> > -¿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.
Bueno en la 2.0 se necesitaba crear un conjunto de disquetes
especiales. Crear esos disquetes cuesta un tiempo y debian
podría haber decidido aprovechar el tiempo en otra cosa.
> > -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.
Eso se decía. Al menos eso me decían a mi.
> > 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)
Es comprensible.
> > ¿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?
Bueno, también es cierto que es muy poco divertido para un
desarrollador, el que el paquete que en una versión
funcionaba en la siguiente ya no lo haga y que lo tenga que
volver a preparar. El mantenimiento es aburrido y si ya lo
es cuando el programador original cambia la versión, mas aún
debe serlo si es debido a otras razones.
> > 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?
El problema es dificil de resolver y veo que la culpa
principal no es de debian.
> > 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.
¿Pero cuales son esas nuevos territorios que hacen que una
distribución mas fácil de actualizar no sea posible? En
principio no veo tanto inconviente.
Otro asunto, es que también se pueden adaptar las nuevas
ideas para que no impliquen tantos cambios. También es un
ejercicio intelectual bastante interesante.
> > -¿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í.
Claro que no, pero es un problema. Se supone que el software
libre hace que se pueden juntar proyectos parecidos en uno
solo sea mas fácil y que se pueda aprovechar fácilmente lo
que han hecho otros. Sin embargo vemos como hay dos grandes sistemas de
paquetes y los dos libres, vemos como hay dos grandes
proyectos de escritorios, etc. Eso desde luego estimula mas
a los desarrolladores, ya que quieren hacerlo mejor que el
otro, pero va en contra del usuario, que o no sabe cual
elegir o tiene que elegir los dos. A veces creo que algunos
proyectos se inician de una manera infantil o que a veces
algunos tienen que iniciar proyectos por que los del
proyecto competidor de forma infantil no han aceptado
las nuevas ideas de los que se han ido. Esto en si que ya
digo que es infantil, lo es todavía mas si consideramos que
lo que hacen se supone que lo hacen para unos usuarios
particulares, se supone que el objetivo es que el usuario se
sienta satisfecho, aunque en muchas ocasiones eso es lo que
menos les importa realmente.
> > ¿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.
La diversidad es riqueza, cuando es diversidad de verdad. De
nada me valen dos sistemas de paquetes distintos pero que
realmente hacen lo mismo (no me conozco internamente rpm y
deb y no se si realmente son iguales o no, lo que digo es
simplemente un ejemplo).
No se lo dificil que puede ser técnicamente que solo haya un
sistema de paquetes, pero desde luego politicamente es bien
fácil y desde mi punto de vista, creo que es que querríamos
todos.
Saludos.
:-)
--
**** Miguel Gil ** Dirección correo electrónico: mgilgar@usa.net ****
*************** WEB: Humor Informático Hispano **********************
* URL: http://www.geocities.com/SiliconValley/Lakes/2062/index.html *
### Powered by Linux (debian 2.0) ###
Reply to: