andrelop’s blog

Brinquedos geek

Ao chegar em casa ontem tive uma agradável surpresa : minha encomenda havia chegado e, junto com ela, meus brinquedinhos geek. Na verdade, dentre as três coisas que comprei, apenas uma pode ser considerada um brinquedinho, mas todas as três são mais ou menos relacionados ao meu lado geek, então …

Algo que precisava e que comprei foi um mini-mouse USB óptico para usar com meu laptop. Agora sim eu consigo apontar e clicar no mesmo objeto e não apontar e o clique sair em um lugar diferente. O meu mini-mouse anterior era um PS/2 antigo, com a maldita rodinha e vivia atraíndo sujeira e travando. Esse novo promete se comportar melhor.

O segundo item de minha lista de compras é um misto de leitor de cartões 6 em 1 e pen drive. Ele lê cartões SD, Multimedia Card, MMC Móbile, RSMMC, MiniSD e MicroSD e eu o comprei junto com um cartão SD de 2GB em uma promoção no site de compras Submarino. Funciona que é uma beleza : é só espetar na USB e o GNOME já cria um ícone no desktop representando um dispositivo removível de 2GB

O último item, esse um misto de geekness e trabalho, é o livro Blog Corporativo, de Flávio Cipriano, também adquirido no Submarino, como todos os outros itens. Como havia citado em um post anterior, tenho interesse pelo assunto e quero ajudar o pessoal da empresa a fazer uso de blogs para conversar com o cliente.

Ah ! Para não perder o post : hoje estou em casa tentando recuperar meu braço esquerdo de um problema que quase me impediu de movê-lo durante os 3 últimos dias. Espero que amanhã esteja melhor e consiga voltar ao trabalho normalmente. Na verdade, eu nem poderia estar escrevendo esse post, mas como precisei ligar o computador para pegar uns documentos importantes, acabei não resistindo.

A importância de padrões

Para pensar : lendo o blog do Ian Murdock, me deparei com um post curto de duas linhas (ou de uma única linha se você é louco o suficiente para usar fontes de tamanho oito) onde Ian cita um comentário de Mike Melanson, engenheiro líder da equipe que desenvolve o porte para Linux do Flash Player da Adobe.

Mike responde a pergunta de um jornalista da ZDNet sobre qual é a parte mais difícil no processo de desenvolvimento do Flash Player para Linux. Sua resposta, citada pelo Ian, foi :

“I would say the hardest part is selecting APIs that have broad coverage across distributions.”

Ou, em uma tradução livre :

“Eu diria que a parte mais difícil é selecionar APIs que possuam grande cobertura entre as distribuições.”

Estamos em uma posição bem diferente hoje em dia, com empresas desenvolvedoras de softwares comerciais bastante conhecidas querendo portar suas aplicações para Linux, situação bem diferente de alguns anos atrás, quando ainda éramos tratados como um bando de adolescentes malucos e drogados sem noção da realidade.

Porém, agora parece que temos mais um problema : padronização. Sim, porque nenhuma grande empresa desenvolvedora de software vai se dar ao trabalho de submeter sua equipe de desenvolvimento ao trabalho sujo de aprender inúmeras APIs diferentes para poder suportar diversas distribuições distintas.

Sou a favor de que cada distribuição deva ter sua própria identidade e ser livre para poder focar em seu público alvo específico ou seja lá no que quiser focar, afinal, liberdade é bom e eu gosto. Por isso, creio que seja praticamente impossível um mundo onde todas as distribuições GNU/Linux sejam 100% compatíveis. Essa á a razão de existirem inúmeras distribuições.

Mas também creio que deva sim existir um certo nível de compatibilidade, até certo ponto que permita que desenvolvedores de softwares comerciais que pretendam lançar versões de seus softwares para GNU/LInux consigam fazê-lo sem que sejam obrigados e ter um trabalho espetacularmente grande para fazer com que o mesmo funcione no maior número possível de distribuições.

Veja bem, eu não sou a favor de softwares comerciais, mas em alguns casos não adianta, você (ou seu cliente) precisa deles e não há como fugir. Nesses casos, é melhor rodar o software comercial em um sistema operacional livre do que optar por utilizar outro sistema operacional comercial e com isso ter todo o sofrimento e as desvantagens que já conhecemos.

