Lennart_poettering_SystemD

¿Porqué SystemD es el demonio?

SystemD es un sistema de inicio del kernel (a lo que se le suele conocer como init en entornos Unix, como Linux). Fue creado por Lennart Poettering (quien es su máximo valedor) y Kay Sievers trabajando para Red Hat, y tiene licencia LGPL 2.1 (con excepciones licenciadas con GPL 2). Está disponibe en GitHub.

Es un programa que genera una inmensa polémica, del que se está oyendo hablar cada vez más y que es utilizado por la mayoría de distribuciones. Sus detractores son muchos, sin embargo es utilizado cada vez por más distribuciones Linux. Así que surgen las preguntas. ¿Porqué SystemD es tan malo? Y si es tan malo, ¿porqué cada vez más distribuciones lo están utilizando?

Partiendo de que yo soy un total desconecedor de los sistemas de inicio, intentaré adentrarme en esta problemática para aprender un poco en el camino e intentar responder esas preguntas. Es un tema complejo, además, así que este artículo pretende ser una mera aproximación o introducción al tema para que todos podamos empezar a formarnos una idea sobre esta polémica.

Empezaremos comprobando qué es eso de un “sistema de inicio”. Seguiremos aprendiendo un poco de su desarrollo histórico, pues es el que ha llevado a la creación de SystemD. Después aprenderemos sobre sus características, ventajas y defectos o problemas. Pero primero, un par de aclaraciones:

 

 

Programas, procesos y demonios.

 

Siguiendo la recomendación de quien sí sabe bien del tema, vamos a distinguir varias cuestiones:

Un programa es un programa informático o programa de computadora es una secuencia de instrucciones, escritas para realizar una tarea específica en un ordenador.

Un proceso es una instancia en particular, dentro de un programa. En Linux llevan un identificador denominado PID (Process ID). En función del tipo de PID que lleve el proceso, tendrá ciertas características o bien tendrá otras. Un proceso también puede crear otros procesos; en esos casos, al proceso creador se le conoce como “proceso padre”, y a los procesos creados se les conoce como “procesos hijo”.

Un demonio o servicio es un tipo particular de proceso, que funciona en segundo plano (no es controlado directamente por el usuario).

 

 

El inicio y el final de todo.

El sistema de inicio o init, es un demonio especialmente importante en sistemas tipo UNIX. Es el primer proceso en cargarse y ejecutarse; e inicia el espacio de usuario. De él, nacen todos los demás procesos en ese espacio. Mantiene una tabla de procesos activos, lo que es necesario para el buen funcionamiento del sistema; y finalmente es el último proceso en finalizar, al apagar el sistema. Cuando termina init, termina el sistema.

Otra característica importante es que normalmente tiene PID 1. Como decíamos, PID es el identificador de proceso que define ciertas características del mismo. PID 1 se usa en muy pocos casos; permite controlar determinados demonios que se han desligado del proceso padre, pero por otro lado también implica que si el proceso con ID 1 termina, el sistema se cae.

 

 

Un poco de historia.

Tradicionalmente los demonios init han sido de dos tipos: estilo BSD y estilo System V. Ambos estilos lanzaban los servicios mediante una secuencia prefijada.

El estilo BSD establece un único scrip de inicialización en /etc/rc, que lanza todos los servicios. No hay niveles de ejecución (runlevels), el archivo /etc/rc determina qué programas se ejecutan por init. La ventaja de este sistema es que es simple y fácil de editar manualmente, aunque sujeto a errores. Era el estilo del UNIX original, y destacablemente sigue siendo utilizado por defecto en Slackware.

El estilo System V, en el que destaca SysVinit, funciona mediante runlevels, con diferentes scripts que establecen el estado (arranque/parada) de cada servicio en el directorio /etc/rc.d/. Era utilizado por muchas otras distribuciones, como Debian o Arch.

