Esse artigo é a tradução (livre e resumida) do documento que deu origem ao systemd. Escrito por Lennart Poettering, Et al. A partir de 2010 esse polêmico sistema pretende substituir o SysVinit e ir bem além. No documento podemos ver os motivos e as justificativas que levaram desenvolvimento do systemd na visão do seu próprio autor. Original disponível em:

• http://0pointer.de/blog/projects/systemd.html

Esta é uma longa história, mas eu recomendo que você a leia. Eu poderia resumir tudo em uma única frase: estamos experimentando um novo sistema init e ele é divertido. A história é assim:

O processo 1

Todo sistema Unix possui um processo especial identificado pelo número 1. Esse processo é inicializado pelo kernel antes de qualquer outro. Isso faz com que esse processo seja o pai de todos os processos. Devido a isso esse processo pode fazer um monte de coisas que outros processos não podem. Com os poderes vem as responsabilidades, então, o init também é responsável por coisas que outros processos não podem ser. Coisas muito importantes como trazer e manter o espaço usuário durante a inicialização.

No Linux, historicamente, o software que faz esse papel é o venerado pacote sysvinit, que persiste apesar do peso de sua idade. Muitos substitutos já foram sugeridos e apenas um realmente decolou. Seu nome é Upstart e hoje (2010) ele pode ser encontrado em muitas distribuições de peso.

Como mencionado, a responsabilidade central de um sistema init é levantar o espaço usuário. Um init bom faz isto rapidamente. Infelizmente, o sistema SysV init não é rápido o suficiente. Para ser rápido e eficiente duas coisas são cruciais:

(NT: do inglês: To start less, to start more, in parallel)

1. Menos coisas para iniciar;
2. Mais coisas para iniciar em paralelo.

Deste modo, um init eficiente inicia a menor quantidade possível de serviços e adia a inicialização de outros serviços até que ela seja realmente necessária. Sabemos da existência de serviços que, ou são iniciados cedo demais, ou são iniciados tarde demais (syslog, D-Bus etc). Todavia, para a maioria dos serviços é possível definir o tempo de inicialização certo.

Por exemplo, o daemom de Bluetooth não precisa ser inicializado a menos que um dispositivo desse tipo esteja conectado. O mesmo serve para um sistema de impressão. Até que o serviço de impressão seja solicitado, o daemon CUPS não precisa ser executado. Se não temos conexão com uma rede não precisamos do Avahi, e por aí vamos.

Iniciar "mais" em paralelo significa que se temos de executar algo, essas execuções não devem ser serializadas (o que sysvinit faz!), mas devemos rodar tudo ao mesmo tempo, aproveitando ao máximo a disponibilidade de CPU e a largura de banda em disco. O resultado é um tempo de inicialização menor.

Hardware e Software mudam dinamicamente

Sistemas modernos são dinâmicos, tanto em configuração quanto em uso. Grande parte dos sistemas atuais são móveis, isso faz com que diferentes aplicações sejam executadas em diferentes cenários. Muitos dos hardwares atuais são plugáveis, e desta forma, são adicionados e removidos com certa frequência. Isso faz com que certos serviços sejam dinamicamente executados ou parados em função da presença desses hardwares ou cenários móveis.

A maioria dos sistemas correntes que tentaram paralelizar o processo de boot continuam sincronizados com o start-up de vários daemons. Por exemplo, Avahi necessita de D-Bus como uma dependência. Existem vários outros exemplos.