La diferencia entre simplicidad y complejidad.
SysVinit es un programa simple y pequeño que utiliza un archivo de configuración simple para designar procesos para iniciar, el orden en que se inician esos procesos y qué hacer cuando esos procesos terminan.
Además de eso, define formas de seleccionar la lista de procesos a ejecutar. Se implementaron varias implementaciones de esa selección. El método original figuraba como “nivel de ejecución”, que designaba la lista a utilizar. Se llamaba niveles porque en ese momento, cada nivel permitía que los procesos en la lista se ejecutaran en paralelo. Cada nivel de ejecución agrega más procesos al sistema. Durante el inicio del sistema, el “nivel” de destino designado se especificó de manera predeterminada, por lo que el sistema inició la lista de nivel 1, luego, cuando se completó la lista de nivel 2, cuando se completó, la lista de nivel 3.
- ¿Qué es push pull en microcontroladores?
- ¿Qué hace un ingeniero de sistemas en el campo integrado?
- Hay muchos microprocesadores y microcontroladores como 8085 8086 PIC, etc. ¿En qué se diferencian entre sí y el estudio de cualquier microprocesador y microcontrolador le da una comprensión de todos los demás?
- ¿Cuál es la diferencia entre los sistemas embebidos y los sistemas utilizados en robótica o la robótica en su conjunto?
- ¿Cuáles son las habilidades / conocimientos básicos necesarios para la programación integrada / sistemas / firmware?
Por lo tanto, los niveles se convirtieron en una identificación asociada con el estado operativo: el nivel 1 era un solo usuario, y solo funcionaban aquellos procesos necesarios para el modo de un solo usuario, cosas como una sesión de terminal para root (como el único usuario) y el montaje del disco del sistema. El nivel 2 agregó otros discos y servicios del sistema, pero aún así solo un usuario en la consola. El Nivel 3 agregó esos servicios (como el acceso a la red) y habilitó el inicio de sesión multiusuario (inicio de sesión desde más que solo la consola), por lo que se identificó como “multiusuario”.
Las versiones posteriores lo separaron y, en su lugar, agruparon las listas en un inicio (en lugar de que init tenga que reconocer la finalización de un nivel). Por lo tanto, especificar un inicio de nivel tres ejecutaría todos los procesos … Pero ahora, debido a que los procesos no estaban agrupados en niveles, se requería que el nivel tuviera un script de inicio para proporcionar la secuencia. Varios proveedores ampliaron esa complejidad añadida a los scripts de shell (las funciones checkconfig).
La complejidad añadida también agregó más flexibilidad, utilizando directorios para enumerar los procesos que debían iniciarse y el orden. Las secuencias de comandos de inicio hicieron esto con una simple lista de directorios: los nombres de los archivos comenzaron con un designador “Snn”, las S fueron las que se iniciaron en el arranque, una K, las que se iniciaron en el apagado. El valor “nn” era un número de dos dígitos utilizado para designar el pedido. Si dos scripts tuvieran el mismo orden “nn”, podrían iniciarse en paralelo (aunque nadie parece haberlo llevado a cabo).
A algunas personas no les gustó la colección resultante de scripts de shell … así que eliminaron todo y lo reemplazaron con systemd.
Systemd implicaba que TODO se iniciaría en paralelo Y se monitorearía, pero eso causó problemas en los que algunos servicios dependían de otros servicios … Por lo tanto, systemd tuvo que agregar una capa de análisis de red para descubrir qué debía iniciarse en orden. Esa complejidad añadida en que ahora systemd tenía que saber si un inicio había terminado … requiriendo que se modificara el primer proceso para notificar a systemd que realmente estaba operativo … Esto permitió que el primer proceso comenzara a ser monitoreado.
Con el paso del tiempo, los desarrolladores siguieron encontrando más procesos que necesitaban tal secuenciación y modificación (cada sistema de base de datos tenía que modificarse, cada servicio de red …) añadiendo mucha más complejidad.
Conceptualmente, systemd parece más simple. Desde una vista de implementación, es mucho más complejo.
La dependencia de la red es difícil de modificar para agregar un nuevo servicio … Agregarlos al archivo trivial “rc.local” (lo último que se ejecutó en sysVinit) ya no funcionó, porque cosas como la red, los servicios de nombres o las bases de datos podrían no funcionar. Prepárate todavía. La mayoría de las fallas se remontan a la red … por lo que el servicio del administrador de red (donde se aplazó la inicialización de la red) tuvo que modificarse para notificar a systemd cuando la red era realmente utilizable. Aunque todavía falla algunas veces, ¿cuándo se puede usar la red en el caso de múltiples interfaces de red? cuando se inicializa el primer dispositivo? ¿o después de que DHCP haya terminado con otras tres o cuatro (lo que puede llevar un tiempo)? ¿O está listo después de inicializar la red de área de almacenamiento? ¿O después de que se realicen los montajes de NFS?
Entonces, se agregó más complejidad … re-implementando más de los niveles de ejecución de SysVinit. Sin embargo, aún más complejo. El apagado sigue siendo un problema … a veces los sistemas aún se bloquean. El registro a veces sigue siendo un problema (otra complejidad añadida a systemd).
He encontrado que funciona bastante bien en entornos pequeños, como estaciones de trabajo. Una vez que funciona en entornos grandes, es agradable, más rápido que la complejidad del script de shell anterior, pero cuando las cosas salen mal, es casi imposible de depurar.
Otros tendrán opiniones diferentes, pero creo que la complejidad adicional es perjudicial y viola la práctica de “Haz una cosa y hazlo bien”.
