Archive for the 'tecnologia' Category

Por um controle de versão menos insano

Recentemente encontrei um texto do Jeff Atwood sobre a instalação do Subversion. Ele tem alguns argumentos bastante interessantes sobre controle de versão (sempre use controle de versão, faça modificações pequenas e blá, blá, blá…) que me parecem em geral bastante acertados, mas uma coisa me chamou a atenção: por que um programador (que pelo menos parece) tão bem informado quanto ele ainda escolhe um sistema de controle de versão tão completamente insano quando já existem tantas alternativas mais naturais para qualquer ser humano?

A maioria dos sistemas da velha guarda incrementa algum tipo de contador para identificar cada versão do objeto controlado: o Subversion, por exemplo, gera números de revisão quando há modificações em alguma parte da árvore de diretórios e o CVS associa um identificador seqüencial a cada um dos arquivos controlados. O maior problema do versionamento seqüencial é que simplesmente não controla o que queremos que controle. Saber quantas vezes um item qualquer foi modificado é útil, mas não tão útil quanto saber quais foram as modificações e, ainda melhor, quais as dependências entre elas. Sim, é bastante interessante saber qual o estado final de um trecho de código após um certo número de transformações, mas me interessa muito mais saber o que cada uma dessas modificações faz e tratar as modificações como objeto de trabalho, não os resultados delas.

Mais do que quantas modificações aconteceram desde algum ponto qualquer do tempo, eu preciso saber se a segunda modificação pode ser aplicada sem a primeira, se a terceira é uma inversão da primeira ou se a quinta desfaz algumas coisas que a quarta fez. As respostas para todas estas perguntas são necessárias para a operação mais fundamental do controle de versão: o merge.

Quando o Subversion surgiu, lá pelos idos de 2004, um de seus maiores argumentos era o branch barato. Este com certeza é um bom recurso para se ter, afinal de contas derivações precisam ser criadas o tempo todo. Mas o que queremos mesmo é que o merge seja fácil. O branch é só o começo da história. O merge é o ponto alto do processo, é quando as contribuições dos vários envolvidos são combinadas e passam a (pelo menos tentar) funcionar em conjunto. Há uma palestra em que Linus Torvalds resume isto muito bem em algumas poucas palavras: “branches são completamente inúteis, a não ser que você faça o merge”. Só que o versionamento seqüencial pára no branch e o merge precisa ser feito de forma manual porque o sistema não enxerga as dependências entre as alterações, só sabe qual delas aconteceu antes ou depois. Você pode conseguir ajuda para comparar duas versões do mesmo conteúdo, mas é você quem tem que saber quais devem ser as duas versões para este merge em particular que você quer fazer. A coisa fica ainda mais complicada quando você precisa importar modificações de outro branch periodicamente. Quando, por exemplo, seu projeto tem um branch estável em que só se faz conserto de bugs e outro — ou outros — em que são desenvolvidos novos recursos e que precisa receber as mesmas modificações que o estável para se manter livre de bugs. As pessoas acabam desenvolvendo algumas soluções arcanas para controlar manualmente quais alterações já foram aplicadas a quais linhas de desenvolvimento, coisa que o sistema de controle de versão podia (e deveria) fazer sem precisar de babá.

Os identificadores seqüenciais precisam ser atribuídos por algum tipo de servidor central. Não podem ser determinados por máquinas diferentes para evitar conflitos de nomes e acabam sendo completamente artificiais porque refletem simplesmente a ordem em que o servidor recebeu as alterações. Para a maioria das alterações, a ordem de aplicação pouco importa. E quando ela importa, os sistemas com versionamento seqüencial não costumam ajudar.

A alternativa ao controle seqüencial é o controle de patches (termo que admito estar inventando agora, então não deve ser muito preciso e provavelmente você vai encontrar isto com outro nome por aí). Um sistema de controle de patches associa um identificador a uma modificação, não ao resultado dela como os de controle seqüencial. Uma versão qualquer é simplesmente um acumulado de modificações que, quando combinadas, determinam um resultado final.

