systemd

Artículo de Pid Eins (un desarrollador de systemd) sobre los mitos de systemd y el odio visceral que se levanta por parte de muchos usuarios que defienden antes la filosofía UNIX que la filosofía GNU.

Como nota curiosa, los blogs que despotrican de systemd son de personas que defienden el software privativo y son usuarios regulares del código cerrado. ¿Por qué? Pues porque acusan a systemd de ser vírico, como la licencia GPLv3. Ahora sí podéis entender esa masa de bloggers defensores del software privativo que acusan tanto a systemd.

Desde que propusimos por primera vez el sistema para su inclusión en las distribuciones, se ha debatido frecuentemente en muchos foros, listas de correo y conferencias. En estas discusiones se pueden oír a menudo ciertos mitos sobre systemd, que se repiten una y otra vez, pero que ciertamente no ganan nada de verdad por la repetición constante. Tomemos el tiempo para estudiar algunos de ellos:

Mito: El sistema es monolítico

Si construyes systemd con todas las opciones de configuración habilitadas construirás 69 binarios individuales. Todos estos binarios sirven para diferentes tareas, y están claramente separados por varias razones. Por ejemplo, se diseña systemd con la seguridad en mente, por lo tanto la mayoría de los demonios se ejecutan con privilegios mínimos (usando las capacidades del kernel, por ejemplo) y son responsables sólo de tareas muy específicas, para minimizar su superficie de seguridad y su impacto. Además, systemd paraleliza el arranque más que cualquier otra solución anterior. Esta paralelización se produce al ejecutar más procesos en paralelo. Por lo tanto, es esencial que systemd se divida bien en muchos binarios y, por lo tanto, en procesos. De hecho, muchos de estos binarios[1] están separados tan bien, que también son muy útiles fuera de systemd.

Un paquete que incluye 69 binarios individuales difícilmente puede ser llamado monolítico. Sin embargo, lo que es diferente de las soluciones anteriores es que se envían más componentes en un solo tarball, y los mantenemos en un solo repositorio con un ciclo de liberación unificado.

Mito: Systemd y la velocidad

Sí, systemd es rápido (un arranque bastante completo del espacio de usuario en ~900ms, ¿alguien?), pero eso es principalmente sólo un efecto secundario de hacer las cosas bien. De hecho, nunca nos hemos sentado a optimizar el último pedacito de rendimiento de systemd. En cambio, con frecuencia elegimos conscientemente las rutas de código ligeramente más lentas para mantener el código más legible. Esto no significa que ser rápido fuera irrelevante para nosotros, pero reducir a systemd a su velocidad es ciertamente un concepto erróneo, ya que eso no está en absoluto cerca de la cima de nuestra lista de objetivos.

Mito: El arranque rápido de systemd es irrelevante para los servidores

Eso es completamente falso. Muchos administradores están interesados en reducir los tiempos de inactividad durante las ventanas de mantenimiento. En las configuraciones de alta disponibilidad es bueno que la máquina que ha fallado vuelva a arrancar muy rápido. En configuraciones de nube con un gran número de VMs o contenedores el precio de la lentitud se multiplica con el número de instancias. Gastar minutos de CPU y IO en arranques realmente lentos de cientos de VMs o contenedores, reduce la densidad de tu sistema drásticamente, incluso te cuesta más energía. Fast Boot pueden ser bastante caro económicamente. Entonces, el arranque rápido de los contenedores te permite implementar una lógica como los contenedores activados por socket, lo que te permite aumentar drásticamente la densidad de tu sistema en la nube.

Por supuesto, en muchas configuraciones de servidores el arranque es de hecho irrelevante, pero systemd se supone que cubre todo el rango. Y sí, soy consciente de que a menudo es el firmware del servidor el que cuesta más tiempo en el arranque, y el sistema operativo de todos modos rápido en comparación con eso, pero bueno, se supone que systemd todavía debe cubrir toda la gama (véase más arriba…), y no, no todos los servidores tienen un firmware tan malo, y ciertamente no las máquinas virtuales y los contenedores, que son servidores de un tipo, también.

Mito: El sistema es incompatible con los scripts de shell

