Há uns tempos atrás dizia o Mário Valente ter sido ele o inventor do Youtube. Ora, pelo mesmo tipo de raciocínio: o Ubuntu fui eu que inventei.
Em finais de 2003, estávamos a planear a nossa primeira migração para desktops Linux. O cliente era uma empresa com 20-30 PCs e na época as distribuições de Linux eram em termos de Desktop bastante toscas e mal acabadas. O problema crónico de quem fazia as distribuições, sempre foi o síndroma "everything and the kitchen sink", fazendo com que - juntamente com algumas lacunas para as quais na altura não havia resposta - o excesso de software e má integração entre componentes tornassem a utilização por parte do público real bastante penosa e o apoio técnico complicadíssimo.
Como resolvemos? Pegámos numa versão melhorada do Mandrake 9.2. Cortámos, colámos e corrigimos produzindo uma imagem de instalação automática com os componentes bem integrados e uma selecção criteriosa do software mais interessante. Uma espécie de Ubuntu... com o que que havia na época.
Quais o princípios usados neste desenvolvimento?
Less is more
Default is King
Certify or die
[Quatro anos mais tarde, ainda existem algumas máquinas a correr esta versão, que com alguns updates cirúrgicos (Firefox, Flash...) continua a mostrar-se perfeitamente estável]
Como contribuição para o projecto Mandrake, reportámos e comentámos inúmeros bugs individuais acerca da integração de componentes, sugerindo soluções, na expectativa de que as próximas versões os tivessem resolvido. Exemplo:
https://qa.mandriva.com/show_bug.cgi?id=982
Resultado: os bug reports cairam em saco roto e as próximas versões vieram com o mesmo tipo de bugs... mas em novas versões do KDE, Mozilla, etc.
Em 2006 voltámos à carga. Pegamos no Mandriva 2006 e novamente criámos um produto final.
[No fundo para nós é irrelevante se desenvolvemos sobre Debian, Mandriva ou CentOS. O que interessa é o user experience que conseguimos criar. Sempre gostámos do Mandriva devido ao excelente suporte para impressoras (Till Kampeter...), aos fabulosos repositórios PLF, ao KDE, urpmi mas....]
Corrigimos dezenas de bugs, limpámos o excesso de pacotes e testámos extensivamente até que o produto final estivesse "à prova de nabos". Desta vez, para além de reportarmos alguns bugs individuais, exemplo,
https://qa.mandriva.com/show_bug.cgi?id=26155
atacámos com um meta-bug englobando os diversos problemas de QA e sugerindo melhorias no processo:
http://qa.mandriva.com/show_bug.cgi?id=20796
Resultado: gerou-se alguma discussão no Bugzilla mas não se viram acções concretas. É curioso ver como o típico geek responsável por um componente, não tem a mínima visão de conjunto.
Não desistimos. Falamos com o CTO da Mandriva alertando-o para os factos. Em 2007 reunímos com a Caixa Mágica e o Alinex tentando sensibilizá-los para a urgência desta filosofia de desenvolvimento. Já em 2008, reunímos pessoalmente com o CEO da Mandriva que se mostrou muito interessado no que viu e contribuímos com algum QA para a release 12 da Caixa Mágica.
Mas.... entretanto já alguém, com poder ($$$) e visão tinha percebido o que era preciso ser feito. Esse alguém criou o Ubuntu. E esse mesmo Ubuntu está a obrigar as outras distribuições a verem para lá das palas. Já não é alguém isolado a tentar passar uma visão, mas sim o mercado a escolher quem faz melhor.
Tornou-se claro que não é preciso software em quantidades industriais mas sim "one tool for the job - the best available tool". Percebeu-se tudo o que faz parte de uma instalação default deve estar testado, integrado e a funcionar. Só assim se chega a um Desktop que funcione para o público final. E mesmo os geeks, que nunca foram capazes de identificar este tipo de necessidades, acabaram por reconhecer a sua importância e ajudar ao estrondoso sucesso do Ubuntu. E o mais interessante é que este tipo de quality assurance desktop, nem sequer é especialmente difícil nem demorado. Apenas requer uma sensiblidade diferente daquela que o típico developer geek tem. Requer que se entenda como pensam os utilizadores finais. E é por isso que anos e anos de excelência Debian, não conseguiram por si só conduzir a este resultado.
Lembro-me de em 2001, comentar com uma das pessoas da linha da frente do Linux em Portugal, que as distribuições deveriam chegar a acordo sobre "o kernel do ano" e alinhar as versões outros componentes críticos, para facilitar a integração de sofware de terceiros. Na altura a ideia foi recebida com cepticismo.
Passados 8 anos, o que diz Shuttleworth?
quarta-feira, 21 de maio de 2008
terça-feira, 13 de maio de 2008
ADSL Vodafone
Serviço ADSL da Vodafone. The picture says it all....

