Expliquei antes o que acredito que um sistema init deveria fazer e vimos o que os sistemas atuais fazem. Tudo que sugeri como características e requisitos para um sistema de inicialização ideal estará disponível em systemd. Tudo ainda é muito experimental (escrito em 2010) mas o código já está disponível. Vejamos algumas características:

Systemd inicia e supervisiona o sistema inteiro. Ele implementa todas as características apontadas acima e até um pouco mais. Systemd é baseado na noção de Unidades (Units). Uma unidade tem um nome e um tipo. As unidades são armazenadas no sistema de arquivos com nomes como: avahi.service. A leitura desse arquivo faz a configuração de um serviço de mesmo nome. Existem vários tipos de Unidades:

1. serviços - Essa é unidade mais óbvia. Daemons são iniciados, parados, reiniciados, recarregados, etc. Procuramos manter compatibilidade com SysV e podemos ler scripts clássicos presentes em /etc/init.d se eles tiverem um cabeçalho LSB.

2. soquetes - Essa unidade encapsula um soquete no sistema de arquivos ou na Internet. São suportados AF_INET, AF_INET6, e AF_UNIX do tipo stream, datagrama ou pacotes sequenciais. Também suportamos FIFOs clássicos como meio de transporte. Cada tipo de soquete está associado a um serviço. Por exemplo, um soquete nscd.socket inicia nscd.service em uma conexão de entrada.

3. dispositivos - Essa unidade encapsula um dispositivo da árvore de dispositivos Linux. Se um dispositivo é marcado via regras de udev, ele será exposto como uma unidade do tipo dispositivo em systemd. Propriedades configuradas por udev podem ser utilizadas como fonte para definir dependências para esses dispositivos.

4. ponto de montagem - Essa unidade encapsula um ponto de montagem na hierarquia do sistema de arquivos. Systemd monitora todos os pontos de montagem a partir de onde eles vem e para onde eles vão. Além disto, essas unidades podem ser utilizadas para montar ou desmontar esses pontos. O arquivo em /etc/fstab é utilizado como uma fonte adicional de configurações para esses pontos de montagem.

5. automount - Essa unidade encapsula pontos de montagem automatizados. Cada unidade automount possui uma unidade mount correspondente. Isso faz com que esse ponto seja montado tão logo seja acessado.

6. target - Essa unidade é utilizada para agrupamento lógico de unidades. Essas unidades não fazem nada por si só. Elas são referências para grupos de unidades que podem ser controladas em conjunto. Por exemplo, podemos ter um alvo chamado multi-user.target que corresponde a um conjunto de regras do SysV necessárias para levar o sistema para o nível de execução 5 (runlevel 5).

7. snapshot - Similar a target. São utilizados para salvar/reverter o estado de todos os serviços e unidades. Por exemplo, se houver necessidade de entrar em um estado de emergência (Shell de manutenção ou runlevel 1), todos os serviços precisam ser encerrados. Após o término da manutenção o estado anterior precisa ser restaurado.

O mesmo serve para um sistema que entrou em estado de suspensão. Todas essas unidades têm dependências entre si (requerimentos e conflitos). Por exemplo, um ponto de montagem como /home/lennart implicitamente possui uma dependência que é a montagem de /home. Vejamos uma curta lista dessas características:

