Systemd: A Guerra do Init, Complexidade Arquitetural e o Fim do SysVinit

Toda discussão sobre systemd começa técnica e termina parecendo briga de família em churrasco.

De um lado, gente dizendo que ele salvou o boot do Linux moderno. Do outro, gente tratando o projeto como se fosse um polvo arquitetural tentando abraçar o sistema operacional inteiro com tentáculos em init, logs, rede, DNS, sessões, usuários, containers, boot e, se bobear, o café da manhã.

A parte chata é que os dois lados têm algum motivo.

O systemd resolveu problemas reais. Ele trouxe uma forma mais coerente de declarar serviços, lidar com dependências, supervisionar processos, ativar daemons sob demanda e entender o estado do sistema sem depender de uma coleção de scripts shell tentando parecer arquitetura.

Mas também aumentou o acoplamento entre componentes fundamentais do Linux. E isso explica por que tanta gente nunca engoliu muito bem essa vitória.

Só que a guerra do init não foi apenas uma discussão entre “boot rápido” e “filosofia Unix”. Ela foi uma transição histórica meio traumática, atravessada por decisões de distribuição, disputas de governança, ressentimento técnico, medo de lock-in e uma boa dose de drama comunitário.

Antes de comparar systemd, SysVinit, Upstart, OpenRC e companhia, vale entender como a gente chegou nesse ponto.

Porque o systemd não venceu porque era simpático.

Ele venceu porque o modelo anterior estava velho, remendado e insuficiente para o tipo de sistema Linux que as distribuições queriam entregar.

Antes da guerra, o init já estava cansado

O problema não começou com Lennart Poettering escrevendo um post no blog e decidindo irritar metade da internet.

O modelo clássico do SysVinit já carregava sinais de desgaste fazia tempo.

Ele era baseado em scripts shell, runlevels e convenções de diretório como /etc/init.d e /etc/rc?.d. Funcionava. Durante muito tempo, funcionou bem o suficiente. Mas “funcionou bem o suficiente” é aquela frase que geralmente aparece antes de alguém precisar manter um servidor em produção às três da manhã.

No SysVinit tradicional, iniciar um serviço significava executar um script. Parar um serviço significava executar outro trecho do mesmo script. Saber se um serviço estava vivo podia depender de PID files, heurísticas, convenções e fé. Muita fé.

Isso não quer dizer que o mundo SysV era burro ou parado.

Distribuições adicionaram melhorias. O Debian, por exemplo, teve mecanismos como insserv, para ordenar scripts com base em dependências declaradas em headers LSB, e startpar, para execução paralela.

Então não é tecnicamente correto dizer que o SysVinit ficou eternamente preso a uma sequência linear e inocente de scripts. O mundo real era mais complexo.

Mas essas melhorias eram remendos sobre um modelo centrado em scripts.

A base continuava frágil para supervisionar processos complexos, lidar com dependências dinâmicas, ativação sob demanda, rastreamento confiável de processos filhos e integração com recursos modernos do kernel.

O Linux tinha mudado. O init, nem tanto.

Upstart parecia o futuro por alguns anos

Antes do systemd virar o padrão óbvio das principais distribuições, o candidato mais forte a substituir o SysVinit era o Upstart.

O Upstart nasceu na Canonical e foi adotado pelo Ubuntu. A ideia era trocar parte da rigidez do SysVinit por um modelo orientado a eventos. Em vez de depender apenas de runlevels e scripts sequenciais, serviços poderiam reagir a eventos do sistema.

Isso parecia um caminho natural.

O mundo desktop estava ficando mais dinâmico. Hardware aparecia e sumia. Interfaces de rede mudavam. Sessões gráficas ficavam mais complexas. Sistemas precisavam reagir a eventos em vez de apenas executar uma lista de scripts no boot e torcer para tudo continuar igual.

O Upstart também tinha uma vantagem política importante: ele prometia uma transição menos traumática. Ainda conseguia conviver com scripts SysV, o que tornava a migração mais palatável.

Só que o Upstart não virou o ponto de convergência do ecossistema.

O Fedora planejou trocar Upstart por systemd no Fedora 15. A própria página de feature do Fedora descrevia o systemd como substituto para SysVinit e Upstart, destacando paralelização agressiva, ativação por socket e D-Bus, uso de cgroups e lógica transacional de dependências. Na prática, o Fedora queria algo mais integrado ao Linux moderno do que o Upstart oferecia.