Sistemas seqüenciais são necessariamente centralizados. Não há como decidir qual o número para a próxima versão se não houver uma autoridade central para controlar a numeração. Porém, o inverso não é verdadeiro. Isto é, sistemas baseados em controle de patches não precisam ser distribuídos. A maioria dos que encontramos realmente é, mas não precisavam ser. A questão é que eles podem ser muito bem usados como sistemas centralizados, mas já tem tudo que precisam para serem distribuídos e independentes de um servidor central. Então porque se limitar? Além de poderem fazer tudo que os centralizados conseguem, os sistemas distribuídos ainda costumam ser muito mais fáceis de instalar. Se o Atwood tivesse escolhido um deles, não precisaria nem escrever um tutorial de instalação para si próprio. Era só escolher inicializar um diretório qualquer como repositório e começar a versionar o que quisesse. Sem serviços. Sem nomes de usuário. Sem senhas. Sem dores de cabeça com o firewall.

Minha impressão é que o funcionamento dos sistemas distribuídos de hoje é muito mais parecido com o modo como naturalmente pensamos do que o dos centralizados. Quando quisesse combinar duas linhas de trabalho distintas eu deveria apenas dizer a meu sistema que quero combinar as modificações que eu tenho com as que meu colega tem e ele deveria ser capaz de fazer isso sozinho (assumindo que não haja conflitos complicados). Eu não deveria precisar criar marcadores artificiais e manter manualmente um histórico de quais alterações dele eu já tenho. Por que algumas vezes ainda insistimos em usar sistemas centralizados? Há alguma vantagem oculta neles ou o quê?

O que diabos é AGPL?

A menos que você tenha passado os últimos dez anos preso em uma caverna em um planeta distante com os olhos e ouvidos vendados, deve pelo menos já ter ouvido falar da General Public License, a famigerada GPL. Ela (ainda) deve ser a licença mais usada no mundo para distribuir software livre e suas condições são bastante simples:

  1. Você tem acesso ao código-fonte do programa que está executando e pode fazer basicamente qualquer coisa com ele;
  2. Você pode inclusive modificar o programa, mas se quiser fazer isso precisa distribuí-lo sob os mesmos termos.

O sistema é bem elegante: você pode modificar os programas que recebe e/ou redistribuí-los sem modificação, mas deve oferecer a quem receber o programa de você os mesmos direitos que você recebeu. Isso garante que toda melhoria esteja disponível para todos os interessados e acaba criando comunidades em torno de uma peça de software. Claro que o texto completo da licença é bastante extenso, afinal de contas precisa incluir todo o advoguês para cobrir os casos limite e garantir que ninguém perca nenhum desses direitos no meio do caminho, mas a idéia é basicamente esta.

Porém há um detalhe bastante sutil neste esquema todo. Com a GPL, as pessoas precisam ter acesso ao código-fonte dos programas que estão executando. No caso de programas acessados através de uma interface de rede qualquer quem executa o código é uma máquina remota. Os usuários que acessam a aplicação de outras máquinas numa rede não podem ver o código-fonte e o dono do servidor pode modificar o programa o quanto quiser sem precisar distribuir o código-fonte. Afinal de contas, tecnicamente é só ele e mais ninguém que executa o programa. É completamente legal, por exemplo, que alguém baixe a versão 0.6.10 do Motiro, faça algumas modificações locais e sirva a aplicação para quem quiser usá-la sem ver o código-fonte correspondente.

As aplicações web, como o Motiro, são certamente o exemplo mais óbvio de onde este detalhe pode ser explorado para subverter as intenções iniciais do autor e, como parece que tudo atualmente está indo parar na web, ele ficou bastante evidente. Também é importante notar que é bem possível que o autor realmente quisesse deliberadamente permitir este uso, mas vou deixar esta discussão para outro dia. No caso do autor que quer que todos os usuários possam estudar e contribuir com seu programa, o universo de colaboradores pode ser bastante reduzido se forem considerados usuários apenas os donos dos servidores.

Colocando de uma forma bastante grosseira (e abrindo espaço para quem quiser corrigir), a GPL considera que os usuários são as pessoas que detém as máquinas que executam os programas. Neste sentido, os usuários têm todos os seus direitos, inclusive o acesso ao código-fonte, garantidos. Porém, no caso das aplicações web, as pessoas que realmente usam os sistemas (tipicamente através de seus navegadores) não têm nenhum desses direitos.

Num mundo repleto de processamento distribuído onde a maioria das pessoas não sabe exatamente que computador está efetivamente executando os programas que elas usam, a distinção entre executores e usuários deixa de fazer tanto sentido. A GNU Affero General Public License é uma licença com texto baseado na GPL original (dê uma olhada no texto completo para saber os detalhes, eu não sou advogado) que tenta consertar esta brecha. A história da licença é bem complexa, mas se eu tivesse que resumir, diria que para a AGPL não importa se as pessoas estão executando um programa em um processador local e usando os sistemas através dos seus teclados e monitores ou se acessam um servidor através da Internet; não importa se elas estão executando o programa por conta própria ou se usam do serviço de hospedagem oferecido por outra pessoa, se puderem efetivamente usar um programa, são consideradas usuários e, como tal, devem ter acesso ao código-fonte.

