Blog do Maddog


Reflexões de um Cachorro Louco

As necessidades de muitos

Publicado em 14/12/2011 às 9:30 | 28864 leituras


Versão para impressão Enviar por email

    

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!

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.

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 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.

Não puna por conta de poucos. Projete e desenvolva atualizações.

Carpe Diem!

Comentários

Outros Posts

Ambientes de nuvem privada virtual

Publicado em 06/10/2017 às 13:23 – Comentar primeiro

O Subutai é uma solução de nuvem de código aberto, ponto a ponto (P2P), segura e estável, que cria ambientes de nuvem privada virtual (VPC) para usuários finais usando um modelo de nuvem de contêineres como serviço (CaaS). O usuário final pode instalar qualquer tipo de serviço, aplicativo ou software de infraestrutura que desejar nas máquinas em execução nessa nuvem.
Leia mais...

Software Livre e de Código Aberto: uma questão de economia, não de política

Publicado em 12/11/2016 às 12:36 – Comentar primeiro

Os argumentos apresentados neste artigo são todos aspectos econômicos, e não aspectos políticos. Decisões baseadas em política (e não em economia) devem ser lembradas pelos eleitores nas próximas eleições.
Leia mais...

Rapidinhas do maddog

Publicado em 24/03/2014 às 15:55 – Comentar primeiro

Se você é um estudante de ciência ou engenharia da computação e está procurando uma maneira de fazer dinheiro extra e obter uma grande experiência de trabalho, leia este post até o fim!
Leia mais...

Olá, presidenta Rousseff... eu avisei!

Publicado em 22/10/2013 às 12:18 – Comentar primeiro

Em sua mais recente postagem, maddog conta um pouco sobre o Projeto Cauã e como evitar que problemas como os ocorridos com a espionagem da NSA voltem a ocorrer.
Leia mais...

FISL e DrupalCamp Porto Alegre

Publicado em 10/06/2013 às 12:23 – Comentar primeiro

maddog dá a dica: inscreva-se para na caravana DrupalCamp e vá ao FISL em Porto Alegre com 50% de desconto.
Leia mais...

O ano do centenário de um grande homem: Alan Turing

Publicado em 16/10/2012 às 15:00 – Comentar primeiro

Grã-Bretanha busca corrigir um dos maiores equívocos de sua história, ao ter tratado o cientista como um inimigo de Estado após Segunda Guerra Mundial.


Leia mais...

Mea culpa

Publicado em 18/09/2012 às 15:07 – Comentar primeiro

Como a Apple poderia lidar com seus problemas de forma mais diplomática. 


Leia mais...

Jon 'maddog' Hall se declara homossexual

Publicado em 26/06/2012 às 17:31 – Comentar primeiro

Diretor da Linux Internacional revela as razões de ter "saído do armário" em um post comovente em seu blog pessoal.


Leia mais...

Recessão? Que recessão?

Publicado em 05/06/2012 às 13:34 – Comentar primeiro

Maddog conta a história de sucesso de um desenvolvedor brasileiro que entendeu como usar serviços de software livre.


Leia mais...

O conto das mensagens

Publicado em 04/05/2012 às 13:03 – Comentar primeiro

Maddog avalia os efeitos de mentes fechadas sobre até mesmo o mais simples do softwares.


Leia mais...

As necessidades de muitos

Publicado em 14/12/2011 às 9:30 – Comentar primeiro

Maddog fala sobre o tempo em que desenvolveu uma atualização para o sistema Ultrix, como aprendeu sobre escolhas e o benefício da opinião da maioria.


Leia mais...

Frustrações noturnas

Publicado em 27/10/2011 às 12:32 – Comentar primeiro

Maddog fala sobre algumas frustrações com a tecnologia e como isso pode afetar o seu uso pelos usuários finais


Leia mais...

Cerveja em troca de código

Publicado em 11/07/2011 às 11:55 – 1 comentário(s)

Maddog conta uma história sobre desenvolvedores e a recompensa pelos seus esforços no mundo do software livre.


Leia mais...

Gandhi teria sido um defensor do Software Livre?

Publicado em 05/05/2011 às 11:47 – Comentar primeiro

Maddog traça paralelos com os atos de desobediência civil incentivados por Gandhi com os benefícios do Software Livre.


Leia mais...

Offtopic: Mom&Pop(TM)

Publicado em 15/03/2011 às 10:38 – Comentar primeiro

Maddog conta um pouco sobre sua história familiar e fala sobre o falecimento de sua mãe, Marian Rhoda (Burns) Hall.


Leia mais...

Posts anteriores

lançamento!

LM 119 | Backup e Restauração




Impressa esgotada
Comprar Digital  R$ 10,90 Digital

  1. Soluti Certificação Digital em busca de especialista Linux

    Publicado em 19/04/2017 às 17:18 | 567305 leituras

  1. Seminário sobre gestão de privilégios do Linux dá direito a certificado CPE

    Publicado em 23/05/2017 às 10:35 | 485086 leituras

  1. Baixe o curso de shell script do Julio Cezar Neves

    Publicado em 07/04/2008 às 19:41 | 448385 leituras

  1. 4Linux abre vagas para Líder Técnico em São Paulo e Brasília

    Publicado em 25/07/2017 às 14:12 | 327930 leituras

  1. Novo evento "Universidade Livre" será realizado em Belém/PA em 06/05/2017

    Publicado em 28/04/2017 às 11:19 | 282173 leituras

  1. Lançado SDK do Android 2.2, codinome "Froyo"

    Publicado em 21/06/2010 às 9:22 | 8099 leituras

  1. Linux Magazine Community Edition 84 baixe já a sua

    Publicado em 10/11/2011 às 10:45 | 16033 leituras

  1. Openwave enfrenta Apple e RIM

    Publicado em 01/09/2011 às 14:57 | 10526 leituras

  1. Oracle Enterprise Manager 11g amplia a gestão de aplicativos voltada aos negócios

    Publicado em 07/02/2011 às 16:02 | 12425 leituras

  1. Executivo da Canonical e líder do Debian em projeto conjunto

    Publicado em 18/03/2011 às 11:40 | 11499 leituras

whitepapers

mais whitepapers