Por que o systemd do Linux ainda é divisivo depois de todos esses anos

O systemd tem 10 anos, mas os sentimentos sobre ele na comunidade Linux não melhoraram - é tão divisivo agora como sempre foi. Embora seja usado por muitas das principais distribuições Linux, a oposição hardcore não cedeu.

A sequência de inicialização do Linux

Quando você liga o computador, o hardware é inicializado e, em seguida (de acordo com o tipo de setor de inicialização usado pelo computador), o registro mestre de inicialização (MBR) é executado ou a Interface de Firmware Extensível Unificada (UEFI) é executada. A última ação de ambos é acionar o kernel do Linux.

O kernel é carregado na memória, se descompacta e inicializa. Um sistema de arquivos temporário é criado na RAM, geralmente por um utilitário chamado initramfs ou initrd . Isso permite que os drivers necessários sejam determinados e carregados. Isso, por sua vez, permite que o sistema de arquivos do espaço do usuário carregue e se prepare para estabelecer o ambiente do espaço do usuário.

A criação do ambiente do espaço do usuário é tratada pelo processo init, que é o primeiro processo iniciado pelo kernel em um espaço do usuário. Ele tem um ID de processo (PID) de 1. Todos os outros processos são filhos diretos ou indiretos do processo init.

Antes do systemd , o padrão principal para o processo init era uma reformulação do init do Unix System V. Havia outras opções disponíveis, mas o System V init era a opção padrão na maioria das distribuições derivadas do Software Distribution (BSD) não-Berkeley. Por ter vindo diretamente do System V Unix – o ancestral espiritual do Linux – muitas pessoas o consideram como “a maneira oficial” de fazer init.

O processo de inicialização inicia todos os daemons e serviços necessários para fazer o sistema operacional funcionar de maneira significativa e interativa. Esses daemons lidam com coisas como a pilha de rede, habilitando outro hardware dentro do computador e fornecendo uma tela de inicialização.

Muitos desses processos em segundo plano continuam a ser executados após serem iniciados. Eles fazem coisas como registrar informações de eventos, observar alterações de hardware à medida que você insere ou remove dispositivos e gerencia logins de usuários. Sem surpresa, o sistema init também inclui recursos para gerenciar serviços.

Podemos usar ps para ver o processo que tem PID 1. Usaremos as opções f (lista de formato completo) e p (PID):

 ps-fp 1 

Vemos que o processo com PID 1 é systemd . A execução do mesmo comando no Manjaro Linux produziu um resultado diferente. O processo com PID 1 foi identificado como /sbin/init . Uma rápida olhada nesse arquivo mostra que é um link simbólico para systemd :

 ps-fp 1

 ls -hl /sbin/init 

Usando a ppid (parent process ID) com ps , podemos ver quais processos foram lançados diretamente pelo systemd :

 ps -f --ppid 1 

É uma lista bastante longa, como você pode ver na imagem abaixo.

As alternativas

Vários projetos tentaram produzir uma alternativa ao tradicional System V init. Um dos principais problemas é que, com o init do System V, todos 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 usam paralelismo para iniciar processos simultaneamente e de forma assíncrona.

Aqui estão algumas informações sobre alguns deles:

• Upstart: Desenvolvido pela Canonical, foi usado no Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 e Fedora 9.
• Runit: roda em FreeBSD e outros derivados de BSD, macOS e Solaris, bem como em sistemas Linux. É também o sistema de inicialização padrão no Void Linux.
• s6-linux-init: Este substituto para o System V init foi projetado para seguir de perto a filosofia Unix, que geralmente é reduzida à frase de efeito “faça uma coisa e faça bem”.

Existem muitos outros de diferentes funcionalidades e design. No entanto, nenhum deles criou o furor que o systemd fez.

O Caminho Systemd

systemd foi lançado em 2010 e foi usado no Fedora em 2011. Desde então, foi adotado por muitas distribuições. Foi desenvolvido por Lennart Poettering e Kay Sievers, dois engenheiros de software da RedHat.

