¿Es systemd "malicioso"? [cerrado]


11

Al visitar un foro en línea que discute sobre Debian y Xubuntu, vi algunos usuarios que agregan esta línea en el campo de firma:

... Sin systemd ...

Esta línea se muestra con orgullo (me parece).

De Wikipedia :

systemd es un conjunto de demonios, bibliotecas y utilidades de administración del sistema diseñados como una plataforma central de administración y configuración para el sistema operativo de la computadora Linux.

Entonces systemd, no parece una mala cosa, entonces ¿por qué la gente escribe con orgullo que no la usa?

¿Puede systemdser peligroso o simplemente malo para ti?


1
¿Has leído la parte de adopción y recepción de ese artículo de Wikipedia? Tiene referencias a múltiples artículos sobre por qué a algunas personas no les gusta.
Leiaz

Respuestas:


8

No, no es peligroso ni malo para ti. Te has topado con una pequeña batalla de las guerras init . No voy a entrar en esto en detalle, pero, brevemente, la situación es la siguiente.

Linux ha estado usando sysvinit durante la mayor parte de su vida útil. Esto es antiguo y carece de características y lo único en lo que todos están de acuerdo es que debe cambiarse. Sin embargo, nadie puede ponerse de acuerdo sobre a qué se debe cambiar. Se propusieron varias alternativas, incluidas, entre otras, las siguientes:

Ambos son buenos a su manera y malos en los demás. Como suele suceder en el mundo geek, la elección de qué sistema de inicio (uno de esos dos u otro) adoptar se convirtió en algo similar a una guerra religiosa.

Entonces, te encontraste con alguien a quien no le gusta systemdy, por lo tanto, está orgulloso de no usarlo. Hay varias personas que tienen la opinión opuesta y piensan que systemdes maravilloso y todo lo demás horrible. Al igual que hay sobre cualquier otro tema en las amplias y maravillosas redes.

Afortunadamente, las guerras init están a punto de estallar y ya han pasado su mejor momento. La mayoría de las distribuciones de Linux han decidido cambiar a systemd. Incluso el Ubuntu de Canonical, a pesar de ser la fuerza detrás upstart. Entonces, hoy, en systemdrealidad es el sistema de elección de init para casi todas las principales distribuciones, excepto Gentoo ( fuente de la imagen ):

ingrese la descripción de la imagen aquí


6

¿Leíste el artículo de Wikipedia que vinculaste? Específicamente, el tercer párrafo.

El diseño de systemd ha generado una gran controversia dentro de la comunidad de software libre. Los críticos argumentan que systemd es demasiado complejo y sufre un arrastre continuo de características, y que su arquitectura viola los principios de diseño de los sistemas operativos tipo Unix. También existe la preocupación de que forme un sistema de dependencias entrelazadas, dando así a los encargados de la distribución pocas opciones, pero adoptar systemd a medida que más piezas de software de espacio de usuario dependan de sus componentes.

También hay una gran sección más abajo titulada " Historia y controversia ".


4

Depende de lo que consideres malicioso. P.ej. suckless.org lo considera malicioso:

http://suckless.org/sucks/systemd

Definitivamente no estoy tratando de comenzar una guerra de llamas aquí y, de hecho, lo uso como usuario de Debian, pero francamente estoy de acuerdo con suckless.

ACTUALIZACIÓN: Siento que debería explicar por qué estoy de acuerdo con suckless. Así que aquí va: creo que es demasiado complejo y proporciona un control demasiado "centralizado" sobre el sistema. Los volcados de núcleo, los registros, etc. se almacenan en el diario db. ¿Qué pasa si mi fs falla y la base de datos se corrompe? No hay más registros para mirar. No más archivos centrales para analizar. El almacenamiento de archivos sin formato proporciona una mejor capacidad de recuperación ante fallas en tales casos. Personalmente, estoy bastante de acuerdo con cada punto de la lista sin contenido, pero dejo la respuesta a la pregunta principal a discreción de todos.


44
deberías decir por qué
mikeserv

1
@mikeserv: Hay muchos "porque" en la página sin succión. :) y en la página de Wikipedia (citado en la respuesta de Sparhawk). Creo que es demasiado complejo y proporciona un control demasiado "centralizado" sobre el sistema. Los volcados de núcleo, registros, etc. se almacenan en la base de datos. ¿Qué pasa si mi fs falla y la base de datos se corrompe? No hay más registros para mirar. No más archivos centrales para analizar. El almacenamiento de archivos sin formato proporciona una mejor capacidad de recuperación ante fallas en tales casos. Entonces, sí, ¿POR QUÉ?
Alex

los coredumps y los registros se pueden escribir en revistas y / o syslog, consolas, otros, no estoy de acuerdo, puede ser complicado , pero no creo que eso se traduzca directamente en malicioso , y no creo que esta respuesta respalde esa traducción.
mikeserv

1
@mikeserv: cierto. Sin embargo, es journal db o cuello de botella adicional en el registro del sistema (ahora el registro depende de journald Y de syslogd). Respecto al punto malicioso: que como dije depende de lo que consideres malicioso. Si un sistema previene la resistencia a fallas, eso es realmente malicioso para mí.
Alex

1
No digo que este sea el caso específicamente con systemd, pero una combinación de subsistemas independientes en realidad puede aumentar la resistencia a fallas . Compare un núcleo monolítico con un núcleo de microarquitectura. Ignoremos el rendimiento y solo veamos la resistencia al fracaso. Cuál es más resistente a fallas: una combinación de componentes (potencialmente grandes), que interactúan entre sí a través de interfaces bien definidas; ¿O una enorme masa de código donde todo es libre de tocar cualquier cosa por accidente? Creo que se puede argumentar que si se hace correctamente, la elección de la microarquitectura es más resistente a fallas.
un CVn

3

No es tan malicioso como tonto.

Los diseñadores están tan llenos de su propia visión que no comprenden las cosas que hacen que los sistemas tipo POSIX sean geniales.

"Los que no entienden Unix están condenados a reinventarlo mal".

          Henry Spencer
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.