El Sat, 27 Mar 2010 12:58:43 +0100, carlopmart escribió:
Camaleón wrote:
(...)
todo lo que dices está muy bien, pero upstart es INCAPAZ (y lo pongo en letras grandes para remarcar, no a modo de chillido) de hacer todo eso a dia de hoy.
Entonces es que quizá los de Ubuntu han hecho algo mal en la versión que has probado. O sólo se trata de que al fin y al cabo es una versión pre (de pruebas). Yo no he leído ninguna queja sobre este sistema en las listas de Debian, donde extrañamente, la mayoría de la gente no usa la versión estable sino la de pruebas o la inestable :-? La nota de los desarrolladores la sacaron no hace mucho: http://article.gmane.org/gmane.linux.debian.devel.announce/1395
Y cuidado porque lleva en desarrollo varios años (que no es de ayer). Por eso dije que porqué no han portado el sistema de Solaris SMF, que hace todo eso y algo más y de forma muy controlada y eficiente. No hay ni había razón para hacer un upstart estando SMF. Yo he desplegado bastantes Solaris y OpenSolaris en entornos de producción bajo ese sistema y hasta la fecha ni un problema, ni un servidor clavado. Con upstart en las dos máquinas virtuales que tengo la primera ha sido en la frente .... pacemaker y corosync cascan a la primera de vuelta y por culpa del upstart y ese fantástico sistema de eventos :)) ...
Pero es que el sistema SMF también tiene sus contras, lo ponía en el artículo que envié: *** Other attempts to modernize the init system Previous attempts at replacing the init system such as the LSB specification and initNG have largely been focused on automatically determining the order of these scripts, both to ease the task of the developer, and to allow parallel start-up of scripts to reduce boot speed. Other systems such as Solaris SMF and runit were instead designed to tackle service management problems, allowing a system administrator to query the state of, and change the set of, running services. Finally, Apple's launchd solves neither of these use cases and instead provides a single daemon that replaces the traditional Unix services of init, cron, inetd, and so on. None of these systems tackled the problems we wanted to solve. We wanted an init daemon that allowed the selection and order of scripts to be determined not just by information in the scripts themselves, but by events coming from outside the init system, in particular udev. In fact, what we wanted was an init sequence driven entirely by these events and those of its own making. *** Es decir, si vas a cambiar el sistema, tienes que hacerlo con propiedad. Y si el cambio sólo te solventa el 50% del problema, entonces mejor quedarse como estás o buscar una alternativa. Creo que las otras opciones que existen como posibles sustitutos del sistema antiguo no eran viables. El kernel de Solaris no es el kernel de Linux. Ni el "target" (público objetivo) de Solaris es el de Linux.
Como nota aparte, mencionar que upstart lleva gestándose desde hace varios años. Ni uno ni dos, sino varios. No es un proyecto que haya nacido ayer (según la wikipedia se incorporó en Ubuntu en el año 2.006, y estamos a 2.010, hombre, no sé, desde luego no podremos decir que lo hayan "precipitado"...).
Pruebalo y me lo cuentas ... Pero pruebalo en un server. en el tema escritorio no entro.
Pero la versión que has probado es una ¿Alfa? Jolines, eso no es tampoco muy fiable. ¿Que problemas te daba el upstart exactamente?
Pero es que ese es el escenario. Repito: se está criticando esto por la edición server, no por la desktop. Si Microsoft hubiese hecho lo mismo en la versión 2008 o Solaris, ¿que crees que hubiesen dicho sus clientes?
Pero es que la versión LST de Ubuntu la usa todo tipo de gente y empresas, con o sin soporte de pago, con o sin certificación. No puedes pretender que como dicen el refrán "one size fits all", que se ajuste a todas las necesidades. Supongo que si han tomado la decisión de usar upstart lo van a aplicar a todas las versiones, servidoras, de escritorio o móviles, eso es normal, por una simple cuestión de facilidad de administración. No querrás que lo mantengan en una versión sí y en la otra no, eso sería un cachondeo. Si el sistema funciona, ¿por qué no usarlo?
Pero es que eso no se le pide a un servidor. A mi me dá igual que el servidor necesite 10 o 20 minutos para arrancar. Pero cuando arranque tiene que estar 100% ok.
Pero que no se trata sólo de velocidad, ya te lo he dicho. Es posible que ni quiera arranque. ¿Prefieres eso, que se quede parado intentando arrancar un servicio que da problemas y que por un sólo servicio (que puede ser además totalmente prescindible) te deje el servidor completo inhábil? :-/
Yo no creo que exista esa necesidad en entorno de servidor tal como la implanta upstart.
Quizá ahora nos cuesta verla... como antes dudábamos de la necesidad de udev, pero mira, ahora resulta que tiene su uso >:-) Ese cambio también ha aportado problemas, pero las ventajas han superado los inconvenientes.
Pues mira udev es vital cuando estás trabajando contra entornos de cabinas. A ver quien es el kamikaze que se ponde a conectar N servidores SAN contra N clientes sin disponer de una herramienta de control por uid de dispositivos.
¿Ves? Lo mismo dirás con el upstart cuando le cojas el gustillo :-)
Algo tendrá el upstart cuando SLE y RHEL están haciendo sus cosas pero con SMF ... Sintomático ¿no?.
Son otros sectores, no compares Ubuntu LST con esos dos porque no siguen el mismo camino.
Sinceramente, no estoy diciendo que el concepto de upstart sea malo, pero su implantación es no mala, es pésima. Y ojo que con 4 años de desarrollo alguien debería hacer un pensamiento de si no está haciendo las cosas mal. SMF fue desarrollado en poco tiempo (creo que no llegó a 2 años) y ahí lo tienes ...
Pero ese sistema no soluciona el problema que quieren resolver los desarrolladores de las distribuciones de linux, por eso no lo implementan. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org