Publicado em 14/12/2011 às 9:30 | 36195 leituras
"As necessidades de muito devem se sobrepor às necessidades de poucos... ou do Único", disse Spock no Filme "Star Trek: 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. For exemplo, quando nós escolhemos não projetar e oferecer uma atualização limpa de uma nova versão de programa ou distribuição.
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 instalasse 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 serviços de campo de Hardware poderiam 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 de serviços de campo 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.
Eu argumentei que na maioria das vezes o pessoal que instalava sistemas eram pessoas 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? Eu 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á rodando Unix e, provavelmente, com os componentes de hardware já "no lugar certo".
Para fazer o pessoal de serviço de campo se sentir 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 a nova funcionalidade. 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.
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 aplicações 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 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 de Linux para os 75% a 80% de pessoas que usam o sistema padrão, mas ainda permitir que o sistema seja mudado somente se for o desejo do administrador. Se projetarmos uma distribuição para a atualização, ela pode ser projetada para efetuar somente as maiores mudanças, 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 do que 100%.
Claro que, mesmo com um processo bem projetado, os backups ainda serão necessárias 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 reinstala-los.