Barrapunto

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 que pierden los mantenedores de Debian en QA.

¿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.
Niégalo, pero es lo que estaba usando. Yo no lo probé un dia, lo probé durante dos años, y lo sigo "sufriendo" aun. Al principio Gentoo parecía fantástico, tenía toneladas de "novedades". A la larga me dí cuenta de que muchas "novedades" estaban demasiado verdes para producción, debían ser pulidas, o directamente eliminadas. Es, en definitiva, una distribución donde les encanta probar cosas nuevas contínuamente sin largas discusiones... con todo lo que ello conlleva.

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.
¿Qué aplicación? Entre los paquetes del grupo webapp hace tiempo hubo una moda de copiar tal cual una linea con un grep, un sed... y ninguna red de seguridad (un triste head -n1) o comprobación ("existe el docroot?").
Squirrelmail's 1.4.0-r1 ebuild access violation and possible data losing [gentoo.org]
phpmyadmin 2.4.0 ebuild trashes documentroot [gentoo.org]
Discussion: webapp.eclass [gentoo.org]
Como ves, usé Gentoo. Más comentarios acerca de la calidad de los ebuild más abajo.

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.
Si no compilas en los servidores, interpreto que en todos tienes los mismos flags. Y lo de que "rara vez falla una compilación en la estable", será suerte tuya. O que no usábamos los mismos paquetes. O que actualizas cada día y "parece" que hay pocos errores estadísticamente. O que tienes la combinación de useflags y buildflags perfecta (aunque para estos últimos el -O2 tenía que ser una apuesta segura...). No ando tan despistado sobre esto de compilar como puedas pensar. He compilado antes y despues de mi estancia en Gentoo, y durante la estancia en Gentoo siempre terminé pudiendo compilar cualquier cosa. Después de instalar y/o actualizar librerías (¿dependencias, para qué os quiero?) o tocar el ebuild en si.

Vamos, que para tener un árbol para compilar en él y si la cosa ha funcionado subirlo a todas las máquinas idénticas entre si va muy bién. Para desktop, soportable (si compila bién, puedes disfrutar la última beta de KDE solo unas horas de compilación después de que haya salido). Pero para otros usos, no lo veo yo muy adecuado.

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.
Gracias por la explicación, pero nada nuevo. Usé Gentoo, y había compilado otras veces antes que Gentoo (que no se lo inventaron ellos), y sé perfectamente el porqué de esto. También sé que algunos paquetes que parecen funcionar bién con las librerías nuevas, en realidad no funcionan "del todo bién", y cuando llaman a una función que ha cambiado petan. Pero eso requiere horas de testeo, betatesters, etc... y en Gentoo esto no existe. Cambian el nombre del ebuild, compilan, y si parece que la cosa funciona lo suben. Mira, justito igual que debian unstable. Bastante diferente que testing. MUY diferente que la stable.

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.
Que precisamente son los paquetes más necesarios y de los que suele depender el resto del sistema. Y en Gentoo no tienen ningún reparo en actualizar dichos paquetes cada cuanto sale una nueva versión, faltaría más. Como ya he comentado, no hace falta que sea tan "significativa". Que no rebiente solo intentar ejecutarlo, no significa que el programa no vaya a petar al usar alguna función de alguna librería actualizada desde su compilación.
Lo de avisarte al finalizar la instalación de un paquete es muy bonito, pero como se compile otro paquete detrás de este olvídate de ver qué decía. Si has tenido suerte y estabas mirando tontamente la compilación podrás ir a mirar al ebuild qué decía, sinó ni te enterarás de que tenías que hacer algo.

Sin embargo, en Debian hay decenas de cosas que los paquetes te informan que hay que hacer manualmente para que las cosas funcionen bien
Exacto. Cuando el mantenedor del paquete decide que algo NO puede decidirse automáticamente, en lugar de hacer scripts de medio pelo que en cualquier configuración no muy estándar se lleven algo por delante o dejen algo sin funcionar, te pide que lo hagas tu que sabes como tienes el sistema. Eso si: te lo dice y espera que confirmes, no queda enterrado en 10.000 lineas de compilación.