E aí a transição deixou de ser apenas técnica.

Quando uma distribuição grande escolhe uma tecnologia, é uma decisão. Quando várias escolhem a mesma, vira gravidade.

Fedora puxou a fila

O Fedora foi uma das primeiras grandes distribuições a abraçar o systemd com força.

A página Features/systemd mirava o Fedora 15 e dizia explicitamente que o plano era tornar o systemd o padrão, substituindo o Upstart. Também deixava claro que a compatibilidade com scripts SysV seria importante durante a migração.

Isso é um detalhe importante.

O systemd não entrou no mundo prometendo “joguem tudo fora amanhã”. Ele entrou prometendo uma ponte: suporte a scripts antigos, unidades nativas para serviços novos e uma arquitetura mais moderna por baixo.

A promessa era sedutora para mantenedores de distribuição.

Dava para migrar aos poucos. Dava para empacotar serviços com units nativas. Dava para manter compatibilidade por um tempo. Dava para melhorar boot, supervisão e introspecção sem exigir que todo software do planeta fosse reescrito no mesmo dia.

Esse “por um tempo” é onde mora a ironia.

Porque compatibilidade temporária, em infraestrutura, geralmente vira contrato emocional eterno. E quando o projeto finalmente começa a desmontar a ponte, sempre aparece alguém dizendo: “mas eu ainda estava usando”.

Arch fez do jeito Arch

O Arch Linux adotou systemd como padrão em novas instalações em outubro de 2012.

O comunicado foi bem direto: o grupo base passou a conter systemd-sysvcompat, então novas instalações passariam a iniciar com systemd por padrão. Instalações existentes não seriam afetadas imediatamente, e os pacotes initscripts e sysvinit ainda continuariam disponíveis por um tempo.

Ou seja: bem Arch.

Sem cerimônia demais. Sem três camadas de abstração emocional. O recado era basicamente: “isso aqui é o padrão novo; se você tem instalação antiga, a wiki está ali”.

Mas mesmo no Arch havia o ponto central da transição: alguns pacotes ainda não tinham units nativas e podiam continuar usando scripts legados por um período. A migração não era um botão mágico. Era uma troca gradual, pacote por pacote, serviço por serviço.

O systemd venceu também porque conseguiu ser adotado incrementalmente.

Isso não torna a transição indolor. Só torna possível.

Debian virou o campo de batalha

Se Fedora foi a vanguarda técnica e Arch foi a migração pragmática, o Debian foi o ringue principal.

A decisão do Debian sobre o init padrão para o Jessie foi uma das discussões mais famosas da história recente das distribuições Linux. Não porque ninguém soubesse iniciar um serviço. Mas porque Debian não é só uma distribuição. É um projeto com governança própria, cultura própria e um peso enorme no ecossistema.

Quando o Debian escolhe uma direção, derivados sentem o impacto.

O Comitê Técnico do Debian discutiu systemd, Upstart, OpenRC e SysVinit. A disputa ficou especialmente quente entre systemd e Upstart. Em 2014, a decisão terminou com voto de desempate do presidente do comitê a favor do systemd, como coberto pela LWN em Debian decides on systemd—for now.

Esse “for now” era importante.

A decisão não encerrou a polêmica. Ela apenas definiu o caminho para o Jessie.

O debate envolvia mais do que recurso técnico. Havia uma preocupação real com acoplamento. Um dos pontos mais sensíveis era se pacotes poderiam depender de um init específico rodando como PID 1. Em outras palavras: Debian deveria aceitar um ecossistema onde componentes de desktop e serviços começassem a presumir systemd?

Esse era o coração da briga.

Não era apenas “qual init é melhor?”. Era “que tipo de distribuição o Debian quer ser?”.

Uma distribuição onde systemd é o padrão, mas alternativas seguem viáveis?

Ou uma distribuição onde o systemd vira tão central que alternativas passam a existir só no papel, mantidas na base da teimosia e de patches?

A pergunta era boa. Ainda é.

Ubuntu perdeu graciosamente, mais ou menos

O Ubuntu tinha seu próprio init: Upstart.

