andrelop’s blog

Distribuições voluntárias abertas mais estáveis que distribuições enterprise

Quotando Luis Villa :

It is worth remembering that every significant community linux distro has a community of thousands who will gladly test anything you throw at them, so distros must actively encourage and take advantage of that. Any distro which doesn’t (and many don’t) is throwing away free time and free money. (Relatedly, I firmly believe that as a result of the opportunity for free QA, most open distros should in practice be more stable than their ‘enterprise’ alternatives, which have smaller user bases who would rather pay for someone else to do the work. That in practice enterprise distros tend to be more stable points to inefficiencies in how open distro QA is done, IMHO, not just the obvious points about business models.)

Ótimo ponto Distribuições enterprise possuem usuários que pagam exatamente para que as equipes de QA das mesmas se ocupem em manter a distribuição estável, além de lançar atualizações de segurança que não quebrem nenhuma funcionalidade enquanto corrigindo falhas de segurança.

Ou seja, apesar de, obviamente, existirem excessões, em geral aparentemente os usuários de distribuições enterprise esperam um produto pronto e bem mantido, até porque estão pagando pelo mesmo, dando menor importância ao ato de testes e relatos de problemas do que usuários de distribuições voluntárias abertas.

Por mais dinheiro que as empresas que mantém funcionários trabalhando em tempo integral para fazer o trabalho de QA tenham, nunca será possível ultrapassar em termos de quantidade uma imensa comunidade de usuários testando cada pequeno novo release de software.

Ok, quantidade pode não resultar em qualidade, mas sempre aprendemos que no modelo de desenvolvimento aberto, quanto mais olhos tivermos atentos para o mesmo código, melhor. Correto ?

Isso na verdade é o ponto crucial do modelo de desenvolvimento de software aberto e deveria ser o alicerce principal de qualquer distribuição decente atual. Nesse ponto as distribuições voluntárias abertas saem ganhando, e muito.

Se lermos o restante do post do Luis, podemos conferir que ele, em outro ponto, cita que em uma pesquisa não oficial e totalmente não científica, Lucas (um contribuidor de projetos de software livre) descobriu que 76% dos usuários conectados em redes de IRC em um dado momento utilizavazam a verão “unstable” do Debian. Uau ! Isso é bastante interessante.

Se esse uso for revertido em relatos de problemas/bugs a cada vez que um problema é encontrado, e a quantidade de bugs duplicados quando um problema grave é encontrado no Debian unstable me faz achar que realmente seja, vê-se que realmente temos uma equipe imbatível de testes.

Isso somado a política do Debian em não incluir em um release estável softwares com bugs críticos conhecidos explica a fama de estável que o Debian possui

Performancing : blogando a partir do navegador

Estou testando o Performancing, uma extensão do Firefox para publicação de mensagens em blogs que me pareceu bastante interessante e completa, me permitindo blogar diretamente do Firefox, sem que eu precise me autenticar através da interface de postagens de meu blog.

Adicionar contas é muito fácil, com uma interface Wizard-like. Após ter a conta adicionada, é possível ver as entradas anteriores já postadas, escrever novos posts e verificar uma previsão dos mesmos antes de publicá-los, definir a quais categorias o post deve ser relacionado e muito mais.

O único problema é que meu navegador padrão é o Epiphany, mas essa extensão, se funcionar bem, pode me fazer reconsiderar uma troca

Update: Screenshot disponível, exibindo o plugin em ação.

Thunderbird e ReplyToList : agora possível no Debian !

A principal razão de eu ainda usar um cliente de e-mail em modo texto, mesmo usando um ambiente gráfico, é que eu nunca encontrei um cliente de e-mail gráfico que tivesse a agilidade e o conjunto de recursos que eu estou acostumado a utilizar em meu cliente de e-mail atual.

O Mozilla Thunderbird foi o cliente de e-mail gráfico que chegou mais perto de atender a todas as minhas necessidades e, na verdade, é o cliente de e-mail que utilizo na empresa onde trabalho, onde tenho que lidar com mensagens provenientes de fontes que não dão a mínima para padrões.

Para uso doméstico, onde não sou obrigado a suportar esse tipo de mensagens, sempre me mantive fiel ao meu bom e velho cliente de e-mail em modo texto, que me oferece agilidade e recursos que nenhum outro cliente de e-mail oferece, dos quais eu dependo fortemente.

A única razão pela qual eu ainda não havia conseguido me acostumar ao Mozilla Thunderbird é o fato do mesmo não ter suporte nativo ao recurso de “responder para lista”. Para mim, que assino algo em torno de 15 listas de discussão diferentes, esse recurso é essencial.

