Barrapunto

Precioso comentario. Tendencioso y desinformado, pero precioso.

No explicas qué problemas has tenido con lvm2. A lo mejor si hubieses hecho una instalación Debian from scratch [google.com] no los hubieses tenido. Es lo que tienen los frontends de instalación, y es que hay que desarrollarlos, corregir bugs, etc... mientras que una instalación manual con una guía completita da al usuario AVANZADO la posibilidad de actuar ante algún error o caso especial.

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.

Para ejecutar GNOME no necesitas un servidor X local. Con tener un servidor X basta, y en algunos montajes es remoto. 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.

Por cierto, el tema de las XWindow (que no tienen porque ser "xfree86") en Debian está en proceso de cambio (en ramas unstable y "experimental") por el cambio de licencia. Seguramente se terminará por usar unos paquetes mezcla de los diferentes proyectos. Y el nombre elegido para el METAPAQUETE tiene su sentido en una distribución que ya ha tenido sus más y sus menos con nombres de paquetes cambiantes, etc...

¿Problemas de dependencias de paquetes? ¿Ah, que dices que es en unstable?. Porque stable o testing no probaste, supongo. Se quiere tener lo que acaba de salir del horno el mismo día, y encima que no de ni un solo problema. 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)... porque yo si, y me tocó bastante más los cojones.

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, los que queremos usar *software libre* y no "KDE" o "GNOME" o porque suenan bién o tienen los iconos más bonitos. 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.

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.

¿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. 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.

A todo esto falta nombrar los problemas con compilaciones (que en servidores hace una gracia, pero una gracia... algo bárbaro oiga), a lo ridículo y chapucero de la necesidad de un revdep-rebuild MANUAL, lo anárquico de los nombres de los useflags, a lo que se ha tardado en poder automatizar el uso useflags y buildflags por paquete en una distro donde SIEMPRE se compila, a los problemas arrastrados por cambios de nombres de paquetes (vcron vs cron initscripts), etc...

De tus conclusiones:
1- La primera es una impresión tuya, y bastante sesgada. Aporta algo al sistema de ports, pero tampoco ninguna barbaridad. Tiene ideas buenas y muy aprovechables puesto que dispone (o dispuso) de un buen nucleo de desarrolladores. Pero tiene importantes problemas de base.
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.
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.
4- Efectivamente, y lo hace cada día en la rama unstable. En la estable no hace falta puesto que cuando llegan a ella estan perfectamente limpios, cosa que nunca pasa en Gentoo.

Los dos últimos párrafos suena a pitorreo. ¿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?)?

Con el año nuevo, sigue sin existir un "concepto de mantenimiento fácil", así en general, sin concretar lo más mínimo. ¿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.

Cada cosa tiene su uso. A unas personas les interesa unas características, a otras personas otras. 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.

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