Então a adoção do systemd pelo Debian colocou a Canonical em uma posição desconfortável. Continuar insistindo no Upstart significaria manter uma divergência pesada em relação ao Debian, justamente a base técnica do Ubuntu.

No Ubuntu 15.04, o systemd substituiu o Upstart como gerenciador padrão de boot e serviços em quase todos os sabores, exceto Ubuntu Touch. As release notes do Ubuntu 15.04 ainda indicavam que o Upstart continuava controlando sessões de usuário e que havia caminho para bootar com Upstart pelo GRUB, mas o padrão já tinha mudado.

Essa parte é importante porque mostra que a guerra não terminou com um “todo mundo percebeu que systemd era perfeito”.

Terminou porque manter alternativas divergentes ficou caro.

Distribuições não tomam decisões só com base em pureza arquitetural. Elas tomam decisões com base em manutenção, integração, quantidade de patches, disponibilidade de mantenedores, compatibilidade com upstream e pressão do ecossistema.

O Ubuntu não precisava amar o systemd para adotá-lo.

Bastava a conta da divergência ficar ruim demais.

E aí veio o Devuan

A reação mais simbólica à adoção do systemd no Debian foi o Devuan.

O Devuan nasceu como um fork do Debian com a proposta de manter uma distribuição sem systemd como padrão. Ele virou um lembrete permanente de que a briga não era só sobre comandos diferentes para iniciar serviço.

Era sobre confiança.

Para parte da comunidade, o systemd representava uma centralização perigosa demais. Para outra parte, a resistência parecia nostalgia disfarçada de princípio técnico.

As duas leituras são simplistas quando aparecem sozinhas.

Existia nostalgia, sim. Mas também existiam preocupações legítimas.

E existia pragmatismo técnico, sim. Mas também existia uma tendência real de concentração em torno de um projeto só.

O Devuan não precisava “vencer” para provar um ponto. O simples fato de existir já mostrava que uma parte da comunidade não queria seguir a corrente principal sem resistência.

As principais polêmicas da época

A guerra do init foi barulhenta porque juntou várias discussões diferentes no mesmo saco.

A primeira era a filosofia Unix.

O argumento clássico dizia que sistemas deveriam ser compostos por ferramentas pequenas, independentes e combináveis. O systemd parecia ir na direção contrária: uma suite integrada, com vários componentes coordenados, APIs próprias e um centro de gravidade cada vez maior.

A crítica fazia sentido, mas às vezes era mal formulada.

Chamar systemd de “um único binário gigante que faz tudo” sempre foi tecnicamente errado. O systemd é uma suite de componentes. O próprio site oficial descreve o projeto como uma suite de blocos básicos para um sistema Linux, com PID 1, gerenciador de serviços, logging, configuração de hostname, tempo, usuários logados, containers, rede, DNS e outras peças.

A crítica séria não é “é tudo um binário”.

A crítica séria é: “muita coisa fundamental passou a orbitar o mesmo projeto”.

A segunda polêmica era o journald.

Para muita gente, trocar logs textuais tradicionais por um journal binário parecia uma afronta. A caricatura era simples: “acabaram com /var/log”. Só que não era bem assim. O journald podia coexistir com syslog, encaminhar mensagens e ser configurado de várias formas.

A crítica correta não era “não existem mais logs de texto”.

A crítica correta era: “agora existe uma camada central com formato próprio, ferramentas próprias e semântica própria para consultar parte importante do estado do sistema”.

Isso tem vantagens. Também tem custo.

A terceira polêmica era o acoplamento com desktops modernos.

systemd-logind virou uma peça importante para sessões, seats, inibição de suspensão e diretórios runtime de usuário. Isso impactou ambientes gráficos, gerenciadores de login e distribuições que queriam usar outro init. A crítica não era apenas ao PID 1, mas ao fato de componentes do desktop passarem a depender de APIs associadas ao systemd.

A quarta era portabilidade.

O systemd foi desenhado para Linux. Ele usa recursos específicos do kernel Linux, como cgroups, de forma central. Para quem vinha de uma tradição mais Unix-like e portável entre diferentes sistemas, isso parecia uma ruptura.

Para os defensores, era justamente o ponto: parar de fingir portabilidade genérica e usar bem o Linux real.

A quinta era social.