Esto es completamente 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 que systemd sea incompatible con ellos. Puedes ejecutar fácilmente los scripts de shell como servicios de systemd, puedes ejecutar scripts escritos en cualquier lenguaje como servicios de systemd, a systemd no le importa lo más mínimo lo que hay dentro de tu ejecutable. Además, usamos mucho los scripts de shell para nuestros propios propósitos, para instalar, construir, probar systemd. Y puedes meter tus scripts en el proceso de arranque, usarlos para los servicios normales, puedes ejecutarlos en el último apagado, prácticamente no hay límites.

Mito: Systemd es difícil

Esto también es un completo sinsentido. Una plataforma systemd es en realidad mucho más simple que los Linux tradicionales porque unifica los objetos del sistema y sus dependencias como unidades systemd. El lenguaje de los archivos de configuración es muy simple, y nos hemos deshecho de los archivos de configuración redundantes. Proporcionamos herramientas uniformes para gran parte de la configuración del sistema. El sistema es mucho menos conglomerado que los Linux tradicionales. También tenemos una documentación bastante completa (todos enlazados desde la página principal) sobre casi todos los detalles de systemd, y esto no sólo cubre las interfaces de administración y de cara al usuario, sino también las API de los desarrolladores.

Systemd ciertamente viene con una curva de aprendizaje. Todo lo necesita. Sin embargo, nos gusta creer que en realidad es más sencillo de entender systemd que un arranque basado en Shell para la mayoría de la gente. ¿Nos sorprende que digamos eso? Bueno, resulta que Shell no es un lenguaje bonito de aprender, su sintaxis es arcana y compleja. Los archivos unitarios de systemd son sustancialmente más fáciles de entender, no exponen un lenguaje de programación, pero son simples y declarativos por naturaleza. Dicho esto, si tienes experiencia en shell, entonces sí, adoptar systemd requerirá un poco de aprendizaje.

Para facilitar el aprendizaje, nos esforzamos por proporcionar la máxima compatibilidad con las soluciones anteriores. Pero no sólo eso, en muchas distribuciones encontrarás que algunas de las herramientas tradicionales te dirán ahora incluso – mientras ejecutas lo que estás pidiendo – cómo podrías hacerlo con las nuevas herramientas en su lugar, de una manera posiblemente más agradable.

De todos modos, la conclusión es que Systemd es probablemente lo más simple que puede ser un sistema de este tipo, y que nos esforzamos en hacer que sea fácil de aprender. Pero sí, si conoces sysvinit entonces adoptar systemd requerirá un poco de aprendizaje, pero francamente si dominas sysvinit, entonces systemd debería ser fácil para ti.

Mito: Systemd no es modular

No es cierto en absoluto. En el momento de la compilación tienes un número de controles de configuración para seleccionar lo que quieres construir, y lo que no. Y documentamos cómo puedes seleccionar con más detalle lo que necesitas, yendo más allá de nuestros interruptores de configuración.

Esta modularidad no es totalmente diferente a la del núcleo de Linux, donde puedes seleccionar muchas características individualmente en tiempo de compilación. Si el kernel es lo suficientemente modular para ti, entonces systemd debería estar bastante cerca también.

Mito: systemd es sólo para escritorios

Eso no es cierto. Con systemd tratamos de cubrir casi el mismo rango que el propio Linux. Mientras que nos preocupamos por los usos de los escritorios, también nos preocupamos de la misma manera por los usos de los servidores, y los usos integrados también. Puedes apostar que Red Hat no lo convertiría en una pieza central de RHEL7 si no fuera la mejor opción para administrar los servicios en los servidores.

Gente de numerosas compañías trabajan en systemd. Los fabricantes de coches lo construyen en los coches, Red Hat lo utiliza para un sistema operativo de servidor, y GNOME utiliza muchas de sus interfaces para mejorar el escritorio. Lo encuentras en los juguetes, en los telescopios espaciales, y en las turbinas de viento.

La mayoría de las características en las que he trabajado más recientemente son probablemente relevantes principalmente en los servidores, como el soporte de contenedores, la gestión de recursos o las características de seguridad. Ya cubrimos bastante bien los sistemas de escritorio, y hay un número de compañías que hacen desarrollo de sistemas para embebidos, algunas incluso ofrecen servicios de consultoría en ello.

Mito: Systemd fue creado como resultado del síndrome de NIH