Otros simplemente quitábamos o añadíamos las flags que no queríamos al instalar
Si, vaya, paquete por paquete; un sistema cómodo, rápido, y que minimiza los errores humanos.

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?
La mayor parte de apt lleva años desarrollado, y las cosas nuevas no se añaden porque a un desarrollador le parezca buena idea, sinó que son fruto de largas discusiones y análisis hasta llegar a un mínimo de consenso. Es un sistema maduro, y lejos de ser algo grave es una ventaja.

Y vcron pasó a llamarse vixie-cron
Y el initscript pasó de llamarse "vcron" a "cron" a secas. Un ejemplo tonto más. Menos mal que aunque no hubiese podido añadir el nuevo script por conflicto durante el depscan.sh, el viejo servía. Si llega a cambiar el nombre del ejecutable también, NO hubiese arrancado ningún cron. Y eso en algunos sistemas es problemático.

Y a pesar de ello y de que yo tengo la suerte de no encontrarme con esos problemas, puedo usar eclipse. :)
Si tus necesidades son usar eclipse, perfecto para ti. Gentoo tiene su utilidad para según qué tareas, esto no vamos a negarlo. Pero no es la navaja suiza que muchos intentan "vender".

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.
Estuve el tiempo suficiente para saber que esa supuesta optimización era una gran farsa/ilusión, aunque por suerte no me importaba lo más mínimo. Vi otros beneficios, algunos de los cuales consideré como buenas ideas que debían madurar, otros como prescindibles, otros como grandes errores. No es que lo *hayais*, es que lo *hemos* explicado mil veces. Yo también estuve mi tiempo feliz en Gentoo. Admiré sus novedades. Pero al final conseguí ver qué había ganado y qué había perdido, y decidí que no me valía la pena (a mi) seguir con él. Simplemente eso.
Debian tiene sus cosas odiosas. Por ejemplo, su estructura en ocasiones es demasiado rígida. A veces uno piensa que se pasan tres pueblos con la demora de la entrada de paquetes desde unstable a testing, o de experimental a unstable (aunque suelen haber buenas razones si uno se molesta en informarse). Pero esas "desventajas" no consiguen cambiar la balanza de lado.

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.
Ya he comentado lo que opino de ese contrato social. Pero las policies no se limitan al contrato social. En Debian por lo menos van mucho más allá. Definen todo el sistema, y los mantenedores de paquetes se deben ajustar a ellas para mantener el sistema consistente. En mi opinión, Gentoo falla demasiado en este punto.

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.
Pues a mi me pasa eso mismo con Gentoo. A lo mejor no tenemos las mismas preferencias. Aunque para ciertas cosas Debian te toque mucho más la moral (creación de paquetes DEB vs ebuilds, dependencias en ocasiones demasiado estrictas, tener que recurrir a dselect en alguna ocasión...), prefiero eso y tener el sistema funcionando y actualizando sin problemas, que no saber si en una actualización me quedaré con el sistema malfuncionando durante las horas que se pase recompilando fuentes.
Para mi la comodidad viene de la seguridad que da esa complejidad. No complejidad de uso (ya me gustaría que actualizarla siempre fuera darle a un botón), sinó complejidad estructural que asegura un cierto control y consistencia en los cambios.

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.
Lo único que sé de Mandrake es que aparte de incluir asistentes que solo recientemente han comenzado a funcionar sin problemas, algunos desarrolladores del kernel (y, concretamente, de clustering) la usan. Por algo será. Supongo que como toda distribución que se precie (tampoco es que haya muchas), si dejas a un lado las ayudas específicamente diseñadas para principiantes, puedes conseguir muy buenos resultados. Eso si, a ensuciarse las manos.
Yo cuando empezé a usar Gentoo también pensé que sería la distribución. También lo pensaba el que me inició. Ahora yo he vuelto a Debian y él se ha ido a SUSE. Como ves, no es la más adecuada para todo el mundo. Sin embargo, también soy lo sufientemente abierto como para darme cuenta de que Debian tampoco es LA distribución, por más que por el momento sea la mejor opción para mi.

