Systemd pelos olhos de um mantenedor de uma distribuição musl

Artigo original ↗ Discussão no Hacker News ↗

A migração do Linux em direção ao systemd como init e gerenciador de serviços dominante é elogiada por elevar o nível em confiabilidade, tratamento de dependências e recursos modernos, mas criticada por criar uma monocultura frágil e por emaranhar muitas funções do sistema sob um único guarda-chuva. Os comentaristas destacam pontos concretos de atrito — de registros binários e peculiaridades do systemd-resolved à complexidade, superfície de segurança e inadequação para configurações pequenas ou embarcadas — ao mesmo tempo em que reconhecem que sua integração estreita muitas vezes “simplesmente funciona” em ambientes desktop e corporativos dinâmicos. Alternativas como OpenRC, s6 e nosh são mencionadas, embora muitos observem que dependências do ecossistema e escolhas de governança de projetos tornam difícil que abordagens concorrentes ganhem tração real.

Monocultura, governança e concorrência

  • Muitos concordam que o systemd resolveu problemas reais (paralelismo na inicialização, supervisão, dependências), mas temem que seu domínio crie uma monocultura que bloqueie alternativas e force compatibilidade com bugs.
  • Outros argumentam que a “multicultura” pré-systemd era caótica e inferior; o systemd simplesmente entregou mais do que os concorrentes.
  • Alguns veem a forma como as distros tornaram o systemd efetivamente obrigatório (especialmente no Debian) como uma falha de governança e uma fonte de ressentimento duradouro.
  • Poucos acham que dar suporte a múltiplos sistemas init é viável, mas isso exige recursos e interesse; o Gentoo é citado como prova.

Escopo do PID 1 e arquitetura

  • Debate sobre o que o PID 1 “deveria” fazer: um programa mínimo de primeiro espaço de usuário vs. um orquestrador central para processos, mounts, rede e mais.
  • Alguns defendem colocar o gerenciamento de processos no PID 1 para obter garantias fortes; outros veem a acumulação de funcionalidades (NVMe-over-TCP, etc.) como inchaço de “canivete suíço”.

Gerenciamento de serviços e experiência de administração

  • Muitos administradores elogiam o systemd por ferramentas padronizadas, dependências entre serviços/mounts/sockets, queda de privilégios mais fácil e agregação de logs por unidade no journald.
  • Outros relatam dores: timeouts durante boot/shutdown, dificuldade para interromper unidades com falha e instâncias por usuário confusas (linger, loginctl).
  • Ativação por socket e designs no estilo inetd dividem opiniões: alguns veem listeners centrais como mais seguros e simples; outros enxergam super-servidores como um antipadrão e risco de DoS.

Registro (journald) e complexidade

  • Journals binários com metadados ricos são vistos como poderosos para logging centralizado, mas:
    • São mais difíceis de usar com ferramentas textuais tradicionais (grep/rsync).
    • São mais lentos e às vezes corrompem, levando a alegações de que estão “reinventando um banco de dados”.
  • Os muitos tipos de unidade e caminhos de busca do systemd melhoram a flexibilidade, mas prejudicam a “localidade do comportamento”, tornando os sistemas mais difíceis de raciocinar.

DNS e rede (systemd-resolved)

  • O resolved recebe críticas significativas: problemas com DNSSEC, comportamento frágil em configurações não triviais e confusão sobre sua prontidão para produção.
  • Os apoiadores enfatizam recursos como DNS dividido ligado a interfaces/VPNs e integração estreita com outros componentes do systemd; os críticos observam que configurações semelhantes são possíveis com dnsmasq, embora com mais cola.

Alternativas e reescritas

  • Várias alternativas são mencionadas: OpenRC, s6/66suite, runit, dinit, nosh e reimplementações em Rust visando compatibilidade parcial com systemd.
  • Alguns acreditam que um sucessor mais limpo, no estilo do PipeWire, possa eventualmente surgir, mas temem que o ritmo do systemd e o lock-in do ecossistema tornem isso difícil hoje.