Esto no es cierto. Antes de que empezáramos a trabajar en systemd estábamos presionando para que el Upstart de Canonical fuera ampliamente adoptado (y Fedora/RHEL también lo usó por un tiempo). Sin embargo, finalmente llegamos a la conclusión de que su diseño era intrínsecamente defectuoso en su núcleo (al menos a nuestros ojos: lo más fundamental es que deja la gestión de la dependencia al administrador/desarrollador, en lugar de resolver este duro problema en el código), y si algo está mal en el núcleo es mejor reemplazarlo, en lugar de arreglarlo. Esta no fue la única razón, sin embargo, otras cosas que entraron en juego, como el acuerdo de licencia/contribución lo estropean. Sin embargo, los NIH no fueron una de las razones…

Mito: Systemd es un proyecto de freedesktop.org

Bueno, systemd está ciertamente alojado en fdo, pero freedesktop.org es poco más que un repositorio de código y documentación. Casi cualquier programador puede solicitar un repositorio allí y volcar sus cosas allí (siempre y cuando sea algo relevante para la infraestructura de los sistemas libres). No hay ninguna cábala involucrada, ningún esquema de “estandarización”, ninguna investigación del proyecto, nada. Es sólo un lugar agradable, libre y fiable para tener su repositorio. En ese sentido es un poco como SourceForge, github, kernel.org, sólo que no es comercial y sin requisitos exagerados, y por lo tanto un buen lugar para guardar nuestras cosas.

Así que sí, alojamos nuestras cosas en fdo, pero la suposición implícita de este mito en que había un grupo de gente que se reunía y luego se ponía de acuerdo en cómo se verían los futuros sistemas libres, es completamente falsa.

Mito: Systemd no es UNIX

Ciertamente hay algo de verdad en eso. Las fuentes de systemd no contienen ni una sola línea de código originado en el UNIX original. Sin embargo, nos inspiramos en UNIX, y por lo tanto hay una tonelada de UNIX en systemd. Por ejemplo, la idea de UNIX de “todo es un archivo” encuentra reflejo en que en systemd todos los servicios están expuestos en runtime en un sistema de archivos del núcleo, el cgroupfs. Entonces, una de las características originales de UNIX era el soporte multipuesto, basado en el soporte de terminal incorporado. Sin embargo, los terminales de texto no son lo habitual en cuanto a la forma de interactuar con el ordenador de manera gráfica. Con systemd trajimos de vuelta el soporte nativo multiaseat, pero esta vez con soporte completo para el hardware de hoy en día, cubriendo gráficos, ratones, audio, cámaras web y más, y todo eso totalmente automático, con capacidad de conexión en caliente y sin configuración. De hecho, el diseño de systemd como un conjunto de herramientas integradas que cada una tiene sus propósitos individuales, pero que cuando se usan juntas son más que la suma de las partes, eso es más o menos el núcleo de la filosofía de UNIX. Entonces, la forma en que nuestro proyecto se maneja (es decir, manteniendo gran parte del SO central en un único repositorio git) está mucho más cerca del modelo BSD (que es un verdadero UNIX, a diferencia de Linux) de hacer las cosas (donde la mayoría del SO central se mantiene en un único repositorio CVS/SVN).

En última instancia, UNIX es algo diferente para todos. Para nosotros los mantenedores de sistemas es algo en lo que nos inspiramos. Para otros es una religión, y al igual que las otras religiones del mundo hay diferentes lecturas y comprensiones de él. Algunos definen el UNIX basándose en piezas específicas de patrimonio de código, otros lo ven sólo como un conjunto de ideas, otros como un conjunto de comandos o APIs, e incluso otros como una definición de comportamientos. Por supuesto, es imposible hacer feliz a toda esta gente.

En última instancia, la cuestión de si algo es UNIX o no importa muy poco. Ser técnicamente excelente no es algo exclusivo de UNIX. Para nosotros, UNIX es una influencia importante (diablos, la más grande), pero también tenemos otras influencias. Por lo tanto, en algunas áreas el sistema será muy UNIX, y en otras un poco menos.

Mito: Systemd es complejo