1. Para cada processo instanciado, você pode controlar: o ambiente, os recursos, os diretórios de trabalho e o raiz, a máscara de arquivos, o nível de gentileza, a prioridade e a classe de I/O, a política de uso e afinidade de CPU, o id de usuário e de grupo, o acesso ao sistema de arquivos e várias outras coisas. Você pode fazer coisas como conectar em stdin/stdout/stderr, serviços como syslog, /dev/kmsg ou ttys arbitrárias.
2. Cada processo executado possui seu próprio cgroup e ele é fácil de configurar com systemd para colocar serviços nesses grupos configurados externamente. Por exemplo, através de utilitários libcgroups.
3. A configuração nativa usa uma sintaxe que segue de perto padrões do tipo ".desktop".
4. Como mencionado, systemd fornece compatibilidade com scripts SysV. Tiramos vantagem de cabeçalhos LSB ou chkconfig (Red Hat) se disponíveis. Se essas opções não estão disponíveis nós tentamos fazer o melhor com as informações disponíveis, tais como as prioridades iniciais em /etc/rc.d. Esses scripts são considerados uma fonte alternativa de informações. Opcionalmente podemos ler arquivos clássicos de PID para identificar um serviço. Note que fazemos uso de informações do cabeçalho LSB e traduzimos isso como dependências nativas em systemd.
5. De modo similar, lemos a configuração em /etc/fstab e consideramos os dados como outra fonte de informações. A opção comment= em fstab torna suas entradas automaticamente controladas por systemd.
6. Quando uma unidade possui múltiplas fontes de configuração (por exemplo, /etc/systemd/system/avahi.service e /etc/initd.avahi) a configuração nativa terá precedência, o formato legado é ignorado, permitindo atualizar caminhos e pacotes para continuar usando scripts SysV e serviços systemd por um tempo.
7. Suportamos um mecanismo de templates e instâncias simples. Exemplo: Em vez de termos seis arquivos para configurar seis gettys, temos apenas um único getty@.service que usamos para instanciar getty@tty2.service e afins. A interface pode ser herdada pelas dependências.
8. Suportamos a compatibilidade completa com o modo tradicional de inetd para ativação de soquetes. Temos um modo simples de imitar a ativação por soquete de launchd e recomendamos esse modo para novos serviços. O modo inetd somente permite passagem de um soquete para o daemon started, enquanto o modo nativo suporta a passagem arbitrária de números do arquivo de descritores. Suportamos uma instância por conexão, assim como uma instância para todos os modos de conexão. No modo antigo nomeamos o daemon que será inicializado em um cgroup, após os parâmetros de conexão, e utilizamos a lógica de templates mencionada anteriormente.
9. Provemos compatibilidade com /dev/initctl para certas extensões. Implementada através de um FIFO ativado por serviço, que simplesmente traduz essas requisições legadas para D-Bus. Na prática, coisas como o antigo shutdown, poweroff e comandos similares em Upstart e sysvinit agora estão em systemd.
10. Provemos compatibilidade com utmp e wtmp. Acreditamos que fizemos melhor que o modo original destas funções.
11. Systemd suporta diversos tipos de dependências entre unidades. A ordem como as unidades são alteradas pode ser ajustada com After/Before. Isso é completamente ortogonal e exige que um requerimento positivo seja expressado como algo mandatório ou facultativo. Então, quando há um conflito ele é expresso na forma de uma dependência negativa. Existem outros três tipos de dependências que são pouco utilizadas.
12. Systemd lida o mínimo possível com transações. Se uma unidade é requisitada para inicializar ou encerrar ela será adicionada e suas dependências são transações. Então, verificaremos se as transações são consistentes.
13. Gravamos o tempo de execução (start/exit), o PID e o estado de saída de cada processo que inicializamos e supervisionamos. Esses dados podem ser cruzados com dados de daemons em abrtd, autid e syslog.
14. Suportamos a reexecução do Init a qualquer tempo permitindo upgrades sem reboot.
15. Iniciamos um trabalho para eliminar shell script do processo de boot. Acreditamos que o sistema possa ser inicializado em C e depois movido para systemd.
16. O estado do servidor será monitorado por D-Bus.
17. Damos enfase na ativação baseada em soquete e bus-name, deste modo suportamos dependências entre soquetes e serviços, e entre serviços.
18. Quando um processo é inicializado por systemd, isso pode ser confirmado com systemd.confirm_spawn=1 na linha de comando.
19. Usando systemd.default= na linha de comando, seus parâmetros pessoais podem ser definidos em tempo de boot.
20. Há uma interface para inicializar/parar serviços. Seu nome é systemadm.

Você deve que sytemd utiliza muitas características que são únicas no Linux, e não é limitada a POSIX. Isso destrava uma série de funcionalidades dentro de um sistema que é projetado para a portabilidade, mas outros sistemas não podem prover essas funcionalidades.

NT: Essa tradução busca entender o espírito do texto de Lennart. Se precisa das palavras exatas procure o texto original. Não emita comentários baseados nessa tradução, ela não é precisa o suficiente para permitir isso.

[1] - https://en.wikipedia.org/wiki/Harald_Hoyer