On Thu, 22 Apr 1999, Marcelo E. Magallon wrote: >>> Miguel Gil <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] **** *************** WEB: Humor Inform�tico Hispano ********************** * URL: http://www.geocities.com/SiliconValley/Lakes/2062/index.html * ### Powered by Linux (debian 2.0) ###
