abemus Systemd [Opinion sysarmy]

Desconocido

Quiero traer al debate la existencia de systemd, hoy en día ya fué adoptado por muchas de las distros más populares... Me gustaría escuchar fundamentos, enojos, opiniones, y experiencias de cada uno.



Por mi parte cada día Lennardito me cae peor...

qlixed

Fundamente.

Si no fundamentas, no tiene sentido la pregunta.

luigibalzani

Para mi le falta mucho para funcionar en servers, me ha pasado que firewalld pierda reglas y se corten servicios, problemas con visualizacion de logs y alguna cosa mas que no recuerdo ahora.

Lennardito deberia ser director de marketing de M$, en eso es buenisimo....

msx

DISCLAIMER: a recontra favor.

Para mi el rechazo tiene que ver con una serie de factores, algunos con más y otros con menos peso pero que generalmente se reducen a desconocimiento en algunos casos ó cuestiones subjetivas ('no es lo que me gusta', 'así - no lo veo - yo') en otros:

1. Es distinto: para qué tengo que aprender algo de nuevo si lo que ya existía funcionaba?
2. Es binario! No es editable! Es el Mono de los sysadmines! Un caballo de troya codeado por reptilianos Illuminati para adelantar el NWO!
3. Es monolítico.
4. No es acorde a la filosofía Unix porque no hace una sola cosa y nada más que eso, bien.

• Porque ataca problemas que se venían workaroundeando desde hace años;
• Por incorpora un sistema de ejecución preemptivo de tareas en donde es infinitamente más fácil planificar el orden y las reglas de activación que con un sistema pasivo tradicional como SysV o Upstart en donde dependemos de condicionales de ejecución previos para imaginarnos posibles escenarios resultantes sobre los que vamos a trabajar;
• Hay un montón de gente inteligente que después de analizarlo y sopesarlo está de acuerdo con que los beneficios son mayores al 'desgarro' generacional que implica abrazar el cambio;
• Porque hace que la gestión del sistema sea una seda: es una navaja suiza muy cómoda;
• Porque permite estandarizar la creación de unidades de servicio y timers haciendo infinitamente más fácil la vida del sufrido sysadmin administrador de ambientes heterogéneos;
• Porque las unidades de servicio le brindan al sysadmin un control granular sobre la ejecución de la herramienta, con un nivel de control similar al esperable de SELinux;
• Porque implementa, bien hecho, la gestión de zócalos para la activación de servicios o eventos del sistema -- evitando así estar corriendo servicios continuamente a la escucha de una eventual llamada que puede ser vulnerados y que además consumen recursos continuamente;
• Porque es container-ready
• Porque systemd-nspawn se siente un fucking SDF-1 al lado de chroot;
• Fundamental: porque se hace cargo de proyectos que estaban abandonados o en muy malas condiciones;
• Porque implementa PAM a nivel global haciendo todavía más cómoda la gestión del sistema;
• Porque la ejecución de las unidades es predecible y controlable;
• Porque al ser el PID 1 además es el fucking rey del sistema. Systemd cuenta con características de seguridad únicas que ni SELinux puede soñar alcanzar gracias a ser el PID 1;
• Es fucking compilado... and alive, mwahahahaha!!
• Para los que dicen que 'justamente, no es compilado, con los scripts de inicio podía revisarlos y ver qué hacían cada uno'... BS. Seriously. Todos hemos visto scripts de inicio de más de 1k líneas llenos de ugly hacks y workarounds para hacer cosas para las que Bash nunca fue pensado. Systemd corta con toda esa melange y divide la lógica operativa entre operador compilado y operando scripteable (unidades de servicio);
• Al contrario que con otros PID 1 que fueron armándose de a poco y a los ponchazos, systemd está diseñado de forma cohesiva desde el principio para gestionar de forma íntima e integral las distintas partes del sistema;
• El código es enteramente FOSS, el no saber C no es excusa para criticar la adopción del lenguaje.
• Nada más lejos de ser monolítico, de hecho es modular: en sistemas que no utilizan systemd y es necesario tenerlo presente por cuestiones externas (GNOME, por ejemplo) pueden reducirse las dependencias a unos pocos archivos muy livianos;
• Tampoco es cierto que no respeta la filosofía de diseño Unix: los proyectos que incorporó / se comió - como whatever les sea más grato decirlo - son proyectos que o estaban abandonados upstream, estaban en modo mantenimiento o estaban atados con alambre. Resulta que nadie se ocupaba de esos proyectos fundamentales para el sistema operativo pero cuando sí lo hace un grupo de personas con las que otro grupo de personas no está de acuerdo, está mal que lo hagan. Aunque dichos proyectos hoy se transformaron en modulos funcionales bien mantenidos dentro del paraguas de systemd / freedesktop, los mismo siguen siendo opcionales. Si mañana alguien desea reemplazar cualquiera de ellos puede, tranquilamente, deshabilitar la funcionalidad interna y acoplar una solución distinta al esquema systemd. Por supuesto que al ser systemd el PID1 y gestor del sistema cualquier nuevo módulo / desarrollo que pretenda ocupar el puesto de alguno de los módulos internos deberá incorporar la interfaz necesaria para comunicarse con systemd. Again, en este caso particular, systemd vino a llenar un hueco que estuvo abandonado por mucho tiempo pero pocos estaban al tanto y otros que sí lo estaban no se preocuparon demasiado por revertir la situación. Ahora, para rasgarse las vestiduras, todos mandados a hacer!
• Cientos de características awesome de las que sólamente he leído y a las que todavía no tuve oportunidad de aprender a usar =(
• Linux is not Unix. We are in 2015 -- almost 2016. Stop it.