Por isso, creio que a idéia do LSB seja importante, uma vez que a o objetivo é criar padrões comuns à todas as distribuições, mas não ao ponto de “desfigurá-las” e fazer com que existam milhares de clones de distribuições GNU/Linux por aí. Com isso, um fornecedor de software comercial pode homologar sua aplicação comercial para LSB e não para cada uma das inúmeras distribuições separadamente.

Sem algo como a LSB, com certeza a homologação para inúmeras distribuições não vai acontecer. E por razões óbvias : é muito caro manter equipes de homologação para cada distribuição, mesmo para somente as distribuições mais conhecidas.

E, como a homologação em massa não vai acontecer mesmo, o que acaba acontecendo na prática é que as empresas desenvolvedoras de softwares comerciais acabam criando parcerias com as empresas responsáveis pelo desenvolvimento de distribuições comerciais e homologando seus produtos somente para essas distribuições.

Nessa, distribuições comunitárias como Debian, Gentoo, Slackware e outras ficam de fora e não podem ser consideradas em nenhum projeto que envolva o uso de algum desses softwares comerciais. Além do motivo óbvio disso ser ruim, acredito que isso pode ser também ruim a longo prazo, pois acaba colocando distribuições comunitárias como uma opção de segundo nível ou sem importância.

A longo prazo, se esse problema persistir, podemos ter um mundo onde Linux = Red Hat Enterprise ou Linux = SuSE Enterprise (ou seja lá como essa distribuição é chamada hoje em dia). Devido a isso, todas as distribuições comunitárias deveriam sim apoiar o LSB e se tornarem compatíveis.

Um dos release goals do Etch, o codinome da próxima versão estável do Debian, é justamente compatibilidade com o padrão LSB 3.1. Logicamente, a versão estável atual do Debian, o Sarge, já é pelo menos parcialmente compatível com versões anteriores do padrão LSB.

Business Blogging

Em uma  campanha para fazer com que o pessoal não técnico do trabalho (o pessoal das áreas não tecnológicas, ou “as pessoas engravatadas”) entenda a importância e a utilidade de blogar, comecei a pesquisar sobre blogging corporativo.

Encontrei um arquivo sobre o tema, publicado ontem mesmo, no site Linux Journal. Vou citar um pequeno trecho do mesmo abaixo, em uma tradução livre (e possivelmente com erros, mas a intenção é boa) :

Caso você procure na fonte de toda a sabedoria - não, não quis dizer a Wikipedia, mas sim a Amazon - você encontrará títulos como The Corporate Blogging Book, Blogging for Business, Blog Marketing e outros. Independente do título, a mensagem básica é a mesma : caso você esteja em negócios, você tem que estar blogando. Porque caso você não o esteja fazendo, você não está “tendo uma conversa” com seus clientes, o que significa, por sua vez, que você não está enviando sua mensagem ou não está tendo valiosos comentários como retorno.

O artigo continua e vale a pena uma leitura, até porque nem precisa se registrar para ler (aleluia). Ele compara projetos de código aberto com negócios e cita que contribuidores de grandes projetos de software livre costumam blogar sobre o que fazem para obter feedback de seus “clientes”, ou seja, nós mesmos, os usuários

Mas esse não é o meu ponto (só uma desculpa para colocar o post no Planet Debian Brasil, já que citei projetos de código aberto - o que é uma blasfêmia, deveria software livre ! ). O que gostaria de saber é a opinião dos leitores desse blog e de qualquer pessoa que por acaso venha a ler esse post de alguma maneira sobre o assunto.

Também gostaria de indicações de livros sobre o assunto, de preferência livros que não sejam demasiadamente técnicos e que caiam na besteira de querer ensinar como configurar seu próprio blog ou planet (isso eu faço sem problemas), mas sim foque em técnicas e conselhos sobre como ter a tão falada “conversa com o cliente”.

Tem sugestões ? Então, comentários no post, por favor

Entrando em modo usuário