(Uma observação relacionada: consegui permissão dos demais autores do Motiro para mudar a licença de distribuição e hoje publiquei a versão 0.6.11 do programa, agora sob AGPL. Se estiver precisando de um sistema para acompanhamento de projetos, considere usar o Motiro.)

Orientação a objeto, e daí?

Não é tão incomum sugerir algo novo para um programador “orientado a objetos” e escutar alguma variante da velha frase “mas isso não vai de encontro a todas as noções conhecidas de orientação a objetos?”. Pode acontecer ao mostrar linguagens dinâmicas que permitem redefinição de métodos em tempo de execução, ao demonstrar as vantagens das closures ou até ao introduzir interfaces fluentes. Você escolhe.

Não precisamos nem discutir o que diabos é orientação a objetos para notar que o termo está perdendo o sentido mais rápido do que um raio. Nenhum dos exemplos citados parecem ofender o meu conceito de orientação a objeto e também não vejo porque feririam o de ninguém. Para ser sincero, desde quando os objetos tornaram-se tão sagrados que não possam ser subvertidos um pouco de vez em quando? Apesar disso já vi este argumento ser usado em todos os três casos.

O ponto aqui não é que orientação a objetos não sirva para nada. Nem que o purismo deva ser evitado. Na verdade, o purismo pode ser bastante útil como ferramenta intelectual. Duvido, por exemplo, que muitos dos recursos interessantes introduzidos em Haskell surgissem se não houvesse um compromisso com a pureza da linguagem em termos de transparência referencial. O grande problema com a orientação a objeto não é o purismo.

É o sucesso.

Com a popularização na última década da orientação a objeto o termo se disseminou. Isso fez mal para ele porque quanto mais gente conhece um termo fracamente definido, maiores as chances de ser desvirtuado ou simplesmente usado sem sentido nenhum. Parece que orientação a objeto acabou virando argumento contra qualquer coisa e, como geralmente ninguém sabe a que definição o falante está se referindo, não sobram muitos contra-argumentos. Nas poucas vezes que uma discussão mais ou menos civilizada é possível, o resistente acaba não se convencendo de verdade. Seria melhor que as pessoas dissessem que não gostaram da idéia, mas “estou sendo apresentado a esta técnica agora, parece diferente de tudo que já vi, estou com medo e não quero avaliar melhor as alternativas” não parece tão profissional. Sobra para a velha e leal orientação a objetos.

Testes não são para testar

Um teste é uma verificação feita sobre um programa para garantir que uma determinada entrada produza uma saída esperada. Testes são, de acordo com esta definição (propositalmente vaga), finitos e pontuais. Portanto não podem ser utilizados para verificar completamente a saída de um programa com entradas infinitas. A não ser que se disponha de tempo infinito.

Mas alguém tem tempo infinito?

Como a maioria dos programas úteis têm conjuntos de entrada extremamente grandes (e os infinitos nem são tão raros assim) e tempo não é um recurso muito abundante, testes só podem ser executados para um subconjunto necessariamente pequeno das entradas. Isso limita bastante a efetividade deles como recursos de validação. Não há como verificar se um programa está completamente correto com testes apenas, mas há várias técnicas que podem ser usadas para aproveitar melhor o pouco de certeza que eles podem oferecer. Testes não são perfeitos para validação, mas ainda são a melhor opção disponível.

Para que os testes sejam minimamente úteis, o programa precisa ser escrito com testabilidade em mente. A explosão combinatória pode derrubar os melhores programadores num piscar de olhos. Testar uma função de três parâmetros não costuma ser tão fácil quanto testar duas de dois. Quem quiser escrever testes um pouco menos complicados vai precisar tomar cuidado para não fazer tanta coisa dentro de uma função só. Do mesmo modo é mais fácil testar uma rotina que recebe um parâmetro de um sistema externo como entrada do que uma que faz a chamada internamente.

Estes são exemplos simples de separação de responsabilidades. Talvez sejam até óbvios, mas os defeitos ficam ainda mais destacados quando se está escrevendo o código dos testes junto com o código do programa em si. O maior valor dos testes está aí. Testabilidade é sinônimo de baixo acoplamento, que por sua vez é característica essencial do software bem escrito. Claro que testes servem para verificar corretude, mas somente de código bem feito. Atentar para os testes é mais do que validar saídas para entradas, é garantir que não está escrevendo uma grande bola de código entrelaçada de todos os lados.