systemd é muito mais do que uma substituição de inicialização. Em vez disso, é um conjunto de aproximadamente 70 binários que lidam com inicialização do sistema, daemons e serviços, registro e registro em diário e muitas outras funções que já eram tratadas por módulos dedicados no Linux. A maior parte deles não tem nada a ver com a inicialização 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 aplicativos locais.
• systemd-networkd : Gerencia e detecta dispositivos de rede e gerencia as configurações de rede.
• systemd-tmpfiles: Cria, exclui e limpa arquivos e diretórios voláteis e temporários.
• systemd-localed: Gerencia as configurações de localidade do sistema.
• systemd-machined: detecta e monitora máquinas virtuais e contêineres.
• systemd-nspawn: pode iniciar um comando ou outro processo em um contêiner de namespace leve, fornecendo uma funcionalidade semelhante ao chroot.

E isso é apenas a ponta do iceberg, que também é o cerne da questão. O systemd há muito ultrapassou o que é exigido de um sistema init, que, de acordo com seus oponentes, é a própria definição de fluência de escopo.

"É muito grande. Faz demais.”

Os oponentes do systemd apontam a grande e curiosa mistura de funcionalidades que ele engloba. Todos esses recursos já existiam no Linux e, talvez, alguns deles precisassem de uma atualização ou uma nova abordagem. No entanto, agrupar toda essa funcionalidade no que deveria ser um sistema init é arquiteturalmente intrigante.

systemd foi chamado de ponto único de falha para muitas funções críticas, mas isso não parece ser justificável. É certo que lança a filosofia Unix de criar pequenas ferramentas que trabalham juntas em vez de grandes softwares que fazem tudo pela janela. Embora o systemd não seja estritamente monolítico (é composto por muitos binários em vez de um único grande), ele inclui muitas ferramentas e comandos de gerenciamento diferentes sob um guarda-chuva.

Embora possa não ser monolítico, é grande. Para ter uma ideia de escala, contamos as linhas de texto na base de código do kernel 5.6.15 e o branch master systemd do repositório GitHub.

Esta foi uma métrica relativamente grosseira. Contava linhas de texto, não apenas linhas de código. Então, isso inclui comentários, documentação e tudo mais. No entanto, foi uma comparação idêntica e nos deu 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) linhas de texto. Por outro lado, o systemd tinha 1.349.969, ou quase 1,4 milhão. Com nossa métrica despreocupada, o systemd sai com cerca de 5% do tamanho do kernel, o que é uma loucura!

Como outra comparação, a contagem de linhas para uma implementação moderna do System V init para a distribuição Arch Linux chegou a 1.721 linhas.

Poettering claramente não tem consideração pela Sociedade de Computadores do Instituto de Engenheiros Elétricos e Eletrônicos (IEEE), nem pelo padrão Portable Operating System Interface (POSIX). Na verdade, ele encorajou os desenvolvedores a ignorar o POSIX:

“Então, pegue uma cópia do The Linux Programming Interface, ignore tudo o que ele diz sobre compatibilidade com POSIX e corte seu incrível software Linux. É bastante aliviador!”

Houve acusações de que o systemd é um projeto da Red Hat que só beneficia a Red Hat, mas está sendo forçado a alimentar o mundo Linux mais amplo. Sim, ela nasceu dentro da Red Hat e é governada e dirigida por ela. No entanto, dos 1.321 colaboradores, apenas uma fração trabalha para a Red Hat.

Então, quais são os benefícios da Red Hat?

Jim Whitehurst, presidente da IBM, que já foi CEO da Red Hat, disse:

“A Red Hat considerou muitas opções disponíveis e até usou o Upstart da Canonical para Red Hat Enterprise Linux 6. Por fim, escolhemos o systemd porque é a melhor arquitetura que fornece extensibilidade, simplicidade, escalabilidade e interfaces bem definidas para resolver os problemas que vemos hoje e prever no futuro”.

Whitehurst também disse que viu benefícios em sistemas embarcados também. A Red Hat faz parceria com “os maiores fornecedores integrados do mundo, particularmente nas indústrias de telecomunicações e automotiva, onde a estabilidade e a confiabilidade são a preocupação número um”.

Estas parecem razões tecnicamente sólidas. Você pode entender a necessidade de confiabilidade da empresa, e não é irracional para a Red Hat cuidar de seus próprios interesses, mas todos os outros deveriam seguir o exemplo?

