Distribuições Linux, systemd e o conceito de 'sistema operacional'

Apesar de ser aceito coloquialmente, chamar "Linux" de sistema operacional beira o erro. Porque Linux é apenas um kernel, que sozinho não serve para nada. É preciso um espaço de usuário para você conseguir fazer algo útil com um kernel. Precisamos, no mínimo, de uma biblioteca C e alguns binários. Este espaço de usuário vai desde o BusyBox usado em sistemas embarcados até a enorme pilha de software que temos em distribuições para desktops, servidores.

Pelo fato da quase totalidade dos softwares usados nos sistemas basados no kernel Linux serem open source e de não existir uma entidade que centralize o desenvolvimento, durante o curso da história das distribuições, nunca houve uma preocupação na uniformização do sistema. Cada distribuição adotou padrões que lhe convinham e a anarquia sempre reinou. Muito diferente do que ocorre no software proprietário, onde uma das principais preocupações é o planejamento e a compatibilidade.

Diferentes ambientes gráficos, diferentes locais de arquivos de configuração, diferentes mecanismos para instalar/configurar daemons, diferentes bibliotecas, diferentes formatos de empacotamento, diferentes experiências de usuário.

William Jon McCann, desenvolvedor do Gnome, diz que, com o Gnome 3, finalmente tentarão construir um sistema operacional. Estas palavras foram ditas num tópico da lista de discussão do projeto onde Lennart Poettering sugeriu que o systemd passasse a ser uma dependência do Gnome.

Então chegamos ao systemd. Primeiramente, abro minha posição: sou um fã e torço para o systemd domine o mundo. O systemd é um init escrito do zero com o objetivo de fazer as coisas da maneira certa, aproveitando os recursos do kernel Linux pela primeira vez na história de um init! Lennart planejou o systemd com a ajuda de Kay Sievers, o mantenedor do udev.

É comum lermos que o grande destaque do systemd é proporcionar um boot mais rápido. Porém esse não é objetivo principal: é uma consequência. Além de mudanças estruturais, como uso de cgroups para monitorar com precisão os daemons, uma das primeiras diferenças que o usuário se depara na administração de um sistema que use o systemd é o fato dos scripts de inicialização SySV init (/etc/rc.d/init.d) serem tratados como legado. Os scripts SysV são uma colcha de retalhos de shell script sem uniformidade, nem mesmo em qual pasta são armazenados entre as distribuições.

O systemd usa no lugar arquivos unit, que para serviços têm a exensão ".service", que são colocados pelo gerenciador de pacotes em /lib/systemd/system e que podem ser customizados pelo administrador em /etc/systemd/system. O último diretório tem sempre preferência quando possui um arquivo unit com o mesmo nome de um existente no primeiro.

Os arquivos unit não são programas, ou seja, não são shell scripts executáveis, possuem uma formatação clara, fácil de ser analizada sintaticamente, e possuem várias opções que podem substiuir parâmetros que antes ficavam em /etc/sysconfig. O Fedora na versão 16 (ainda em desenvolvimento) migrou boa parte dos daemons para os arquivos unit. Com o tempo, o objetivo é que eles sejam incorporados ao código upstream (o tarball do desenvolvedor), o que já aconteceu com alguns programas, a propósito.

O novo init disponibiliza uma interface acessível via D-Bus (o IPC usado hoje em todas as distribuições), além de ferramentas de modo texto, para tarefas como alteração do hostname, configuração da data, hora, fuso horário, listar/habilitar/desabilitar serviços. A idéia é que, com a maioria da distribuições usando o systemd, os ambientes gráficos e aplicativos diversos não precisem se preocupar de que forma interagirão com o encanamento sobre o qual estão rodando para efetuar estas tarefas. Basta usar o que o systemd oferece, tudo ficará uniforme. Além disso, num futuro não muito distante, o systemd assumirá o gerenciamento de sessões e será capaz de gerenciar os processos de cada sessão de forma independente, finalmente trazendo ao Linux um suporte completo a multiseat.

Na busca por uma paralelização agressiva no boot, também traz a infraestrutura para ativação por soquete, que permite que daemons sejam iniciados sob demanda quando requisitados, entre outras vantagens. Estas modificações demorarão um poucos mais, pois exigem mudanças no código dos programas. Até o momento, apenas daemons syslog (rsyslog, syslog-ng), o CUPS, entre alguns outros foram adaptados.

Mas o que isso tem a ver com o conceito de 'sistema operacional'? Bastante. Porque um dos principais componentes de um sistema operacional é o seu encanamento, o que está abaixo do capô. A forma como os aplicativos se comunicam com as camadas de baixo nível do espaço de usuário. Aí entra o systemd, para começar a acabar coma anarquia neste local.

De volta ao Gnome, quem usa a versão 3 do ambiente sabe que por padrão ele tem pouca configuração de personalização disponível. Independentemente da distribuição, a cara é a mesma. Eu gostaria de poder mudar algumas coisinhas, mas não perco meu sono não. Para mim, é este o caminho mesmo. Definir uma identidade. Que nem todos gostarão, é óbvio. Paciência. O objetivo maior é pensar na plataforma.

Linux é escolha? Depende. Para um desenvolvedor, as "escolhas" significam muito mais do que bonitas palavras. Adam Jackson responde que não. E tenho que concordar com ele.

Do que adianta a escolha entre três softwares que deveriam fazer a mesma tarefa mas que nenhum a faz com qualidade? De quem é a responsabilidade de manter estes três softwares funcionando numa distribuição e arcar com todo o trabalho excedente para testar todas as interações possíveis entre eles? Falta de foco e desperdício de esforços. Eu admiro demais o código aberto, mas não tem como negar que estas situações são prejudiciais. Aliás, a teoria da seleção natural que sempre é invocada é descabida. A seleção natural demora séculos para dar resultados. No ecossistema open source, não temos tempo nem muito menos mão de obra sobrando (muito pelo contrário). Assim, enquanto a suposta "seleção" está agindo, significa usuários com software de baixa qualidade em suas máquinas, significa aborrecimento e desgaste para a plataforma.

Então, Red Hat, coloque todas suas forças no systemd, no Gnome 3 e num Fedora sempre bleeding edge. Empurrem a plataforma para frente. Tenham força para aguentar as flamewars e o FUD vindo dos que não querem mudanças, dos que querem sistemas operacionais Linux uma imagem espelho do Unix de 1970. Como Lennart diz, Unix é uma inspiração, não um dogma.