Uma extensão para acrescentar essa funcionalidade existe, mas a mesma depende de algumas modificações no código do Mozilla Thunderbird, através da aplicação de um patch que aparentemente está agendado para entrar somente na versão 3.0 (sim, isso mesmo, 3.0 e não 2.0) do Thunderbird. Eu previ que não seria uma boa manter minha própria cópia compilada manualmente do Thunderbird e ter que atualizá-la constantemente a cada novo release.

Hoje, porém, parece que minhas preces foram ouvidas : o novo pacote da versão 1.5.0.5 do Mozilla Thunderbird que acabou de entrar no Debian unstable contém o patch em questão aplicado, possibilitando que a inclusão do recurso de responder para listas seja tão fácil quanto simplesmente instalar a extensão que implementa esse recurso.

Hora de, novamente, tentar fazer a migração, reescrever meus filtros do procmail para expressá-los de maneira que o Mozilla Thunderbird entenda e, quem sabe, dar adeus ao fetchmail. Porém, ainda vou manter um MTA local em meu laptop (usando meu servidor pessoal como relayhost), já que seria pedir demais subsitutos gráficos (extensões do Thunderbird talvez ?) do reportbug e do comando bts (presente no pacote devscripts). Ou não ?

Update: Screenshot disponível, exibindo a opção de menu (também existe um botão na barra de menus) adicionada após a instalação do plugin.

stable_api_nonsense e distribuições enterprise-ready

Hoje tive a prova de que realmente não há sentido drivers de dispositivos serem mantidos externamente à árvore oficial do kernel. Se eles são mantidos fora, em minha opinião, só existem duas explicações :

• O código não é limpo/correto o suficiente para ser aceito na árvore oficial

• Os desenvolvedores nunca leram a documentação explicando porque uma API estável para o kernel não tem sentido

Já havia passado por muita raiva anteriormente utilizando módulos de kernel mantidos externamente, mas a política de atualizações de segurança do Debian sempre me ajudou muito nisso, porque mesmo com uma mudança de ABI em novos pacotes de kernel, regerar módulos de kernel empacotados no Debian é trivial e eu tinha a garantia de que a mudança na ABI foi necessária para corrigir uma falha de segurança real e não para acrescentar backports de funcionalidades novas suspeitas mascaradas como atualizações de segurança.

Mas hoje tive de lidar com outra distribuição que não segue essa política e me convenci que não ter o código para dar suporte a qualquer tipo de hardware que seja incluso na árvore oficial do kernel só gera dor de cabeça. O cenário : dois servidores, cada qual com 8 processadores e 8GB de memória, acessando um IBM TotalStorage DS4300 via fibra. O módulo que usamos para ter suporte um pouco melhor a failover das fibras é código mantido fora da árvore oficial do kernel (são dois, na verdade, mas isso é outra história).

Atualizações de segurança do kernel “oficiais” (ou seja, pacotes lançados pelo distribuidor oficial) instaladas, código do módulo externo recompilado, initrds regerados, servidores reiniciados e tudo aparentemente funcional. Percebeu o “aparentemente” ? O diabo está nos detalhes : o failover das fibras simplesmente parou de funcionar, congelando os servidores quando qualquer uma das fibras era removida e reinserida.

Depois de muita dor de cabeça para entender qual era o problema descobrimos que uma nova versão do código que implementa o módulo de kernel para controle de failover foi lançada. A nova versão corrigiu o problema, que foi “introduzido” pela nova versão do kernel.

Regras para se ter em mente quando lidando com distribuições enterprise-ready e código que deveria estar no kernel mas por algum motivo inexplicável não está :

• Seja relaxado em relação a segurança e fique vulnerável por algum tempo, esperando os desenvolvedores de seu módulo externo atualizarem o código em questão antes de aplicar as atualizações de kernel que são marcadas como críticas pelo distribuidor do seu sistema operacional.

• Distribuições “enterprise”, corretamente licenciadas, hardware e software homologados de nada adiantam quando a política de atualizações de “segurança” dessas distribuições introduzem código novo (e não somente correções de segurança) no meio de uma atualização de segurança.

Ah ! E porque raios as pessoas atualizam o código de seus drivers com base em versões de kernel de uma distribuição enterprise específica e não com base no kernel oficial ? Essas “parcerias” entre distribuidores de versões “enterprise” e grandes empresas de hardware/software me deixam furioso.

Por essas e outras que sempre bato a cabeça na parede quando ouço : “Tanto faz a distribuição, Linux é tudo a mesma coisa”. Hoje em dia isso é pura mentira. Todo o discurso de previsibilidade, de uma agenda e de uma grande empresa por trás vai por água abaixo quando vemos coisas como essas no dia-a-dia.