A festa seqüencial acabou

Dia desses montei uma máquina nova para mim. Ela tem um desses processadores pomposos de núcleo duplo que já deixaram de ser os artigos de luxo que eram há alguns anos. Minha máquina anterior tem um processador de núcleo simples da época em que os de núcleo duplo tinham preços proibitivos. Este núcleo solitário trabalha a uma freqüência de 1.8GHz enquanto os dois núcleos da máquina nova rodam a 2.2GHz. Acho que a diferença é suficientemente pequena para que possamos dizer que a freqüência é mais ou menos a mesma. Os ganhos de performance, portanto, devem ser proporcionados principalmente pela presença dos dois núcleos e não do aumento de freqüência.

Porém a máquina nova não parece ser muito mais rápida que a antiga. Obviamente ela se sai muito melhor que a anterior quando há vários processos rodando ao mesmo tempo. Mas quando preciso que ela execute um programa único, a performance é mais ou menos a mesma. Por um lado, é verdade que o gargalo da maioria das aplicações realmente não está no processador nem na memória, mas nos dispositivos de entrada e saída como rede e disco. Para estas aplicações é de se esperar que um aumento da capacidade de processamento não faça grande diferença. Por outro lado, esta máquina nova não parece mais rápida nem para atividades com uso intenso do processador.

Utilização de CPUEm nome da boa e velha curiosidade, resolvi fazer um teste rápido. Peguei um dos meus CDs de música e coloquei a máquina para compactar uma amostra razoável de áudio. Compactação de áudio (e vídeo) é uma daquelas tarefas ridiculamente paralelizáveis. Uma forma bastante óbvia de aproveitar melhor o hardware seria deixar que cada um dos processadores ficasse responsável pela compactação de metade do trecho de áudio. Apesar disso, quando estava compactando o áudio, observei que apenas um dos núcleos fica em uso em um dado momento. De vez em quando o processamento é transferido de um núcleo para outro, mas apenas um é usado efetivamente.

Quando há vários processos diferentes brigando por um pouco de tempo de processador, os sistemas operacionais modernos são bastante espertos para distribuírem a carga inteligentemente. O problema acontece quando há um programa que demanda muito do processador mas não está preparado para ser quebrado em partes menores e executado em paralelo. Se ele não usa nenhum mecanismo para identificar os trechos de código que podem ser executados lado a lado, o máximo que o sistema operacional pode fazer é enxergá-lo como um grande amontoado de instruções a serem executadas uma após a outra. Chegamos a um ponto em que os sistemas operacionais estão prontos e o hardware também está pronto, só faltam as aplicações.

Máquinas com múltiplos processadores já são realidade há um bom tempo e o uso de vários núcleos por chip não é tão novo assim, mas este tipo de tecnologia estava limitado a certos nichos. A preocupação em utilizar o poder de vários processadores operando em paralelo só começa a se popularizar agora que a festa seqüencial acabou. Antes não fazia muito sentido dar-se ao trabalho de escrever programas paralelizáveis porque era possível fazê-los executar de forma mais rápida simplesmente enfiando mais alguns megahertz nos processadores. Porém agora o limite da freqüência, e principalmente da dissipação do calor associado, parece ter sido atingido e, por mais que esperemos, não vai dar mais para comprar processadores que operem a freqüências muito maiores que as atuais.

Meu palpite é que, de agora em diante, quem precisar melhorar a performance de suas aplicações utilizando todo o hardware disponível (o que não se aplica a todo mundo, afinal a “otimização prematura é a raiz de todo o mal”) vai precisar escrever programas paralelos. Na verdade, eu acho que as pessoas já estariam escrevendo programas paralelos há muito tempo se fosse mais fácil. Só que os ambientes para desenvolvimento mais populares de hoje não são muito amigáveis para este tipo de programa. As plataformas mais usadas ainda fazem uso de alguns conceitos que se mostraram bem difíceis de digerir, como threads e semáforos.

Isso quer dizer que precisamos descobrir novos modelos de pensamento se quisermos trabalhar com código concorrente e paralelo. Se você me permitir outro palpite, posso arriscar dizer que os modelos mais eficientes do futuro não vão ser tão seqüenciais quanto os atuais.

Alguém tem um Mac por aí?