Ciertamente hay algo de verdad en eso. Las computadoras modernas son bestias complejas, y el sistema operativo que se ejecuta en ellas, por lo tanto, tendrá que ser complejo también. Sin embargo, systemd no es ciertamente más complejo que las implementaciones anteriores de los mismos componentes. Más bien, es más simple, y tiene menos redundancia (ver arriba). Además, la construcción de un sistema operativo simple basado en systemd implicará muchos menos paquetes que un Linux tradicional. Menos paquetes facilita la construcción de su sistema, se deshace de las interdependencias y de gran parte del diferente comportamiento de cada componente involucrado.

Mito: Systemd está hinchado

Bueno, hinchado ciertamente tiene muchas definiciones diferentes. Pero en la mayoría de las definiciones, “sistémico” es probablemente lo opuesto a “hinchado”. Dado que los componentes systemd comparten una base de código común, tienden a compartir mucho más código para rutas de código comunes. He aquí un ejemplo: en una configuración tradicional de Linux, sysvinit, start-stop-daemon, inetd, cron, dbus, todos implementaron un esquema para ejecutar procesos con varias opciones de configuración en un cierto, esperemos que limpio, entorno. En systemd se comparten las rutas del código para todo esto, para el análisis de la configuración, así como la ejecución real. Esto significa menos código, menos lugar para los errores, menos memoria y presión de caché, y por lo tanto es algo muy bueno. Y como efecto secundario, se obtiene una tonelada más de funcionalidad para ello…

Como se mencionó anteriormente, systemd también es bastante modular. Puedes elegir en el momento de la construcción qué componentes necesitas y cuáles no. Por lo tanto, la gente puede elegir específicamente el nivel de “hinchazón” que quiere.

Cuando construyes systemd, sólo requiere tres dependencias: glibc, libcap y dbus. Eso es todo. Puede hacer uso de más dependencias, pero éstas son totalmente opcionales.

Así que, sí, de cualquier manera que se mire, no está realmente hinchado.

Mito: El hecho de que system sólo exista en Linux no es agradable para los BSD

Completamente equivocado. La gente de BSD no está interesada en systemd. Si systemd fuera portable, esto no cambiaría nada, aún así no lo adoptarían. Y lo mismo es cierto para los otros Unixes en el mundo. Solaris tenía SMF, BSD tiene su propio sistema “rc”, y siempre lo mantuvieron separado de Linux. El sistema de inicio está muy cerca del núcleo de todo el sistema operativo. Y estos otros sistemas operativos por lo tanto se definen a sí mismos entre otras cosas por su espacio de usuario central. La suposición de que adoptarían nuestro espacio de usuario central si lo hiciéramos portátil, no tiene ningún fundamento.

Mito: El hecho de que systemd sea sólo para Linux hace imposible que Debian lo adopte por defecto

Debian soporta núcleos que no son de Linux en su distribución. Systemd no funcionará con ellos. Sin embargo, ¿es eso un problema, y debería eso impedirles adoptar systemd como predeterminado? En realidad no. La gente que adaptó Debian a estos otros núcleos estaba dispuesta a invertir tiempo en un esfuerzo masivo de adaptación, establecieron sistemas de prueba y construcción, y parchearon y construyeron numerosos paquetes para su objetivo. El mantenimiento tanto de un archivo de unidad del sistema como de un clásico script de inicio para los servicios empaquetados es una cantidad de trabajo insignificante comparado con eso, especialmente porque esos scripts la mayoría de las veces ya existen.

Mito: Systemd podría ser portado a otros núcleos si sus mantenedores lo quisieran

Eso simplemente no es cierto. Portar systemd a otro núcleo no es factible. Usamos demasiadas interfaces específicas de Linux. Para unos pocos uno podría encontrar reemplazos en otros kernels, algunas características que uno podría querer desactivar, pero para la mayoría esto no es realmente posible. Aquí hay una pequeña y muy incomprensible lista:

cgroups, fanotify, umount2(), /proc/self/mountinfo (incluida notificación), /dev/swaps (igual), udev, netlink, la estructura de capacidades, espacios de nombres de todo tipo, varias prctl/sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, l()s, numerosos ioctls, el montaje() la llamada al sistema y su semántica, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ...

Y no, si miras esta lista y escoges los pocos donde puedes pensar en contrapartidas obvias en otros núcleos, entonces piénsalo de nuevo, y mira los otros que no escogiste, y la complejidad de reemplazarlos.

Mito: Systemd no es portable 

