“As necessidades de muito devem se sobrepor às necessidades de poucos... ou do Único”, disse Spock no filme ”Star Trek II: a Ira de Khan”. Com essas palavras, Spock decidiu morrer para salvar o resto de sua equipe. Filosoficamente, concorde você ou não com o Spock, a parte importante da lição é que Spock escolheu agir dessa maneira. Ele exerceu um poder de escolha.

Algumas vezes, desenvolvedores inadvertidamente não oferecem tantas escolhas para seus clientes quanto deveriam. Por exemplo, quando nós escolhemos não projetar e oferecer uma atualização limpa de uma nova versão de programa ou distribuição.

Há muitos anos atrás, eu ajudei a desenvolver uma nova “atualização” para o sistema operacional Ultrix, da DEC. Esse procedimento permitiu que os clientes simplesmente instalassem o sistema sem precisar:

• Fazer boot do sistema a partir da fita no modo usuário único;
• Editar o arquivo de configuração para o kernel;
• Digitar todos os tipos de dados técnicos arcaicos sobre controladores de disco, controladores de linhas seriais etc.;
• Reconstruir o kernel;
• Instalar o kernel adequadamente;
• Reiniciar o sistema.

Em vez disso, meu procedimento permitiu que o kernel com boot sondasse o bus do sistema usando um padrão DEC que o pessoal de hardware poderia seguir à medida que instalavam novos sistemas. Um engenheiro de kernel chegou a me dizer que isso era impossível para o Unix, mas eu fiz um protótipo da solução em menos de um dia.

Depois disso, um engenheiro desavisado disse que esse procedimento não iria dar certo, uma vez que os “loucos do Unix” ignoravam as técnicas de padrões DEC de instalação de hardware no bus, colocando os controladores de hardware “em qualquer lugar” no espaço do endereço do bus, negando o padrão digital.

Argumentei que, na maioria das vezes, o pessoal que instalava sistemas eram pessoas internas da DEC e que os engenheiros de campo colocavam, sim, os componentes no lugar certo. Assim, por que deveríamos puni-los somente para aliviar a dor dos poucos que não colocam as coisas no lugar certo? Pontuei também que a maioria dos sistemas existentes faziam dual boot com VMS (isso foi antes dos tempos do OpenVMS) ou eram sistemas VMS já executando Unix e, provavelmente, com os componentes de hardware já “no lugar certo”.

Para fazer com que os técnicos se sentissem melhor, nós mudamos meu protótipo de sondagem do bus, mostramos às pessoas responsáveis pela instalação do software quais controladores eram encontrados no processo e então, demos oportunidade ao instalador de mudar a configuração que fosse necessária antes de continuar com o processo. Eles ganharam a escolha.

Nós recebemos reviews extasiados com o novo recurso. 99,99% (ou um número mais alto) de clientes tinham o hardware dentro dos padrões, fossem eles DEC ou não DEC seguindo os mesmos padrões DEC. Os clientes também adoraram o fato de a instalação ser tão fácil.

Isso nos leva a outra questão. Atualmente, alguns distribuidores de Linux não trabalham muito duro nas atualizações de uma versão para outra. Parece que há pouco pensamento ou trabalho feito para permitir que os clientes atualizem seus sistemas adequadamente, principalmente por causa da percepção de que a maioria dos clientes mudam e personalizam seus sistemas Linux, causando medo de que a atualização sobrescreva as mudanças do cliente.

Para ser justo, a quantidade de personalizações realizadas por clientes no passado tenderia a eliminar o conceito de instalação “padrão”. Os envolvidos com Linux (ou Unix) tendem a mudar seu ambiente criando diferentes sistemas de arquivos, diferentes tamanhos de sistemas de arquivos, implementando diferentes aplicativos e armazenando coisas em diferentes lugares na hierarquia do sistema de arquivos. No entanto, eu sinto que a maioria dos clientes de hoje usam a distribuição mais ou menos como ela é, com menos personalização do que antes, então o objetivo deveria ser, em minha humilde opinião, permitir que consumidores atualizem continuamente os sistemas.

Ocorre que ao não planejar atualizações, uma distribuição pode estar punindo clientes que não mudam nada no sistema do Linux para proteger os poucos que o fazem. Nós deveríamos projetar e orquestrar as distribuições Linux para os 75% a 80% de pessoas que usam o sistema padrão, mas ainda permitir que o sistema seja modificado somente se este for o desejo do administrador. Se projetarmos uma distribuição para atualização, ela pode ser adaptada para efetuar somente as maiores mudanças e não uma reinstalação completa.

As pessoas que escolheram modificar os sistema fora dos limites da atualização projetada talvez precisem fazer uma reinstalação, mas eu acho melhor ter de 20 a 25% dos clientes tendo de reinstalar o sistema do que 100%.

Claro que, mesmo com um processo bem projetado, os backups ainda serão necessários antes da atualização. Talvez seja necessário, ainda, um teste de atualização. Mas se os técnicos tiverem milhares de sistemas para atualizar e se seguirem as diretrizes elaboradas pela distribuição, deveria ser mais fácil atualizar esses milhares de sistemas do que reinstalá-los.

Não puna muitos por conta de poucos. Projete e desenvolva atualizações que atendam a estes poucos.

Carpe Diem!

* fonte: Linux Magazine