O systemd completa 10 anos, mas a sua aceitação na comunidade Linux continua polarizada, mantendo-se tão controverso como sempre. Apesar de ser o sistema de inicialização adotado por grande parte das distribuições Linux mais populares, a oposição à sua utilização mantém-se firme.
A Sequência de Arranque do Linux
Ao ligar um computador, o hardware passa por um processo de inicialização, e posteriormente, dependendo do tipo de setor de inicialização, é executado o registro mestre de inicialização (MBR) ou a Interface de Firmware Extensível Unificada (UEFI). Ambas as ações têm como último passo o carregamento do Kernel Linux.
O kernel é carregado na memória, descomprimido e inicializado. Um sistema de arquivos temporário é criado na RAM, geralmente por meio de um utilitário chamado initramfs ou initrd. Este sistema permite que os drivers necessários sejam identificados e carregados, abrindo caminho para o carregamento e configuração do sistema de arquivos do espaço do usuário, preparando o ambiente para o utilizador.
A criação do ambiente do espaço do usuário é da responsabilidade do processo init, o primeiro processo a ser iniciado pelo kernel no espaço do usuário, que possui um ID de processo (PID) de 1. Todos os outros processos são filhos diretos ou indiretos do processo init.
Antes da chegada do systemd, o padrão predominante para o processo init era uma reformulação do init do Unix System V. Embora existissem outras opções, o System V init era a opção padrão na maioria das distribuições derivadas de Berkeley Software Distribution (BSD). Por derivar diretamente do System V Unix, o ancestral do Linux, muitos consideravam-no a forma “oficial” de executar o init.
O processo de inicialização é responsável por iniciar todos os daemons e serviços necessários para o funcionamento adequado e interativo do sistema operativo. Estes daemons gerem componentes como a pilha de rede, a ativação de hardware dentro do computador e a exibição do ecrã de inicialização.
Muitos destes processos em segundo plano continuam a executar-se após o seu lançamento. Eles realizam tarefas como registar informações sobre eventos, monitorizar alterações de hardware ao conectar ou remover dispositivos e gerir o login dos utilizadores. O sistema init também inclui funcionalidades para gestão de serviços.
Podemos utilizar o comando ps para visualizar o processo com PID 1. Vamos usar as opções f (formato completo) e p (PID):
ps -fp 1
É possível observar que o processo com PID 1 é o systemd. Ao executar o mesmo comando no Manjaro Linux, obtivemos um resultado diferente, onde o processo com PID 1 era identificado como /sbin/init. Uma análise rápida deste arquivo mostra que se trata de um link simbólico para o systemd:
ps -fp 1
ls -hl /sbin/init
Com a opção ppid (ID do processo pai) do comando ps, conseguimos ver quais processos foram diretamente iniciados pelo systemd:
ps -f --ppid 1
Como se pode ver na imagem abaixo, é uma lista bastante extensa.
As Alternativas
Vários projetos tentaram desenvolver uma alternativa ao tradicional System V init. Um dos principais problemas do init do System V é que os processos são iniciados em série, um após o outro. Para melhorar a eficiência da sequência de inicialização, muitos projetos alternativos utilizam o paralelismo, iniciando processos de forma simultânea e assíncrona.
Seguem algumas informações sobre algumas dessas alternativas:
Upstart: Desenvolvido pela Canonical, foi utilizado no Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 e Fedora 9.
runit: Funciona em FreeBSD e outros derivados do BSD, macOS e Solaris, bem como sistemas Linux. É o sistema de inicialização padrão do Void Linux.
s6-linux-init: Este substituto do System V init foi projetado para seguir a Filosofia Unix, que é muitas vezes resumida pela máxima “faça uma coisa e faça-a bem”.
Existem muitas outras alternativas com diferentes funcionalidades e designs. No entanto, nenhuma delas causou o impacto que o systemd causou.
O Caminho do Systemd
O systemd foi lançado em 2010 e adotado pelo Fedora em 2011. Desde então, tem sido implementado em diversas distribuições. Foi desenvolvido por Lennart Poettering e Kay Sievers, dois engenheiros de software da RedHat.
O systemd é muito mais que apenas um substituto para o sistema init. É um conjunto de cerca de 70 binários que lidam com o arranque do sistema, daemons e serviços, registo de eventos e muitas outras funcionalidades que antes eram realizadas por módulos dedicados no Linux. A maior parte destas funcionalidades não está relacionada com o arranque do sistema.
Alguns dos daemons fornecidos pelo systemd são:
systemd-udevd: Gerencia dispositivos físicos.
systemd-logind: Gerencia logins de usuários.
systemd-resolved: Fornece resolução de nomes de rede para aplicações locais.
systemd-networkd: Gerencia e deteta dispositivos de rede e define as configurações de rede.
systemd-tmpfiles: Cria, elimina e limpa ficheiros e diretórios voláteis e temporários.
systemd-localed: Gerencia as configurações de idioma do sistema.
systemd-machined: Deteta e monitoriza máquinas virtuais e contêineres.
systemd-nspawn: Permite iniciar um comando ou processo dentro de um contêiner de espaço de nomes leve, oferecendo funcionalidade semelhante ao chroot.
E isto é apenas uma pequena parte do systemd, que é também o principal ponto de discórdia. O systemd ultrapassou há muito o que se esperaria de um sistema init, o que, segundo os seus opositores, é a definição de fluência de escopo.
“É Demasiado Grande. Faz Demasiado.”
Os opositores do systemd criticam a grande e complexa mistura de funcionalidades que ele agrega. Todas estas funcionalidades já existiam no Linux e, talvez, algumas delas necessitassem de uma atualização ou nova abordagem. No entanto, o agrupamento de toda esta funcionalidade no que se esperaria ser um sistema init é arquitetonicamente questionável.
O systemd tem sido apontado como um ponto único de falha para diversas funções críticas, algo que não se justifica totalmente. É verdade que se afasta da Filosofia Unix de criação de ferramentas pequenas que trabalham em conjunto, em vez de grandes softwares que fazem tudo sozinhos. Embora o systemd não seja estritamente monolítico (é composto por muitos binários, em vez de um único grande), inclui muitas ferramentas e comandos de gestão diferentes sob o mesmo “guarda-chuva”.
Embora não seja monolítico, é um sistema grande. Para ter uma ideia da sua dimensão, contamos as linhas de texto na base de código do kernel 5.6.15 e no branch master do systemd do repositório GitHub.
Esta foi uma métrica relativamente imprecisa. Contava linhas de texto, e não apenas linhas de código, incluindo comentários, documentação e tudo o mais. No entanto, foi uma comparação idêntica e forneceu-nos um critério simples:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
O kernel tinha quase 28 milhões (27.784.340, para ser exato) de linhas de texto. Já o systemd tinha 1.349.969, ou seja, quase 1,4 milhões. De acordo com a nossa métrica, o systemd tem cerca de 5% do tamanho do kernel, o que é surpreendente!
Como outra comparação, a contagem de linhas para uma implementação moderna do System V init para a distribuição Arch Linux era de 1.721 linhas.
Poettering demonstra não ter consideração pelo Instituto de Engenheiros Elétricos e Eletrónicos (IEEE) Computer Society, nem pelo padrão Portable Operating System Interface (POSIX). De facto, ele incentivou os desenvolvedores a ignorarem o POSIX:
“Portanto, obtenham uma cópia do The Linux Programming Interface, ignorem tudo o que diz sobre compatibilidade com POSIX e criem o vosso incrível software Linux. É bastante libertador!”
Surgiram acusações de que o systemd é um projeto da Red Hat que beneficia apenas a Red Hat, mas está a ser imposto ao resto do mundo Linux. Sim, foi criado na Red Hat e é gerido e dirigido por ela. No entanto, dos 1.321 colaboradores, apenas uma parte trabalha para a Red Hat.
Então, quais são os benefícios para a Red Hat?
Jim Whitehurst, o presidente da IBM, que já foi CEO da Red Hat, afirmou:
“A Red Hat analisou muitas opções disponíveis, tendo utilizado até o Upstart da Canonical para o Red Hat Enterprise Linux 6. Acabámos por optar pelo systemd por ser a melhor arquitetura, proporcionando extensibilidade, simplicidade, escalabilidade e interfaces bem definidas para resolver os problemas que vemos hoje e prever no futuro.”
Whitehurst também mencionou que via vantagens em sistemas embarcados. A Red Hat tem parcerias com “os maiores fornecedores de sistemas embarcados do mundo, principalmente nas indústrias de telecomunicações e automotiva, onde a estabilidade e confiabilidade são uma prioridade.”
Estas parecem ser razões tecnicamente sólidas. É compreensível a necessidade de confiabilidade da empresa e não é irracional que a Red Hat defenda os seus próprios interesses, mas será que todos os outros devem seguir o exemplo?
Adoção Cega do Systemd?
Alguns opositores do systemd afirmam que as distribuições e pessoas estão apenas a seguir cegamente as diretrizes da Red Hat e a adotarem o systemd.
No entanto, tal como a expressão “beber o Kool-Aid”, esta analogia não está correta. Popularizada em 1978 após o líder do culto, Jim Jones, ter coagido mais de 900 dos seus seguidores a cometer suicídio bebendo um líquido com sabor a uva misturado com cianeto, esta expressão denigre o Kool-Aid de forma injusta. O grupo bebeu, de facto, Flavor Aid, mas o Kool-Aid ficou manchado por esta associação desde então.
Além disso, as distribuições Linux não seguem cegamente a Red Hat; elas adotam o systemd após uma análise cuidadosa. O debate prolongou-se nas listas de discussão do Debian por um longo período. No entanto, em 2014, a comunidade votou para adotar o systemd como sistema de inicialização padrão, mas também para dar suporte a alternativas.
O Debian é um exemplo importante, pois não é derivado do RedHat, Fedora ou CentOS. Não existe uma influência direta da Red Hat no Debian. E o Debian, tal como o PID 1, tem muitos descendentes, incluindo o Ubuntu e seus muitos spin-offs.
As decisões tomadas pela comunidade Debian têm um grande alcance. São também vigorosamente debatidas e votadas através do método de votação de Condorcet. A comunidade não toma estas decisões de ânimo leve.
Em dezembro de 2019, votaram novamente para continuar a focar-se no systemd e a explorar alternativas. O oposto de seguir cegamente, este é, na verdade, um exemplo claro de democracia e liberdade de escolha em ação.
As Limitações da Escolha
Geralmente, não é possível escolher se deseja usar o systemd numa distribuição Linux específica. Em vez disso, as próprias distribuições decidem se o usarão ou não e pode escolher qual distribuição Linux prefere. Se a sua distribuição favorita mudar para o systemd, tal como um músico que muda de estilo, pode ser chocante.
Pessoas que utilizam Debian, Fedora, CentOS, Ubuntu, Arch, Solus e openSUSE e que se opõem à adoção do systemd, podem sentir que estão a ser impedidas de usar a sua distribuição preferida. Se forem suficientemente fervorosas em relação a alguma das opções de arquitetura, expansão de escopo ou desrespeito pelo POSIX, podem considerar insustentável continuar a usar essa distribuição.
Existe um espetro, naturalmente. De um lado, estão pessoas que não compreendem os problemas (ou mesmo se importam) e, do outro, estão os opositores mais apaixonados. Algures no meio, estão aqueles que não gostam de mudanças, mas não se incomodam o suficiente para mudar de distribuição. Mas e os “refugiados” da distribuição, que não podem continuar a usar a distribuição escolhida devido às suas preferências ou princípios?
Infelizmente, não é tão simples como instalar o sistema init que se pretende. Nem todos têm a capacidade técnica para o fazer, e existem dificuldades quando aplicações ou ambientes de desktop como o GNOME têm dependências do systemd.
Que tal mudar para outra distribuição? Algumas distribuições como a Devuan surgiram como forks de distribuições sem systemd (neste caso, o Debian) que adotaram o systemd. Utilizar o Devuan deverá ser semelhante à utilização da distribuição pai, mas não é o caso em todos os forks sem systemd. Por exemplo, se mudar do Fedora para AntiX, Gentoo ou Slackware terá uma experiência muito diferente.
O Systemd Veio Para Ficar
Gosto do que o systemd faz (mecanismos de controlo simples e padronizados para processos). Não compreendo a lógica de algumas das coisas que ele faz (logs binários). Também não gosto de algumas coisas que ele faz (renovar as pastas pessoais – quem pediu isso?).
Distribuições como o Debian estão a fazer a coisa mais inteligente, investigando alternativas para manter as suas opções em aberto. No entanto, o systemd veio para ficar a longo prazo.
Se gere máquinas Linux para outras pessoas, aprenda o systemd da mesma forma que conhece o System V init. Assim, não importa o que encontre, poderá desempenhar as suas funções.
Usa Linux apenas em casa? Nesse caso, escolha uma distribuição que atenda às suas necessidades técnicas e complemente a sua ideologia Linux.