Barrapunto

Parece mentira que a nadie se le haya ocurrido esto antes. De 41 a 17 segundos. Muy bien por Jimmy, esta hecho un fiera.

que vi la noticia en Tod-OS y por lo menos a mi en una mandrake 10.1 (me resisto a instalarme la mandriva xD) no me funciona, o bueno, no me funciona del todo bien, se queda enganchado unas veces al 20%, otras al 90%....

Busque un poco de documentacion por google pero no hay mucho la verdad, asi que me he vuelto al arranque de toda la vida y poco a poco me ire "pegando" con el initng a ver si lo hago andar bien.

Eso si, la carga hasta el 90% es asombrosamente rapida, todo sea dicho.

Salud!!

De hecho hace un par de semanas le hice la pregunta de ¿por qué no? a un profesor de mi escuela. Me comentó que era por lo de que son scripts y que, en algunos casos, es necesaria la secuenciación.

Está claro que quizás lanzar algunos demonios antes que otros no puede ser (por ejemplo httpd antes de procesar el fstab) pero crear cinco o seis hilos de inicio está genial. Estoy harto de, cuando el servidor de DHCP no está disponible, tener que esperar el porrón de segundos que está esperando respuesta (a no ser que le des un Control-C)

si el ordenador tiene una sola cpu, por lo tanto hacen sólo una cosa a la vez. Luego si hacemos concurrencia de inicio, aumentaremos la cantidad de cambios de contexto, lo que hará que todo sea más lento.

Ahora, si somos realistas, al iniciar los servicios no usamos toda la cpu, debido a que esperamos respuestas de la red, esperamos respuestas de hardware inicializando, y otros.

Por lo tanto mientras esperamos la respuesta de la red con las IP de los dns podríamos estar subiendo otra cosa y aquí la concurrencia tiene sentido.

La pregunta para ver si vale la pena es: ¿los tiempos de los procesos de inicio bloqueados son mayores que los cambios de contexto necesarios para tener concurrencia?

En Libertonia hablaron sobre ello [escomposlinux.org].

En Linuca [linuca.org] hablaron de ello en el 2003!!!

... pero como aporta un post anterior [barrapunto.com] para que si solo afecta al arranque

Si es necesaria la secuenciación de muchos servicios, y se arranca el equipo de vez en cuando, a mi personalmente me da igual ahorrarme 30 segundos en el arranque, la verdad, ya que existe mayores problemas potenciales que soluciones.

Vamos, que esta muy bien y lo pienso probar, pero no perdería mucho tiempo instalandolo y configurandolo ;-) (si me viene por defecto con la instalación pos bueno... ;-) )

Todo lo anterior es IMHO, como siempre ;-).

... incrementa dramáticamente... en mi opinión queda mucho mejor incrementa espectacularmente

Otro anglicismo que me repatea (no se a vosotros) es "vuelos domésticos", en lugar de vuelos nacionales.

Hay que favorecer el caso frecuente, y lo frecuente en un ordenador no es el arranque, sino su uso. Una maquina va a estar mucho mas tiempo funcionando que arrancando, por lo que segun la ley no merece la pena invertir esfuerzos en mejorar dicha parte. Si el arranque secuencia funciona adecuadamente, no veo la necesidad de paralelizar a toda costa. Es mas, no se vosotros, pero yo en el arranque de sistemas tengo servicios que dependen de otros servicios, dependencias fuertes que si no se cumplen finalizan en fallos, por ejemplo, un servicio que dependa de una base de datos para su inicio. En este supuesto, no es nada aconsejable.

A ver si alguna distro fomenta este tipo de novedades: por ahora ninguna parece sacarle partido (el arranque paralelo de gentoo lo he probado y apenas mejora)..

Yo personalmente hago algo parecido a lo que runlevel0 dice hacer: hibernar en vez de apagar. Pero por defecto! Transparente al usuario. Yo al darle al botón de apagar en el menú de KDE o de KDM, lo tengo configurado para que primero reinicie el KDM, y una vez reiniciado, hiberna.

