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.
últimas postagens
A sequência de inicialização do Linux
Ao ligar o computador, o hardware inicializa e, em seguida (de acordo com o tipo de setor de inicialização seu computador usa) ou o registro mestre de inicialização (MBR) executa ou o Interface de firmware extensível unificada (UEFI) é executado. A última ação de ambos é acionar o Kernel Linux.
O kernel é carregado na memória, se descompacta e inicializa. UMA sistema de arquivos temporários é 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. Tem um ID do 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 Inicialização do Unix System V. Havia outras opções disponíveis, mas o System V init era a opção padrão na maioria dasDistribuição de software de Berkeley (BSD) distribuições derivadas. 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 demônios 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 o systemd:
ps -fp 1
ls -hl /sbin/init
Usando a opção ppid (ID do processo pai) 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:
Subir na vida: Desenvolvido por Canônicofoi usado no Ubuntu 9.10, chapéu vermelho, Red Hat Enterprise Linux (RHEL) 6, CentOS 6, e Fedora 9.
Executá-lo: Corre em FreeBSD e outros derivados BSD, macOS e Solarisbem como sistemas Linux. É também o sistema de inicialização padrão em Vazio Linux.
s6-linux-init: Este substituto para o System V init foi projetado para seguir de perto o Filosofia Unixque muitas vezes é reduzido à 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 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 Poesia de Lennart e Kay Sieversdois 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, oferecendo uma funcionalidade semelhante a 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 o 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 no branch master do 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.
Poeter claramente não tem consideração pelo Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE) Computer Society, nem o Interface de sistema operacional portátil (POSIX) padrão. Na verdade, ele incentivou os desenvolvedores a ignorar 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 Whitehursto presidente da IBM, que foi uma vez o 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. Cunhado em 1978 após líder do culto, Jim Jonescoagiu 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 se alastrou no Debian listas de discussão por um longo tempo. No entanto, em 2014, a comunidade votou pela adoção do systemd como sistema de inicialização 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 sobre o uso 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 continuar a focar-se 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 o systemd. Como um músico favorito que muda de gênero, isso pode ser chocante.
Pessoas que usam o Debian, Fedora, CentOS, Ubuntu, Arco, Soluse openSUSEe se opõem à adoção do systemd, podem sentir que estão sendo impedidos 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 GNOME, ter dependências de systemd.
Que tal mudar para outra distribuição? Alguns gostam Devuanapareceu como forks de distribuições não systemd (neste caso, Debian) que adotaram systemd. O uso do Devuan deve ser semelhante à distribuição pai, mas esse não é o caso de todos os forks não systemd. Por exemplo, se você sair do Fedora e mudar para AntiX, Gentooou Slackwarevocê 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 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 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 outras pessoas, 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.