Substituindo o Systemd por OpenRC no Debian

Por que substituir o systemd / necessidade de competição

• Muitos argumentam que o systemd se tornou dominante demais, criando uma monocultura de facto e tornando alternativas difíceis de implantar.
• Preocupações: proliferação de dependências em muitos componentes de baixo nível, complexidade acidental e mantenedores sendo desdenhosos com problemas de compatibilidade.
• Outros respondem que o systemd funciona bem para eles, resolve problemas antigos do init e que alternativas sérias ainda estão incompletas ou são de nicho.

Comparações técnicas: systemd vs OpenRC e outros inits

• O OpenRC é apresentado como um gerenciador de serviços leve com ordenação de dependências, supervisão (supervise-daemon), inicialização paralela e integração com cgroups.
• Alguns observam que os arquivos de unidade do systemd e os arquivos de serviço do OpenRC são estruturalmente bastante semelhantes em casos básicos.
• Há debate sobre se scripts de init baseados em shell são inerentemente frágeis ou se a abordagem declarativa e orientada por binários do systemd é superior.

Debian, Devuan e escolhas de distribuição

• Contexto histórico: o Debian avaliou systemd, Upstart e OpenRC; o OpenRC foi visto como pouco desenvolvido no momento da decisão do Debian.
• O Debian inicialmente dava suporte a múltiplos sistemas de init, mas depois padronizou no systemd devido ao custo de manutenção.
• O Devuan é mencionado como “Debian sem systemd”, mas difere de simplesmente trocar o init no Debian stock (repositórios separados, patches).
• Alguns argumentam que uma distro deve escolher um init; a “escolha” deveria acontecer no nível da distro, não dentro de cada distro.

Escopo do systemd e “OS-ificação”

• O systemd agora cobre init, logging, networking, bootloader, autodetecção de partições, instaladores, recursos no estilo contêiner, etc.
• Os defensores gostam da camada de SO coerente e integrada e das APIs unificadas que simplificam ferramentas como o Cockpit.
• Os críticos veem isso como exagero de escopo, com risco de lock-in e tornando mais difícil trocar componentes.

Sistemas imutáveis e controle

• Discussão sobre stacks imutáveis baseadas em systemd e uma empresa focada em sistemas “amutable” bloqueados.
• Alguns veem sistemas imutáveis e controlados centralmente como benéficos para fornecedores (por exemplo, consoles, dispositivos de consumo).
• Outros temem que esses mecanismos, uma vez padronizados no nível do init/SO, possam ajudar no bloqueio do usuário ou na exclusão de distros não systemd, especialmente se combinados com políticas de secure boot.

Verificação de idade / preocupações com privacidade

• Um campo planejado de idade/data de nascimento no systemd provoca reações fortes.
• Críticos veem isso como habilitando “farejamento de idade”, alinhando-se a leis intrusivas e coleta de dados; a intenção de cumprir a regulamentação é vista com suspeita.
• Defensores observam que é um campo opcional de metadados, pode ser compilado fora ou deixado em branco, e pode evitar que cada serviço reimplemente seu próprio mecanismo.
• Há discordância sobre se os desenvolvedores devem cumprir tais leis, ignorá-las ou resistir ativamente como casos de teste.

Usabilidade, confiabilidade e bugs

• Alguns relatam o systemd como robusto e completo em funcionalidades há anos, especialmente em comparação com o SysV clássico.
• Outros relatam bugs graves do passado (por exemplo, corridas de desligamento via D-Bus, perda de dados no journald, picos de CPU, incompatibilidades de supervisão) e os veem como falhas de design, não apenas erros de implementação.
• Reconhece-se que tanto init no estilo sysv quanto systemd já quebraram sistemas em produção; a base de código muito maior do systemd é vista por alguns como uma superfície de ataque maior para bugs.

Fragmentação vs padronização

• As vozes pró-systemd destacam a redução da fragmentação entre distros, melhor consistência entre distros e empacotamento mais fácil.
• As vozes anti-monocultura valorizam a diversidade (Gentoo, Alpine, Void, Devuan) e se preocupam quando desktops (GNOME/KDE) ou ferramentas assumem discretamente o systemd.
• Alguns observam que o POSIX buscava antes suavizar a portabilidade, mas desktops modernos e integração profunda entre componentes precisam de mais do que apenas POSIX.

Alternativas e distros “plano B”

• Gentoo + OpenRC, Alpine (com OpenRC), Void e outros sistemas inspirados em supervisão são citados como opções viáveis sem systemd.
• É relatado que o Alpine funciona bem como desktop (por exemplo, com i3 ou KDE), especialmente em hardware de baixo consumo.
• Existem ferramentas para converter unidades do systemd para outros formatos, mas manter compatibilidade semântica é considerado não trivial.

Meta: cultura, política e lei

• A discussão toca na desconfiança da influência corporativa (Red Hat/IBM, grandes empresas de tecnologia) e no medo de que seus incentivos se afastem dos usuários preocupados com privacidade.
• Há debate sobre lutar contra más leis por meio da política, dos tribunais ou da não cooperação técnica.
• Alguns caracterizam a crítica ao systemd como emocional ou quase tribal; outros argumentam que estão respondendo a questões técnicas e de governança reais.