Debido al tiempo transcurrido desde la creación de esos estilos, ha surgido la necesidad de crear opciones más potentes y adaptadas a las necesidades y capacidades actuales de los kernel y sistemas operativos. Nombraremos en particular OpenRC, y Upstart.

OpenRC es el sistema de inicio por defecto en Gentoo (aunque también es admitido por otras distribuciones, como por ejemplo Arch Linux aunque sin soporte oficial). Este sistema de inicio es parcialmente compatible tanto con BSD como con SistemV, y está basado en dependencias (Gentoo también admite SystemD, si alguien prefiere utilizarlo). Una de sus ventajas sobre los anteriores sistemas, es que admite la paralelización de procesos; esto es, mientras que en los sistemas anteriores cada proceso era lanzado de forma secuencial, uno detrás de otro según cierto orden, en OpenRC es posible trabajar con más de un proceso a la vez. Como resultado, se consigue un ahorro de tiempo al inciar el sistema. Sin embargo, la paralelización puede causar problemas importantes, y OpenRC la admite de forma opcional hasta que sean solventados. Además, otras características a destacar son que OpenRC puede utilizarse con otros kernels además de Linux, y admite el manejo de procesos mediante cgroups (Control Groups), una característica que permite el kernel Linux. Veamos: a medida que un proceso (proceso “padre”) crea otro proceso (proceso “hijo”), y este a su vez crea un tercer proceso (proceso “nieto”), y este crea tal vez otro proceso más (proceso “bisnieto”); se va dificultando el control del primer proceso, respecto a los proceso más alejados. Esto puede dificultar, por ejemplo, la finalización de los procesos más alejados, quedando descolgados a su aire cuando el primer o el segundo proceso son finalizados (a esto se le conoce como “procesos zombies”). Cgroups soluciona este problema estableciendo grupos de procesos a los que se le asigna determinadas características, y en particular la característica “ser dependiente del proceso padre”). Entonces, si un proceso padre es finalizado, todos los procesos agrupados con él también son finalizados. Pero no sólo esa característica es asignable a un proceso, también son asignables muchas otras como por ejemplo el límite de memoria a utilizar.

Por su parte, Upstart fue creado por Canonical para Ubuntu (por lo que fue ampliamente utilizado por muchos usuarios). También fue adoptado por otras distribuciones, y constituyó tal vez el intento más importante para sustituir los antiguos init. Upstart tampoco lanzaba los servicios de forma prefijada, sino respondiendo a “eventos” previos. Esto le permite lanzar servicios de forma paralela, obteniendo la consiguiente ganancia de tiempo, aunque también implica el peligro de que determinados procesos se inicien ANTES de otros procesos que necesitan previamente. Para evitarlo, Upstart también incluye un sistema de dependencias entre los diferentes procesos. Sin embargo, como sabemos incluso Canonical ha abandonado Upstart para pasarse a SystemD.

 

 

Como funciona SystemD.

SystemD fue creado por Red Hat, como un sustituto más moderno de init. Entre sus ventajas podemos destacar que, al igual de Upstart, permite lanzar los servicios paralelamente. Pero a diferencia de la creación de Canonical, no necesita dependencias. En su lugar, crea sockets para cada servicio; esto significa que el servicio está precargado en memoria, pero no está activo. Los programas pueden incluso escribir en esos sockets, pero sin leerlos ni iniciarlos. Esos sockets sólo son leídos e iniciados cuando es necesario utilizar ese servicio en particular.

Otra ventaja de SystemD radica en su manejo de los puntos de montaje. Para iniciarse, algunos servicios necesitan que su punto de montaje estén efectivamente montado. SystemD, al igual que ocurre con la precarga en memoria de los servicios, pre-crea los puntos de montaje necesarios, pero sin llegar a montarlos realmente. A medida que cada servicio lo necesite, irá montándolos de verdad.

Otra característica de SystemD es que al igual que OpenRC, también utiliza los cgroups.