Então parece que a Apple está preparando uma versão do seu navegador Safari para Windows. Parece também que o bicho está disponível como beta e, como tenho acesso a uma máquina Windows XP no trabalho, achei que não faria mal a ninguém testar o navegador que há algum tempo atrás era exclusividade de usuários Mac. Claro que o primeiro site que testei foi o do projeto Motiro e o resultado não foi muito animador:

Motiro no Safari 3 Beta em Windows XP

Os trechos de texto com alguma modificação de estilo (títulos, negrito, cores personalizadas) não foram exibidos e houve alguns problemas de perda de alinhamento em alguns elementos. Isso tornou o site totalmente inútil para qualquer pessoa com um mínimo de juízo (como não sou uma dessas pessoas, ainda tentei abrir algumas páginas da wiki e parece que os problemas continuam em todas as páginas).

Há algum tempo venho usando o BrowsrCamp.com para ver algumas fotos de como o Motiro aparece no Safari. Obviamente que ver fotos estáticas do seu site não é uma opção tão boa quanto vê-lo ao vivo, mas é melhor do que nada. A versão que eles usam não é este beta do Safari 3, mas um Safari 2 que presumo ser estável. Nele o Motiro aparece bem mais apresentável:

Motiro no Safari 2.0.4 em Mac OS X

Será que o Safari mudou tanto do 2 para o 3 que passou a renderizar sites de modo completamente diferente? Ou este é um comportamento apenas da versão Windows do Safari 3? Se alguém tiver um Mac por aí e puder fazer estes testes com o Motiro, eu agradeceria muito. Depois dessa estou pensando seriamente em concentrar os esforços completamente nos aspectos de compatibilidade com navegadores para o release 0.6.7.

Comunidade Eclipse lisonjeada

Parece que a Microsoft anunciou esta semana a nova versão do Visual Studio. Antigamente ele era um ambiente de desenvolvimento, mas agora parece que vai ser uma plataforma para várias aplicações. Pelo que pude encontrar de cobertura on-line, parece que agora eles querem produzir uma plataforma extensível para ferramentas de desenvolvimento. A idéia básica é usar o alicerce do Visual Studio para construir aplicações como plugins. Mais ou menos como o Eclipse vem fazendo desde os tempos memoráveis da versão 2.0, lá pelos idos de 2002. Qual será a próxima? Construir aplicativos de propósitos diversos sobre a plataforma Visual Studio? Algo como Eclipse RCP, que está disponível desde a versão 3.0 (que saiu mais ou menos em 2004)?

Ian Skerret, diretor de marketing da Fundação Eclipse está mais do que certo em afirmar que a cópia é a forma mais sincera de admiração. Todas as organizações e indivíduos que formam a comunidade de desenvolvedores da plataforma Eclipse devem estar lisonjeados. Afinal de contas quando os seus competidores mergulham com tanta vontade nesse tipo de perseguição gato-e-rato, eles estão involuntariamente dizendo que você estava certo o tempo todo.

Os fornecedores externos interessados em construir sobre esta nova plataforma devem estar ansiosos para que a brincadeira continue. Talvez eles consigam um pouco do ambiente colaborativo, da abertura e da flexibilidade que o Eclipse já experimenta há anos. Porém, tendo em vista os recentes desdobramentos do caso TestDriven.NET, parece que isso não vai acontecer muito cedo.

Você batiza seus bugs?

O título era para ser outro. Algo como “Você batiza suas sugestões de funcionalidade, pedidos de mudança, tickets, estórias de usuário ou seja lá como você gosta de chamar as solicitações de melhoria para suas aplicações?”, mas acho que ficaria um pouco longo demais. Resolvi generalizar tudo para “bugs”, mas por favor não se irrite se não escolhi seu termo favorito. Com uma lista de termos tão longa quanto essa, é difícil conseguir agradar a todos.

Uma vez trabalhei junto com alguns amigos em um jogo. Um jogo é só um programa de computador e, assim como qualquer programa de computador, acaba adquirindo alguns defeitos durante o desenvolvimento. A peculiaridade dos jogos é que eles costumam imitar o mundo real, tornando mais fácil fazer associações e analogias.

Nosso jogo tinha alguns defeitos particularmente interessantes. Um deles fazia com que alguns personagens começassem a se deslocar em uma direção que não coincidia com a animação exibida. Dava para ver o boneco tentando andar na diagonal enquanto o deslocamento real era na horizontal. Ficávamos entretidos olhando aquilo e acabamos inventando um nome para o defeito: Moonwalker, uma referência ao passo de dança popularizado por Michael Jackson.

