La idea era usar la interfaz de arranque de Red Hat, Plymouth, (mucho más vistosa que la actual) a partir de la siguiente versión de la distribución, pero parece que hay cambio de planes: el objetivo es que para la versión 10.04 el sistema arranque en menos de 10 segundos, con lo que Plymouth no tendría tiempo ni siquiera de iniciarse.
#1: No hay por que dejar de cargar nada: puede paralelizarse.
El problema es que el levantamiento de unos servicios puede requerir que otros ya esten iniciados, por lo que seria preciso establecer primero un (relativamente) complejo sistema de dependencias para que el lanzamiento de cada uno se realice cuando todos los servicios sobre los que necesite apoyarse esten ya disponibles.
De hecho, creo que ya existe una alternativa al init clásico (secuencial) que paraleliza la carga. Nunca lo he probado, pero puedo imaginarme los problemas que (aunque salvables) debe tener porque ahora, ahora mismo, el orden de carga de los servicios es lineal y puede decidirse de forma aleatoria y/o mas o menos experimental.
En una carga concurrente programada, todos los servicios esperarian a que sus prerrequisitos estuvieran satisfechos. El problema se como medimos eso: ¿por el fin de la ejecución de su script de carga?.
En muchos casos funcionaria, pero en otros no porque sus scripts de carga terminan antes de que el servicio esté realmente disponible. Probablemente para ahorrar tiempo y porque se espera que para cuando sean necesarios ya habrán terminado de inicializarse.
Un sistema de carga en paralelo requeriria que todos éstos scripts se modificaran para no terminar hasta que el servicio asociado esté plenamente disponible (lo que supondria una ralentización importante para el init clásico --aunque ésto puede trampearse chequeando la versión del init--).
Al final, la cuestion es: mucho trabajo para poco rendimiento. Pero siempre llega el momento que alguien se pica y por sus cojones lo hace. Y si no, valgan de ejemplo las aalib y el bb (o el aaxine).
Comento sin leerme la noticia porque con esta calor me sobrecalentaría el cerebro leyendo inglés.
Los arranques se pueden acelerar, pero a ver qué servicios no cargan en el inicio. Hay servicios que tardan el doble en arrancarse con el SO funcionando
Ubuntu no tiene ningun brillo. Si quieren lograr arranque rapido y eficaz prueben distribuciones de verdad como Gentoo, Slackware o Archlinux. ¿Para que forzar que ubuntu inicie rapido si no está hecho para eso?
#6 Por qué depender del script? Si se está ejecutando sobre un sistema que paraleliza el init de cada uno de los servicios, sería tan sencillo como establecer un lístener para cada una de esas dependencias. A día de hoy gestores de dependencias hacen algo parecido.
Java permite hacer cosas con interfaces como Observable y demás zarandajas. Si Java puede hacer cosas así, c y c++, tendrán artilugios para implementar listeners y observadores sobre los PROCESOS del servicio, que no sobre el script de inicio.
Además, desde la propia arquitectura se podría saber cuando un servicio está listo y cuando no, y siendo el propio sistema el que sepa cuando las dependencias de cada uno de los servicios están satisfechas.
#6 por cierto, estaba rebuscando una cosa para lo que comentas al final sobre el workaround para saber qué tipo de init se está ejecutando.
Decirte que realmente no es una ñapa eh? Es un patrón de diseño muy común que se llama Estrategia ( http://en.wikipedia.org/wiki/Strategy_pattern ) y consiste en decidir un funcionamiento u otro en función (qué mal suena coño) de algún parámetro u estado en tiempo de ejecución.
En este caso tendrías una estrategia de carga líneal y otra de carga paralela. No sería tan descabellado.
#10: No he dicho que sea descabellado. De hecho a mi también me gusta la idea.
Sólo digo que supone mucho trabajo porque no hay que cambiar sólo el init, sino todos los procesos procesos de carga de todos los servicios existentes (que no son sólo los que puedas tener instalados tu en tu sistema ni mucho menos).
El mayor problema aquí está en la migración y en que todo el mundo se adapte al nuevo "standard" (y para ello primero tiene que llegar a serlo) mas que en la própia implementación.
Pero con el tiempo lo veremos. Seguro. Solo que hay que tener en cuenta que no va a ser mañana
Comentarios
#1: No hay por que dejar de cargar nada: puede paralelizarse.
El problema es que el levantamiento de unos servicios puede requerir que otros ya esten iniciados, por lo que seria preciso establecer primero un (relativamente) complejo sistema de dependencias para que el lanzamiento de cada uno se realice cuando todos los servicios sobre los que necesite apoyarse esten ya disponibles.
De hecho, creo que ya existe una alternativa al init clásico (secuencial) que paraleliza la carga. Nunca lo he probado, pero puedo imaginarme los problemas que (aunque salvables) debe tener porque ahora, ahora mismo, el orden de carga de los servicios es lineal y puede decidirse de forma aleatoria y/o mas o menos experimental.
En una carga concurrente programada, todos los servicios esperarian a que sus prerrequisitos estuvieran satisfechos. El problema se como medimos eso: ¿por el fin de la ejecución de su script de carga?.
En muchos casos funcionaria, pero en otros no porque sus scripts de carga terminan antes de que el servicio esté realmente disponible. Probablemente para ahorrar tiempo y porque se espera que para cuando sean necesarios ya habrán terminado de inicializarse.
Un sistema de carga en paralelo requeriria que todos éstos scripts se modificaran para no terminar hasta que el servicio asociado esté plenamente disponible (lo que supondria una ralentización importante para el init clásico --aunque ésto puede trampearse chequeando la versión del init--).
Al final, la cuestion es: mucho trabajo para poco rendimiento. Pero siempre llega el momento que alguien se pica y por sus cojones lo hace. Y si no, valgan de ejemplo las aalib y el bb (o el aaxine).
#6 mis respetos
Lo importante es aguantar procesos en multitarea no arrancar antes.
#3 No veo por qué ambas cosas son incompatibles.
En menos de "10.04"!! Bah, entonces el Windows "7" es mejor!!
Comento sin leerme la noticia porque con esta calor me sobrecalentaría el cerebro leyendo inglés.
Los arranques se pueden acelerar, pero a ver qué servicios no cargan en el inicio. Hay servicios que tardan el doble en arrancarse con el SO funcionando
Ubuntu no tiene ningun brillo. Si quieren lograr arranque rapido y eficaz prueben distribuciones de verdad como Gentoo, Slackware o Archlinux. ¿Para que forzar que ubuntu inicie rapido si no está hecho para eso?
¿No podría ser vistoso Y en menos de 10 segundos?
#6 Por qué depender del script? Si se está ejecutando sobre un sistema que paraleliza el init de cada uno de los servicios, sería tan sencillo como establecer un lístener para cada una de esas dependencias. A día de hoy gestores de dependencias hacen algo parecido.
Java permite hacer cosas con interfaces como Observable y demás zarandajas. Si Java puede hacer cosas así, c y c++, tendrán artilugios para implementar listeners y observadores sobre los PROCESOS del servicio, que no sobre el script de inicio.
Además, desde la propia arquitectura se podría saber cuando un servicio está listo y cuando no, y siendo el propio sistema el que sepa cuando las dependencias de cada uno de los servicios están satisfechas.
#6 por cierto, estaba rebuscando una cosa para lo que comentas al final sobre el workaround para saber qué tipo de init se está ejecutando.
Decirte que realmente no es una ñapa eh? Es un patrón de diseño muy común que se llama Estrategia ( http://en.wikipedia.org/wiki/Strategy_pattern ) y consiste en decidir un funcionamiento u otro en función (qué mal suena coño) de algún parámetro u estado en tiempo de ejecución.
En este caso tendrías una estrategia de carga líneal y otra de carga paralela. No sería tan descabellado.
#10: No he dicho que sea descabellado. De hecho a mi también me gusta la idea.
Sólo digo que supone mucho trabajo porque no hay que cambiar sólo el init, sino todos los procesos procesos de carga de todos los servicios existentes (que no son sólo los que puedas tener instalados tu en tu sistema ni mucho menos).
El mayor problema aquí está en la migración y en que todo el mundo se adapte al nuevo "standard" (y para ello primero tiene que llegar a serlo) mas que en la própia implementación.
Pero con el tiempo lo veremos. Seguro. Solo que hay que tener en cuenta que no va a ser mañana