Devido a um projeto no trabalho, é bem possível que eu tenha que passar as próximas semanas (ou meses, quem sabe) me dedicando a produzir muita documentação. Eu escrevo muito diariamente, mas desde sempre só uso vim. Porém, devido a essa documentação ter que ser produzida em um formato que possa ser compartilhado com outras pessoas normais (não técnicas), me vi obrigado a começar a explorar as possibilidades do OpenOffice.org Writer, já que o mínimo que eu poderia fazer era dar força ao padrão ODF.

Não estou acostumado com esse tipo de software e não consigo gostar de processadores de texto complexos como esses, mas pelo que vi até o momento, ele parece até bem completo. O mais estranho é perceber que, depois de um tempo lidando com o bicho, você se dá conta de que está fazendo downloads de verificadores ortográficos e de dicionários de termos de informática e, o pior de tudo, está realmente usando isso tudo.

Uau ! Tenho medo do que pode estar por vir. Acho que vou começar a virar usuário comum. Socorro

stable_api_nonsense e distribuições enterprise-ready

Hoje tive a prova de que realmente não há sentido drivers de dispositivos serem mantidos externamente à árvore oficial do kernel. Se eles são mantidos fora, em minha opinião, só existem duas explicações :

• O código não é limpo/correto o suficiente para ser aceito na árvore oficial

• Os desenvolvedores nunca leram a documentação explicando porque uma API estável para o kernel não tem sentido

Já havia passado por muita raiva anteriormente utilizando módulos de kernel mantidos externamente, mas a política de atualizações de segurança do Debian sempre me ajudou muito nisso, porque mesmo com uma mudança de ABI em novos pacotes de kernel, regerar módulos de kernel empacotados no Debian é trivial e eu tinha a garantia de que a mudança na ABI foi necessária para corrigir uma falha de segurança real e não para acrescentar backports de funcionalidades novas suspeitas mascaradas como atualizações de segurança.

Mas hoje tive de lidar com outra distribuição que não segue essa política e me convenci que não ter o código para dar suporte a qualquer tipo de hardware que seja incluso na árvore oficial do kernel só gera dor de cabeça. O cenário : dois servidores, cada qual com 8 processadores e 8GB de memória, acessando um IBM TotalStorage DS4300 via fibra. O módulo que usamos para ter suporte um pouco melhor a failover das fibras é código mantido fora da árvore oficial do kernel (são dois, na verdade, mas isso é outra história).

Atualizações de segurança do kernel “oficiais” (ou seja, pacotes lançados pelo distribuidor oficial) instaladas, código do módulo externo recompilado, initrds regerados, servidores reiniciados e tudo aparentemente funcional. Percebeu o “aparentemente” ? O diabo está nos detalhes : o failover das fibras simplesmente parou de funcionar, congelando os servidores quando qualquer uma das fibras era removida e reinserida.

Depois de muita dor de cabeça para entender qual era o problema descobrimos que uma nova versão do código que implementa o módulo de kernel para controle de failover foi lançada. A nova versão corrigiu o problema, que foi “introduzido” pela nova versão do kernel.

Regras para se ter em mente quando lidando com distribuições enterprise-ready e código que deveria estar no kernel mas por algum motivo inexplicável não está :

• Seja relaxado em relação a segurança e fique vulnerável por algum tempo, esperando os desenvolvedores de seu módulo externo atualizarem o código em questão antes de aplicar as atualizações de kernel que são marcadas como críticas pelo distribuidor do seu sistema operacional.

• Distribuições “enterprise”, corretamente licenciadas, hardware e software homologados de nada adiantam quando a política de atualizações de “segurança” dessas distribuições introduzem código novo (e não somente correções de segurança) no meio de uma atualização de segurança.

Ah ! E porque raios as pessoas atualizam o código de seus drivers com base em versões de kernel de uma distribuição enterprise específica e não com base no kernel oficial ? Essas “parcerias” entre distribuidores de versões “enterprise” e grandes empresas de hardware/software me deixam furioso.

Por essas e outras que sempre bato a cabeça na parede quando ouço : “Tanto faz a distribuição, Linux é tudo a mesma coisa”. Hoje em dia isso é pura mentira. Todo o discurso de previsibilidade, de uma agenda e de uma grande empresa por trás vai por água abaixo quando vemos coisas como essas no dia-a-dia.

