O melhor init da praça
Comecei a acompanhar o systemd quando Lennart Poettering anunciou em seu blog a criação do projeto em 2010. Me convenceu prontamente a ideia.
Entrou como padrão no Fedora 15 operando basicamente aos moldes do Upstart no RHEL 6. Em grande parte lidando com scripts SysV no modo de compatibilidade. Não lembro ter enfrentando grandes bugs, porém eles existiam ao filtrar as flame wars da lista fedora-devel. No Fedora 17, a implementação já estava bem azeitada. Foi uma das poucas versões que durou bastante na minha máquina, praticamente até o dia em que foi descontinuada. Comecei a usar o openSUSE na versão 12.3 e da mesma forma não tive surpresas. Mais daemons rodavam com scripts SysV, mas a integração dos alemães foi boa.
No ínterim entre o systemd 26 do Fedora 15 até o 210 que uso hoje no openSUSE 13.2, alguns componentes importantes foram adicionados. udevd foi incorporado ao repositório e passou a compartilhar código com o systemd. logind (30), o sucessor espiritual do descontinuado ConsoleKit. journald (38), uma implementação syslog sob vitaminas, que armazena logs estruturados num formato de arquivo binário, e mais alguns daemons diversos para configuração do sistema, hostnamed (25), timedated, localed, (30) foram criados. Seus processos rodam separados do PID 1, o init em si, e disponibilizam via D-Bus seus recursos, que podem ser aproveitados por ambientes desktop e, claro, outros códigos, incluindo as ferramentas de linha de comando
Existiria um suposto vendor lock-in nesses serviços dizem. Será? De fato, ninguém oferecia suas funcionalidades anteriormente. Suas interfaces facilitam a vida dos programadores de ambientes desktop. Aproveitá-las faz todo o sentido, em especial as do logind, como Martin Gräßlin vive tentando explicar. Os ambientes desktop não dependem do logind, hostnamed, timedated, localed. Dependem das interfaces oferecidas por eles via D-Bus. Tais interfaces são documentadas e podem ser implementadas por outros projetos. D-Bus é multiplataforma. Marcos, acho que nenhum outro projeto implementa-as! E eu keko? O time do systemd está construindo um sistema operacional. Não são fãs do fetiche da portabilidade. Portabilidade tem um custo enorme. Quem quiser implementá-las que o faça. Não digam que, por ficarem de braços cruzados apenas reclamando, o time do systemd é responsável por vendor lock-in. É oferecida uma infraestrutura; programadores podem suportar alternativas. Nada os impede. Curiosamente, durante os quase cinco anos, ninguém colocou a mão na massa para desenvolver uma alternativa. Convenhamos, entretanto: não podemos culpar o time do systemd por isso. Leio muito recentemente sobre um ConsoleKit2. Agora sim, bem melhor do que histeria.
Voltando à questão de compilações mínimas, até o logind pode ser desabilitado. Os dois componentes obrigatórios são: udevd e journald. O primeiro por razões óbvias. O systemd não tem como funcionar sem ele. O segundo é quem colhe os logs de todos os serviços. Contudo, pode ser configurado para nada armazenar e repassar as mensagens para uma implementação syslog convencional. RHEL 7 e SLES 12 o configuram assim e o rsyslog continua no seu lugar de sempre.
Um exemplo da modularidade é a versão 210 usada no openSUSE 13.2 e SLES 12. Nela, o networkd (209) não está disponível por ter sido desabilitado na compilação. Cada distribuição faz as escolhas que achar melhor na hora de habilitar os componentes. Tirando os dois requeridos — e possivelmente o logind, de importância fundamental para a pilha gráfica —, o resto é opcional.
Trata-se do melhor init da praça para Linux. Bugs claro que existirem. Existem em qualquer lugar. Eu mesmo reportei um faz alguns dias (já consertado). Cansa é ver crítica e mais crítica sem base técnica, apenas por motivação mística, pueril. Pelo menos o rebuliço advindo da epopeia da escolha do Debian está servindo para dar publicidade ao projeto.
Entrou como padrão no Fedora 15 operando basicamente aos moldes do Upstart no RHEL 6. Em grande parte lidando com scripts SysV no modo de compatibilidade. Não lembro ter enfrentando grandes bugs, porém eles existiam ao filtrar as flame wars da lista fedora-devel. No Fedora 17, a implementação já estava bem azeitada. Foi uma das poucas versões que durou bastante na minha máquina, praticamente até o dia em que foi descontinuada. Comecei a usar o openSUSE na versão 12.3 e da mesma forma não tive surpresas. Mais daemons rodavam com scripts SysV, mas a integração dos alemães foi boa.
No ínterim entre o systemd 26 do Fedora 15 até o 210 que uso hoje no openSUSE 13.2, alguns componentes importantes foram adicionados. udevd foi incorporado ao repositório e passou a compartilhar código com o systemd. logind (30), o sucessor espiritual do descontinuado ConsoleKit. journald (38), uma implementação syslog sob vitaminas, que armazena logs estruturados num formato de arquivo binário, e mais alguns daemons diversos para configuração do sistema, hostnamed (25), timedated, localed, (30) foram criados. Seus processos rodam separados do PID 1, o init em si, e disponibilizam via D-Bus seus recursos, que podem ser aproveitados por ambientes desktop e, claro, outros códigos, incluindo as ferramentas de linha de comando
loginctl, hostnamectl, timedatectl, localectl. São daemons ativados via D-Bus. Fazem o que tem de fazer e finalizam-se, só sendo iniciados novamente ao terem seus serviços requisitados. Praticamente todos os daemons auxiliares podem ser desabilitados na compilação. Afinal, um dos alvos do systemd são os sistemas embarcados onde é usado em produção.Existiria um suposto vendor lock-in nesses serviços dizem. Será? De fato, ninguém oferecia suas funcionalidades anteriormente. Suas interfaces facilitam a vida dos programadores de ambientes desktop. Aproveitá-las faz todo o sentido, em especial as do logind, como Martin Gräßlin vive tentando explicar. Os ambientes desktop não dependem do logind, hostnamed, timedated, localed. Dependem das interfaces oferecidas por eles via D-Bus. Tais interfaces são documentadas e podem ser implementadas por outros projetos. D-Bus é multiplataforma. Marcos, acho que nenhum outro projeto implementa-as! E eu keko? O time do systemd está construindo um sistema operacional. Não são fãs do fetiche da portabilidade. Portabilidade tem um custo enorme. Quem quiser implementá-las que o faça. Não digam que, por ficarem de braços cruzados apenas reclamando, o time do systemd é responsável por vendor lock-in. É oferecida uma infraestrutura; programadores podem suportar alternativas. Nada os impede. Curiosamente, durante os quase cinco anos, ninguém colocou a mão na massa para desenvolver uma alternativa. Convenhamos, entretanto: não podemos culpar o time do systemd por isso. Leio muito recentemente sobre um ConsoleKit2. Agora sim, bem melhor do que histeria.
Voltando à questão de compilações mínimas, até o logind pode ser desabilitado. Os dois componentes obrigatórios são: udevd e journald. O primeiro por razões óbvias. O systemd não tem como funcionar sem ele. O segundo é quem colhe os logs de todos os serviços. Contudo, pode ser configurado para nada armazenar e repassar as mensagens para uma implementação syslog convencional. RHEL 7 e SLES 12 o configuram assim e o rsyslog continua no seu lugar de sempre.
Um exemplo da modularidade é a versão 210 usada no openSUSE 13.2 e SLES 12. Nela, o networkd (209) não está disponível por ter sido desabilitado na compilação. Cada distribuição faz as escolhas que achar melhor na hora de habilitar os componentes. Tirando os dois requeridos — e possivelmente o logind, de importância fundamental para a pilha gráfica —, o resto é opcional.
Trata-se do melhor init da praça para Linux. Bugs claro que existirem. Existem em qualquer lugar. Eu mesmo reportei um faz alguns dias (já consertado). Cansa é ver crítica e mais crítica sem base técnica, apenas por motivação mística, pueril. Pelo menos o rebuliço advindo da epopeia da escolha do Debian está servindo para dar publicidade ao projeto.
Comentários
Postar um comentário