O systemd tem 10 anos, mas os sentimentos sobre isso na comunidade Linux não diminuíram – é tão divisivo agora como sempre foi. Embora seja usado por muitas das principais distribuições de Linux, a oposição incondicional 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) ou a interface de firmware extensível unificada (UEFI) é executada. A última ação de ambos é iniciar 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 de espaço do usuário é tratada pelo processo init, que é o primeiro processo lançado 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 systemd, o padrão principal para o processo init foi um retrabalho do init do Unix System V. Havia outras opções disponíveis, mas o init do System V era a opção padrão na maioria das distribuições não derivadas do Berkeley Software Distribution (BSD). Como ele veio diretamente do System V Unix – o ancestral espiritual do Linux – muitas pessoas o consideram “a maneira oficial” de fazer o init.
O processo init inicia todos os daemons e serviços necessários para fazer o sistema operacional funcionar de uma maneira significativa e interativa. Esses daemons lidam com coisas como a pilha de rede, habilitando outro hardware dentro do seu computador e fornecendo uma tela de inicialização.
Muitos desses processos em segundo plano continuam em execução após serem iniciados. Eles fazem coisas como registrar informações de eventos, observar as alterações de hardware conforme você insere ou remove dispositivos e gerenciam os 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 o f (lista de formato completo) e p (PID) opções:
ps -fp 1
Vemos que o processo com PID 1 é systemd. Executar o 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 o ppid (ID de processo pai) opção com ps, podemos ver quais processos foram lançados diretamente por systemd:
ps -f --ppid 1
É uma lista bem longa, como você pode ver na imagem abaixo.
As alternativas
Vários projetos tentaram produzir uma alternativa ao init tradicional do System V. 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 de maneira simultânea e assíncrona.
Aqui estão algumas informações sobre alguns deles:
- Subir na vida: Desenvolvido pela Canonical, foi usado no Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 e Fedora 9.
- Executá-lo: É executado em FreeBSD e outros derivados BSD, macOS e Solaris, bem como em sistemas Linux. É também o sistema init padrão no Void Linux.
- s6-linux-init: Esta substituição para o init do System V foi projetada para seguir de perto a filosofia Unix, que muitas vezes é reduzida à frase de efeito “faça uma coisa e faça-a bem”.
Existem muitos outros com funcionalidades e designs diferentes. No entanto, nenhum deles criou o furor systemd fez.
A maneira sistemática
systemd foi lançado em 2010 e foi usado no Fedora em 2011. Desde então, foi adotado por muitas distribuições. Ele foi desenvolvido por Lennart Poettering e Kay Sievers, dois engenheiros de software da RedHat.
systemd é muito mais do que uma substituição do init. Em vez disso, é um conjunto de aproximadamente 70 binários que tratam da 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 por systemd estão:
- systemd-udevd: Gerencia dispositivos físicos.
- systemd-logind: Gerencia logins de usuários.
- resolvido pelo sistema: Fornece resolução de nome de rede para aplicativos locais.
- systemd-networkd: Gerencia e detecta dispositivos de rede e gerencia configurações de rede.
- systemd-tmpfiles: Cria, exclui e limpa arquivos e diretórios temporários e voláteis.
- systemd-localed: Gerencia as configurações de localidade do sistema.
- systemd-usinado: Detecta e monitora máquinas virtuais e contêineres.
- systemd-nspawn: Pode lançar um comando ou outro processo em um contêiner de namespace leve, oferecendo uma funcionalidade semelhante ao chroot.
E isso é apenas a ponta do iceberg, que também é o ponto crucial da questão. systemd há muito ultrapassou o que é exigido de um sistema init, o que, de acordo com seus oponentes, é a própria definição de aumento de escopo.
“É muito grande. Isso faz muito. ”
Oponentes de systemd aponte a grande e curiosa combinação de funcionalidades que ela abrange. Todos esses recursos já existiam no Linux e, talvez, alguns deles precisassem de uma atualização ou uma nova abordagem. No entanto, agrupar todas essas funcionalidades no que deveria ser um sistema init é arquitetonicamente 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 isso lança a filosofia Unix de criar pequenas ferramentas que funcionam juntas em vez de grandes pedaços de software que fazem tudo pela janela. Enquanto systemd não é estritamente monolítico (é composto de muitos binários em vez de um único e enorme), ele inclui muitas ferramentas e comandos de gerenciamento díspares sob o mesmo guarda-chuva.
Embora possa não ser monolítico, é grande. Para se ter uma ideia da escala, contamos as linhas de texto na base de código 5.6.15 do kernel e o systemd branch master do repositório GitHub.
Esta foi uma métrica relativamente grosseira. Ele contou linhas de texto, não apenas linhas de código. Então, isso incluiu comentários, documentação e tudo mais. No entanto, foi uma comparação idêntica e nos deu um parâmetro 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 contraste, systemd tinha 1.349.969, ou quase 1,4 milhão. Com nossa métrica despreocupada, 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 init do System V 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 de Interface de Sistema Operacional Portátil (POSIX). Na verdade, ele encorajou os desenvolvedores a ignorar o POSIX:
“Portanto, consiga uma cópia de The Linux Programming Interface, ignore tudo o que diz sobre compatibilidade POSIX e corte seu incrível software Linux. É bastante aliviante! ”
Tem havido acusações de que systemd é um projeto da Red Hat que beneficia apenas a Red Hat, mas está sendo alimentado à força para o mundo Linux em geral. Sim, ele nasceu dentro da Red Hat e é governado e dirigido por ele. No entanto, dos 1.321 contribuidores, 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é mesmo usou o Upstart da Canonical para Red Hat Enterprise Linux 6. Em última análise, escolhemos o systemd porque é a melhor arquitetura que fornece extensibilidade, simplicidade, escalabilidade e interfaces bem definidas para resolver os problemas que vemos hoje e preveja no futuro. ”
Whitehurst também disse que viu benefícios em sistemas embarcados também. A Red Hat tem parceria com “os maiores fornecedores de produtos embarcados do mundo, especialmente nas indústrias de telecomunicações e automotiva, onde estabilidade e confiabilidade são a preocupação número um”.
Essas parecem razões tecnicamente sólidas. Você pode compreender 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 de systemd dizem que as distribuições e as pessoas estão apenas seguindo cegamente o exemplo da Red Hat e adotando-a.
No entanto, assim como a frase “bebendo Kool-Aid”, isso não está certo. Cunhado em 1978 após o líder do culto, Jim Jones, coagiu seus mais de 900 seguidores a cometer suicídio ao beber um líquido com sabor de uva misturado com cianeto, a frase envergonha incorretamente o Kool-Aid. O grupo realmente bebeu Flavor Aid, mas Kool-Aid foi manchado por aquele pincel desde então.
Além disso, as distribuições Linux não seguem cegamente a Red Hat; eles estão adotando systemd após séria deliberação. O debate grassou nas listas de discussão do Debian por um longo tempo. No entanto, em 2014, a comunidade votou para adotar systemd como o sistema init padrão, mas também oferece suporte a alternativas.
O Debian é um exemplo importante porque não é derivado do RedHat, Fedora ou CentOS. Não há orientaçã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 Condorcet. A comunidade também não faz essas escolhas levianamente.
Ele votou novamente em dezembro de 2019 para continuar a se concentrar em 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
Você geralmente não consegue escolher se quer usar systemd com uma distribuição Linux específica. Em vez disso, as próprias distribuições escolhem se desejam usá-lo e você pode escolher qual distribuição Linux prefere. Talvez uma distribuição Linux que você adora mudou para systemd. Como um músico favorito que muda de gênero, isso pode ser chocante.
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 impedidos de usar sua distribuição de escolha. Se eles tiverem uma opinião forte o suficiente sobre qualquer uma das escolhas arquitetônicas, aumento de escopo ou desconsideração pelo POSIX, eles podem achar insustentável continuar usando essa distribuição.
Existe um espectro, é claro. Em uma extremidade, você tem as pessoas que não entendem as questões (ou mesmo se importam) e, na outra, você tem os objetores fervorosos. Em algum lugar no meio estão aqueles que não gostam de mudanças, mas não estão incomodados o suficiente para abandonar o barco. Mas e quanto aos refugiados da distribuição, que não podem permanecer na distribuição escolhida por causa de suas preferências ou princípios?
Infelizmente, não é tão fácil quanto instalar qualquer 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, dependem de systemd.
Que tal mudar para outra distribuição? Alguns, como Devuan, apareceram como nãosystemd bifurcações de distribuições (neste caso, Debian) que adotaram systemd. Usar Devuan deve ser semelhante à distribuição pai, mas esse não é o caso para todos os nãosystemd garfos. 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
Eu gosto do que systemd faz (mecanismos de controle simples e padronizados para processos). Eu não entendo a razão de algumas coisas que ele faz (logs binários). Eu também não gosto de algumas coisas que ele faz (reformar as pastas pessoais – quem pediu isso?).
Distribuições como o Debian estão fazendo a coisa certa e investigando alternativas para manter suas opções abertas. Contudo, systemd está nele para o longo prazo.
Se você administra máquinas Linux para outras pessoas, aprenda systemd assim como você conhece o init do System V. Desta forma, independentemente do que encontrar, poderá cumprir as suas funções.
Basta usar o Linux em casa? Em caso afirmativo, escolha uma distribuição que atenda às suas necessidades técnicas e complemente sua ideologia Linux.
RELACIONADOS: O Systemd mudará o funcionamento do seu diretório pessoal do Linux
0 Comments