Geek profissional
Ubuntu
Ode ao Ubuntu-PT
May 8th
No além mar também existe Ubuntu. É o caso da comunidade Ubuntu-PT, que possui um Planeta, como também aqui temos. Em homenagem a esta comunidade, ofereço para os leitores do Planeta Ubuntu Brasil um trecho de uma obra dos mais célebres portugueses que inaugura aquilo que nos mais une Brasil e Portugal no Software Livre: a língua portuguesa.
Depois de procelosa tempestade,
Noturna sombra e sibilante vento,
Traz a manhã serena claridade,
Esperança de porto e salvamento;
Aparta o sol a negra escuridade,
Removendo o temor do pensamento:
Assim no Reino forte aconteceu,
Depois que o Rei Fernando faleceu.
“Porque, se muito os nossos desejaram
Quem os danos e ofensas vá vingando
Naqueles que tão bem se aproveitaram
Do descuido remisso de Fernando,
Depois de pouco tempo o alcançaram,
Joane, sempre ilustre, alevantando
Por Rei, como de Pedro único herdeiro,
(Ainda que bastardo) verdadeiro.
“Ser isto ordenação dos céus divina,
Por sinais muito claros se mostrou,
Quando em Évora a voz de uma menina,
Ante tempo falando o nomeou;
E como cousa enfim que o Céu destina,
No berço o corpo e a voz alevantou:
- “Portugal! Portugal!” alçando a mão
Disse “pelo Rei novo, Dom João.” -
Início do Canto IV da obra ‘Os Lusíadas‘, de Camões.
Empacotar é coisa do século passado – acordo de cooperação tecnológica
Feb 3rd
Em seu blog, Ian Murdock, o fundador do Debian nos diz em ‘Como gerenciamento de pacotes mudou tudo‘ que:
Qual é o maior avanço que o Linux trouxe para a indústria ? Essa é uma pergunta interessante, e uma que na minha opinião tem uma resposta simples: Gerenciamento de pacote ou, mais especificamente, a capacidade de instalar e atualizar software através da rede de uma forma transparente, integrada e elegante, juntamente com o modelo distribuído de pacotes. (adaptado)
De fato, é um diferencial ímpar. Mas esta tecnologia do mundo GNU Linux está presa ao século passado. Os programas já compilados que instalamos nas nossas distribuições favoritas são produzidos em um processo artesanal que me remete as antigas linhas de montagem em que cada produto precisava ser manualmente embalado.
Divido aqui a comunidade de software livre em dois grandes tipos: aquela que desenvolve, que está engajada diretamente na produção de software, na programação dele. São projetos como OpenOffice, Gnome, Apache etc. Do outro lado, temos também as comunidades que distribuem esses softwares, que fazem as distribuições como Debian, Ubuntu, Fedora, ArchLinux etc. São grupos bem distintos com culturas bem distintas e integrados pela prática rococó do empacotamento.
Para efeito de conversa, pensemos no Apache, exemplo favorito de Sergio Amadeu. Quando o projeto Apache lança uma nova versão de seu software, ele lança apenas o código fonte. Cada usuário GNU Linux, para utilizá-lo, tem que baixar o código-fonte e prepará-lo para compilar. Tal tarefa não é uma das mais fáceis e exige tomada de decisão baseada em quesitos técnicos. Cada dependência, cada pedacinho que compõe o programa teria que ser separadamente baixado, compilado e configurado manualmente. Para ferramentas grandes como Gnome e KDE isso chega a levar dias. Por isso vou um pouco além de Murdock: eu diria que o GNU Linux seria insalubre se não fossem os sistemas de gerenciamento de pacotes. Tais sistemas permitem a mágica do único comando ou com um punhado de cliques, o Apache seja instalado já previamente compilado e pré-configurado para o uso mais comum.
Mas… como o pacote do Apache ou de qualquer outro software são gerados ? Eis o processo que me dá arrepios: assim que uma nova versão do software é lançada, um voluntário de cada distribuição GNU Linux existente tem que manualmente fazer o download da nova versão do programa, compilá-la, configurá-la e por tudo isso em um pacote, que por si só, o empacotamento não é um processo simples e como a compilação, exige um engajamento em questões técnicas profundas. De fato, é uma otimização. Uma pessoa faz o trabalho sujo uma vez para que as outras milhares possam queimar essas etapas demoradas e chatas.
- Oras Kurt, mas se é tão bom, do que estas reclamando ?
Bem, não posso dizer pelos outros, mas me sinto muito estúpido quando sou obrigado a fazer algo que uma máquina faria muito mais rápido e eficientemente do que eu. Se toda a internet funciona com máquinas independentes, sendo a intervenção humana resumida a alguns Homer Simpsons olhando LEDs piscarem, por que cada singelo software tem que ser manualmente baixado, compilado, configurado e empacotado ? É uma perda de material humano e de tempo.
De fato, a força do Software Livre está em sua construção colaborativa. Mas precisamos depositar força de trabalho naquilo que realmente demanda por um cérebro orgânico. Por que não criamos scripts e softwares que automaticamente criem pacotes para cada distribuição ? Por que precisamos depender de um voluntário para que tenhamos em nossa distribuição favorita um software ? Tal processo ineficiente gera distorções: algumas distribuições tem um pacote e outras não, algumas tem versões mas atuais outras com versões antiquérrimas. Se todos usamos GNU Linux, por que manter em um cenário tão desigual em termos de disponibilidade de software ?
Em vez de cada distribuição criar a cada lançamento de softwares um pacote para ele, basta cada distribuição criar uma única vez um script para empacotar o Apache e a cada nova versão deste software, o script detecta, baixa, compila, configura e põe no repositório devido (por exemplo, os testing ou development).
- Eu já pensei nisso, mas é algo difícil de se fazer…
É difícil porque cada comunidade de desenvolvimento adota padrões diferentes. Tal diversidade atrapalha a construção destes scripts e intrisicamente seu funcionamento. O que venho aqui neste artigo propor de novo é um Acordo de Cooperação Tecnológica (ACT). Se conseguirmos padronizar o modus operandi das comunidades que desenvolvem software livre e das que distribuem, esses scripts funcionariam com tranquilidade. Mas, jamais para criar um padrão único para todas as distribuições e sim acordos de duas partes envolvidas: uma distro e um software combinam um padrão para que o empacotamento possa ser realizado. É a criação de um acordo, uma promessa de se deter a um padrão e não criar um padrão único. Exemplificando: é combinar qual vai ser o uniforme de um colégio e não que todos os colégios do mundo tenham o mesmo uniforme.
Nesse acordo, os projetos de softwares livres que possuem comunidade sólidas, como os que eu mencionei ao longo deste artigo, entrariam em acordo de cooperação com os responsáveis das distribuições que os utiliza ou os distribuem automaticamente instalados (como é o caso do Gnome para Ubuntu) para estabelecer algumas regras, algumas guidelines para o lançamento de novas versões. Onde fica que o arquivo XPTO, como que é a estrutura de XYZ, onde se armazenará o metadata da descrição do programa etc… de forma que:
a) A comunidade que desenvolve o software se compromete a seguir certos padrões no lançamento de seu código fonte, estabelecidos em consenso interno e com as comunidades das distribuições.
b) Cada distribuição assinante do acordo se compromete em desenvolver e manter scripts que façam o empacotamento automático.
- E se o script em algum momento falhar ?
É aí que finalmente deve entrar a força de trabalho humana, lendo os logs do script para detectar o erro, e providenciar a correção dele junto a comunidade que desenvolve o software ou reparando o bug do script para que ele volte a ser autônomo. Também o acordo não iria engessar os desenvolvedores e arrastá-lo para padrões artificiais. Na verdade, ninguém precisa mudar de padrão. Apenas eles precisam ser estabelecidos, listados, fixados, para que os scripts possam ser construídos e funcionarem. Dessa forma, estaremos construindo toda uma cadeia produtiva de lançamento de software livre, caminhando para mais um salto evolutivo nos sistemas operacionais GNU Linux.
UPDATE: Tenho ciência que algumas distribuições mais voltadas para a compilação no ambiente do usuário (como Gentoo e ArchLinux) têm automações parecidas. Não estou aqui sugerindo um processo na relação entre o usuário e o processo de instalação de softwares e sim no processo de empacotamento que a maioria das distribuições Linux fazem entregando ao usuário binários já compilados em forma de pacotes que dependem de intervenção humana. Se observarmos os dados do Distrowatch retirados hoje, temos como distribuições mais populares:
1- PCLinuxOS – RPM
2- Ubuntu – DEB
3- OpenSUSE – RPM
4- Fedora – RPM
5- LinuxMint – DEB
6- Sabayon – Portage
7- Mandriva – RPM
8- Debian – DEB
9- Mepis – DEB
10- Damn Small Linux – DEB
11- CentOS – RPM
Excetuando o Sabayon, todos utilizam essa abordagem manual na criação de pacotes.
Claro: o pior cego é aquele que não quer ver
Sep 29th
Quando adquiri uma linha da Claro, todos que conheço torceram o nariz e disseram que eu teria problemas na certa. Demorou, mas estavam corretos. A Claro tem se demonstrado ser o pior tipo de cego: aquele que não quer ver.
Paguei minha conta no mês de julho e até a primeira semana de setembro, eles não conseguiram detectar o pagamento da mesma. Coisa que qualquer muambeiro que vende pelo MercadoLivre consegue fazer com perícia. Fui contactado pelo setor de cobrança (que parece ter uma preferência por ligar bem cedo pela manhã) e orientado a enviar um fax com o comprovante de pagamento.
Mas pera aí, um fax ?! Estamos em 2007 ! Que tipo de empresa, ainda mais uma de tecnologia, que oferece serviço de internet móvel, se relaciona com seu cliente por um… fax ? Ah, claro, a Claro ! Me recusei a enviar o fax por meios próprios. Não tenho aparelho de fax e não tem cabimento esse equipamento em tempos atuais. Perguntei a atendente se poderia enviar o comprovante digitalizado por e-mail, ela disse que não seria possível.
Como não tenho fax, eu teria que ir na rua no meu escasso tempo durante o horário comercial caçar um funcionando perto de um lugar que eu trabalhe. Além disso, teria que pagar pelo envio. Oras, se eu adimpli, se eu paguei minha conta, por que tenho que pagar para provar que paguei ? Discuti com a atendente que isso não fazia sentido e ela concordou (em algum acesso raro de lógica por parte de alguém que trabalhe lá).
A atendente me sugeriu que eu fosse até uma loja própria da Claro e pedisse lá que me enviassem o tal fax. Agora sim fazia sentido, eu seria atendido presencialmente num estabelecimento da empresa e lá fariam os trâmites corretos. Assim que fiz, fui numa dessas lojas próprias cujo endereço a atendente me passou e entreguei o comprovante original de pagamento explicando meu caso. A moça que me atendeu dirigiu-se para trás do balcão, passou o fax na minha frente e me entregou o comprovante, agradecendo e desejando-me um bom dia. Considerei o problema resolvido até que 3 dias depois, numa manhã de sábado meu telefone toca. Era o setor de cobrança da Claro, adivinhem, cobrando a conta de julho. E para eles, nenhum fax foi enviado. Incrível, não ?
E agora, o que farei ? Me recuso a pagar para provar que cumpri com meus compromissos fiinanceiros. Tentei utilizar o serviço EmailFax.com.br para cumprir a missão, mas com esse serviço não é possível enviar sinais DTMF antes do sinal de fax, tornando-se impossível navegar em um menu antes de mandar o sinal de fax, que é o caso do atendimento da Claro.
Meu karma com fax não para por aí: só esse ano a incompetência da ItauSeguros a fez perder duas vezes documentos que enviei por fax sobre o furto do meu carro. Será que essas empresas não perceberam que fax é um veículo caro, lento e problemático ? Estamos em plena era das multifuncionais… se você solicita que seu cliente envie uma imagem digitalizada, ela pode ser arquivada na empresa, replicada para vários setores, aparecer na tela do atendente do callcenter… enfim, possibilidades infinitas. Agora quando insistem que dados e documentos sejam transmitidos e armazenados em fiinas folhas curvas de papel, os acidentes são recorrentes e meu caso é para provar isso.
Se tratando de fax, o Ubuntu Gutsy Gibbon, próxima versão do sistema que será lançado no dia 18 de outubro tem novidades. O pacote hplip-gui trás uma ferramenta para envio de faxes e um address book de contatos para as multifuncionais da HP com suporte a fax. Apesar de ter encontrato impressoras dessa modalidade a partir de 300 reais, não é o meu caso. Possuo uma Photosmart C3180 que para minha surpresa foi automaticamente detectada e instalada no Gutsy: bastou ligar ela na tomada e no cabo USB que sem qualquer clique ou configuração, o Ubuntu a detectou e a ativou pronta para uso.
Por fim, queridos profissionais de TI: utilizem um neurônio a mais e por favor, implementem um sistema de recebimento e gerenciamento de imagens em anexo por e-mails. Isso qualquer sobrinho seu que saiba PHP poderá fazer por um preço bastante singelo. Ele pode usar a API do EmailFax.com.br. E quem sabe com a economia que o sistema gerará e a satisfação do cliente você conseguirá ser promovido… seria uma boa, não ? Nem precisa dizer que fui eu que deu a idéia 
Fotos da Festa Edgy no Rio e Floripa
Nov 5th
Logo depois da Festa Edgy no Rio de Janeiro tive que viajar a trabalho para uma reserva ecológica no litoral de São Paulo. Depois de charfurdar em muito manguezal e também uma picada de vespa para ganhar um terceiro cotovelo, chego em casa em farrapos para ainda em tempo postar as fotos da Festa Edgy no Rio e em Florianópolis, a pedido do BradocK.
Rio de Janeiro
Na fileira da esquerda, de cima para baixo: Ibsen, Junix, eu, Turicas
Na fileira da direita, de cima para baixo: Krysamon, Nelson, estranho, lsilva e Ricardo Pinheiro.
Tanto no Rio como em Floripa As pizzas e CDs circulavam enquanto a prosa e a confraternização rolava solta. Obrigado a todos que participarem dessas festas e outras no Brasil como em Teófilo Otoni (MG) Salvador (BA), Vitória da Conquista (BA), Joinville (SC) e Aracaju (SE).
Festa Edgy Rio de Janeiro: MARCADA
Oct 22nd
Conforme votação aberta em http://wiki.ubuntubrasil.org/FestaEdgyRJ foram selecionados o local, data e hora para a comemoração da chegada da salamandra (Edgy Eft), a próxima versão do Ubuntu a ser lançada nessa semana. Confira os dados:
Local: Pizza & Grill Largo do Machado (ao lado do metrô)
Data: 27/10/06 (sexta-feira)
Hora: 19h
São todos bem-vindos. Quem usa Ubuntu, quem não usa, quem quer conhecer mais sobre o Software Livre e GNU e quer ter uma prosa franca ao vivo com quem usa. Tragam esposas, amantes, filhos, sogras, colegas de trabalho, todos para confraternizarmos e comemorarmos uma nova versão do Ubuntu.
O local escolhido é um rodízio de pizza bastante inusitado, com mais de 180 sabores incluindo alguns assustadores como pizza de sushi ou pizza de bobó de camarão, além é claro, de sabores tradicionais como calabresa. Também servem refrigerantes em 2L para dilatar bem o estômago e encher a pança de forma bem econômica. Afinal, dieta se começa na segunda-feira, não sexta, no dia da festa.
Espero encontrar vocês lá. Não se acanhem, ninguém se conhece bem. Colocarei CDs do ShipIt empilhados na mesa para fácil identificação. Ah, se alguém que use Fedora e OpenSUSE puder ir eu agradeço. Depois do último evento de SL que fui me interessei pelos projetos e gostaria de conhecer melhor.
Para outras cidades, verifique as datas/horas/locais de comemoração clicando aqui.
ntfs-3g no Universe do Edgy
Oct 5th
O pacote do ntfs-3g já está disponível nos repositório Universe do Edgy. Agora será bem mais simples para os usuários que ainda permanecem com dual boot ter permissão de escrita em suas partições NTFS.
O uso do ntfs-3g é bem estável e seguro a que tudo indica. Mas, não é perfeito. Vi num blog de um rapaz que fez alguns stress tests e alguns arquivos maiores que 4gb corromperam. Então fica a dica de evitar gravar arquivos nessa grandeza. Essa novidade é um passo importante pois aproxima mais o Ubuntu das soluções ‘out of the box’. Creio eu que o que falta para que o ntfs-3g entre no main e até venha junto no LiveCD é uma maturidade maior do projeto e do código fonte. Atingindo-se isso, é um sério candidato a ser incorporado no Ubuntu por padrão.
Festa Edgy Rio de Janeiro. E a hora da salamandra !
Sep 30th
Para quem mal se acostumou com o Dapper, prepare-se: o Edgy já está por vir. Está previsto para ser lançado dia 26 de outubro. E para não perder o costume, vamos comemorar !
Se você estiver no Rio de Janeiro na semana do dia 26 de outubro, cheque este wiki. Nele, você poderá votar numa data, hora e local de sua preferência para que os usuários Ubuntu presentes na cidade maravilhosa possam se encontrar e festejar a nossa nova versão.
Conhece ninguém ? Nem nós ! É tímido ? Todos nós somos. Todos são convidados a confraternizar independente de que distribuição use ou até sistema operacional. Que tal trazer aquele seu conhecido que está doido para experimentar o Linux mas ainda tem medo ? Ele poderá ter uma sessão particular de tira-dúvidas regada a muita cerveja 
Para festas em outros municípios, confira esta página.
Aguardo todos vocês.
Edgy Eft não terá mais kernels p/ k7 e 686
Sep 10th
Além dos cassetes, os k7 também serão coisa do passado. Quem tem acompanhado o desenvolvimento do Ubuntu Edgy Eft e utilizava um kernel específico para as arquiteturas k7, 686 ou amd64 já deve ter notado a presença de um linux-image-generic no lugar de seu kernel habitual.
Pois bem, em recentes benchmarks (bem simples diga-se de passagem) notaram que não havia um considerável ganho de desempenho entre um kernel 386 e outro 686 que justificasse o custo operacional de manter o kernel especial. O mesmo se verificou entre as variantes amd64-generic e amd64-xeon.
Um único teste foi realizado comparando o kernel compilado para 386 e para k7. As diferenças foram maiores do que as encontradas entre 386/686. Mas ainda assim não acharam justificável a permanência do linux-image-k7.
Sendo assim, os pacotes linux-image-generic nos desktops e o linux-image-server nos servidores irão atender os processadores das famílias 686 e k7 sem otimizações específicas para os mesmos. As variantes 64 bits como amd64-k8 ou amd64-xeon deixarão de existir e estes processadores serão atendidos por um kernel de fato compilado para 64 bits mas com o nome linux-image-generic por uma questão de simplificação. Resta aos adictos pelos kernels especiais a tarefa de compilá-los por conta própria. Outros pacotes compilados de forma especial como o mplayer, mencoder, ardour e Xen permanecem na forma que estão.
Apesar de eu concordar que mais testes são necessários, essas alterações não devem causar decréssimo notável de desempenho por parte do usuário por mais que soe de início. Portanto, nada de alardes. Mas fica o convite a todos a fazerem mais benchmarks que tragam números que talvez demonstrem que essa decisão não deveria ter sido tomada, porém, até agora nenhum surgiu nesse sentido.
O Edgy tem sim ganhos de performance, vindo de reorganizações do processo de boot, de desligamento e até do LiveCD. Além, é claro, das melhorias costumeiras das novas versões de todos os pacotes. O que deve vir a tona para próximas versões são as discussões sobre medidas mais intrusivas na melhoria de performance como preload ou o prelink.
O preload analisa os hábitos do usuário e a partir desta análise prevê quais aplicações serão abertas em seguida no sistema e já as carrega juntamente com suas dependências para acelerar a abertura mediante a solicitação do usuário.
Já o prelink faz a ligações das aplicações com suas bibliotecas e armazena estas informações que usualmente são criadas cada vez que o programa é aberto. Como haverá uma espécie de ‘cache’ para estas ligações, o processo de abertura de programas que requerem muitas bibliotecas deverá ser acelerado. Há obviamente um custo: a instalação de programas via APT passa a ser mais demorada e a interrupção do processo de prelinking pode causar a quebra do sistema ou aplicação. O Fedora e o SuSE já usam prelink por padrão em algumas aplicações específicas.
DVD no Edgy Knot 2
Sep 7th
Continuando a conquista do ambiente terrestre e cada vez menos dependente da água, vamos agora configurar um DVD no Edgy Knot 2.
O procedimento em parte continua o mesmo do Dapper: instalar o pacote libdvdread3. Mas a diferença para por aí. Depois de ter esse pacote instalado, é necessário rodar um script para baixar o libdvdcss2. O que de fato mudou foi o caminho desse script, o que não está documentado até então e erroneamente exibido no packages.ubuntu.com. Para concluir a instalação do ‘codec’ de DVD:
sudo /usr/share/doc/libdvdread3/install-css.sh
É importante que nenhum outro instalador como apt-get, aptitude ou Synaptic estejam em uso durante a execuçao do comando acima. E chazan, DVD pronto para rodar filmes
PPPoE no Edgy Eft Knot 2
Sep 6th
Cansado da estabilidade do Dapper, forrei minha cama com plástico e resolvi instalar o Edgy Eft na versão Knot 2. Trata-se de uma segunda prévia da próxima versão do Ubuntu, a ser lançada em meados de outubro. Como ainda falta um bocado para o lançamento, está longe do sistema estar pronto para uso, portanto, é brincar com fogo.
O primeiro fósforo que risquei foi tentando atualizar o Dapper para o Edgy. Me queimei. Este experimentos rendeu a comunidade 3 relatos de bug. As respostas foram muito rápidas. Um deles foi resolvido em menos de 6h. Mas eu já estava ansioso demais: acendi a fogueira e instalei o Edgy Eft Knot 2 do zero.
E cá estou, escrevendo este post para você. Mas nem tudo foi tão simples. Em menos de 1h de uso já dois erros inesperados aconteceram aqui e também os relatei. Portanto, friso aos aventureiros o devido cuidado para não fazer xixi na cama.
Mas eu diria que o pior problema foi a dificuldade de se configurar uma conexão ADSL com PPPoE. Ainda não está corrigido esse problema mas no Launchpad Andreas Simon nos tras uma solução. Eis ela:
Abra o Terminal ou equivalente e digite o seguinte comando:
sudo gedit /usr/sbin/pppoeconf
Desça até a linha 22 e adicione o símbolo # como primeiro caractere da linha. O mesmo para as linhas 23 e 24, ficando assim:
# elif [ -x /usr/bin/zenity ] ; then
# DIALOG=”zenity”
# X11=”-X”
O vilão do problema é o zenity, que geraria a interface de configuração do PPPoE se não estivesse defeituoso. Comentando estas linhas, estamos desabilitando o zenity e fazendo com que o Xdialog assuma essa função. E chazan, basta tentar rodar o sudo pppoeconf denovo e ele funcionará como no Dapper. O mesmo procedimento vale para o Edgy sendo rodado como LiveCD.
De resto, recomendo todo cuidado. Em caso de incêndio, os bombeiros podem não chegar a tempo.