Así cuando vuelvo a encender el ordenador, me sale directamente el KDM, y tarda desde el GRUB hasta el KDM 20 segundos :). Lo mejor de todo: que ¡el uptime se conserva!.

El método lo explico, para debian-kde/kubuntu (adaptarlo a otras distros/configuraciones debe ser trivial) scripts incluídos, en Booting Kubuntu in 22 seconds [ubuntu.com] Atención: ¡es un mal hack! Seguro que alguien con más conocimientos sabría mejorarlo.

Uso el script de hibernación que trae el kubuntu por defecto. En apagar/hibernar me tarda unos 40 segundos (unos 36 sin hacer aparentemente apenas nada), y la suspensión no furula muy bien que digamos. La verdad, prefiero que tarde 40 segundos en apagar que en encender ;-).

Pero eso es porque no he tenido tiempo/ganas de jugar con el Software suspend 2 for Linux [suspend2.net], el cual permite suspender e hibernar a *cualquier* computadora que corra linux =), y al parecer no tiene esos problemas.

Suerte con ello!
      Edulix..

A primera vista parece interesante. Me gustaría utilizarlo en el portatil donde los tiempos de arranque son importantes, para el trabajo diario. ¿Alguien lo ha probado, qué pasos se han de seguir?

Gracias por la corrección, ya lo he cambiado. Esto de poner noticias a última hora no es buena idea...

Es cierto. En Ubuntu usan una rutina para leer los datos de arranque a memoria y así que no se "maree" el disco cuyo acceso para leer ficheros pequeños y de forma paralela puede llegar a ser más lento que si se hace la lectura de forma secuencial. Windows creo que hace lo mismo.

No. El arranque en Windows es secuencial -al menos hasta llegar a tareas programadas-, lo que pasa es que levanta la interfaz gráfica antes de que haya arrancado todo, en paralelo. Con Windows podemos tener el escritorio y una ventana de MS Internet Explorer antes de que se haya levantado la red. Así da sensación de un arranque más rápido.

Por otro lado, lo de "marear al disco duro" no tiene sentido por cómo se planifican las lecturas y cómo se escriben los archivos en NTFS.

No todo el mundo tiene el ordenador encendido todo el día. Si esto mejora y se populariza, y las distribuciones lo van adoptando, sería un punto más a favor de Linux para los usuarios "normales" de ordenadores, especialmente los de portátiles. Más arriba comentaban que es mejor la hibernación/suspensión, pero en Linux no está soportada en todos los ordenadores, así que un arranque más rápido sería bastante útil. Imagínate la situación: estás con el portátil en la universidad y quieres mirar cuál es la siguiente clase. Sacas el portátil para conectarte a la web y mirar el horario. Pero tienes prisa y Linux tarda mucho en arrancar. Sin embargo, ahora resulta que han sacado una cosa que se llama initng y gracias a ello va muchísimo más rápido, ¿no te parece útil?

Quizá no sea importante en un entorno de servidor, pero si en uno de escritorio y más si es un portátil. Cada vez que veo como arranca un AmigaOS (ojo, no hablo de los ordenadores Amiga de los 80) o MorphOS se me cae la baba... alguno que lo use por aquí puede decir cuanto tarda en cargar? 6-7 segundos? y después del reset? 2-3 segundos?

Eso no es del todo cierto, ya que los accesos de lectura/escritura a sectores contiguos son logicamente más rápidos, ahora bien, si el disco está muy fragmentado estará mareado de todas formas XD

Porque hay gente como yo, que cuando se va, apaga el ordenador.

Si estuvieras en un centro donde se encienden los ordenadores 1 hora para dar clases, te darías cuenta que no es lo mismo 20 seg. que 1 minuto.

En lo que si estoy de acuerdo con otros hilos de la conversación es que en un servidor me da exactamente igual el tiempo de arranque:

quercus:~# uptime
08:49:04 up 54 days, 23:08, 1 user, load average: 0.00, 0.00, 0.00

¡Y fue por un problema con el sai! ;)