A discussão sobre systemd ficou pessoal demais, rápido demais. Houve crítica técnica legítima, mas também houve hostilidade, ataque pessoal e muito ruído. Isso é péssimo porque degrada a discussão: quem critica vira automaticamente “dinossauro”, quem defende vira automaticamente “fanboy de Red Hat”, e ninguém precisa mais pensar.

É confortável. E inútil.

O resultado é que systemd virou menos uma tecnologia e mais um teste de personalidade.

Agora sim: o comparativo técnico importa

Depois de todo esse contexto histórico, o comparativo técnico fica mais honesto.

Porque a pergunta nunca foi apenas “qual init inicia serviço mais rápido?”.

A pergunta era: qual modelo faz mais sentido para um Linux moderno, com desktops complexos, containers, cgroups, dispositivos dinâmicos, unidades de usuário, timers, sockets, sessões gráficas, virtualização e um ecossistema enorme de pacotes?

O SysVinit representava simplicidade histórica, previsibilidade e uma quantidade absurda de conhecimento acumulado. Mas também representava scripts shell frágeis, supervisão limitada e dificuldade para modelar dependências modernas.

O Upstart tentou resolver parte disso com eventos. Foi importante, teve adoção real e parecia o caminho natural por alguns anos. Mas não virou a fundação comum das principais distribuições.

OpenRC, runit e s6 seguem sendo alternativas tecnicamente respeitáveis, cada uma com suas escolhas. OpenRC mantém um modelo mais próximo da tradição de init com dependências explícitas e boa legibilidade. runit e s6 valorizam supervisão simples e composição. Em certos ambientes, especialmente sistemas menores, servidores minimalistas ou distribuições específicas, fazem bastante sentido.

Mas o systemd venceu no Linux mainstream porque ofereceu um pacote completo.

E essa frase é elogio e crítica ao mesmo tempo.

O que o systemd mudou de verdade

O systemd foi anunciado publicamente em 2010, no texto clássico de Lennart Poettering, Rethinking PID 1. A proposta não era só trocar um binário chamado init por outro. A proposta era repensar o papel do processo PID 1 em um sistema Linux moderno.

No Linux, o PID 1 é o primeiro processo em user space. Ele nasce depois do kernel e vira responsável por iniciar o resto do sistema. Isso não é pouca coisa. Se o PID 1 quebra, o sistema não fica “meio triste”. Ele entra em crise existencial.

O systemd assumiu esse papel com uma ideia central: em vez de iniciar scripts soltos, ele gerencia unidades.

Uma unidade pode ser um serviço, um socket, um mount point, um timer, um target, um device, um path e por aí vai. A documentação de systemd.unit descreve esse modelo como a base declarativa do systemd.

Na prática, isso muda bastante coisa.

Em vez de escrever um script shell enorme tentando cobrir start, stop, restart, reload, status e mais meia dúzia de casos especiais, você descreve o comportamento esperado de um serviço em um arquivo .service.

Um exemplo mínimo:

[Unit]
Description=Minha aplicação
After=network.target

[Service]
Type=exec
ExecStart=/usr/local/bin/minhaapp --foreground
Restart=on-failure

[Install]
WantedBy=multi-user.target

Isso não é perfeito, mas é muito mais legível do que boa parte dos scripts de init que existiam no mundo real.

O systemd passa a entender que existe uma unidade chamada minhaapp.service, que ela deve iniciar depois de network.target, que o processo principal é executado por ExecStart, e que ele deve ser reiniciado em caso de falha.

E o mais importante: isso não é só texto decorativo. O systemd usa essas informações para montar um grafo de dependências e executar transações de inicialização, parada e reload com muito mais contexto do que o SysVinit clássico tinha.

O ganho do systemd não é apenas iniciar serviços: é tratar o sistema como um grafo supervisionado de unidades.

Targets não são só runlevels com outro nome

No SysVinit, runlevels representavam estados globais do sistema. O runlevel 3, por exemplo, geralmente indicava modo multiusuário em texto; o runlevel 5, modo gráfico. O significado exato podia variar por distribuição, porque Linux adora transformar padrão em sugestão.

O systemd substitui essa ideia por targets.

Existe uma compatibilidade aproximada entre runlevels e targets, mas não é uma equivalência perfeita. A própria documentação de runlevel no systemd trata runlevels como uma forma obsoleta de agrupar serviços. Já systemd.target descreve targets como unidades usadas para agrupar outras unidades.