En Gentoo eso tampoco ocurre y sin embargo sigo teniendo el paquete instalado. El JRE de Sun debes bajarlo tú de acuerdo con la licencia. De todas formas, para eso hay otros JRE como blackdown sin esas limitaciones.
Perfecto, o sea que tampoco es TAN automático. Vamos, que en Debian son más comandos que en Gentoo, pero en ninguna de las dos es inmediato. Eso si, en cada problema que uno tiene con Gentoo (y por más suerte que tu tengas, se tienen bastantes), directo a los foros. Pero si no se sabe hacer algo en Debian, se le cae a uno el cielo encima. ¿Probaste a hacer una pequeña búsqueda en Google? : http://serios.net/content/debian/java.php No se, ¿tampoco es tan difícil no?

En las fechas de los enlaces yo no tenía aún webapp en mis servidores. Es más, dudo mucho que pasara de ~x86 hasta unos cuantos meses después (quizás hubiesen sido menos de aceptar esa oferta y ayudarlos en ello :), y desde luego nada en este mundo te haría presagiar que fuera una versión estable. ¿O sí?
En esas fechas, habían webapps. Si hubiesen funcionado como debían, habrían estado bién para actualizar phpmyadmins, squirrelmails, y webapps populares similares. Y digo "como debían" porque no estaban en "~x86", sinó que estaban como estables.
Lo que no había aun era el plugin webapp de portage, y cada "developer" que hacía un ebuild lo hacía como le daba la gana. Uno en concreto "ideó" una linea la mar de mona para adivinar el DocumentRoot de Apache, y los demás la copiaron. El único problema es que esa linea estaba mal hecha con ganas, y el resultado era que portage cagaba las aplicaciones en el primer DocumentRoot, cargándose en el proceso lo que ya hubiera. Esa linea continuó en decenas de paquetes durante un laaaaargo tiempo. Nadie se preocupó de los efectos que producía : la instalación de la mayoría se podía cepillar tu DocumentRoot a la mínima de cambio. Y eso, amigo mio, no es que no te arranque el XMMS. Eso es *muy grave*.
Si esa es la tónica y modus operandi de Gentoo (y por lo que he observado, lo es), prefiero la rigidez y largas discusiones técnicas y filosóficas de Debian. ¿Que puede que ahora Gentoo haya cambiado? Puede, pero entonces la estan haciendo menos flexible, y más rígida. Si ésta es la dirección, entonces en Debian "ya están ahí".

Intuyo que tu experiencia con la distribución se limita bastante a servidores, pero desde luego que si estabas con webapp por aquellas fechas no creo que fuera para nada serio.
Principalmente a servidores, si. Y al contrario de lo que tu te apresuras a afirmar, sí era algo serio. Aunque depende de lo que entendamos por serio, claro. El servidor de web y correo de una empresa, para ellos lo es, creeme. Aunque supongo que para ti si no es un cluster no es serio. En otra ocasión tocó los servidores de un banco, y te aseguro que a la mínima ojeada que le hagan a Gentoo, ésta no entra ni por asomo. Pero es que ni con una versión congelada. No vale para proyectos serios, porque *no es seria*.
Por otro lado, también lo he usado en varios desktops "estables" (solo 6, eso si), y los resultados tampoco han sido nada del otro mundo. Especialmente molestas son las compilaciones de KDE a medias por errores en las dependencias. ¿Solución?: ir a los foros, instalar tal paquete, actualizar tal otro, y volver a probar. Y si no funciona quitar tal useflag. Se respira seriedad por todos sitios.
Eso no significa que mi experiencia con "Gentoo" en el desktop sea mínima, significa que las bestialidades que le he hecho a Gentoo y Debian en un par de desktops *míos* no creo que sean representativas de las distribuciones en si. Es el uso normal de las mismas en lo que me baso para "juzgarlas".

Es más, están planeando hacer una rama estable congelada al estilo de woody (aunque no tengo mucha fe en que haya suficientes recursos para ello).
Yo no tengo la más mínima fe en ello. No hay la organización suficiente para conseguir una rama estable. Puede que para la parte más importante que llevan los maintainers del "core", si; pero para eso