Já escrevi várias vezes sobre o systemd (links ao final do texto) e sobre as coisas boas que ele traz.
Há vários recursos interessantes e várias novas formas de se fazer as coisas, de maneira mais eficiente.
Por outro lado, o systemd tem sofrido severas críticas — e com razão.
Neste post, pretendo dar uma olhada nas principais ponderações (contrárias) que se tem feito — as opiniões não são minhas, portanto.
Sinta-se à vontade para comentar (concordando ou discordando) dos pontos elencados neste artigo.
Principais críticas ao systemd
Dentre os argumentos, alguns podem ter um teor muito técnico, enquanto outros são mais acessíveis a iniciantes.
Mesmo que alguns argumentos técnicos possam parecer um pouco complicados, nas suas minúcias, podem ser entendidos pela sua lógica.
- O systemd falha em cumprir um dos principais requisitos da filosofia Unix, no quesito faça uma coisa e faça-a bem feita, uma vez que se apresenta em uma coleção de várias peças binárias interligadas.
O autor Douglas Mcllroy definiu sucintamente a filosofia Unix neste 3 pontos:- Escreva programas que façam apenas uma coisa mas que a façam bem feito.
- Escreva programas que trabalhem juntos.
- Escreva programas que lidem com streams de texto, pois esta é uma interface universal.
O pecado, aqui, é que ele avança agressivamente além das funções de um init system, que seria apenas dar início ao sistema operacional.
Ele toma conta da gestão de energia, da gestão de dispositivos, dos pontos de montagem, do cron, da enriptação de discos, dos soquetes API/intetd, do syslog, da configuração da rede, da gestão de autenticação e de sessões, do readahead, da descoberta de particionamentos GPT, dos registros de contêineres. da gestão do hostname/locale/hora, do mDNS/DNS-SD, do console Linux… e a lista continua! Tudo “enrolado” em um só lugar.
O systemd cresce sem limites, para se tornar um middleware extremamente invasivo.O systemd agride normas básicas do design, como o famoso “menos, é mais!” ou “keep it simple, stupid!” (“simplifique, estúpido!“, em uma tradução livre).
- Os arquivos de journaling do systemd, (mantidos pelo journald) são armazenados em um formato binário complicado e precisam ser inquiridos através do journalctl.
Este método torna o journal mais suscetível a corrupção, uma vez que não tem ACID – transações em conformidade.
Dizem que você deveria ignorar este fato.
A única forma de obter logs tradicionais é rodar um syslogd padrão, tal como o rsyslog, junto ao journal.
Novamente, por que o systemd está se metendo nesta área? - Uma vez que está intimamente ligado a API do kernel do Linux, diferentes versões do systemd são incompatíveis com versões não correspondentes de kernel.
Desta forma, a portabilidade de diversos componentes fica desnecessariamente comprometida.
Trata-se de uma política isolacionista que, essencialmente, prende o ecossistema Linux em sua própria gaiola.
Esta abordagem torna-se um obstáculo ao desenvolvimento de software portável entre as diferentes variações do Linux e entre outros sistemas Unix-like.
Isto prejudica o uso de aplicativos de diferentes versões e a manutenção de sistemas por longo prazo. - O udev e o dbus são dependências forçadas. Na verdade, o udev se fundiu com o systemd há um bom tempo atrás.
A integração do device node manager, que costumava ser parte do kernel Linux, não é uma decisão fácil. As implicações políticas são grandes e torna vários pacotes do sistema dependentes do udev — que, em consequência, se tornam dependentes do systemd, apesar de haver forks, como o eudev.
A partir do systemd-209, os desenvolvedores passaram a ter sua própria API sd-bus, pouco documentada e não-padronizada. Ela substitui boa parte da libdbus e diminui a transparência acerca do que acontece no sistema.
A intenção é migrar o udev a este novo transporte, substituindo o Netlink e, em consequência, tornar o udev um daemon esclusivo do systemd.
O impacto desta opção é profundo. - O systemd provê um ajudante que captura coredumps e os direciona ou para /var/lib/systemd/coredump ou para o journal, onde precisam ser inquiridos, se quiser, com o coredumpctl.
Críticos afirmam que esta abordagem parte do pressuposto de que usuários e administradores são burros. O pior é que a propensão a corrupção dos journal logs a tornam uma opção irresponsável de design.
Ela também pode criar complicações relacionadas a privilégios, em ambientes multiusuários. - O tamanho do systemd, enquanto software, é uma falha que se destaca.
No momento em que este post está escrito, o systemd já chegou a 9 relatórios de vulnerabilidades (CVE), desde que foi lançado, em 2010.
Não é muito, convenhamos.
Mas a tendência de um software deste tamanho é se tornar alvo favorito para crackers. - É viral por natureza, uma vez que seus auxiliares expõem suas APIs e, ao mesmo tempo, estão amarrados ao init do systemd.
Ao tentar oferecer o máximo de funcionalidade e se manter como dependência de inúmeros pacotes, força os mantenedores a fazer conversões ou ficar à deriva.
Como exemplo, o ambiente GNOME, comumente usa componentes do systemd, tal como o logind. Mais e mais desenvolvedores irão requerer o uso do systemd, em função deste tipo de situação.
A crescente e rápida adoção por distribuições importantes, como o Debian, Arch Linux, Ubuntu, Fedora (desde 2011), openSUSE e outros, mostra que muitos estão pulando para dentro deste barco, com ou sem justificativas plausíveis. Na comunidade Debian, como é tradicional, houve bastante discussão sobre o assunto. - O systemd agrupa a si mesmo em PID 1, em vez de agir como um processo supervisor autônomo.
Uma vez que ele controla inúmeros componentes, há uma enormidade de cenários em que ele pode cair e levar junto todo o sistema.
Vale também mencionar que, para reduzir a necessidade de reiniciar a máquina, o systemd provê um mecanismo que reserializa e reexecuta o systemctl em tempo real. Se isto falhar, contudo, o sistema cai.
Um dos cenários em que isto poderia ocorrer seria não conseguir carregar uma versão anterior, potencialmente incompatível de si mesma. Um componente importante para o sistema, como este, não deveria trazer este risco. - Projetado com a biblioteca glibc em mente, não leva em consideração o suporte a outras libcs. De modo geral, desenvolvedores do systemd tem uma idéia “bugada” dos padrões libc, no que toca a compatibilidade com a glibc.
- A natureza complicada do projeto torna difícil estendê-lo e ir além de seus limites.
Acredita-se que muitos usuários irão escrever mais programas complicados para interagir com a API do systemd — ou mesmo ajustá-lo diretamente. - Ultimamente, a difusão do systemd é simbólico de algo maior do que ele mesmo.
Mostra uma mudança radical no pensamento da comunidade do Linux — não necessariamente positiva.
É orientada para o desktop, para limitações de escolhas, isolacionista e contrária a padrões. - Os rumos do projeto, também são alvo de críticas ácidas. O systemd “sequer sabe” aonde quer chegar.
Há referências a ele como “um daemon de sistema” ou a “um bloco de construção do userspace básico, para obter um sistema operacional”.
Ambas as definições são altamente ambíguas e, de certa forma, mutuamente excludentes.
O projeto engole as funcionalidades de vários utilitários tradicionais do Linux, ferramentas de rede, relatórios de sistema entre outros.
Ainda assim, não há uma direção clara para ele, além dos caprichos dos próprios desenvolvedores.
Para concluir, embora o projeto se apresente com o propósito de padronizar as distribuições GNU/Linux — ironicamente, ele mesmo não tem padrões claros e parece estar perpetuamente rolando, sem sair do lugar.
Referência
https://elias.praciano.com/2016/10/alternativas-ao-systemd/.
https://elias.praciano.com/tag/systemd.
https://www.ubuntubsd.org/wiki:why_not_systemd.
One reply on “Por que o systemd é uma má ideia.”
Muito bom o seu post, realmente eu não fazia idéia de como o systemd é complicado por natureza, acessando o site de vulnerabilidades http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=systemd ele está com 22 falhas de segurança, MDS.
Mais uma vez obrigado por compartilhar esse conhecimento de forma clara e educativa.