¡Sin sentido! Usamos la funcionalidad específica de Linux porque la necesitamos para implementar lo que queremos. Linux tiene tantas características que UNIX/POSIX no tenía, y queremos potenciar al usuario con ellas. Estas características son increíblemente útiles, pero sólo si son realmente expuestas de manera amigable para el usuario, y eso es lo que hacemos con systemd.

Mito: Systemd utiliza archivos de configuración binarios

No tengo idea de quién inventó este loco mito, pero no es en absoluto cierto. Systemd se configura casi exclusivamente a través de simples archivos de texto. Algunos ajustes también pueden ser alterados con la línea de comando del kernel y a través de variables de entorno. No hay nada binario en su configuración (ni siquiera XML). Sólo archivos de texto simples y fáciles de leer.

Mito: Systemd es inflexible

Bueno, systemd ciertamente cubre más terreno que antes. Ya no es sólo un sistema de inicio, sino el bloque básico de construcción de espacio de usuario para construir un sistema operativo, pero nos aseguramos de mantener la mayoría de las características opcionales. Puedes desactivar muchas en tiempo de compilación, e incluso más en tiempo de ejecución. De esta manera puedes elegir libremente la cantidad de características que quieras.

Mito: el sistema te obliga a hacer algo malo

Systemd no es la mafia. Es Software Libre, puedes hacer con él lo que quieras, y eso incluye no usarlo. Eso es más o menos lo contrario de “forzar”.

Mito: systemd hace imposible ejecutar syslog

No es cierto, nos aseguramos cuidadosamente cuando introdujimos journal que todos los datos también se pasan a cualquier demonio syslog que se esté ejecutando. De hecho, si algo cambió, entonces sólo ese syslog obtiene datos más completos ahora que antes, ya que ahora cubrimos las primeras cosas de arranque así como STDOUT/STDERR de cualquier servicio del sistema.

Mito: Systemd es incompatible

Nos esforzamos mucho por proporcionar la mejor compatibilidad posible con sysvinit. De hecho, la gran mayoría de los scripts de inicio deberían funcionar bien en systemd, sin modificar. Sin embargo, en realidad hay algunas incompatibilidades, pero tratamos de documentarlas y explicar qué hacer al respecto. En última instancia, cada sistema que no es realmente sysvinit tendrá una cierta cantidad de incompatibilidades con él, ya que no compartirá las mismas rutas de código.

Nuestro objetivo es asegurarnos de que las diferencias entre las diversas distribuciones se mantengan al mínimo. Esto significa que los archivos unitarios suelen funcionar bien en una distribución diferente de aquella en la que se escribió, lo que supone una gran mejora con respecto a los clásicos scripts de inicio, que son muy difíciles de escribir de forma que se ejecuten en múltiples distribuciones de Linux, debido a las numerosas incompatibilidades entre ellos.

Mito: Systemd no es programable, debido a su uso de D-Bus

No es cierto. Prácticamente todas las interfaces D-Bus que systemd proporciona también están disponibles en una herramienta de línea de comandos, por ejemplo en systemctl, loginctl, timedatectl, hostnamectl, localectl y similares. Puedes llamar fácilmente estas herramientas desde los scripts de shell, abren prácticamente toda la API desde la línea de comandos con comandos fáciles de usar.

Dicho esto, D-Bus en realidad tiene enlaces para casi cualquier lenguaje de scripts que este mundo conozca. Incluso desde el shell se pueden invocar métodos arbitrarios de D-Bus con dbus-send o gdbus. En todo caso, esto mejora la capacidad de escritura debido al buen soporte de D-Bus en los diversos lenguajes de escritura.

Mito: Systemd requiere que uses algunas herramientas de configuración arcaicas en lugar de permitirte editar tus archivos de configuración directamente

No es cierto en absoluto. Ofrecemos algunas herramientas de configuración, y usarlas le da un poco de funcionalidad adicional (por ejemplo, ¡completar la línea de comandos para todas las configuraciones!), pero no hay ninguna necesidad de usarlas. Siempre puedes editar los archivos en cuestión directamente si lo deseas, y eso es totalmente compatible. Por supuesto, a veces es necesario recargar explícitamente la configuración de algún demonio después de editar la configuración, pero eso es más o menos cierto para la mayoría de los servicios UNIX.

