Esta entrada es traida textualmente desde mi blog personal a petición de cierto personaje holguinero que todos conocemos y con ella solo pretendo arrojar un poco de luz sobre systemd para que las discusiones sean un tanto mas equitativa y de paso algunos usuarios sepan por fin que es systemd.
Antes de comenzar debo decir que no me gusta nada la decisión de cambiar las cosas en Debian pero, en ningun momento planeo abandonar mi querida espiral. Solo intento que, si vamos a discutir un tema, por lo menos lo hagamos lo más preparados posible aún cuando yo mismo no me considero pro-systemd. Para lograr la desmitificación de systemd me apoyaré en un sitio web donde los desarrolladores dan su punto de vista el cual llegó a mis manos por un colega que si parece ser pro-systemd aunque no sea usuario de Debian. Dicho esto creo que puedo pasar a intentar desmitificar lo que se dice sobre systemd.
systemd es a base de binarios
Quizás este sea uno de los aspectos que más nos choquen, ¿si todo es a base de binario como monitorear las cosas que usualmente hacemos a travez de logs?. No tengo ni idea de como nació este mito, pero no es absolutamente cierto.
systemd se configura casi exclusivamente a través de archivos de texto simple. Unos ajustes que también pueden alterar con la línea de comandos del kernel y a través de variables de entorno. No hay nada binario en su configuración (ni siquiera XML). Sólo un simple, sencillo y fácil de leer archivo de texto.
Esa cosa es monolítica y lo controla todo
Antes de llegar a la web mencionada anteriormente confieso que yo mismo pensaba de esta manera pero luego de leer lo que dicen sus desarrolladores mi opinión ha cambiado algo…
Si usted hace una build de systemd con todas las opciones de configuración habilitadas usted construirá 69 binarios individuales. Estos binarios sirven para diferentes tareas, y se separan cuidadosamente por un número de razones. Por ejemplo, se ha diseñado systemd pensando en la seguridad, por lo tanto, la mayoría de los demonios corren con privilegios mínimos (utilizando las capacidades del núcleo, por ejemplo) y son responsables de sólo tareas muy específicas, para reducir al mínimo su superficie la seguridad y el impacto. También, systemd paraleliza el arranque más que cualquier solución anterior. Esta «paralelización» se crea ejecutando varios procesos en paralelo. Por lo tanto queda visto que systemd está muy bien dividido en muchos binarios y por lo tanto los procesos. De hecho, muchos de estos binariosse separan tan bien, que son muy útiles fuera de systemd.
Un paquete que incluyó 69 binarios individuales difícilmente pudiera ser llamado monolítico. Lo que es diferente de las soluciones anteriores sin embargo, es que enviamos más componentes en un único tarball, y los mantenemos encadenados en un único repositorio con un ciclo de lanzamiento unificado.
Eso no se parece a Unix
Ciertamente hay algo de verdad en eso. Los archivos de las fuentes de systemd no contienen una sola línea de código procedente de las líneas originales de UNIX. Sin embargo, se deriva la inspiración de UNIX, y por lo tanto hay un montón de UNIX en systemd. Un ejemplo sería la idea de UNIX «todo es un archivo» el cual se encuentra reflejado en que en systemd todos los servicios se exponen en tiempo de ejecución en un sistema de archivos del kernel, los cgroupfs. Entonces, una de las características originales de UNIX fue el soporte multi-seat, basada en el apoyo integrado en el terminal. Con systemd trajimos el soporte multi-seat de forma nativa nuevamnte, pero esta vez con el soporte total para el hardware de hoy, que cubren gráficos, ratones, audio, cámaras web y más. De hecho el diseño de systemd como una suite de herramientas integradas que cada uno tiene sus propósitos individuales pero cuando se usan juntos son más que la suma de las partes, que más o menos en el centro de la filosofía UNIX. Entonces, la forma en que nuestro proyecto se maneja (es decir, el mantenimiento de la mayor parte del núcleo del sistema operativo en un único repositorio git) es mucho más cercano al modelo BSD (que es un verdadero UNIX, a diferencia de Linux) de hacer las cosas (donde la mayor parte del sistema operativo central es mantenerse en un único repositorio CVS / SVN) cosa que nunca fue asi en Linux.
En última instancia, la cuestión de si algo es UNIX o no importa muy poco. Siendo técnicamente excelente es apenas exclusivo de UNIX. Para nosotros, UNIX es una influencia importante (de hecho, el más grande), pero también tenemos otras influencias. De ahí que en algunas zonas systemd serán muy UNIX, y en otras un poco menos.
Es que eso es muy complejo…
Ciertamente hay algo de verdad en eso. Las computadoras modernas son bestias complejas y el sistema operativo que se ejecuta en ellas obviamente también lo será, por lo tanto tienen que ser complejo. Sin embargo, systemd ciertamente no es más complejo que las implementaciones anteriores de los mismos componentes. Es más sencillo, y tiene menos redundancia. Por otra parte, la construcción de un sistema operativo sencillo basado en systemd implicará mucho menos paquetes que los que usa un Linux tradicional. Menos paquetes hace que sea más fácil de construir su sistema, se deshace de las interdependencias y de gran parte del comportamiento diferente de todos los componentes involucrados.
Eso no me va a dejar usar scripts de Shell
Esto es totalmente falso. Simplemente no los usamos para el proceso de arranque, porque creemos que no son la mejor herramienta para ese propósito específico, pero eso no significa systemd era incompatible con ellos. Puede ejecutar fácilmente los scripts de shell como servicios systemd o demonios, puede ejecutar scripts escritos en cualquier idioma como servicios systemd ya que a systemd no le importa lo más mínimo lo que hay dentro de su ejecutable. Por otra parte, en gran medida utilizamos scripts de shell para nuestros propios fines, para la instalación, construcción, pruebas de systemd. Y usted puede pegar los scripts en el proceso de inicio temprano, se utilicen para los servicios normales, se pueden ejecutar en la última parada, prácticamente no hay límites.
Llegados a este punto supongo que algunas de las principales creencias pueden haber sido aclaradas, a pesar de no sentirme un defensor del cambio y tener mis recelos sobre eso de «un demonio para controlarlos a todos» creo que al final nadie se atreverá a decir que por lo menos no funciona, incluso conozco algunos usuarios que notan que con systemd «la PC camina mas rapido» pero ya esas serían otras cosas que pudieran discutirse. Por el momento solo me resta invitarlos a debatir aquí los puntos de vista que tengan sobre el gestor de inicio que muchas distribuciones han adoptado aunque ahora las mayores reacciones se estén viendo dentro de la comunidad de Debian el cual hasta le ha nacido un nuevo fork con todo esto. Si gustarle o no es una cuestion de cada uno, yo por mi parte solo quiero poner mi granito de arena en la desmitificación de systemd que al final va a estar presente en Jessie, la próxima versión estable de Debian.
¿Te resultó interesante? Compártelo ...
O te arreglas o te haces los papelillos jajaja. Primero hablas de los LOGS que SI son binarios, y luego saltas para los ficheros de configuración de Systemd que no lo son, para luego decir que el jodido paquete crea 69 binarios.. No entiendo na!
cosas que pasan cuando tratas de poner tus propias palabras y luego seguir con las palabras del desarrollador jejeje. Lo que quiero decir es que cuando dices que systemd es a base de binarios a todos les choca eso y sueltan una pregunta como la que puse… quizas es culpa del redactor, es decir … yo jejeje
Edito para que no se malinterprete mi comentario..
Claro, porque el #@#%!^ Lennart no sabe lo que hace xDD
Hombre, que yo te respeto, pero con ese comentario… O te robaron la identidad?
No, soy yo, lo que pasa que Systemd me altera, recién acabo de leer mi comentario y parece que le estoy diciendo al Neji que no sabe lo que hace, no fue lo que quise decir, así que lo edité.. 😛
Muahahaha! Sufres de PTSD provocado por systemd en Arch.
Bueno Ernesto, eres viejo en este mundo, vamos a estar de acuerdo en que no estamos de acuerdo, y, dale tiempo a systemd, míralo con otros ojos. Aunque esté tomando el camino de one ring to rule them allno debe ser es un engendro de RedHat, si las grandes distros lo están adoptando, es porque es funcional, punto.
Otra entrada sobre systemd!!!! 😯
Systemd cada vez se parece más a la epidemia del ébola… ¡¡¡to’ el mundo está contagia’o!!!
A ver, systemd venció, con respecto a sysvinit y otros tiene sus ventajas y sus desventajas, en mi opinión, en cuanto a calidad y funcionalidades están bastante parejos (por eso han habido tantas discusiones), como también en mi opinión las ventajas sobrepasan a las desventajas (por eso la mayoria votó por él) pero estos mitos están vistos muy del lado de systemd, por ejemplo, pueden haber 69 o 300 binarios en la compilación, que si al fallar uno, compromete todo el sistema, pues este sigue siendo monolítico, y ese es el caso de systemd. Otra de las cuestiones muy discutidas son los binarios, pues se usan para el almacenamiento de los logs, la tesis de que un log binario es mas seguro, puede ser válida, pero en systemd tiene sus problemas como el hecho de que si alguien intenta modificar un log, este se vacía por completo e incluso rompe al sistema, esto es algo que estoy seguro se va a arreglar, pero es a lo que se refiere la mayoria cuando habla de que esta basado en binarios. Y para terminar, ciertamente no se parece a unix, rompe completamente con la filosofía de «haz una sola cosa, y hazla bien», no me voy a meter en si esta justificado o no romper con esta filosofía, pero la rompe, y por tanto, no se parece a unix.
Saludos.
Cesar, pero systemd no fue diseñado pensando en Unix. ¿Por que debería de respetar la tradición arcaica y obsoleta de Unix? Linux es inovador y revolucionario.
Si, linux es inovador y revolucionario, pero me parece que el concepto que mencionaba no tiene nada de arcaico, y ha hecho a los sistemas basados en la filosofía unix (linux, bsd, macos entre otros) extremadamente estables, cuando un único programa se dedica a gestionar varias tareas, y falla, pues todas esas tareas que gestiona se pierden, además de que es mas complicado de mantener y mejorar porque hay que tratar con mas código (lo que a la vez favorece que se cometan mas errores), mientras que por otro lado, si se dedica a una sola tarea, y falla, los demás programas que se dedican a las otras cosas siguen funcionando, y por tanto las demás tareas no se pierden, mientras que su mantenimiento y mejora se hace mucho mas fácil, pues hay que lidiar con menos código, el cual esta centrado en realizar una sola función. No te parece esto último más innovador y revolucionario?
Saludos.
A mi de systemd me preocupa una sola cosa, o bueno es la que mas me preocupa. Al controlar todo, que ocurriría si dentro de tres meses nos llega la primera falla de seguridad de systemd, o simplemente una nueva versión de systemd tiene una falla debido a regresiones en la programación? Se jode todo? Me quedo sin sistema? Precisamente la filosofía UNIX en su propia concepción evita eso.
Por cierto, yo que iba a publicar hoy algo de systemd en SWL-X, pero se ha hablado tanto de este tipo en el .cu en la ultima semana que lo mejor es no ser redundante
Hola Maikel.
Bro, di lo que tengas que decir:
Un hombre que no arriesga nada por sus ideas, o no valen nada sus ideas, o no vale nada el hombre –Platón–
Yo te considero un gran maestro.