A diferença prática é que vários targets podem estar ativos ao mesmo tempo. Eles não são apenas “modos globais exclusivos”. São pontos de sincronização e agrupamento dentro do grafo de unidades.

O boot moderno com systemd gira em torno de targets como basic.target, multi-user.target, graphical.target, sockets.target, timers.target e outros. A documentação de bootup mostra bem esse fluxo.

Isso torna o sistema mais flexível, mas também mais abstrato.

E abstração, como sempre, cobra pedágio.

Cgroups: a parte que muita gente ignora

Uma das mudanças mais importantes do systemd não está no arquivo .service. Está no uso de cgroups.

No modelo antigo, um daemon podia fazer fork, criar subprocessos, perder relação clara com o script que o iniciou e deixar o init dependendo de PID files para descobrir quem era o processo principal.

Isso funcionava até não funcionar.

E quando não funcionava, sobrava para alguém rodar ps, grep, kill, olhar /var/run, tentar entender se o processo morreu, se o PID foi reutilizado, se o daemon fez fork duas vezes ou se o script simplesmente mentiu.

O systemd usa control groups para associar processos a unidades. Quando ele inicia um serviço, os processos daquele serviço entram em uma hierarquia de cgroups vinculada à unit. Isso permite saber quais processos pertencem a qual serviço, aplicar limites de recursos e encerrar árvores inteiras de processos com mais previsibilidade.

É por isso que comandos como este são tão úteis:

systemctl status nginx.service

O systemctl não está apenas lendo um arquivo qualquer. Ele consulta o estado que o systemd mantém sobre aquela unit: processo principal, subprocessos, logs recentes, status, código de saída e relação com o resto do sistema.

Isso não significa que PID files desapareceram do planeta. A documentação de systemd.service ainda suporta PIDFile=, especialmente para serviços Type=forking. Mas, para serviços modernos, o caminho mais limpo é deixar a aplicação rodar em foreground e permitir que o systemd supervisione diretamente.

Um serviço legado ainda pode fazer sentido assim:

[Unit]
Description=Meu daemon legado
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/sbin/meudaemon --daemonize --pidfile /run/meudaemon.pid
PIDFile=/run/meudaemon.pid
Restart=on-failure

[Install]
WantedBy=multi-user.target

Mas isso é compatibilidade com o mundo antigo.

O ideal moderno é algo mais direto:

[Unit]
Description=Minha aplicação moderna
After=network.target

[Service]
Type=exec
ExecStart=/usr/local/bin/minhaapp --foreground
Restart=on-failure

[Install]
WantedBy=multi-user.target

Menos ritual. Mais supervisão real.

Socket activation: iniciar só quando precisa

Outra ideia importante do systemd é socket activation.

Em vez de iniciar todos os serviços durante o boot e torcer para ninguém tropeçar na ordem de dependências, o systemd pode criar sockets antes dos daemons e iniciar o serviço apenas quando houver conexão. Essa ideia não nasceu do nada; o próprio Poettering já explicava isso em textos sobre socket activation.

O modelo é simples: uma unit .socket define o ponto de escuta, e uma unit .service define o serviço ativado quando aquele socket recebe tráfego.

# /etc/systemd/system/foobar.socket
[Unit]
Description=Socket do foobard

[Socket]
ListenStream=/run/foobar.sock

[Install]
WantedBy=sockets.target

# /etc/systemd/system/foobar.service
[Unit]
Description=Serviço do foobard

[Service]
ExecStart=/usr/local/bin/foobard

Depois:

systemctl daemon-reload
systemctl enable --now foobar.socket

A documentação de systemd.socket detalha esse comportamento. O ganho é claro: inicialização paralela, menos dependência rígida de ordem e possibilidade de ativação sob demanda.

Isso é bonito no papel e útil na prática.

Também é mais uma prova de que o systemd não tentou apenas “substituir o init”. Ele tentou redesenhar a forma como serviços se relacionam com o sistema.

O journald não matou o /var/log

Poucas partes do systemd irritam tanta gente quanto o journald.

A crítica mais comum é que ele trocou arquivos de texto simples por um formato binário. Isso é parcialmente verdade, mas a frase costuma ser usada de um jeito meio preguiçoso.