Outro defeito tinha a ver com liberação de memória. Em algum ponto do código, estávamos liberando erroneamente a memória usada para armazenar os quadros da animação do movimento dos personagens. Isso de vez em quando fazia eles desaparecerem da tela por alguns milésimos de segundos e reaparecerem em outro ponto mais à frente. Chamamos isto de Tele-transporte. Um terceiro defeito, desta vez na rotina de detecção de colisão, fazia com que o personagem principal pudesse atravessar as paredes em alguns pontos. Este foi prontamente batizado com o nome “Ladrão Fantasma”.

Deixando a nostalgia de lado por um momento, o fato é que os nomes humanizavam todo o trabalho desde a detecção até a eliminação dos defeitos, do mesmo modo que os nomes de domínio humanizam os endereços na Internet (e as pessoas acabam usando os mecanismos de busca para levar a idéia ainda mais adiante). Para um computador é simples enviar uma requisição para 200.186.109.162, mas para uma pessoa é mais simples entrar no thiagoarrais.wordpress.com (e muita gente acha ainda mais simples buscar por “Mergulhando no Caos”). Do mesmo modo, pode ser natural para uma máquina marcar como resolvido o registro referente ao bug #1376, mas para um humano é mais natural levantar do lugar e dizer “Consertei o Moonwalker”.

O Motiro institucionaliza esta prática. Os “bugs” nele são chamados “sugestões de recurso” e toda sugestão de recurso é uma página wiki. Como qualquer outra página wiki, elas têm um título: um nome que precisa ser informado por quem registra ou edita um bug. Se a pessoa não estiver se sentindo muito criativa na hora, pode deixar de preencher o título e a página receberá um número.

Os demais sistemas de acompanhamento de que tenho notícia costumam usar um número para se referir aos bugs e disponibilizam um sumário para humanizar um pouco a coisa. O Motiro é o único que conheço que elimina os números de bug em favor dos títulos. O fato de nenhum outro sistema do tipo fazer isto pode significar duas coisas: ou esta é uma daquelas idéias que parecem ridiculamente óbvias depois que alguém as têm (como o Ovo de Colombo), ou é uma péssima idéia mesmo.

Se você parar para pensar, defeitos são coisas que se quer eliminar o mais rápido possível. Algo que você não quer andando por aí durante muito tempo. Se uma barata aparece na sua cozinha, você vai lá e mata. Não fica inventando nomes fofinhos e engraçadinhos para a intrusa. Se os defeitos são detectados e corrigidos rapidamente, não faz muito sentido perder tempo bolando nomes.

Por outro lado, os recursos para eliminação de defeitos são limitados. Pode ser que o chinelo não esteja por perto na hora que a barata aparece, pode ser que você tenha um pavor gigantesco de baratas e não consiga fazer nada além de gritar e correr ou pode ser que você precise estudar bastante antes de entender alguma tecnologia. Quando não é possível corrigir todos os defeitos ao mesmo tempo, alguns deles precisam existir por mais tempo que os outros e podem ganhar nomes.

Além disso, bugs neste contexto não são somente defeitos. Podem ser também sugestões de novos recursos e comentários para melhoria. Neste caso, também volta a fazer sentido batizar estas coisas. Algumas dessas sugestões podem precisar ser amadurecidas e um nome é uma boa forma de se referir a elas.

De qualquer modo, o fato de nenhum sistema atual favorecer as palavras em detrimento dos números é intrigante. Afinal, pessoas geralmente lembram melhor das palavras do que dos números, não?

E você? Costuma batizar seus bugs?

Novos Debian e Ubuntu: Instalação e efeitos visuais (resenha)

Este é o primeiro artigo de uma série com minha avaliação do Debian Etch e Ubuntu Feisty Fawn, lançados em abril de 2007. Os demais artigos serão publicados em breve, conforme sejam finalizados.


Abril foi um mês bastante movimentado no mundo Linux. Duas das maiores distribuições publicaram novas versões estáveis: o Debian 4.0 (Etch) saiu dia oito, quase dois anos depois do Sarge, e o Ubuntu 7.04 (Feisty Fawn) saiu duas semanas depois (quinta-feira, dia 19). Eu uso as duas no meu desktop principal e como iria fazer a atualização de qualquer modo, resolvi aproveitar para dedicar algum tempo a uma resenha simultânea.

