Visitas: 27  
Tiempo total: 0 días con 6:53:42 hrs  

A continuación se describe la definición y las características de los procesos de inicio en los distintos sistemas GNU/Linux como init, systemd, upstart e init en Android. El objetivo es realizar una comparativa de su funcionamiento, cuales son los aspectos negativos de aquellos que merecen mencionarlos y como están divididos.

Proceso Init

Significa initialization y es el proceso que se inicia de primero después de la carga del kernel, comúnmente tiene el PID 1 y se implementa de distinta manera en los sistemas Unix: System V y BSD. En este último, se implementa de una manera bastante simple, utilizando el script /etc/rc el cual es fácil de editar, pero está sujeto a errores dejando inutilizable el arranque del sistema.

GNU/Linux utiliza el estilo System V y en general, el usuario no debe de preocuparse de este proceso porque pasara inadvertido, caso contrario si se utilizan terminales seriales, modens que auto atienden llamadas o si se desea cambiar el nivel de ejecución por defecto.

El proceso init es buscado por el kernel en un archivo binario en /sbin/init Otro detalle que se puede mencionar, es la administración de procesos padre e hijos, en este caso si el proceso padre muere los hijos pasan a ser automáticamente hijos del proceso init.

Una de las principales diferencias entre las dos implementaciones, es que el estilo System V utiliza niveles de ejecución, mientras BSD no.

Proceso systemd

Fue publicado por Lennart Poettering como software libre y significa proceso en segundo plano (system daemon). Este proceso fue escrito exclusivamente para la API del núcleo Linux reemplazando al proceso de inicio Init. Este proceso proporciona un mejor marco de trabajo expulsando las dependencias de servicio, permitiendo hacer más trabajo paralelamente al inicio del sistema reduciendo la sobrecarga del Shell.

Systemd, tiene algunas características negativas, entre algunas de estas están:

1. Es complejo para un proceso de inicio.
2. El sistema de archivos journald no cumplen con las características ACID, es decir que son corruptibles y se almacenan en un formato binario complicado.
3. Las diferentes versiones de systemd son incompatibles con las diferentes versiones del kernel de Linux.
4. Udev y dbus son dependencias forzosas. El administrador de dispositivos esta ahora integrado al proceso de inicio systemd, es decir que no es parte del kernel.
5. Los core dumps son almacenados en el jounald, siendo obligatorio ser usuario root en un sistema multiusuario para poder consultarlos.
6. El tamaño del systemd es menor que el kernel de Linux, pero igual de crítico, mostrando 9 reportes CVE (información de seguridad y vulnerabilidad).
7. Systemd es viral, es decir que debido a su alcance en funcionalidad y arrastre como dependencia a cientos de paquetes. Esto significa que varios mantenedores de distribuciones van a necesitar de systemd, por ejemplo GNOME lo utiliza como dependencia para varias utilidades (gdm, gnome-shell y gnome-extra-apps).
8. Systemd controla una gran cantidad de componentes, requiriendo para su actualización un reinicio forzoso, aunque systemd ofrece un sistema para reiniciarse y reejecutarse a sí mismo, pero existen varias formas de que ocurra una falla en esto, resultando en la caída total del sistema. Esto es una SPOF (punto simple de fallo).
9. Systemd fue desarrollado con glibc y no se preocupa por soportar otras glibc (versiones). Una librería estándar de C para systemd es aquella que pueda soportar cada bug que se genere con systemd.
10. La utilización de la API de systemd para escribir programas es complicado debido a la complejidad de systemd.
11. Es un cambio de pensamiento en la comunidad Linux, Systemd es un parasitismo más que systemd en sí mismo. Es la reinvención de la rueda.
12. Systemd deja de ser un proceso de inicio, para ser algo que represente el capricho de los desarrolladores.

Upstart

Fue creado por Scott James Remnant, antiguo trabajador de Canonical LTD. Upstart es un reemplazo basado en eventos del proceso init. Upstart, funciona cuando se enciende o se apaga la computadora, su modo de ejecución es asíncrono, es decir que una tarea futura debe de esperar hasta que la actual se haya completado.

Las principales limitantes de Upstart, son las siguientes:

• No puede reconocer la conexión y desconexión de dispositivos USB.
• No reconoce la carga de firmware, que debe de realizarse después de que se conecta el dispositivo, y antes de que pueda utilizarse.

Proceso de inicio en Android

El proceso de inicio es llamado init y está ubicado en la raíz del dispositivo (es llamado init.rc), lanza los script de inicio escritos en /etc/rcX.d. A diferencia de los sistemas Linux, Android utiliza su propio proceso init, que esta divido en dos: init.rc (ya mencionado) y init.<machine_name>.rc.

Init.rc contiene las instrucciones de inicialización genéricas, y init.<machine_name>.rc contiene las instrucciones especificas del dispositivo de hardware que está corriendo el programa. El parámetro <machine_name> es un código, por ejemplo para emuladores el código es ‘goldfish’.

Referencias

[http://es.wikipedia.org/wiki/Init]
[http://www.tldp.org/pub/Linux/docs/ldp-archived/system-admin-guide/translations/es/html/ch09.html]
[http://es.wikipedia.org/wiki/Systemd]
[http://www.linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda]
[http://es.wikipedia.org/wiki/Udev]
[http://es.wikipedia.org/wiki/Upstart]
[http://www.neuronasdigitales.com/proceso-de-inicio-en-android/]
[http://elinux.org/Android_Booting]
[http://u.delta9.pl/k/i/systemd_shewantsit.jpg]