Bebendo o Kool-Aid do sistema?

Alguns oponentes do systemd dizem que as distribuições e as pessoas estão apenas seguindo cegamente a liderança da Red Hat e adotando-a.

No entanto, assim como a frase “beber o Kool-Aid”, isso não está certo. Cunhada em 1978 depois que o líder do culto, Jim Jones, coagiu seus mais de 900 seguidores a cometer suicídio bebendo um líquido com sabor de uva misturado com cianeto, a frase incorretamente envergonha Kool-Aid. O grupo realmente bebeu Flavor Aid, mas Kool-Aid foi manchado por esse pincel desde então.

Além disso, as distribuições Linux não seguem cegamente a Red Hat; eles estão adotando o systemd após séria deliberação. O debate durou muito tempo nas listas de discussão do Debian. No entanto, em 2014, a comunidade votou para adotar o systemd como o sistema init padrão, mas também para oferecer suporte a alternativas.

O Debian é um exemplo importante porque não é derivado do RedHat, Fedora ou CentOS. Não há direção aplicada ao Debian da Red Hat. E o Debian, como o PID 1, tem muitos descendentes, incluindo o Ubuntu e seus muitos spin-offs.

As decisões tomadas pela comunidade Debian são de longo alcance. Eles também são vigorosamente debatidos e votados usando o método de votação de Condorcet. A comunidade também não faz essas escolhas de ânimo leve.

Votou novamente em dezembro de 2019 para continuar a se concentrar no systemd e continuar a explorar alternativas. O oposto de seguir cegamente, este é na verdade um exemplo clássico de democracia e liberdade de escolha no trabalho.

As limitações da escolha

Geralmente, você não pode escolher se deseja usar o systemd com uma distribuição Linux específica. Em vez disso, as próprias distribuições escolhem se querem usá-lo e você pode escolher qual distribuição Linux você prefere. Talvez uma distribuição Linux que você adora tenha mudado para systemd . Como um músico favorito que muda de gênero, isso pode ser chocante.

As pessoas que usam Debian, Fedora, CentOS, Ubuntu, Arch, Solus e openSUSE e se opõem à adoção de systemd , podem sentir que estão sendo impedidas de usar sua distribuição de escolha. Se eles se sentirem fortes o suficiente sobre qualquer uma das opções de arquitetura, aumento de escopo ou desrespeito pelo POSIX, eles podem achar insustentável continuar usando essa distribuição.

Há um espectro, é claro. De um lado, você tem as pessoas que não entendem as questões (ou mesmo se importam), e do outro, você tem os opositores apaixonados. Em algum lugar no meio estão aqueles que não gostam de mudanças, mas não se incomodam o suficiente com isso para abandonar o barco. Mas e os refugiados da distribuição, que não podem permanecer na distribuição escolhida devido às suas preferências ou princípios?

Infelizmente, não é tão fácil como instalar o sistema init que você deseja. Nem todo mundo tem capacidade técnica para fazer isso, não importa as dificuldades que surgem quando aplicativos ou ambientes de desktop, como o GNOME, têm dependências do systemd .

Que tal mudar para outra distribuição? Alguns, como o Devuan, apareceram como forks de distribuições não systemd (neste caso, Debian) que adotaram o systemd . O uso do Devuan deve ser semelhante à distribuição pai, mas esse não é o caso de todos os forks que não são do systemd . Por exemplo, se você sair do Fedora e mudar para o AntiX, Gentoo ou Slackware, você terá uma experiência muito diferente.

Não vai a lugar nenhum

Gosto do que o systemd faz (mecanismos de controle simples e padronizados para processos). Eu não entendo a lógica de algumas 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 fazendo a coisa mais inteligente e investigando alternativas para manter suas opções abertas. No entanto, o systemd está nele para o longo prazo.

Se você administra máquinas Linux para outros, aprenda systemd assim como conhece o System V init. Dessa forma, não importa o que você encontre, você poderá desempenhar suas funções.

Basta usar o Linux em casa? Nesse caso, escolha uma distribuição que atenda às suas necessidades técnicas e complemente sua ideologia Linux.

RELACIONADO: O Systemd mudará o funcionamento do seu diretório inicial do Linux