Por último destacaremos que SystemD define un sistema de “Units”. Son archivos de configuración de los recursos que el sistema conoce y puede emplear: servicios, puntos de montaje,el sistema de archivos, la swap, etc. Cada unit define características para ese recurso, permitiendo controlar el recurso de forma independiente a otros recursos. Este sistema es muy potente, y permite hacer muchísimas cosas, permitiendo sustituir o eliminar determinados programas o procesos del sistema o incluso de otros programas. Pero, justamente esto es algo que sus detractores no quieren que haga un simple init…

 

 

KISS: estúpido, simple y estable. (definición de lo que no es SystemD).

SystemD, que funciona con el kernel linux, no es UN demonio, sino un conjunto de VARIOS demonios , creados desde una perspectiva unificadora tanto del sistema operativo concreto como de las diversas distribuciones linux: su objetivo es, por una parte, establecer un administrador de sistema y de servicios; una plataforma de desarrollo de software, y una conexión entre las aplicaciones y el núcleo de Linux. Y por otra parte, eliminar diferencias entre las diversas distribuciones de GNU/Linux.

En esta oración, leemos varias aberraciones para las filosofías KISS, UNIX/Linux y de libertad que guían a buena parte de la comunidad. La filosofía KISS implica que un software debe ser lo más simple posible (en su propio funcionamiento), de tal forma que también será muy estable. Esto va en línea con la filosofía UNIX de que un software sirva para una única función. Y todo ello en un contexto de software libre con código abierto que otorguen al usuario libertad y control en sus propio sistema y software, pudiendo modificarlo y variarlo tanto como quiera o necesite, si es que tiene los conocimientos para hacerlo. Así que veamos con mayor detenimiento todos estos problemas, y las críticas que hacen los destractores de SystemD.

En primer lugar, SystemD funciona con el kernel Linux, y punto. No es compatible con otros kernels. Esto es algo negativo de por sí. Sin embargo, este nivel de dependencia respecto al kernel puede ser considerado el punto de partida para el control sobre todo el ecosistema GNU/Linux, y también tiene otras implicaciones: el nivel de unidad entre el kernel Linux y SystemD es tal que SystemD es incompatible con versiones diferentes del kernel. Así, por ejemplo SystemD está muy atado a funcionar con glibc , resultando incompatible con otras librerías.

SystemD no es simple ni cumple una única función. Es un programa muy complejo formado por diversos demonios que, lejos de limitarse a las funciones de init, está absorbiendo cada vez más funciones, procesos y demonios. Por ejemplo, el control de energía, manejo de puntos de montaje, encriptación de discos, configuración de red, etc. Miremos más atentamente el manejo de puntos de montaje. Éste proceso está controlado por udev que es el gestor de dispositivos del kernel Linux Su función es controlar los ficheros de dispositivo en /dev. Sin embargo, udev ha pasado a estar integrado en SystemD. Todos los programas que necesiten a udev como dependencia, ahora también dependen de Systemd.

Otro problema es el manejo de journal, un sistema de registro de incidencias que permite solucionar fácilmente fallos del sistema. SystemD ha modificado la forma en que trabaja respecto a opciones anteriores, haciéndola más compleja. Maneja journal mediante código binario fácilmente corruptible, además de otras problemáticas.

Todo esto tiene implicaciones preocupantes. Como el programa es cada vez más complejo, adquiere cada vez más código que puede fallar y colapsar al propio SystemD. Pero, recordemos, SystemD tiene PID 1. Si SystemD colapsa, también colapsa todo el sistema operativo. Peor aún es si SystemD colapsa debido a procesos que si fuesen independientes, no tendrían jamás PID 1 (y al colapsar no causaría daños tan graves). Por ejemplo, que por fallar udev colapse SystemD, y por tanto también el sistema entero.

De igual forma es cada vez más difícil o complejo poder revisar el programa para pulirlo y detectar deficiencias.