Mito: Systemd es inestable y está lleno de bugs

Ciertamente no, según nuestros datos. Hemos estado monitoreando el rastreador de bugs de Fedora (y algunos otros) de cerca durante mucho tiempo. El número de bugs es muy bajo para un componente tan central del sistema operativo, especialmente si se descuentan los numerosos bugs RFE que rastreamos para el proyecto. Somos bastante buenos en mantener a systemd fuera de la lista de bugs bloqueadores de la distribución. Tenemos un ciclo de desarrollo relativamente rápido con la mayoría de los cambios incrementales para mantener alta la calidad y la estabilidad.

Mito: Systemd no es depurable

Falso. Algunas personas intentan insinuar que el shell era un buen depurador. Bueno, en realidad no lo es. En systemd le proporcionamos características de depuración reales en su lugar. Por ejemplo: depuración interactiva, trazado verboso, la capacidad de enmascarar cualquier componente durante el arranque, y más. Además, proporcionamos documentación para ello.

Es ciertamente bien depurable, lo necesitábamos para nuestro propio trabajo de desarrollo, después de todo. Pero le concedemos una cosa: utiliza diferentes herramientas de depuración, aunque creemos que son más apropiadas para este propósito.

Mito: Systemd hace cambios por el bien de ellos

Es muy falso. Tenemos casi exclusivamente razones técnicas para los cambios que hacemos, y los explicamos en las diferentes piezas de documentación, páginas wiki, artículos de blog, anuncios de listas de correo. Nos esforzamos por evitar hacer cambios incompatibles, y si lo hacemos tratamos de documentar el por qué y el cómo en detalle. Y si te preguntas algo, ¡pregúntanos!

Mito: Systemd es un proyecto sólo de Red-Hat, es propiedad privada de algunos desarrolladores sabelotodo, que lo usan para dar a conocer sus puntos de vista al mundo