Meu intuito não é criar mais uma polêmica com um artigo do tipo “Ubuntu matando Debian”: eu sinceramente não acho que o Ubuntu tenha esse tipo de tendência suicida. Esta breve resenha é somente para oferecer minha visão de usuário e entusiasta das duas distribuições. Eu sou programador (e, se é que isso faz alguma diferença, atualmente estou usando principalmente Ruby, Java e Haskell), portanto esta resenha deve ser mais útil para quem tem um perfil parecido. Mas, se este não é seu caso, não precisa abandonar a leitura ainda. O velho ditado já dizia que ninguém é de ferro e quem sou eu para contrariar velhos ditados? Eu também escuto música, assisto vídeos e uso alguns aparelhos externos como câmeras digitais e tocadores de música, coisas que todo mundo exige de um computador hoje em dia — e que em muitos casos são tudo que se exige. Só não espere encontrar algo sobre aplicativos de escritório por aqui.

O sistema

A máquina que estou usando para estes testes é meu sistema de casa. Na época em que a montei (há uns bons dois anos e meio) ela era razoavelmente possante, mas acho que hoje em dia equivale a um PC médio desses que já vêm encaixotado e que os vendedores de supermercado empurram para quem está “procurando um computador”. É um Athlon XP (32 bits) 2000+ com 512MB de memória RAM, 160GB de disco rídigo e placa de vídeo com chipset NVidia FX 5200 e 128MB de memória.

Na minha classificação esta máquina com certeza não está acima de “razoável”. Apesar disso, tanto com o Debian como com o Ubuntu, ela consegue se sair bem para o que preciso atualmente e não demonstra sinais de cansaço mesmo quando estou usando um ambiente de desenvolvimento muitas vezes considerado pesado (e, para quem conhece, este seria o Eclipse com alguns plugins personalizados), navegando com algumas abas abertas e com os efeitos de desktop 3D ativados.

Portanto, ponto para as duas distribuições no quesito performance.

Instalação

O processo de instalação para cada umas das duas distribuições demorou pouco mais de uma hora. Boa parte deste tempo foi usado na comunicação com os servidores. Eu fiz a instalação logo após os lançamentos oficiais e é de se esperar que o tempo seja um menor agora que o servidores estão um pouco menos sobrecarregados. Obviamente, tudo isso depende também da qualidade da sua conexão com a Internet.

Esperar uma hora pela instalação do sistema operacional não é uma das coisas mais divertidas que se pode fazer com um computador. No entanto, a instalação do Ubuntu brilha nesta área. O processo todo é feito a partir de um CD Live e o sistema pode ser usado normalmente durante a instalação. Isso significa que enquanto tudo é instalado você pode ler seus e-mails e notícias ou então começar a preparar algum artigo para o seu blog. A instalação do Debian, por outro lado, roda em modo texto. Você ainda pode navegar na Internet usando o lynx ou algum outro navegador em modo texto, mas a experiência com certeza não é a mesma. De qualquer modo, o processo não é tão traumático porque não é todo dia que você vai reinstalar um sistema Debian do zero. O meu poderia ter sido atualizado normalmente a partir da versão Sarge, só fiz uma instalação limpa para poder relatar minhas experiências aqui para meus 80 milhões de leitores.

Outro recurso da instalação do Ubuntu que me agradou bastante foi a habilidade de importar dados pessoais de outros sistemas operacionais. Isto permite, por exemplo, que você importe do seu Windows coisas como mensagens de e-mail salvas localmente, endereço de acesso ao Messenger e endereços gravados no seu navegador. Eu não precisava disso dessa vez, mas teria sido bem útil há um ano e meio quando instalei meu primeiro Ubuntu (que também foi meu primeiro Linux). Parabéns para a equipe do Ubuntu por facilitar a migração.

Colírio para seus olhos

Um dos recursos mais polêmicos desta versão do Ubuntu foi a inclusão de efeitos 3D para a área de trabalho. Durante o desenvolvimento do Feisty os boatos se espalhavam rapidamente. Era comum escutar numa semana que os efeitos estariam dentro e ver a notícia ser desmentida na semana seguinte.

Falar em efeitos visuais para desktop Linux ultimamente é falar de XGL, Compiz e Beryl. Porém, o pivô de toda a polêmica não foi nenhum dos três. Por trás de tudo estavam os drivers binários.