Pero, decíamos que SystemD tiene una perspectiva de “control unificado” por así decir, sobre el sistema (como acabamos de ver), abarcando cada vez más y más procesos. Pero por otro lado, también tiene una perspectiva unificadora sobre el ecosistema GNU/Linux: el objetivo es eliminar “diferencias sin sentido entre distribuciones”. Esto es repulsivo para muchas personas que precisamente, algo que aman del software libre en general y de GNU y Linux en particular, es que puede modificarse tanto como sea necesario. De hecho, no sólo diferentes pueden querer sistemas operativos que trabajen de diferentes maneras según los intereses de esas personas; incluso una misma persona puede querer usar diversos sistemas operativos que se ajusten a necesidades o gustos diversos.

 

 

SystemD, ¿sí o no?

La decisión de utilizar SystemD depende o bien de decisiones empresariales, como podría ser el caso de Ubuntu, o bien de decisiones tomadas por la comunidad correspondiente, como podría ser el caso de Arch. La decisión no es nada fácil, y SystemD no es la solución perfecta y definitiva. Pero es indudable que SystemD aporta beneficios indudables. Es por ello que tantas empresas y comunidades muy diferentes entre sí no lo habrían adoptado. A cambio, tiene también defectos muy serios, limitando la libertad del usuario y añadiendo numerosos puntos débiles que por sí mismos pueden colapsar el ordenador o incluso ser atacados por crackers y delincuentes. Lo deseable sería que cada quien pueda valorar si desea utilizar SystemD u otro init, y que la distribución que utilice le permita efectivamente usar alternativas a SystemD sin problema alguno… aunque esto parece cada vez más y más difícil. Aunque diversas distribuciones con SystemD por defecto tienen la opción de emplear sistemas de inicio alternativos a SystemD, estas alternativas son eso mismo: alternativas a “lo oficial” o a “lo predeterminado”. La información disponible es mucho menor, y no suele comentarse esas opciones antes de instalar la distribución; de tal forma que para muchos usuarios no existe alternativa a SystemD porque, para empezar, ni siquiera saben que su sistema operativo utiliza algo llamado Systemd. La falta de información es aquí el problema principal. Dada la naturaleza expansiva de SystemD, es probable que este proceso vaya en aumento, al convertirse o necesitarse cada vez más alternativas a procesos o programas absorvidos por SystemD.

Y hasta aquí va este pequeño resumen. A partir de los enlaces anteriores podéis ahondar en este tema. Cualquier defecto del artículo es culpa mía, y no de ellos. En particular es recomendable este artículo del blog linuxito, donde podéis comprobar más críticas a aspectos técnicos de SystemD. Espero que os haya interesado el artículo, y tal vez hayamos podido aprender algo juntos.

 

Nota: Derechos de autor de la imagen.