O systemd-journald coleta logs do kernel, da saída padrão e erro padrão de serviços, de syslog e de outras fontes. Esses logs podem ser armazenados em journal persistente ou volátil, dependendo da configuração. O journalctl é a ferramenta usada para consultar esses registros.

Na prática:

journalctl -u nginx.service -b

Esse comando mostra os logs da unit nginx.service no boot atual. É difícil negar que isso é conveniente.

O problema é quando a explicação vira caricatura: “o journald substituiu o syslog e acabou com /var/log”.

Não é bem assim.

O journald pode coexistir com rsyslog ou syslog-ng. Ele também pode encaminhar mensagens para um daemon syslog tradicional. A própria documentação do systemd sobre syslog trata essa integração.

Então a crítica correta não é “o journald apagou os logs de texto da humanidade”.

A crítica correta é outra: o systemd centralizou a coleta e a consulta de logs em um componente próprio, com formato próprio, ferramentas próprias e semântica própria.

Isso tem vantagens reais: metadados estruturados, filtros por unit, boot, prioridade, PID, usuário e mais um monte de campos úteis.

Mas também tem custo: mais dependência de ferramenta específica, mais uma peça para entender, mais uma camada entre o operador e o log bruto.

De novo: trade-off.

Não conto de terror.

A crítica ao “monolito” precisa mirar no alvo certo

Chamar o systemd de “um único binário gigante que controla tudo” é tecnicamente errado.

O systemd é uma suite. Existem componentes diferentes: PID 1, journald, logind, resolved, networkd, timesyncd, homed, boot, nspawn, entre outros.

Eles não são todos o mesmo processo. Também não são todos obrigatórios em toda instalação. A documentação sobre minimal builds deixa claro que há componentes centrais e componentes opcionais.

Mas isso não absolve a crítica.

O problema não é “um único binário”. O problema é o escopo do projeto.

O systemd virou o lugar onde muita coisa do sistema Linux passou a se concentrar: init, serviços, logs, sessões, timers, sockets, DNS, rede, containers, home directories, boot loader e por aí vai.

Alguns componentes são excelentes. Outros são opcionais. Outros são controversos. E alguns dão aquela sensação de que alguém olhou para o Linux e pensou: “isso aqui ainda não tem um binário nosso, que descuido”.

A crítica séria ao systemd não deveria ser “é tudo um binário só”.

Deveria ser: “a suite systemd cria um centro de gravidade muito forte no ecossistema Linux”.

Isso é bem diferente.

E muito mais difícil de responder com meme.

logind não é homed, e detalhes importam

Um erro comum em discussões sobre systemd é jogar todos os componentes no mesmo balde e chamar tudo de “systemd fazendo coisa demais”.

Sim, o projeto tem escopo amplo. Mas se a crítica técnica erra o componente, ela perde força.

Por exemplo: quem gerencia logins, sessões, seats, inibidores de suspensão e diretórios runtime de usuário é o systemd-logind.

Já o systemd-homed lida com gerenciamento de áreas home e contas de usuário associadas. É outra coisa.

Dá para criticar os dois. Dá para achar que ambos expandem demais o alcance do projeto. Mas não dá para confundir as funções e depois reclamar que ninguém leva a crítica a sério.

Precisão importa, principalmente quando a opinião é forte.

A compatibilidade com SysV está acabando no upstream

Durante muitos anos, uma das respostas para a crítica era: “calma, o systemd ainda consegue lidar com scripts SysV”.

Isso era verdade.

O systemd-sysv-generator criava units automaticamente a partir de scripts SysV, permitindo compatibilidade com serviços antigos.

Mas essa ponte não é garantia eterna.

No upstream, o systemd v260 removeu o suporte a scripts de serviço System V. As notas da release v260 dizem explicitamente que o suporte a scripts System V foi removido e recomendam atualizar software para incluir units nativas. A página de compatibilidade com SysV também passou a tratar esse suporte como histórico.

Isso não significa que toda distribuição removeu tudo imediatamente. Distribuições empacotam versões diferentes, aplicam patches, seguram mudanças e preservam compatibilidade quando precisam.

Mas a direção do upstream é clara: unit nativa é o caminho. Script SysV é legado.

E isso muda o tom da conversa.

Em 2015, dava para falar em transição com camada de compatibilidade.

Em 2026, essa camada já está sendo desmontada no projeto principal.

