por
pobrecito hablador
el Lunes, 07 Febrero de 2005, 15:35h
(#440435)
Precioso comentario. Tendencioso y desinformado, pero precioso.
He intentado que sólo se quedara en "precioso". Pero es la realidad de mi único día en Debian desde hace bastante tiempo.
No explicas qué problemas has tenido con lvm2.
No los explico porque no los consideré dignos de resaltar usando un d-i beta.
Arranque feo, que funciona en todas las arquitecturas, y con todas las tarjetas gráficas. Que en las tuyas funcione el bootsplash me parece perfecto. Pero no es en todas.
¿Quién ha dicho nada de bootsplash? Yo no gasto de eso. El arranque es feo, la información se "escupe" sin mucho orden. Tras ejecutar el script de GDM, se ejecuta el de XDM para decirme que ya está GDM... El "sistema" para activar o desactivar servicios es horroroso. No sé, échale un vistazo a otros sistemas, quizás esta vez cojas a la primera de qué estoy hablando.
Para ejecutar GNOME no necesitas un servidor X local. Con tener un servidor X basta, y en algunos montajes es remoto.
Pues vuélvete a leer lo que puse. Me pareció interesante esto y que en cambio metiera decenas de paquetes a su gusto para otras cosas que sí que no pedí. Pero bueno, es que soy un poco exigente. :)
Claro, que si en lugar de meterte a trapo en el apt-get en la instalación hubieses seleccionado que querías un desktop, otro gallo te hubiese cantado. Cosas de pasarse de listo.
Claro, y otros tantos paquetes entrando sin saber para qué. Le pido a mi sistema un control suficiente como para poder seleccionar qué es lo que quiero y qué lo que no. Está muy bien que puedas optar por no querer este control. Está muy mal que no puedas optar por quererlo. Supongo que pedir eso en Debian es a tus ojos pasarse de listo. Bueno, una razón más por la que sigo con Gentoo.
Se quiere tener lo que acaba de salir del horno el mismo día, y encima que no de ni un solo problema.
No. Lo que digo y si quieres te repito, es que llevo 2 años en Gentoo ~x86, y en un único día en Debian unstable ya he tenido tantos problemas como en Gentoo ~x86 en toooodooo ese tiempo. Mientras mi mayor problema en Gentoo ha sido el FALLO de compilaciones (nada de dependencias de las que no se sabe nada ni similares) que en cuestión de 5 minutos tengo solucionado gracias a los foros (gotcha!), en Debian he tenido el disgusto de probar varios males endémicos de su sistema de paquetes de forma bastante condensada. Y ese post siempre es comparando Gentoo inestable con Debian inestable. Curiosamente en Gentoo es bastante más que posible esperar no tener errores al actualizar. No suelo rezar para que no ocurra nada grave, no hay necesidad.
Bueno, supongo también que en Gentoo "ESTABLE" nunca te has encontrado con problemas de compilación por falta de librerías que no estaban en las dependencias (sarcasmo)
También uso la estable en servidores (sí, sí, en servidores! soy un hereje! peor aún que los que usan mdk!! :). Nunca me he encontrado ese problema. Supongo que yo debo tener una flor en el culo.
Por cierto, ¿módulo binario de nvidia? ¿Hablamos del propietario? ¿Miraste el primer punto del Contrato Social de Debian? ¿Tiene Gentoo algo parecido? Hay gente a la que SI nos importa
Sí. Sí. Sí [gentoo.org]. Me parece muy bien, pero no viene al caso.
Lo mismo para JRE (aunque hay utilidades para crear paquetes a partir de los de SUN que dan bastantes menos problemas que los ebuilds correspondientes.
Sí, en especial bastante menos problemas. Yo hago "emerge eclipse-sdk" y se instala eclipse con su JRE si es necesario. En debian sid (hablamos de sid, ni idea de cómo será en las demás) no vale un "apt-get install eclipse-sdk". Y curiosamente, yo sí dije sí a software non-free. Supongo que tu concepto de "problemas" no es el mismo que el mío.
Referencias a paquetes que no pueden encontrarse. Veamos... ¿me pasó eso alguna vez en Gentoo "ESTABLE"? Pues mira, si. Bueno, supongo que tal como maneja portage los metapackages es normal.
Me gustaría ver algún ejemplo de que eso haya ocurrido en la rama estable. De hecho, ya es difícil que ocurra en la inestable, nunca me ha ocurrido a mí, será suerte (veo que contrariamente a lo que yo creía, a mí me sobra). Ya me dirás "cómo" maneja portage los metapaquetes. Yo te doy mi opinión: de forma elegante, efectiva y muy práctica. Y escribir ebuilds es una tarea harto sencilla.
¿Errores de sintaxis en scripts de paquetes? ¿Pero tu has estado usando Gentoo? Porque yo juraría que eso que estuve usando se llamaba Gentoo, y tenía unos scriptillos llamados ebuilds que petaban cuales escopetas de feria.
¿No lo niegas? :) Yo sí te niego que eso que estuvieses usando fuese Gentoo. Al menos tal como lo describes. Yo he probado y he dado evidencias. Haz tú lo mismo y cuéntanos.
Ah, y encima de vez en cuando los de webapp se llevaban el primer DocumentRoot de Apache por delante, así por la jeta. Algo GRANDE para un servidor web, si señor.
Esa es una aplicación que tiene que ver con unos pocos paquetes muy característicos, y que yo curiosamente uso en mis servidores. Una vez más: never happened to me. Suerte que tengo, oye. Sin embargo, lo dicho, aterrizo en Debian un día y el destino se ceba conmigo.
A todo esto falta nombrar los problemas con compilaciones (que en servidores hace una gracia, pero una gracia... algo bárbaro oiga)
Yo no compilo en mis servidores, y aún así rara vez falla una compilación en la estable (muy rara vez, tanto que ni siquiera recuerdo un ejemplo que dar). Creo que andas un tanto despistado de más sobre esto de "compilar", y luego, ya que haces mención a lo de llevar decenas de servidores, te doy unas pistas.
a lo ridículo y chapucero de la necesidad de un revdep-rebuild MANUAL
Esto es cierto (salvo la parte de chapucero y ridículo). Y consiste en que una vez hay una actualización de paquetes que actualizan bibliotecas compartidas de las que hacen uso otros paquetes, hay que reinstalarlos para enlazarlos debidamente. Curiosamente, esto solo es necesario para algunos paquetes realmente especiales cuando cambian de versión de forma *significativa*. Y aún así, los señores de Gentoo indican claramente lo que hacer en estos casos en cuanto se termina de instalar el paquete. Es un punto mejorable, y no suele haber problema alguno.
Sin embargo, en Debian hay decenas de cosas que los paquetes te informan que hay que hacer manualmente para que las cosas funcionen bien, y no hablo de actualizaciones traumáticas porque aún tengo que DURAR para verlas (aunque por supuesto, todo el mundo conoce historias de terror en actualizaciones de KDE y similares). Pero de lo que viví hace ya felizmente un par de añitos, la cosa no es siquiera comparable a Gentoo.
a lo que se ha tardado en poder automatizar el uso useflags y buildflags por paquete en una distro donde SIEMPRE se compila
Sí, bastante. Otros simplemente quitábamos o añadíamos las flags que no queríamos al instalar. De todas formas, eso ya no es así, ¿verdad? Quizás como argumento se te pueda contestar que Debian ha tardado muchísimo más en tener un sistema como apt. Y eso es bastante más grave, ¿no?
a los problemas arrastrados por cambios de nombres de paquetes (vcron vs cron initscripts)
¿Lo qué? Desde que uso Gentoo (desde finales del 2002) el initscript para cron ha sido el correspondiente al cron que instalabas. Y vcron pasó a llamarse vixie-cron, siendo la actualización tan simple como un update normal y corriente en el que vcron se desinstalaba y un paquete nuevo, vixie-cron se instalaba. Sin embargo, gracias a algo muy bonito llamado CONFIG_PROTECT, el antiguo script seguía ahí funcionando igual que siempre. Doloroso, sin duda.
1) [...] Pero tiene importantes problemas de base.
Y a pesar de ello y de que yo tengo la suerte de no encontrarme con esos problemas, puedo usar eclipse. :)
2- La única razón por la que se me ocurre que alguien prefiera Gentoo habiéndola usado el tiempo suficiente es por las compilaciones de KDE, Gnome y compañía para su propio procesador. Y de hecho, es la "ventaja" más publicitada.
Lo que indica sin lugar a dudas, como cualquier usuario de Gentoo mínimamente experimentado sabrá, que el tiempo que estuviste con Gentoo no fue suficiente para entender siquiera cuál es el objetivo ni los beneficios de esa distro. Esa es la "ventaja" con la que se quedan los que no han conocido Gentoo y que algunos ya hemos explicado mil veces. En la propia página de Gentoo se habla sobre cuáles son algunas de sus ventajas. La que mencionas para mí como he dicho en el anterior post es incluso más una desventaja.
3- Cuando lleves varias decenas de máquinas con Gentoo, durante un periodo de dos años, vuelves y afirmas otra vez lo mismo sin que se te caiga la cara de vergüenza.
Pues de momento no va a ser posible, porque llevo solamente 9, dos escritorios en casa, cinco servidores, un portátil y una máquina Gentoo Hardened en la que hago mis pruebas y a la vez sirve los paquetes i686 para los cinco servidores. ¿Compilar en mis servidores? Pues hombre, hacerlo por separado debe de ser un poco de masoquismo.
De momento llevamos con esos servidores unos 18 meses y aún no se me ha caído la cara de vergüenza. Es más, estoy dando gracias todavía de haber podido salir de los infiernos de RPM y DEB.
¿Tu has vidido la "migración" (actualizaciones mal hechas a tutiplen) de versiones de perl, python, mysql, portage, glibc? ¿Tu has usado algún paquete de los webapp? ¿Tu has intentado actualizar un sistema tras semanas sin actualizarlo? ¿Tu has actualizado las versiones de desktops? ¿Y encima afirmas que lo has hecho en la rama inestable (¿~x86?)?
Sí (pero en mi caso bien hechas, mi suerte, que me persigue una vez más, estoy por jugar una quiniela). Sí. Sí (emerge -Duk world). Sí. Sí. Para algo tienen que dar 2 años con Gentoo en cualquier sitio en el que un Linux puede funcionar. Y sin embargo, qué agradecido sigo a los chicos de Gentoo.
¿Mantenimiento DE QUE? ¿De desktop? Entonces puede que un sistema maduro como Debian pueda ser complicado de aprender si solo se quiere tener "a la última" un triste desktop. ¿Servidores? Pruébalo con Gentoo, y no mueras en el intento.
¿De qué? De lo que quieras. He probado casi de todo en esta vida. Llevo más de 2 años con Gentoo en un triste desktop. Algo más de año y medio con Gentoo en varios servidores que realmente funcionan como queremos y están para lo que los usuarios quieren, y con los cuales intentamos aprovechar las tecnologías que ahora se usan, no las de hace 4 años. Y... aún no he muerto en el intento. Creo que tras una década de experiencia en linux difícilmente voy ahora a morir en el intento. ;)
Leyendo las policies de cada distribución uno se puede hacer a la idea de si es la que le conviene, sin necesidad de ir a trollear a los foros sin el más mínimo criterio.
Para eso te he puesto el enlace al contrato social de Gentoo, y para eso te recomiendo que hagas como yo y nos cuentes la historia desde el otro lado. Yo no elijo Gentoo sólo porque sus características me interesen. Lo que a mí me interesa, y es algo que todos los sistemas deberían proveer, es facilidad de mantenimiento sin tener que diezmar mis posibilidades. Lo siento, Debian no cumple con eso. De hecho esto es como la mayoría de cosas en este mundo: cuando te acostumbras a la comodidad, difícil es volver atrás.
Y tras una década probando una infinidad de distribuciones, de las que sólo me duraron significativamente Debian 1.3-2.2 y Mandrake (sí, montones de debianitas con la cuarta parte de conocimientos que yo me llamaban "novato" por usar Mandrake), conocí Gentoo y supe casi al instante que ésta iba a ser LA distribución.
El arranque es feo, la información se "escupe" sin mucho orden. Eso es, a la vez, una ventaja y un inconveniente. He visto varios servicios arrancar, dar un error fatal, y el script de arranque de gentoo darlo como OK. Si los scripts de "adaptación" de mensajes no están perfectamente hechos, y desinforman al usuario, casi que es mejor que éste esté atento a lo que pasa por si hay algún problema.
Tras ejecutar el script de GDM, se ejecuta el de XDM para decirme que ya está GDM... Tienes razón, existen sistemas más elegantes. Por ejemplo, el alternatives de debian podría usarse ya que es para estos casos. Pero añadirlo a un script de arranque de la distribución en si, allí de fijo aunque no hayas instalado kdm gdm o xdm no me parece elegante. No creo que sea este el sitio que le corresponde.
Pues vuélvete a leer lo que puse. Me pareció interesante esto y que en cambio metiera decenas de paquetes a su gusto para otras cosas que sí que no pedí. Pero bueno, es que soy un poco exigente.:) Si eso te pareció interesante, vamos acercando posiciones. Lo del mutt y el exim tiene su explicación: apt y los scripts de mantenimiento envian mensajes a root con reports, errores, etc... por lo que necesitan un MTA y un MUA para que el administrador los lea. Desde luego, lo segundo es discutible. Y para lo primero, hay que decir que gentoo por defecto te endosa el ssmtp, que me parece mejor elección que exim pero que al fin y al cabo tb es un MTA "capado" o MDA. Yo al terminar siempre substituyo exim por postfix, pero imagino que tb se podrá hacer por ssmtp.
Sí. Sí. Sí [gentoo.org]. Me parece muy bien, pero no viene al caso. Hombre, creo que venir viene. La "metadata" para instalar el jre es libre, vale, pero el paquete en si no. Es un interfaz libre para instalar un software no libre. SUN/IBM JRE sigue siendo cerrado, por más que el ebuild sea libre.
Sí, en especial bastante menos problemas. Yo hago "emerge eclipse-sdk" y se instala eclipse con su JRE si es necesario. En debian sid (hablamos de sid, ni idea de cómo será en las demás) no vale un "apt-get install eclipse-sdk". ¿A lo mejor estaría bién que en debian hubiera un paquete que te bajara el jre, te lo empaquetase, y te lo instalase por su cara bonita? Puede, es discutible, pero razonable. Sin embargo, creo recordar que antes Debian traía el jdk empaquetado, y no se si tras unas discusiones en debian-legal el paquete "empaquetador" se bajaba él solito el tar de la web oficial como hace el de las fuentes de windows. Al final, tras unas discusiones en debian-legal el paquete se lo baja el usuario a mano desde la web de SUN, porque me parece que es lo que te deja hacer la licencia. Eso significa que mientras SUN no abra la boca perfecto, pero que cuando lo haga puede que se acabe esto de bajarla automáticamente.
Eso si, parece que en Gentoo alguien se olvidó de que hay aplicaciones que necesitan la version 1.3 (por ejemplo, pasarelas de pago), y borran los ebuilds viejos sin más. Y creo recordar que no era cosa de un simple sed. Menos mal que aun conservaba el ebuild viejo porai.
Y escribir ebuilds es una tarea harto sencilla. Ahí está una de las grandes ventajas y a la vez grandes inconvenientes de esta distribución. Escribir un ebuild y que funcione en el ordenador de uno mismo es tarea harto sencilla. Que funcione en el de todo el mundo, es muy diferente. Los paquetes de debian son difíciles de contruir y que te los acepten porque hay unas policies (políticas) muy estrictas, que aseguran que el paquete es consistente con la distribución. Mira los bugreport (y el comentario de Donny Davies) de dos párrafos más abajo. Además, para pasar de experimental a unstable, de ahí a testing, y de ahí a stable, el paquete debe demostrarse estable para todo el mundo en todas las arquitecturas. ¿Que eso lleva más tiempo y más recursos? Podríamos discutir si el tiempo que pierden todos los usuarios buscando en los foros por fallos de compilación en Gentoo es realmente menor que el
Re:Gentooer debianizando por un día
(Puntos:0)He intentado que sólo se quedara en "precioso". Pero es la realidad de mi único día en Debian desde hace bastante tiempo.
No explicas qué problemas has tenido con lvm2.
No los explico porque no los consideré dignos de resaltar usando un d-i beta.
Arranque feo, que funciona en todas las arquitecturas, y con todas las tarjetas gráficas. Que en las tuyas funcione el bootsplash me parece perfecto. Pero no es en todas.
¿Quién ha dicho nada de bootsplash? Yo no gasto de eso. El arranque es feo, la información se "escupe" sin mucho orden. Tras ejecutar el script de GDM, se ejecuta el de XDM para decirme que ya está GDM... El "sistema" para activar o desactivar servicios es horroroso. No sé, échale un vistazo a otros sistemas, quizás esta vez cojas a la primera de qué estoy hablando.
Para ejecutar GNOME no necesitas un servidor X local. Con tener un servidor X basta, y en algunos montajes es remoto.
Pues vuélvete a leer lo que puse. Me pareció interesante esto y que en cambio metiera decenas de paquetes a su gusto para otras cosas que sí que no pedí. Pero bueno, es que soy un poco exigente. :)
Claro, que si en lugar de meterte a trapo en el apt-get en la instalación hubieses seleccionado que querías un desktop, otro gallo te hubiese cantado. Cosas de pasarse de listo.
Claro, y otros tantos paquetes entrando sin saber para qué. Le pido a mi sistema un control suficiente como para poder seleccionar qué es lo que quiero y qué lo que no. Está muy bien que puedas optar por no querer este control. Está muy mal que no puedas optar por quererlo. Supongo que pedir eso en Debian es a tus ojos pasarse de listo. Bueno, una razón más por la que sigo con Gentoo.
Se quiere tener lo que acaba de salir del horno el mismo día, y encima que no de ni un solo problema.
No. Lo que digo y si quieres te repito, es que llevo 2 años en Gentoo ~x86, y en un único día en Debian unstable ya he tenido tantos problemas como en Gentoo ~x86 en toooodooo ese tiempo. Mientras mi mayor problema en Gentoo ha sido el FALLO de compilaciones (nada de dependencias de las que no se sabe nada ni similares) que en cuestión de 5 minutos tengo solucionado gracias a los foros (gotcha!), en Debian he tenido el disgusto de probar varios males endémicos de su sistema de paquetes de forma bastante condensada. Y ese post siempre es comparando Gentoo inestable con Debian inestable. Curiosamente en Gentoo es bastante más que posible esperar no tener errores al actualizar. No suelo rezar para que no ocurra nada grave, no hay necesidad.
Bueno, supongo también que en Gentoo "ESTABLE" nunca te has encontrado con problemas de compilación por falta de librerías que no estaban en las dependencias (sarcasmo)
También uso la estable en servidores (sí, sí, en servidores! soy un hereje! peor aún que los que usan mdk!! :). Nunca me he encontrado ese problema. Supongo que yo debo tener una flor en el culo.
Por cierto, ¿módulo binario de nvidia? ¿Hablamos del propietario? ¿Miraste el primer punto del Contrato Social de Debian? ¿Tiene Gentoo algo parecido? Hay gente a la que SI nos importa
Sí. Sí. Sí [gentoo.org]. Me parece muy bien, pero no viene al caso.
Lo mismo para JRE (aunque hay utilidades para crear paquetes a partir de los de SUN que dan bastantes menos problemas que los ebuilds correspondientes.
Sí, en especial bastante menos problemas. Yo hago "emerge eclipse-sdk" y se instala eclipse con su JRE si es necesario. En debian sid (hablamos de sid, ni idea de cómo será en las demás) no vale un "apt-get install eclipse-sdk". Y curiosamente, yo sí dije sí a software non-free. Supongo que tu concepto de "problemas" no es el mismo que el mío.
Referencias a paquetes que no pueden encontrarse. Veamos... ¿me pasó eso alguna vez en Gentoo "ESTABLE"? Pues mira, si. Bueno, supongo que tal como maneja portage los metapackages es normal.
Me gustaría ver algún ejemplo de que eso haya ocurrido en la rama estable. De hecho, ya es difícil que ocurra en la inestable, nunca me ha ocurrido a mí, será suerte (veo que contrariamente a lo que yo creía, a mí me sobra). Ya me dirás "cómo" maneja portage los metapaquetes. Yo te doy mi opinión: de forma elegante, efectiva y muy práctica. Y escribir ebuilds es una tarea harto sencilla.
¿Errores de sintaxis en scripts de paquetes? ¿Pero tu has estado usando Gentoo? Porque yo juraría que eso que estuve usando se llamaba Gentoo, y tenía unos scriptillos llamados ebuilds que petaban cuales escopetas de feria.
¿No lo niegas? :) Yo sí te niego que eso que estuvieses usando fuese Gentoo. Al menos tal como lo describes. Yo he probado y he dado evidencias. Haz tú lo mismo y cuéntanos.
Ah, y encima de vez en cuando los de webapp se llevaban el primer DocumentRoot de Apache por delante, así por la jeta. Algo GRANDE para un servidor web, si señor.
Esa es una aplicación que tiene que ver con unos pocos paquetes muy característicos, y que yo curiosamente uso en mis servidores. Una vez más: never happened to me. Suerte que tengo, oye. Sin embargo, lo dicho, aterrizo en Debian un día y el destino se ceba conmigo.
A todo esto falta nombrar los problemas con compilaciones (que en servidores hace una gracia, pero una gracia... algo bárbaro oiga)
Yo no compilo en mis servidores, y aún así rara vez falla una compilación en la estable (muy rara vez, tanto que ni siquiera recuerdo un ejemplo que dar). Creo que andas un tanto despistado de más sobre esto de "compilar", y luego, ya que haces mención a lo de llevar decenas de servidores, te doy unas pistas.
a lo ridículo y chapucero de la necesidad de un revdep-rebuild MANUAL
Esto es cierto (salvo la parte de chapucero y ridículo). Y consiste en que una vez hay una actualización de paquetes que actualizan bibliotecas compartidas de las que hacen uso otros paquetes, hay que reinstalarlos para enlazarlos debidamente. Curiosamente, esto solo es necesario para algunos paquetes realmente especiales cuando cambian de versión de forma *significativa*. Y aún así, los señores de Gentoo indican claramente lo que hacer en estos casos en cuanto se termina de instalar el paquete. Es un punto mejorable, y no suele haber problema alguno.
Sin embargo, en Debian hay decenas de cosas que los paquetes te informan que hay que hacer manualmente para que las cosas funcionen bien, y no hablo de actualizaciones traumáticas porque aún tengo que DURAR para verlas (aunque por supuesto, todo el mundo conoce historias de terror en actualizaciones de KDE y similares). Pero de lo que viví hace ya felizmente un par de añitos, la cosa no es siquiera comparable a Gentoo.
a lo que se ha tardado en poder automatizar el uso useflags y buildflags por paquete en una distro donde SIEMPRE se compila
Sí, bastante. Otros simplemente quitábamos o añadíamos las flags que no queríamos al instalar. De todas formas, eso ya no es así, ¿verdad? Quizás como argumento se te pueda contestar que Debian ha tardado muchísimo más en tener un sistema como apt. Y eso es bastante más grave, ¿no?
a los problemas arrastrados por cambios de nombres de paquetes (vcron vs cron initscripts)
¿Lo qué? Desde que uso Gentoo (desde finales del 2002) el initscript para cron ha sido el correspondiente al cron que instalabas. Y vcron pasó a llamarse vixie-cron, siendo la actualización tan simple como un update normal y corriente en el que vcron se desinstalaba y un paquete nuevo, vixie-cron se instalaba. Sin embargo, gracias a algo muy bonito llamado CONFIG_PROTECT, el antiguo script seguía ahí funcionando igual que siempre. Doloroso, sin duda.
1) [...] Pero tiene importantes problemas de base.
Y a pesar de ello y de que yo tengo la suerte de no encontrarme con esos problemas, puedo usar eclipse. :)
2- La única razón por la que se me ocurre que alguien prefiera Gentoo habiéndola usado el tiempo suficiente es por las compilaciones de KDE, Gnome y compañía para su propio procesador. Y de hecho, es la "ventaja" más publicitada.
Lo que indica sin lugar a dudas, como cualquier usuario de Gentoo mínimamente experimentado sabrá, que el tiempo que estuviste con Gentoo no fue suficiente para entender siquiera cuál es el objetivo ni los beneficios de esa distro. Esa es la "ventaja" con la que se quedan los que no han conocido Gentoo y que algunos ya hemos explicado mil veces. En la propia página de Gentoo se habla sobre cuáles son algunas de sus ventajas. La que mencionas para mí como he dicho en el anterior post es incluso más una desventaja.
3- Cuando lleves varias decenas de máquinas con Gentoo, durante un periodo de dos años, vuelves y afirmas otra vez lo mismo sin que se te caiga la cara de vergüenza.
Pues de momento no va a ser posible, porque llevo solamente 9, dos escritorios en casa, cinco servidores, un portátil y una máquina Gentoo Hardened en la que hago mis pruebas y a la vez sirve los paquetes i686 para los cinco servidores. ¿Compilar en mis servidores? Pues hombre, hacerlo por separado debe de ser un poco de masoquismo.
De momento llevamos con esos servidores unos 18 meses y aún no se me ha caído la cara de vergüenza. Es más, estoy dando gracias todavía de haber podido salir de los infiernos de RPM y DEB.
¿Tu has vidido la "migración" (actualizaciones mal hechas a tutiplen) de versiones de perl, python, mysql, portage, glibc? ¿Tu has usado algún paquete de los webapp? ¿Tu has intentado actualizar un sistema tras semanas sin actualizarlo? ¿Tu has actualizado las versiones de desktops? ¿Y encima afirmas que lo has hecho en la rama inestable (¿~x86?)?
Sí (pero en mi caso bien hechas, mi suerte, que me persigue una vez más, estoy por jugar una quiniela). Sí. Sí (emerge -Duk world). Sí. Sí. Para algo tienen que dar 2 años con Gentoo en cualquier sitio en el que un Linux puede funcionar. Y sin embargo, qué agradecido sigo a los chicos de Gentoo.
¿Mantenimiento DE QUE? ¿De desktop? Entonces puede que un sistema maduro como Debian pueda ser complicado de aprender si solo se quiere tener "a la última" un triste desktop. ¿Servidores? Pruébalo con Gentoo, y no mueras en el intento.
¿De qué? De lo que quieras. He probado casi de todo en esta vida. Llevo más de 2 años con Gentoo en un triste desktop. Algo más de año y medio con Gentoo en varios servidores que realmente funcionan como queremos y están para lo que los usuarios quieren, y con los cuales intentamos aprovechar las tecnologías que ahora se usan, no las de hace 4 años. Y... aún no he muerto en el intento. Creo que tras una década de experiencia en linux difícilmente voy ahora a morir en el intento. ;)
Leyendo las policies de cada distribución uno se puede hacer a la idea de si es la que le conviene, sin necesidad de ir a trollear a los foros sin el más mínimo criterio.
Para eso te he puesto el enlace al contrato social de Gentoo, y para eso te recomiendo que hagas como yo y nos cuentes la historia desde el otro lado. Yo no elijo Gentoo sólo porque sus características me interesen. Lo que a mí me interesa, y es algo que todos los sistemas deberían proveer, es facilidad de mantenimiento sin tener que diezmar mis posibilidades. Lo siento, Debian no cumple con eso. De hecho esto es como la mayoría de cosas en este mundo: cuando te acostumbras a la comodidad, difícil es volver atrás.
Y tras una década probando una infinidad de distribuciones, de las que sólo me duraron significativamente Debian 1.3-2.2 y Mandrake (sí, montones de debianitas con la cuarta parte de conocimientos que yo me llamaban "novato" por usar Mandrake), conocí Gentoo y supe casi al instante que ésta iba a ser LA distribución.
Re:Gentooer debianizando por un día
(Puntos:2)Eso es, a la vez, una ventaja y un inconveniente. He visto varios servicios arrancar, dar un error fatal, y el script de arranque de gentoo darlo como OK. Si los scripts de "adaptación" de mensajes no están perfectamente hechos, y desinforman al usuario, casi que es mejor que éste esté atento a lo que pasa por si hay algún problema.
Tras ejecutar el script de GDM, se ejecuta el de XDM para decirme que ya está GDM...
Tienes razón, existen sistemas más elegantes. Por ejemplo, el alternatives de debian podría usarse ya que es para estos casos. Pero añadirlo a un script de arranque de la distribución en si, allí de fijo aunque no hayas instalado kdm gdm o xdm no me parece elegante. No creo que sea este el sitio que le corresponde.
Pues vuélvete a leer lo que puse. Me pareció interesante esto y que en cambio metiera decenas de paquetes a su gusto para otras cosas que sí que no pedí. Pero bueno, es que soy un poco exigente.
Si eso te pareció interesante, vamos acercando posiciones. Lo del mutt y el exim tiene su explicación: apt y los scripts de mantenimiento envian mensajes a root con reports, errores, etc... por lo que necesitan un MTA y un MUA para que el administrador los lea. Desde luego, lo segundo es discutible. Y para lo primero, hay que decir que gentoo por defecto te endosa el ssmtp, que me parece mejor elección que exim pero que al fin y al cabo tb es un MTA "capado" o MDA. Yo al terminar siempre substituyo exim por postfix, pero imagino que tb se podrá hacer por ssmtp.
Sí. Sí. Sí [gentoo.org]. Me parece muy bien, pero no viene al caso.
Hombre, creo que venir viene. La "metadata" para instalar el jre es libre, vale, pero el paquete en si no. Es un interfaz libre para instalar un software no libre. SUN/IBM JRE sigue siendo cerrado, por más que el ebuild sea libre.
Sí, en especial bastante menos problemas. Yo hago "emerge eclipse-sdk" y se instala eclipse con su JRE si es necesario. En debian sid (hablamos de sid, ni idea de cómo será en las demás) no vale un "apt-get install eclipse-sdk".
¿A lo mejor estaría bién que en debian hubiera un paquete que te bajara el jre, te lo empaquetase, y te lo instalase por su cara bonita? Puede, es discutible, pero razonable. Sin embargo, creo recordar que antes Debian traía el jdk empaquetado, y no se si tras unas discusiones en debian-legal el paquete "empaquetador" se bajaba él solito el tar de la web oficial como hace el de las fuentes de windows. Al final, tras unas discusiones en debian-legal el paquete se lo baja el usuario a mano desde la web de SUN, porque me parece que es lo que te deja hacer la licencia. Eso significa que mientras SUN no abra la boca perfecto, pero que cuando lo haga puede que se acabe esto de bajarla automáticamente.
Eso si, parece que en Gentoo alguien se olvidó de que hay aplicaciones que necesitan la version 1.3 (por ejemplo, pasarelas de pago), y borran los ebuilds viejos sin más. Y creo recordar que no era cosa de un simple sed. Menos mal que aun conservaba el ebuild viejo porai.
Y escribir ebuilds es una tarea harto sencilla.
Ahí está una de las grandes ventajas y a la vez grandes inconvenientes de esta distribución. Escribir un ebuild y que funcione en el ordenador de uno mismo es tarea harto sencilla. Que funcione en el de todo el mundo, es muy diferente. Los paquetes de debian son difíciles de contruir y que te los acepten porque hay unas policies (políticas) muy estrictas, que aseguran que el paquete es consistente con la distribución. Mira los bugreport (y el comentario de Donny Davies) de dos párrafos más abajo. Además, para pasar de experimental a unstable, de ahí a testing, y de ahí a stable, el paquete debe demostrarse estable para todo el mundo en todas las arquitecturas. ¿Que eso lleva más tiempo y más recursos? Podríamos discutir si el tiempo que pierden todos los usuarios buscando en los foros por fallos de compilación en Gentoo es realmente menor que el