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.
Índice
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 dominante para o processo init foi uma reformulação da inicialização 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 forma 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 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
. 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 ele é um link simbólico para systemd
:
ps -fp 1
ls -hl / sbin / init
Usando a opção ppid
(ID do processo pai) com ps
, podemos ver quais processos foram iniciados 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 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 no FreeBSD e outros derivados do BSD, macOS e Solaris , bem como em sistemas Linux. É também o sistema init padrão no Void Linux.
- s6-linux-init : este substituto para o init do System V foi projetado 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 diferentes funcionalidades e designs. No entanto, nenhum deles criou o furor systemd
.
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
são:
- systemd-udevd: gerencia dispositivos físicos.
- systemd-logind: Gerencia logins de usuários.
- resolvido por systemd: 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 locais do sistema.
- systemd-machined: 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. ”
Os oponentes de systemd
apontam a grande e curiosa combinação de funcionalidades que engloba. 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. Embora systemd
não seja estritamente monolítico (é composto de muitos binários em vez de um único e enorme), inclui muitas ferramentas e comandos de gerenciamento díspares em um único 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:
(localizar ./ -name '*. *' -print0 | xargs -0 cat) | wc -l
O kernel tinha quase 28 milhões (27.784.340, para ser exato) linhas de texto. Em contraste, systemd
tinha 1.349.969, ou quase 1,4 milhão. Com nossa métrica despreocupada, systemd
chega a 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 leva em consideração a Sociedade de Computadores do Instituto de Engenheiros Elétricos e Eletrônicos (IEEE), nem o 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! ”
Houve acusações de que systemd
é um projeto da Red Hat que beneficia apenas a Red Hat, mas está sendo alimentado à força por todo o mundo Linux. Sim, ele nasceu dentro da Red Hat e é governado e dirigido por ele. 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. 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, particularmente 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 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 de systemd
distribuições e pessoas estão apenas seguindo cegamente a liderança 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
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á 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 systemd
e 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 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 distro Linux prefere. Talvez uma distribuição Linux que você adore mudou 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 impedidas 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 por 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 habilidade 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 Devuan , apareceram como não systemd
bifurcações de distribuições (neste caso, Debian) que foram adotadas systemd
. O uso de Devuan deve ser semelhante à distribuição pai, mas esse não é o caso para todos os não- systemd
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
Gosto de algumas das systemd
funções (mecanismos de controle simples e padronizados para processos). Eu não entendo a razão de algumas coisas que ele faz (logs binários). Também não gosto de parte do que ele faz ( reformulação das 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. No entanto, systemd
está nele para o longo prazo.
Se você administra máquinas Linux para outras pessoas, aprenda systemd
tão bem quanto 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.
RELACIONADO: O Systemd mudará o funcionamento do seu diretório pessoal do Linux