Os drivers de código-aberto para placas 3D sob Linux ainda não têm todos os recursos necessários para proporcionar o tipo de experiência que o Ubuntu queria. Como a filosofia do projeto é não incluir código proprietário na instalação padrão, eles precisaram chegar a algum meio termo razoável. E finalmente conseguiram: disponibilizaram os drivers proprietários de forma fácil após a instalação. Desse modo, quem quer ativar os recursos avançados pode fazê-lo facilmente ao mesmo tempo que aqueles que não fazem questão não precisam executar código proprietário.

A instalação dos drivers 3D está a dois cliques da instalação padrão. Depois que a instalação estiver concluída, é só parar de ler seus e-mails, reiniciar a máquina e seguir para Sistema > Administração > Gerenciador de Drivers Restritos. Isto vai fazer com que o driver seja automaticamente baixado e instalado. Para ativar os efeitos é só marcar um campo em Sistema > Preferências > Efeitos da Área de Trabalho. Fácil assim.

Resumo

Instalar e rodar as duas distribuições está bem fácil. A configuração padrão vem com os programas mais comuns e depois só é preciso adicionar aqueles outros mais específicos. Não é preciso saber exatamente que programas você precisa para fazer uma instalação, mas é possível escolher um por um se você souber o que quer.

O Ubuntu sai na frente para quem quer admirar alguns efeitos visuais interessantes no desktop por permitir a instalação fácil dos drivers binários e a ativação simples dos recursos visuais. Nada é impossível com o Debian, mas talvez você tenha que pesquisar e perguntar para mais pessoas e acabe levando um pouco mais de tempo.

Este artigo é apenas a primeira parte da resenha. A próxima parte, que será publicada em breve, irá se concentrar nos recursos multimídia, incluindo integração com dispositivos externos.

Blogs-diário, blogs-opinião e minha tentativa como entrevistador

Tem um tipo de blog pelo qual tenho uma ojeriza tremenda: o blog-diário. Acho que eles já pararam de fazer isso (porque migraram para os sites de relacionamento), mas sabe aqueles blogs de adolescentes cujos artigos costumam ser sobre a festinha de ontem ou a bronca que o professor passou na turma hoje mais cedo? Sabe aqueles blogs cujos artigos mais elaborados são aqueles que têm uma letra de música qualquer que o autor e seus amiguinhos estavam escutando no dia (e mais nada)?

Este tipo de coisa não acontece somente com garotos e garotas de 14 anos, alguns blogueiros na área de tecnologia também estão infectados com a mesma doença. Neste caso os assuntos mudam um pouco. Passam a ser sobre o último release dos seus projetos, as conferências mais badaladas e os encontros de grupos de usuários locais. Eles podem não notar, mas estão agindo do mesmo modo que os adolescentes. Estão somente publicando um diário de bordo.

Acho que blogs deveriam ser um meio para publicar opiniões e vê-las serem destrinchadas, atacadas e testadas. Se estivéssemos em uma revista semanal, os blogs deveriam ser mais como uma coluna ou um editorial do que como o resumo da semana. Os leitores não querem saber o quanto o autor é inteligente, produtivo ou como tem sucesso em tudo que resolve fazer. Ao invés disso, um blog deve ser um espaço para o autor ajudar os leitores a se tornarem mais inteligentes, produtivos e a terem mais sucesso em tudo que resolverem fazer.

Apesar disso tudo, acabei caindo nesta armadilha em conseqüência da correria nossa de cada dia. Se você consultar os históricos aqui do blog, vai ver que os dois últimos artigos anteriores a este se encaixam perfeitamente no que eu descrevi como artigos de blog-diário. O último é só um anúncio de reunião de grupo de usuários e o penúltimo uma bela de uma babada em meu próprio trabalho juntamente com o anúncio da publicação do Motiro (não consegui resistir a mais um link). Mas o sinal mais alarmante de que eu estou usando meu blog como um diário é que este mesmo artigo que você está lendo agora também é só mais uma anotação de diário.

Sim, eu publiquei toda esta introspecção e fiz você ler até aqui somente para anunciar que participei da entrevista que o Eduardo Fiorezi fez com o Vitor Pamplona. Foi bastante gratificante receber um segundo convite para o programa do Eduardo, principalmente por ter sido surpreendido com uma posição de entrevistador ao invés de entrevistado e pela estrela do programa ser uma figura tão relevante.

Espero que com estes três últimos artigos eu não tenha perdido metade da minha audiência, mas prometo que vou fazer de tudo para que o próximo revele algum pensamento interessante sobre tecnologia.

Por enquanto, um anúncio de entrevista disfarçado de reflexão é tudo que tenho a oferecer.



Seguir

Obtenha todo post novo entregue na sua caixa de entrada.