29 COMENTARIOS

  1. […] de systemd y usan su propio sistema de inicio ), Si queréis saber un poco más al respecto, en este blog lo explican con más […]

  2. Solo añadir dos cosas, si un servicio, socket o unidad falla, no falla todo systemd y el sistema como lo dices, simplemente se notifica el error y se puede reiniciar el servicio, socket o unidad fácilmente (es una de sus ventajas). Por otro lado el diseño de systemd no es nuevo y GNU fue la primera en plantear la idea de crear un administrador de sistema basado en daemos (DMD actualmente GNU Shepherd) y fue el primer reemplazo pensado para sysvinit.
    Lo segundo lo mencioné indirectamente. El concepto es daemon y no “demonio”. Esa es una tradución/interpretación muy equivocada y si se busca más a fondo, en español lo más cercano sería “ángel de la guarda”.

  3. Solo añadir dos cosas, si un servicio, socket o unidad falla, no falla todo systemd y el sistema como lo dices, simplemente se notifica el error y se puede reiniciar el servicio, socket o unidad fácilmente (es una de sus ventajas). Por otro lado el diseño de systemd no es nuevo y GNU inició con la idea de crear un administrador de sistema basado en daemos (DMD actualmente GNU Shepherd) y fue el primer reemplazo pensado para sysvinit.
    Lo segundo lo mencioné indirectamente. El concepto es daemon y no “demonio”. Esa es una tradución/interpretación muy equivocada y si se busca más a fondo en español lo más cercano sería “ángel de la guarda”.

  4. Gracias a systemd he dado el salto definitivo a OpenBSD. Este sistema es mucho más que una excelente alternativa y está 100% libre de esta aberración.

  5. […] de systemd y usan su propio sistema de inicio ), Si queréis saber un poco más al respecto, en este blog lo explican con más […]

  6. Gran artículo incluso para neófitos en ese campo. Me ha aclarado un poco las polémicas de lo que leo por ahí… Gracias

  7. Ya que te tomaste el trabajo de escribir tan extenso artículo, voy a hacerte algunas correcciones a modo de aporte. Espero no lo tomes a mal.

    1. “SystemD es un sistema de inicio del kernel”.

    No, es un sistema de inicio de userland, al kernel lo inicia el bootloader, y es el propio kernel que le da vida al PID 1 (en este caso systemd) para iniciar userland.

    2. “En función del tipo de PID que lleve el proceso, tendrá ciertas características o bien tendrá otras.”

    Esto es una falacia. El PID no dice nada de las características de un proceso. Es como el DNI, no dice nada acerca de una persona, sólo es un numero para identificarla.

    3. “BSD […] Era el estilo del UNIX original, y destacablemente sigue siendo utilizado por defecto en Slackware.”

    Falso, Slackware utiliza un sistema de inicio propio que es un híbrido entre BSD y System V. No se ajusta a ninguno de los dos y tiene características de ambos.

    4. Esto puede dificultar, por ejemplo, la finalización de los procesos más alejados, quedando descolgados a su aire cuando el primer o el segundo proceso son finalizados (a esto se le conoce como “procesos zombies”)

    Error. Cuando se mata a un proceso sus hijos aún en ejecución son heredados por init, y continúan ejecutando normalmenten hasta que finalizan o alguien los “mata” (otro proceso con privilegios suficientes, el usuario con la herramienta kill). Un proceso “zombie” es un proceso que ha finalizado pero su padre no ha capturado el código de retorno, por lo que éste queda ocupando un espacio en la tabla de procesos sin que el proceso exista, a esto se llama proceso “zombie” o “defunct”, difunto (man ps), no existe como tal, sólo ha quedado una entrada en la tabla de procesos.

    5. “Entre sus ventajas podemos destacar que, al igual de Upstart, permite lanzar los servicios paralelamente.”

    Es verdad. Pero este es uno de los tantos argumentos que los Administradores de Sistemas (Sysadmins) consideramos desventaja más que ventaja. En un servidor no es una característica deseable que los servicios inicien en paralelo por varios motivos.

    Me parece muy bueno el artículo y sólo quisiera agregar que a medida que pasa el tiempo, systemd muestra su verdadero rostro: agregar complejidad innecesaria donde no la había y tomar el control de la comunidad GNU/Linux como un todo, para que Red Hat potencie su modelo de negocio, que es la venta de soporte, capacitación y servicios:

    Palabras del CTO de Red Hat en una entrevista allá por el año 2006:

    “Red Hat’s model works because of the complexity of the technology we work with. An operating platform has a lot of moving parts, and customers are willing to pay to be insulated from that complexity.”

    Saludos y gracias por compartir mi artículo.

    • Muchas gracias por los comentarios y las estupendas clarificaciones, por supuesto que no me las tomo a mal, sino que al contrario, las agradezco mucho. Lo único que me sienta mal es no haber puesto esos puntos correctamente en el texto.

      En lo referente al punto 1, en parte es porque me expresé mal (ya que quería decir que SystemD trabaja con el kernel linux en particular), pero has dejado más claro el que es el kernel quien lanza el init.

      En lo referente al punto 5, hablas de servidores. En otros aparatos que no sean servidores, ¿sí es positiva la paralelización?

      • En sistemas de escritorio es una característica deseable porque el usuario quiere levantar la tapa de la notebook y que esté el escritorio listo.
        El gran problema es justamente esto, una característica contrapuesta entre sistemas de escritorio y servidores, systemd puede ser algún día un buen sistema de inicio para desktops (aunque dudo que lo sea) pero no así para servidores, que requieren ser estables y robustos. Entonces Debian y otras distros con gran llegada en el terreno de servidores deberían dar la posibilidad de elegir qué sistema de inicio utilizar, en lugar de forzar el uso de un sistema de inicio que tal vez está orientado al escritorio, o al menos no es adecuado para servidores
        Algunos tuxlibanes se ofenden, pero el terreno de servidores el más importante, claro está. Los usuarios desktop de Linux son extremadamente pocos, mientras que en servidores Linux es el rey.

        • Yo prácticamente soy un usuario de Linux de escritorio que opta más por mejorar las cosas primero bajo el capó y luego la carcasa. Gracias a Debian y Slackware es que aprendí a tener un entorno de escritorio ideal para cualquier ocasión, y básicamente prefiero primero solucionar el problema de raíz antes que meter las cuatro patas a la hora de improvisar una solución.

          Con SystemD, creo que me tomaré un par de años como mínimo para conocer bien al Kraken que gestiona el arranque de la distro, porque si no lo hago, pueda que me toque un servidor con SystemD y con un epic fail que pueda que tenga una solución sencila o compleja (espero que no ocurra semejante situación, pero cualquier cosa puede pasar). En mi caso, me la pasé como dos o tres años para comprender la naturaleza desastrosa de los BSoD y del kernel NT para poder así dar soluciones certeras y no un “formatea no’ más” como otros help deskers mediocres.

  8. El motivo porque cada vez más distros lo eligien es porque al desarrollador lo libera de la tarea de ponerse a escribir scripts y estudiar el desencadenado de arranque. Aquí un desarrollador de Arch lo explica de forma completa https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc

    Al día de la fecha no hay software que imite lo de systemd. Creo que de ambos lados tenemos buenas intenciones para con Linux y GNU. No tiene sentido ese movimiento en contra de su creador., como tampoco cierto bullying a devuan. ¿Que ganan con eso? Nunca estarán de acuerdo. He observado en reddit principalmente a desarrolladores de debian alterarse con el tema.

    No es el camino irse para BSD (aunque algunos quieran echarlos). No ha pasado ni pasará esa premonición sobre que se verán obligados a usar systemd.

    Systemd no es un proyecto GNU, y tampoco pertenece al Kernel Linux. Está al medio, y sufre por esto. Quiere imponer cosas, pero al ser software libre se lo puede sacar del medio con ciertos conocimientos. Gentoo hasta reafirmó su OpenRC/eudev.

    • Gracias por la aclaración y el enlace. Creo que siempre habrá quien quiera liarse con los detalles para tener mayor conocimiento y control sobre “el programa que sea”, en este caso el init. En la/s comunidad/es linux, creo que siempre habrá quien huya del dominio que busca SystemD y siempre habrá alternativas. También BSD es alternativa, pero creo que sí que habrá alternativas también con el kernel linux.

  9. Gracias por la lectura. Ha sido muy interesante pero creo que cuando dices casi al final “Es por ello que tantas empresas y comunidades muy diferentes entre sí no lo habrían adoptado” te estás equivocando. Desde mi punto de vista el motivo de tanta adopción por parte de las distros, a mi entender, reside en la enorme cantidad de dependencias que genera y hoy por hoy es casi imposible sobrevivir sin él quiera uno o no. La prueba es los enormes costes en tiempo que tiene la gente de Devuan para hacer un Debian sin systemd. Sinceramente espero que triunfen y consigan publicar lo que llaman la Free Badge (si no recuerdo mal), con ello podrían conseguir que todas las distros que lo quisieran podrían poner nuevamente el init de su elección (incluso systemd) o por lo menos dejar al usuario final esa elección que de momento nos han robado ya que así lo entiendo yo. Estamos en la tierra del software libre y nos han colado (a todos) un troyano por el cual nos han quitado la libertad de elegir lo cual es bastante curioso y el panorama que se presenta indica que la cosa va a mas.

    Gracias nuevamente por tu artículo.

  10. Primero que nada muy buen artículo, aunque al poner systemD y no systemd demuestra una cierta bajada de linea del autor que rompe un poco con la objetividad del artículo.
    * Con respecto al uso de systemd diría simplemente que es genial.
    * Sobre el tema de sus múltiples demonios que lo hacen algo mucho mas que un simple init cabe descartar que distribuciones como debian permiten elegir que funciones de systemd activar o no. y que también se pueden utilizar otro init diferente como sysvinit aunque sobre systemd (udev)
    * La gente de devuan están desarrollando un fork de udev que no dependa de systemd con lo cual se eliminaría la dependencia de systemd que tienen en la actualizad otros programas
    * si bien journal es genial, tambien se puede desactivar y tener los log tradicionales.

    Mi postura es que distribuciones como debian tienen que permitir el no uso de systemd porque
    * es un int que genera mucha polemica y desconfianza dividiendo a los usuarios
    * mandó a archivo a proyectos como Debian Hurd y Debian GNU/kFreeBSD

    • Gracias por las aclaraciones. El último punto del artículo es un poco mi opinión personal, seguramente debí marcar bien eso.

  11. SystemD tiene MUCHOS más inconvenientes,peligros y errores que ventajas;pero el que más importa,es el que atañe directamente al corazón de lo que a sido GNU/Linux desde su inicio:Libertad y Comunidad,esto es:Diversidad,respeto,sencilles….SystemD lo unico que augura es un mal futuro para Linux.
    Si tan solo FreeBSD fuera un sistema de escritorio tan poderoso,fiable y estable como es en el campo de los servidors,yo ya me habría cambiado desde que entendí por vez primera el peligro de SystemD:backdoors,unificación forzosa,spyware,etc
    Una lástima.
    Yo recomiendo que dejen Linux y comienzen a usar FreeBSD;entre más usuarios tenga,mejor será su desarollo en el escritorio.

  12. Muchas gracias por el artículo, está muy bien y de un tema de actualidad que sigue bastante difuso. Yo simplemente voy a poner la puntillita en “KISS: estúpido, simple y estable. “, que realmente no es eso, sino Keep It Simple, Stupid (o Keep It Smple and Stupid como dicen en Antergos) pero no hablan nunca de estabilidad xD y ojo, que a mí Arch y sus variantes me parecen cremita y suelen ser muy estables, al menos bajo mi experiencia (de hecho, escribo desde Manjaro)

    • Quería hacer un guiño a Slackware, ya que he tomado por válida la wikipedia española. Dice la entrada de Slackware:
      “Según la página oficial de Slackware el término KISS se refiere a keep it simple stable, que traducido sería manténgalo simple y estable.”

      Después he visto más páginas que dicen lo mismo, pero es porque copian la wikipedia. No he encontrado esa referencia en la página oficial de Slackware, lo que no quiere decir que no esté en algún lugar, o que lo haya estado anteriormente.

      No habría puesto la palabra ahora, pero como indicas parece que hay diferentes variantes al significado de KISS. Eso sí,también parece que en general, la simplicidad KISS es una gran ayuda a la estabilidad del programa.

  13. Información Bitacoras.com

    Valora en Bitacoras.com: ¿Porqué SystemD es el demonio? SystemD es un sistema de inicio del kernel (a lo que se le suele conocer como init en entornos Unix, como Linux). Fue creado por Lennart Poettering (quien es su máximo valedor) y Kay Sievers …

DEJA UNA RESPUESTA

Por favor, introduzca su comentario!
Por favor, introduzca su nombre aquí