Por qué deberias dejar de usar SYSTEMD - Parte II
Fecha: vie 24 sep 2021 23:21:42 CET
Segunda parte del artículo "Por qué deberias dejar de usar SYSTEMD" en:
Mucha gente piensa erróneamente que los componentes de systemd son independientes, pero eso no es cierto. Eche un vistazo al código y la documentación y observe la estrecha integración entre muchos de estos denominados módulos.
Systemd hoy se ha convertido en una especie de caballo de Troya, en un intento de Red Hat de cambiar el mundo de Linux para servir mejor a sus intereses corporativos.
Tanto el kernel como las herramientas GNU y las distribuciones comenzaron como proyectos impulsados por la comunidad, pero la mayor parte del desarrollo actual está motivado por intereses corporativos, impulsados por desarrolladores que ocupan puestos clave en diferentes empresas, como como Red Hat, Google, Facebook, etc.
Red Hat primero disfrazó sus planes llamando a systemd a un sistema de inicialización alternativo. Luego se reveló la verdad y systemd se convirtió en "un conjunto de software que proporciona bloques de construcción fundamentales para un sistema operativo Linux". Luego, Red Hat lanzó una campaña masiva para influir en todas las demás distribuciones principales de Linux y las presionó para que adoptaran systemd.
Los desarrolladores de systemd abordaron varios proyectos de terceros y trataron de convencerlos para que sus proyectos dependieran de systemd (Lennart Poettering en la lista de correo de Gnome o el intento de "keszybz" en el proyecto tmux). La mayoría de estos intentos se disfrazaron como problemas técnicos, sin embargo, cuando uno lee la larga correspondencia por correo electrónico en la lista de correo de Gnome y en otros lugares, la intención real se vuelve bastante clara.
Otras tácticas implementadas por Red Hat fueron contratar desarrolladores de GNOME y otras distribuciones de Linux, como Debian, y luego hacer que estas personas promovieran systemd.
Tras un gran alboroto, el desarrollador de Debian Joey Hess, los miembros del Comité Técnico de Debian Russ Allbery e Ian Jackson y el mantenedor de paquetes systemd Tollef Fog Heen renunciaron a sus puestos. Las justificaciones principales de todos fueron sobre la integración de systemd dentro de Debian y la comunidad de código abierto que hacían prácticamente imposible el mantenimiento regular. En 2014 aparecía Devuan. Los hechos están más que probados:
Hecho 1: Systemd es de Red Hat
Lennart Poettering y Kay Sievers, que iniciaron el proyecto systemd en 2010, son empleados de Red Hat, y aunque inicialmente se presentó como un nuevo sistema de inicio, luego se ha visto en qué se ha convertido.
Hecho 2: Intereses comerciales en los dispositivos integrados
El negocio principal de Red Hat son los dispositivos integrados, y las preocupaciones principales que aborda systemd por diseño son los dispositivos integrados. Un director ejecutivo de Red Had, Jim Whitehurst, afirmó la asociación con proveedores integrados más grandes del mundo, particularmente en las industrias de telecomunicaciones y automotriz. Se adaptaron fácilmente a systemd porque systemd está diseñado específicamente para satisfacer sus necesidades.
En 2012, Lennart Poettering cambió la licencia systemd de GPL a LGPL para adaptarse mejor al mercado integrado.
Hecho 3: Systemd es realmente un gran monolito
En su publicación de blog "The Biggest Myths", de enero de 2013, Lennart Poettering niega que Systemd sea un "monolito" y afirma que involucra 69 binarios individuales, por lo que difícilmente puede llamarse monolítico. Pero resulta que muchos de esos binarios tienen una funcionalidad que simplemente no funcionará sin otros componentes de systemd.
Si echamos un vistazo a la página man de systemd-networkd, se indica claramente que si establece la opción UseDNS como "true" los servidores DNS recibidos del servidor DHCP se utilizarán y tendrán prioridad sobre los configurados estáticamente. Otros componentes de systemd están aún más integrados.
Hecho 4: preocupaciones sobre la privacidad
systemd-resolve tiene servidores DNS alternativos codificados de forma rígida para Cloudflare, Quad9 y Google. Incluso si los desactiva, un error podría hacer que se usen de todos modos (ya ha pasado).
Hecho 5: Red Hat quiere convertirse en el próximo Microsoft Windows
Esta es otra motivación importante en Red Hat y esto se ilustra en las diapositivas de Lennart Poetterings de FUDCON + GNOME (http://0pointer.de/public/gnomeasia2014.pdf). Vaya a la página 15 y avance lentamente hasta la página 19. Finalmente, terminará con los objetivos del proyecto:
- Convierta Linux de una bolsa de bits en un sistema operativo de propósito general competitivo.
- Cree el sistema operativo de próxima generación de Internet.
- Unificando diferencias inútiles entre distribuciones.
- Devolver la innovación al sistema operativo central.
Combinado con el siguiente conjunto de diapositivas que muestran el mercado al que Red Hat desea dirigirse: Escritorio, servidor, embed, móvil, cloud, grupo.
Es precisamente en el sector "Servidor" en el que la mayor parte de funcionalidades de Systemd no tienen ningún beneficio.
Hecho 6: Red Hat necesita otras distribuciones importantes
Red Hat no podía quedarse sola si quería tener éxito. Influyeron de alguna manera en las otras distribuciones principales de GNU/Linux como Debian, ya que si era rechazado Red Hat no podría continuar con sus planes porque a demasiados proyectos no les importaría cómo a Red Hat le gustaría que fueran las cosas.
Con la compatibilidad POSIX en mente, los desarrolladores intentan asegurarse de que su proyecto funcione en sistemas *nix. Esto es algo que no interesa a Red Hat.
Sin esas otras distribuciones rechazando systemd se habría vuelto mucho más difícil para Red Hat conseguir los cambios relevantes para sus intereses.
Consecuencias
No se puede confiar en Red Hat desde el punto de vista de la seguridad y si las Fuerzas Armadas de EEUU o alguna otra organización quiere que Red Hat coloque una puerta trasera en systemd, esto puede pasar fácilmente desapercibido durante muchos años, tal como sucedió con Heartbleed. Va a resultar imposible saber si estos errores se introducen en el código a propósito, disfrazados de errores honestos o si realmente son errores reales.
Por otro lado, si se encuentra un error en la aplicación que hace que los servidores DNS se ejecuten a pesar de que los haya desactivado, es posible que se enfrente a un problema de privacidad grave. Además, ejecutar con Cloudflare, Quad9 y los servidores DNS de Google codificados en el código systemd es profundamente problemático, ya que estas empresas no solo son conocidas por violar la privacidad de las personas, sino también porque la NSA se ha infiltrado previamente en los centros de datos de Google, algo revelado por los documentos de Snowden.
La actitud extremadamente arrogante de Lennart Poettering muestran un total desprecio por la privacidad del usuario y por los intereses de la comunidad Linux de código abierto.
Fuente del extracto y traducción
__________________________________________________________
/news/