É de referir que este serviço não funciona com PPPoA / PPPoE(oA) como habitualmente em Portugal, mas directamente com IP over ATM. O cliente recebe o IP por DHCP.
(testado com RFC2684 Bridged + DHCP, o que corresponde a IP+Ethernet over ATM)
Este modo tem como vantagem a menor complexidade de configuração em gateways e ganho de uns meros 2% de eficiência devido a menor overhead.
Outro facto curioso é o Helpdesk referir que o serviço "não tem qualquer contenção", algo que me levanta algumas dúvidas, mas tentarei confirmar.
Referências:
Encapsulation Overheads in ADSL Access Networks
É de referir que este serviço não funciona com PPPoA / PPPoE(oA) como habitualmente em Portugal, mas directamente com IP over ATM. O cliente recebe o IP por DHCP.
(testado com RFC2684 Bridged + DHCP, o que corresponde a IP+Ethernet over ATM)
Este modo tem como vantagem a menor complexidade de configuração em gateways e ganho de uns meros 2% de eficiência devido a menor overhead.
Outro facto curioso é o Helpdesk referir que o serviço "não tem qualquer contenção", algo que me levanta algumas dúvidas, mas tentarei confirmar.
Referências:
Encapsulation Overheads in ADSL Access Networks
segunda-feira, 12 de maio de 2008
Flamewars clássicas
Uma das facetas sociologicamente mais curiosas no ecossistema global do software Open Source é a tendência crónica para as flame wars. Se bem que sejam na sua maioria inúteis (excepto quiçá para descompressão dos intervenientes) reza a história de vários exemplos que, pelas suas implicações, vale a pena mencionar. Lembro-me de três temas quentes que deram origem a discussões memoráveis com consequências reais para o desenvolvimento de alguns projectos:
Gnome vs KDE - Qt e objecções às várias licenças por que passou
http://www.linuxtoday.com/news_story.php3?ltsn=2000-09-05-001-21-OP-LF-KE&tbovrmode=1
Joerg Schilling vs Linux - SCSI addresses, Linux device naming and the infamous ide-scsi module
http://lkml.org/lkml/2004/8/4/89
http://lkml.org/lkml/2004/8/7/34
http://lkml.org/lkml/2004/8/6/82
Keith Packard vs XFree86 - o marasmo do projecto XFree86 como obstáculo ao crescimento do Linux no Desktop
http://xfree86.org/pipermail/forum/2003-March/thread.html
Em todas estas discussões a oposição entre as partes originou desenvolvimentos paralelos (forks ou novos projectos) para resolver o problemas.... e o resto ficou a cargo da selecção natural.
Uma das principais virtudes da abertura do código é a garantia de sobrevivência face a crises existenciais, conflitos ou simples desinteresse das equipas de desenvolvimento. A prova disso é que hoje usamos o Xorg em vez do XFree86, dvdrtools em vez das cdrtools, estando o Gnome e o KDE em pé de igualdade numa saudável competição. Os problemas que deram origem aos vários diferendos acabaram por ser completamente ultrapassados, em claro benefício da comunidade de utilizadores.
Na mesma linha de ideias, tudo indica que a história continuamente se repete. Veja-se por exemplo o recente incidente entre utilizadores e developers no projecto Pidgin:
http://developer.pidgin.im/ticket/4986
Update:
Faltava a clássica e essencial discussão Linus vs Tanenbaum subordinada ao tema "Linux is obsolete". Esta discussão data de 1992 e pode ser vista por exemplo aqui:
http://www.oreilly.com/catalog/opensources/book/appa.html
Ver também:
http://en.wikipedia.org/wiki/Tanenbaum-Torvalds_debate
Gnome vs KDE - Qt e objecções às várias licenças por que passou
http://www.linuxtoday.com/news_story.php3?ltsn=2000-09-05-001-21-OP-LF-KE&tbovrmode=1
Joerg Schilling vs Linux - SCSI addresses, Linux device naming and the infamous ide-scsi module
http://lkml.org/lkml/2004/8/4/89
http://lkml.org/lkml/2004/8/7/34
http://lkml.org/lkml/2004/8/6/82
Keith Packard vs XFree86 - o marasmo do projecto XFree86 como obstáculo ao crescimento do Linux no Desktop
http://xfree86.org/pipermail/forum/2003-March/thread.html
Em todas estas discussões a oposição entre as partes originou desenvolvimentos paralelos (forks ou novos projectos) para resolver o problemas.... e o resto ficou a cargo da selecção natural.
Uma das principais virtudes da abertura do código é a garantia de sobrevivência face a crises existenciais, conflitos ou simples desinteresse das equipas de desenvolvimento. A prova disso é que hoje usamos o Xorg em vez do XFree86, dvdrtools em vez das cdrtools, estando o Gnome e o KDE em pé de igualdade numa saudável competição. Os problemas que deram origem aos vários diferendos acabaram por ser completamente ultrapassados, em claro benefício da comunidade de utilizadores.
Na mesma linha de ideias, tudo indica que a história continuamente se repete. Veja-se por exemplo o recente incidente entre utilizadores e developers no projecto Pidgin:
http://developer.pidgin.im/ticket/4986
Update:
Faltava a clássica e essencial discussão Linus vs Tanenbaum subordinada ao tema "Linux is obsolete". Esta discussão data de 1992 e pode ser vista por exemplo aqui:
http://www.oreilly.com/catalog/opensources/book/appa.html
Ver também:
http://en.wikipedia.org/wiki/Tanenbaum-Torvalds_debate
sexta-feira, 2 de maio de 2008
Adobe vs Open Source (was Macromedia vs Open Source)
- let stupid one liners hanging forever on flash 6 for Linux
- forget Linux during upgrade the to flash 8
- realize you're being bashed by on every Linux user in the world
- check the bad press you're getting
- hire a well known Linux multimedia developer
- fail to have flash 9 for Linux ready on time
- setup a blog for controlling damage and let early betas go through
- release flash 9 for Linux... late
- keep on listening to user feedback and release flash 9 updates regularly
- make the full PDF specification an ISO standard
- release some open source stuff
- join the Linux Foundation and announce Air for Linux
- open the flash related specifications to everyone (comercial and non-comercial use - apparently)
- ....
- profit?
Do we see some progress here?
- forget Linux during upgrade the to flash 8
- realize you're being bashed by on every Linux user in the world
- check the bad press you're getting
- hire a well known Linux multimedia developer
- fail to have flash 9 for Linux ready on time
- setup a blog for controlling damage and let early betas go through
- release flash 9 for Linux... late
- keep on listening to user feedback and release flash 9 updates regularly
- make the full PDF specification an ISO standard
- release some open source stuff
- join the Linux Foundation and announce Air for Linux
- open the flash related specifications to everyone (comercial and non-comercial use - apparently)
- ....
- profit?
Do we see some progress here?
Subscrever:
Mensagens (Atom)