Backports do OpenOffice.org 2.0.3 disponíveis para Debian GNU/Linux 3.1 (Sarge)

Hmm, acabei de ficar sabendo que pacotes Debian do recém-lançado OpenOffice.org 2.03 foram enviados para os repositórios do backports.org. Chequei e ainda não estão disponíveis nos repositórios, mas acho que logo que forem devidamente compilados nos build daemons que gerenciam o serviço backports.org (sim, o backports.org tem um serviço de build daemons, assim como os repositórios oficiais do Debian) eles serão disponibilizados nos respositórios.

Já tenho o OO.org 2.0.3 instalado em meu laptop porque utilizo Debian unstable e os pacotes para essa suíte já foram disponibilizados, mas como não uso o OO.org muito (só para ler arquivos que recebo de outras pessoas e ocasionalmente escrever algum relatório que precise ser entregue em formato .doc, por exemplo), não tenho condições de dizer se melhoraram muito ou pouco. Ao menos os aplicativos da suíte OO.org iniciam e abrem os documentos que as versões antigas abriam corretamente, portanto, para meu uso pessoal, nenhum regresso ocorreu

Assim que estiverem disponíveis nos repositórios, vou atualizar o servidor LTSP de onde trabalho para disponibilizar as correções de bugs trazidas pela nova versão do OO.org para os usuários, já que, atualmente, já utilizamos os backports do OO.org existentes nos repositórios do serviço backports.org (versão 2.0.1).

Primeiro post em português : ainda estou vivo

Apesar de muitos ainda duvidarem, eu estou vivo. Este é meu primeiro post em português e possivelmente aparecerá no Planeta Debian Brasil . A inclusão de meu feed RSS já foi enviada e agora é só aguardar. Isso significa que, se tudo der certo, daqui por diante todos terão o desprazer de ler minhas idéias mais absurdas

Durante os últimos meses (quase um ano, na verdade), mudei de emprego e várias outras mudanças aconteceram. Estou trabalhando longe de casa, na região do ABC paulista, e tem me sobrado pouquíssimo tempo livre para trabalho relacionado ao Debian . Por isso, tenho contribuído bem menos do que gostaria.

Hoje consegui atualizar algumas traduções pendentes do debian-installer e atingir novamente o status de 100% traduzido, mesmo que isso seja temporário, já que sei que logo mais algo mais será acrescentado/modificado e as traduções precisarão ser atualizadas. Mas é um bom sinal, significa que a equipe de desenvolvimento está na ativa e preparando uma versão ainda melhor para o etch.

Além disso, atualizei algumas traduções que estavam paradas na fila de espera (ipsec-tools e samba), mas ainda existem muitas traduções pendentes para serem atualizadas e muitas outras para serem iniciadas. Como sempre, a seção sobre o status das traduções tem maiores detalhes. Perceba que estou falando de traduções de templates debconf e não de outras traduções.

Aliás, o Felipe tem algumas idéias interessantes que podem ajudar bastante a alavancar nossos esforços de tradução e ajudar nosso idioma a subir alguns degraus no ranking. Não vou comentar as idéias aqui ainda porque são somente idéias e nada ainda concreto e porque foi uma converda privada que tivemos e, portanto, não creio que seria justo torná-la pública sem o consentimento do faw.

Durante este tempo todo que fiquei desaparecido também participei de alguns eventos. Não muitos, mas nessas raras ocasiões pude reencontrar os amigos e ajudar, mesmo que desajeitadamente, nos stands do Debian. O último evento emque estive foi na LinuxWorld, que aconteceu aqui em São Paulo. Reencontrei o Felipe, o Otávio, o Fernando Ike, o quase-tão-sumido-como-eu Alex (rootsh) e diversas outras pessoas legais, bem como conheci algumas outras figurinhas interessantes do cenário do software livre no Brasil.

Espero poder participar de outros eventos e reencontrar novamente estas pessoas e quantas outras estiverem dispostas a me aturar. Se um dia eu aprender a conversar de forma decente, será um plus

Update: Os comentários estão habilitados, caso alguém precise me dar um chá de realidade e me mandar parar de escrever bobeiras. Só não sei ainda por quanto tempo vou deixá-los habilitados. Só a perseverança dos spammer dirá.