Falta de liberdade?
Como macaco velho que acompanha o nem mais tão novo assim systemd, já tive a oportunidade de ler muitas discussões/flames a respeito do mesmo. Um traço que chama a atenção é a falta de racionalidade de seus detratores. Entre as críticas, a tal "falta de liberdade". Essa é a que mais me espanta. Porque é um código livre, com uma documentação excelente (arrisco dizer que está entre os projetos open source mais bem documentados), programado por um time que conseguiu envidar esforços para resolver problemas. Talvez queiram dizer que a "liberdade" é aquela de trocar componentes fundamentais do sistema operacional à esmo e esperar que tudo funcione?
Se dissessem que as ferramentas são "muito fáceis", "muito diferentes do que existia antes", ou que "é muito bugado", "consome recursos em excesso", daria para considerar — ressalvas à parte. A propósito dos bugs, não acho que seja um código muito bugado.Dois Três bugs realmente graves me vêm à cabeça.
RHBZ#1184016, que demorou menos de dois meses para ser arrumado por 2230852b e a0827e2b.
RHBZ#1170765, bug antigo, do qual finalmente temos o diagnóstico. Lennart diz que reverter 743970d2 não é a melhor solução (mas é o que as distribuições estão fazendo, com exceção do Fedora, que não fez porcaria nenhuma) e commitou e9db43d5, que ainda não conserta-o por completo. Diz estar aberto a contribuições para um patch que compense a deficiência no monitoramento da hierarquia legada do subsistema de cgroups. Solução definitiva é usar a nova hierarquia unificada disponível a partir do kernel 4.2 e suportada a partir do systemd 226 (a8c0f367).
[Atualização - 24/09/2015] Ok, lembrei de mais um, cujos sintomas eram mensagens "Looping too fast. Throttling execution a little" e, dependendo de outros fatores, falta de responsividade (ou até mesmo loop infinito). Krzysztof Kotlenga esmiuçou o problema e resolveu-o hoje. Vejam que, pelo email, é um funcionário de uma empresa polonesa fornecedora de soluções embarcadas para o setor automotivo, em especial para o transporte coletivo! Quando digo abaixo "projeto vivo", é sobre isso de que falo.
Às vezes a velocidade das correções pode não ser ideal. No entanto, temos um código ativamente desenvolvido. Um projeto vivo, com diferentes colaboradores, hobbistas e profissionais de variadas empresas. A Red Hat lidera em termos de número de commits, porém não importa. Poderia ser outra empresa, não faria diferença! Os patches são analisados sob óptica puramente técnica[1]. By design, tira a complexidade que antes estava nos scripts SysV e implementa-a, com mais recursos, em seu código em C. O que antes era espalhado, com várias implementações diferentes, cada uma contendo suas deficiências, fica agora centralizado num lugar onde todas as distribuições podem trabalhar, compartilhando código e QA. Michael Stapelberg, na DebConf13, resumiu a questão (a partir de 9:07). A concorrência, ou seja, o Upstart, supostamente "mais estável", tem bugs piores e seu desenvolvimento acabou.
[1] Algumas poucas vezes patches bem programados foram rejeitados por não enquadrarem-se no design. Trata-se de decisão dos mantenedores e precisa ser tomada. Todo grande projeto de software necessita de uma liderança nessas situações que diga sim ou não. E percalços acontecem; não podemos julgar todo o trabalho, contudo, com base neles.
Se dissessem que as ferramentas são "muito fáceis", "muito diferentes do que existia antes", ou que "é muito bugado", "consome recursos em excesso", daria para considerar — ressalvas à parte. A propósito dos bugs, não acho que seja um código muito bugado.
RHBZ#1184016, que demorou menos de dois meses para ser arrumado por 2230852b e a0827e2b.
RHBZ#1170765, bug antigo, do qual finalmente temos o diagnóstico. Lennart diz que reverter 743970d2 não é a melhor solução (mas é o que as distribuições estão fazendo, com exceção do Fedora, que não fez porcaria nenhuma) e commitou e9db43d5, que ainda não conserta-o por completo. Diz estar aberto a contribuições para um patch que compense a deficiência no monitoramento da hierarquia legada do subsistema de cgroups. Solução definitiva é usar a nova hierarquia unificada disponível a partir do kernel 4.2 e suportada a partir do systemd 226 (a8c0f367).
[Atualização - 24/09/2015] Ok, lembrei de mais um, cujos sintomas eram mensagens "Looping too fast. Throttling execution a little" e, dependendo de outros fatores, falta de responsividade (ou até mesmo loop infinito). Krzysztof Kotlenga esmiuçou o problema e resolveu-o hoje. Vejam que, pelo email, é um funcionário de uma empresa polonesa fornecedora de soluções embarcadas para o setor automotivo, em especial para o transporte coletivo! Quando digo abaixo "projeto vivo", é sobre isso de que falo.
Às vezes a velocidade das correções pode não ser ideal. No entanto, temos um código ativamente desenvolvido. Um projeto vivo, com diferentes colaboradores, hobbistas e profissionais de variadas empresas. A Red Hat lidera em termos de número de commits, porém não importa. Poderia ser outra empresa, não faria diferença! Os patches são analisados sob óptica puramente técnica[1]. By design, tira a complexidade que antes estava nos scripts SysV e implementa-a, com mais recursos, em seu código em C. O que antes era espalhado, com várias implementações diferentes, cada uma contendo suas deficiências, fica agora centralizado num lugar onde todas as distribuições podem trabalhar, compartilhando código e QA. Michael Stapelberg, na DebConf13, resumiu a questão (a partir de 9:07). A concorrência, ou seja, o Upstart, supostamente "mais estável", tem bugs piores e seu desenvolvimento acabou.
[1] Algumas poucas vezes patches bem programados foram rejeitados por não enquadrarem-se no design. Trata-se de decisão dos mantenedores e precisa ser tomada. Todo grande projeto de software necessita de uma liderança nessas situações que diga sim ou não. E percalços acontecem; não podemos julgar todo o trabalho, contudo, com base neles.
Comentários
Postar um comentário