No es cierto. Actualmente, hay muchos hackers comprometidos en el árbol de Systemd en Git. De estos, sólo seis están empleados por Red Hat. Los demas son gente de ArchLinux, de Debian, de Intel, incluso de Canonical, Mandriva en su día, Pantheon y un número de gente de la comunidad con plenos derechos de autor. Y con frecuencia cometen grandes cosas, grandes cambios. Entonces, en el 2013 habían 374 individuos con parches en nuestro árbol, y ellos también vinieron de un número de diferentes compañías y antecedentes, y muchos de ellos tienen más de un parche en el árbol. Las discusiones sobre dónde queremos llevar a systemd se hacen al aire libre, en nuestro canal IRC (#systemd en freenode, siempre estás invitado), en nuestra lista de correo, y en los festivales públicos (como el próximo en Brno, estás invitado). Asistimos regularmente a varias conferencias, para recoger comentarios, para explicar lo que estamos haciendo y por qué, como pocos lo hacen. Mantenemos blogs, participamos en redes sociales, y nos esforzamos mucho por explicar el por qué y el cómo hacemos las cosas, y por escuchar los comentarios y averiguar dónde están los problemas actuales (por ejemplo, a partir de esos comentarios compilamos esta lista de mitos que se escuchan a menudo sobre el sistema…).

Lo que la mayoría de los colaboradores de systemd probablemente comparten es una idea aproximada de cómo debería ser un buen sistema operativo, y el deseo de hacer que esto ocurra. Sin embargo, por la naturaleza misma del proyecto siendo de Código Libre, y arraigado en la comunidad systemd es justo lo que la gente quiere que sea, y si no es lo que quieren entonces pueden dirigir la dirección con parches y código, y si eso no es factible, entonces hay numerosas otras opciones para usar, también, systemd nunca es exclusivo.

Un objetivo de systemd es unificar un poco el paisaje disperso de Linux. Tratamos de deshacernos de muchas de las diferencias más inútiles de las diversas distribuciones en varias áreas del núcleo del sistema operativo. Como parte de eso, a veces adoptamos esquemas que fueron previamente usados por sólo una de las distribuciones y lo empujamos a un nivel en el que es el predeterminado de systemd, tratando de llevar suavemente a todos hacia el mismo conjunto de configuración básica. Esto nunca es exclusivo, sin embargo, las distribuciones pueden continuar desviándose de eso si así lo desean, sin embargo, si terminan usando el bien soportado valor por defecto, su trabajo se hace mucho más fácil y pueden obtener una o dos características. Ahora, resulta que la mayoría de las veces adoptamos esquemas en los que los Debianismos, en lugar de los Fedoraismos/Redhatismos son los mejor soportados por systemd. Por ejemplo, los sistemas que ejecutan systemd ahora generalmente almacenan su nombre de host en /etc/hostname, algo que solía ser específico de Debian y ahora se usa en todas las distribuciones.

Sin embargo, una cosa que le concederemos, es que a veces podemos ser muy listos. Tratamos de estar preparados cada vez que abrimos la boca, para poder respaldar con hechos lo que afirmamos. Eso podría hacernos parecer como sabelotodos.

Pero en general, sí, algunos de los contribuyentes más influyentes de systemd trabajan para Red Hat, pero son minoría, y systemd es una comunidad sana y abierta con diferentes intereses, diferentes antecedentes, sólo unificada por unas pocas ideas aproximadas de dónde debería ir el viaje, una comunidad en la que el código y su diseño cuenta, y ciertamente no la afiliación a una empresa.

Mito: Systemd no soporta dividir /usr del directorio raíz

No tiene sentido. Desde sus inicios systemd soporta la opción –with-rootprefix= en su script de configuración que permite decirle a systemd que divida ordenadamente el material necesario para el inicio temprano y el material necesario para más adelante. Toda esta lógica está completamente presente y la mantenemos actualizada ahí mismo en el sistema de construcción de systemd.

Por supuesto, todavía no creemos que arrancar con /usr no disponible sea una buena idea, pero lo apoyamos muy bien en nuestro sistema de construcción. Esto no solucionará los problemas inherentes al sistema que se encontrarán en todo el tablero, pero no se puede culpar a systemd, porque en systemd lo apoyamos perfectamente.

Mito: Systemd no te permite reemplazar sus componentes

No es cierto, puedes apagar y reemplazar casi cualquier parte de systemd, con muy pocas excepciones. Y esas excepciones (como journal) generalmente te permiten ejecutar una alternativa junto a él, mientras cooperas amablemente con él.

Mito: El uso del Bus-D en el sistema en lugar de los sockets lo hace no transparente

Esta afirmación ya es contradictoria en sí misma: D-Bus también utiliza los sockets como transporte. Por lo tanto, siempre que se usa el D-Bus para enviar algo, se usa un socket para eso también. D-Bus es principalmente una serialización estandarizada de mensajes para enviar sobre estos sockets. Esto lo hace más transparente, ya que esta serialización está bien documentada, es entendida y hay numerosas herramientas de rastreo y enlaces de lenguaje para ella. Esto es muy distinto de los protocolos habituales de cosecha propia que utilizan los diversos demonios UNIX clásicos para comunicarse localmente.

Pid Eins

Puedes hacer lo que desees con tu init pero es necesario y transparente hacer resaltar la verdad entre tanta mentira. Systemd no es el diablo, ni es una “mierda” como dicen algunos. Systemd es software libre y hace su trabajo con eficiencia. Sin embargo está de moda demonizar systemd. Systemd es posible que no lleve la filosofía UNIX pero es que no hace falta porque ya lo hace GNU. Esa filosofía UNIX parte de un entorno privativo, GNU lleva la filosofía libre antes que nada. Systemd no es un dictador: Escribe servicios solamente, y el usuario decide de habilitarlos y deshabilitarlo.

Ahora, muchos que despotrican de este humilde blog porque ataco a las distros que vienen con software privativo por defecto ¿nos vienen a decir que el 99% de las distribuciones son malas porque tienen systemd? ¿Quieren decir que yo no puedo hacer un listado de esas distros sucias a la vez que mis ‘amigos’ dicen que el 99% de las distros tienen un init de mierda que ataca la filosofía UNIX? Ah, cuantas vueltas da el mundo. GNU is not UNIX ni falta que le hace.

Soy usuario de systemd como de openRC y ambos son libres. Nunca me gustaron las modas, y la moda es decir que systemd es Satanás.

Entonces adoro a Satanás.

 

Fuente: maslinux

¿Quién está en línea?

Hay 320 invitados y ningún miembro en línea