Quem ainda mantém serviço com script SysV deveria começar a migrar para unit nativa antes que a gambiarra vire arqueologia operacional.

run0: porque até o sudo entrou na conversa

Como se systemd já não estivesse em assunto suficiente, a série 256 trouxe o run0.

O run0 funciona como uma invocação alternativa do systemd-run para executar comandos com privilégios elevados ou diferentes. Ele usa autenticação via polkit e cria um serviço isolado para executar o comando, sem depender de SetUID/SetGID como o sudo.

É tentador chamar isso de “substituto do sudo”, mas essa frase simplifica demais.

O sudo é uma ferramenta madura, amplamente usada, com um modelo conhecido de configuração via sudoers. O run0 segue outra lógica: ele se apoia no systemd, em polkit e em units transitórias.

Isso não quer dizer que seja ruim.

Quer dizer que ele carrega a filosofia do systemd até no ato de elevar privilégio: em vez de “rodar um comando como root”, ele cria um contexto gerenciado pelo service manager.

Tecnicamente interessante.

Filosoficamente previsível.

Socialmente inflamável.

Ou seja: systemd sendo systemd.

O systemd venceu porque o mundo mudou

A tese mais honesta é esta: o systemd venceu porque o Linux que as distribuições queriam entregar já não cabia bem no modelo clássico de init.

Máquinas modernas têm serviços dinâmicos, dispositivos aparecendo e sumindo, sessões gráficas complexas, containers, virtualização, cgroups, timers, sockets, unidades de usuário, dependências condicionais e integração profunda com o desktop.

Dá para fazer muita coisa disso sem systemd? Sim.

Dá para fazer com OpenRC, runit, s6, supervision trees e outras abordagens? Sim.

Dá para fazer de forma integrada, padronizada e amplamente adotada entre as principais distribuições Linux? Aí a conversa muda.

O systemd não ganhou por ser minimalista.

Ele ganhou por ser abrangente.

E essa abrangência é justamente a fonte da vitória e da crítica.

O custo da padronização

Padronização é confortável até você perceber que ela também concentra poder técnico.

Quando quase tudo no Linux mainstream assume systemd, projetos começam a depender de APIs, comportamentos e componentes associados a ele. Distribuições alternativas precisam manter compatibilidade, adaptar pacotes ou remar contra uma corrente cada vez mais forte.

Isso não torna o systemd “maligno”.

Mas torna o ecossistema menos plural em uma camada muito sensível.

A filosofia Unix clássica defendia ferramentas pequenas, independentes e combináveis. O systemd segue outra filosofia: componentes integrados, estado centralizado, interfaces comuns e coordenação forte.

Não é que uma seja automaticamente certa e a outra automaticamente errada.

Mas são visões diferentes de sistema.

O problema é fingir que essa diferença não existe.

O systemd trouxe ordem onde havia muita cola shell. Trouxe introspecção onde havia script opaco. Trouxe supervisão real onde havia PID file. Trouxe um modelo declarativo onde havia convenção espalhada.

Mas também trouxe um centro de gravidade enorme.

E centros de gravidade enormes são úteis até virarem dependência inevitável.

Então o systemd é bom ou ruim?

Essa pergunta é ruim.

O systemd é uma resposta técnica forte para problemas reais do Linux moderno. Ele é melhor que o SysVinit clássico em supervisão, dependências, introspecção, ativação sob demanda e integração com recursos do kernel como cgroups.

Ao mesmo tempo, ele representa uma mudança de filosofia.

Sai o modelo de várias peças pequenas e relativamente independentes; entra uma suite integrada que define grande parte da experiência operacional do sistema.

Quem diz que systemd é só “bloat” ignora os problemas reais que ele resolveu.

Quem diz que systemd é apenas progresso inevitável ignora os custos reais que ele trouxe.

A resposta adulta é mais chata: systemd é uma engenharia pragmática, poderosa e expansiva. Ele resolveu um problema enorme e criou outro tipo de problema no caminho.

No fim, a guerra do init acabou não porque todo mundo concordou.

Acabou porque as principais distribuições seguiram em frente.

O systemd venceu.

Mas venceu do jeito mais systemd possível: não apenas substituindo o init, e sim redefinindo o que o init deveria ser.

E talvez seja exatamente por isso que tanta gente ainda discute.