A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

• Informix Dynamic Server
• IBM DB2
• Microsoft SQL Server
• MySQL
• Oracle Database 10g or later
• PostgreSQL
• Sybase Adaptive Server

Os critérios de avaliação foram:

• Performance
• Funcionalidades de segurança
• Scalabilidade vertical
• Atomicidade
• Consistência
• Isolação de transações
• Durabilidade das transações
• Qualidade das ferramentas de modelagens
• Suporte ao XML
• Suporte a Multiplatforma
• Qualidade das ferramentas de gerenciamento inclusas no banco de dados
• Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
• Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

• A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.

• O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.

• O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.

• O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.

Foi lançada recentemente uma matriz de comparação entre as versões do PostgreSQL aqui. A lista é muito interessante pois mostra uma série de funcionalidades que foram surgindo e ficando obsoletas entre as versões 7.4 e 8.3. Vale a pena conferir e contribuir com a iniciativa.

Bom, depois de escrever sobre algumas vantagens do PostgreSQL em relação ao Oracle, chegou a hora de fazer o inverso. Eis aqui algumas características do Oracle que eu realmente sinto falta no PostgreSQL.

• Triggers de sistema. O Oracle possui a capacidade de disparar gatilhos quando você inicia o SGDB, quando um usuário se conecta, quando realiza uma operação de DDL, etc. Isso ajuda muito para quem quer realizar auditorias e construir alguns esquemas especiais de segurança. Além disso, o Oracle possui o AUDIT que que é um comando que utiliza uma estrutura pronta para auditar diferentes eventos;
• O PostgreSQL também tem ferramentas para gerar logs, mas o Oracle realiza isso com maior nível de controle, permitindo especificar uma sessão específica. Isto ajuda muito para monitorar uma ação específica dentro de um ambiente de produção.
• O Oracle permite de indicar um tablespace separado para o Tablespace TEMP e UNDO. Isto permite um ajuste de desempenho melhor, particularmente colocando o tablespace TEMP em outro disco em aplicações de BI que fazem consultas enormes. É claro que você consegue fazer isto no PostgreSQL utilizando links simbólicos, mas esta não é a forma mais elegante de se fazer isto. A versão 8.3 do PostgreSQL já deve trazer avanços neste sentido.
• Fine -Grained Access, é uma ferramenta do Oracle que permite o acesso a determinadas linhas de uma tebela de acordo com o perfil do usuário conectado. Este é um recurso interessante que em aplicações corporativas podem ajudar um bocado.
• Maior flexibilidade na definição dos arquivos de log de transação. No Oracle é possível determinar o tamanho e o local de cada log, além de fazer um espelhamento se você desejar. O PostgreSQL permite alterar o tamanho dos arquivos de log alterando um parâmetro no código fonte e também é possível criar links simbólicos para alterar a posição dos arquivos de log. No entanto, acho que o Oracle tem uma solução mais robusta neste ponto.
• O Oracle tem a possibilidade de criar tablespaces com diferentes tamanhos de bloco e buffers específicos para cada tamanho de bloco. Num ambiente que mistura características de OLTP com BI, isto pode ser interessante. É claro que oideal seria separar os dois ambientes em servidores distintos. No entanto esta opção confere ao Oracle uma flexibilidade adicional no ajuste de performance e uso do disco.
• SQLLoader é uma ferramenta para importação de grandes volumes de dados em arquivos texto em diversos formatos. E uma ferramenta realmente robusta e flexível que pode lhe ajudar a fazer ETL, migrar dados de plataformas distintas, etc.
• O Oracle permite a paralelização de operações pesadas, incluindo backups lógicos, importações via SQLLoader, consultas longas, etc. No PostgreSQL, você tem o PGPool II que permite a paralelização de consultas pesadas, mas não tem ferramentas para outras situações. Você também pode disparar duas operações de backup lógico em separado definindo partes diferentes do banco de dados para a operação. No entanto, crieio que a opção de paralelização seja uma alternativa interessante.
• O RAC (Real Aplication Cluster) é uma solução conhecida de cluster de banco de dados no Oracle. O RAC é uma solução que permite escalar o Oracle horizontalmente além de prover uma considerável tolerância a falhas. O PostgreSQL tem a capacidade de escalar verticalmente melhor que o Oracle, mas não tem ainda uma solução para escalar horizontalmente, nem uma solução para tolerância a falhas que seja síncrona, apesar de em Linux existirem soluções para isto. Existe um projeto chamado PGCluster II que promete fazer uma implementação semelhante ao RAC no PostgreSQL.
• As ferramentas de monitoramento da Oracle são realmente úteis. A partir do Oracle 10g o “Database Control” tem facilidades realmente interessantes e acredito que a versão 11g tenha melhorado mais ainda isso. Existe um projeto chamado Cedrus que promete cobrir boa parte deste vácuo no PostgreSQL. No entanto, já existem ferramentas como o Munin, que fazem um bom monitoramento do servidor e possui algumas extensões para o Oracle, PostgreSQL e MySQL, além de ser simples criar novas extensões.
• Ajuste automático de memória. O Oracle possui alguns parâmetros de inicialização se ajustam limites de memória para o Oracle e deixa ele distribuir este espaço entre as diversas áreas internas. Isto realmente pode simplificar muito o trabalho do DBA. Já ouvi falar que o pessoal da SUN tem interesse em investir em mecanismos deste tipo no PostgreSQL, mas isto ainda deverá levar alguns anos para se concretizar.
• Os índices do tipo bitmap ajudam muito em colunas de baixa cardinalidade e poucas gravações. O PostgreSQL tinha programado para implementar esta funcionalidade na versão 8.3 mas adiou para a versão 8.4. No entanto os índices bitmap são utilizados na memória (mas não em disco) no PostgreSQL em durante uma busca.
• O Particionamento de tabelas do Oracle também tem algumas vantagens sobre o particionamento do PostgreSQL como o particionamento por hash e outras funcionalidades que ajudam a dar manutenção em tabelas particionadas.
• Controle de transações dentro de um bloco PL/SQL. Isto é algo que me faz falta no PostgreSQL quando você precisa de funções mais complexas. No PostgreSQL todo o bloco PL roda dentro de uma única transação, enquanto do Oracle você pode declarar o begin, commit, rollback e savepoint dentro do PL/SQL.
• Visões materializadas, são coisas possíveis de serem feitas utilizando-se gatilhos e funções no PostgreSQL, mas é bem mais fácil quando você já tem uma estrutura sintática pronta para isso como no Oracle.
• O Jobs Scheduler é ferramentas do Oracle que permite o disparo de ações específicas através do agendamento em horário específico, se repetindo ou não em intervalos programados. Muitas pessoas resolvem esta ausência utilizando o CRON do Linux, mas o Job Scheduler tem uma série de funcionalidades interessantes, além de permitir tratar tudo via SQL.

É claro que o Oracle tem a mania de abocanhar o mundo e oferece uma miríade de funcionalidades, algumas exóticas e certamente algumas que eu não conheço. Se você sentiu falta de algum item, por favor deixe a sugestão nos comentários. Muito do que está aqui acaba sendo importante para quem pretende migrar de Oracle para PostgreSQL e não sabe se vai encontrar as funcionalidades que espera.

Bom… todos sabem que o Oracle possui uma miríade de recursos bacanas e interessantes. Alguns deles o PostgreSQL realmente não tem, e alguns eu acredito que nunca terá (até porquê a equipe do PostgreSQL tem uma visão diferente em vários pontos da Oracle). Não estou dizendo que o PostgreSQL é melhor que o Oracle ou vice versa… estou dizendo apenas que escolher um SGDB não é como escolher uma roupa para dar de presente. Não basta olhar a marca e se deslumbrar com comerciais fantásticos, shows de luzes e coquiteis luxuosos. Você tem que conhecer as funcionalidades de cada um e saber onde está entrando. E o que quero demonstrar aqui é que o PostgreSQL também revela suas qualidades! É comum pessoas perguntando sobre recursos que o PostgreSQL tem que o Oracle não tem… aqui vai uma pequena lista. Por favor sinta-se a vontade para acrescentar novos itens nos comentários.

• Readline: para quem está acostumado com o bash, sabe como é bacana poder utilizar algumas facilidades providas por esta maravilhosa biblioteca. Completar comandos e histórico de comandos são duas coisas que tornam a experiência em modo texto muito agradáveis. Eu sei que o SQLPLUS tem muitas funcionalidade interessantes, mas o psql é realmente uma ferramenta muito mais agradável devido ao uso do Readline e para mim isto significa perda de produtividade e aumento na curva de aprendizado do SQLPLUS.
• Maior flexibilidade com as linguagens com as PLs. O PostgreSQL tem suporte ao PL/pgSQL, está implantando o PSM e tem suporte a PL/Python, PL/Ruby, PL/PHP, PL/PERL etc. E ainda tem a possibilidade de cria-las no modo TRUSTED e UNTRUSTED. Isso é uma mão na roda e aproxima muito o time de desenvolvedores dos DBAs.
• LIMIT e OFFSET, estas duas cláusulas não fazem parte do padrão SQL, mas a maioria dos SGDBs implementam. Se você tiver que paginar páginas de uma consulta (coisa que você sempre deve fazer ao retornar mais de 100 linhas numa página web por exemplo) utilizando o ROWNUM, você verá que o mundo poderia ser mais simples.
• Uma das primeiras coisas que eu descobri quando comecei a utilizar o Oracle: você não pode criar uma tabela e colocar uma sequência como valor padrão para um campo. Isto é só um pequeno detalhe, mas convenhâmos, é bem prático utilizar um insert sem ter de lembrar o nome da sequência atrelada ao campo;
• O Dollar Quoting é uma característica do PostgreSQLque nos permite evitar situações incômodas onde precisamos escapar aspas simples e duplas. Quando se utiliza PL, isto pode se tornar um tanto incômodo. Além disso o Dollar Quoting é um bom aliado na luta contra o SQL Injection
• Algo irritante no Oracle é o nome atribuído a objetos criados implicitamente. Se você cria uma chave primária e não atribui um nome explicitamente, tanto o PostgreSQL quanto o Oracle atribuem um nome para a sua PK. Mas enquanto o nome atribuído pelo Oracle é algo como SYS1328909 o PostgreSQL utiliza nomes muito mais inteligentes, através de um padrão de nomenclaturas inteligível. Num ambiente de testes onde os desenvolvedores esqueçam de atribuir todos os nomes explicitamente, o caos passa a reinar rapidamente nos nomes de objetos do Oracle.
• Se você quer uma funcionalidade avançada que o PostgreSQL oferece, ela se chama GiST. O GiST é uma infraestrutura para a criação de novos típos de índices para novos tipos de dados. Com ele é possível criar aplicações com demandas muito específicas com um excelente desempenho sem muito esforço. É claro que não é qualquer um que vai utilizar isso (assim como não é qualquer um que utiliza uma série de funcionalidades avançadas do Oracle), mas o leque de opções que isto abre é enorme. Existem algumas implementações de índices utilizando o GiST prontos para você utilizar. Eles mostram o poder de adaptação que o PostgreSQL possui para demandas específicas.
• Conformidade com o padrão SQL2003. Sim… o Oracle possui diversas coisas estranhas como usar o VARCHAR2 ao invés de VARCHAR, não utiliza o as visões do catálogo de sistema padrão e inúmeras coisas estranhas que são heranças antigas do Oracle que parecem que não tem melhorado muito nas últimas versões. O tipo de dados TIMESTAMP por exemplo, só surgiu na versão 9i. O mais simples tipo de dados, o BOOLEAN simplesmente não existe no Oracle. Se você quer saber mais sobre isso, compare você mesmo a lista de compatibilidade do Oracle e do PostgreSQL.
• Melhor integração com o SO. Você já atualizou uma Distribuição Linux com um Oracle instalado? Prepare-se para muita dor de cabeça, pois o processo é no mínimo delicado. Para quem utiliza uma distribuição Linux como o Debian, isso mal passa pela cabeça do DBA. Você atuliza o SO junto com o PostgreSQL e pronto. Outra coisa interessante é que você pode utilizar os redirecionamentos do shell para jogar a saída de uma exportação direto na entrada de uma importação. Isso economiza tempo de disco. Na verdade o PostgreSQL se ajusta muito bem com o Padrão POSIX, enquanto a Oracle insiste em criar suas próprias regras como o OFA (Optimal Flexibe Architeture).
• Você pode subir um Oracle num 486?? O Oracle é pesado, um verdadeiro dragão devorador de recursos. A versão 11g que foi lançada recentemente pede um mínimo de 1GB de memória no servidor. O PostgreSQL é bem mais flexível neste sentido. Você pode subir um PostgreSQL para testes no seu próprio desktop em 2 minutos e já sair testando sem ter que se preocupar muito com isso. Eu particularmente chego a ter 2 ou 3 versões do PostgreSQL rodando no meu desktop sem problemas. Agora dê uma olhada no procedimento de instalação do Oracle e você verá porquê poucas pessoas sabem colocar ele no ar de maneira adequada!
• Suporte a um número maior de arquiteturas. Por incrível que pareça, o Oracle não roda no FreeBSD por exemplo. Vale a pena comparar as arquiteturas suportadas pelo Oracle e PostgreSQL.
• Independência de suporte. Todo mundo pergunta se o PostgreSQL tem suporte confiável no Brasil. Tem sim, não vou me pronunciar a favor de um ou outro aqui, mas temos empresas muito competentes aqui no Brasil. Mas alguém já se perguntou como é o suporte da Oracle??? Como eles são detentores do código fonte do Oracle, só eles podem lhe oferecer um contrato de suporte mais profundo. Pergunte a um DBA Oracle como é o suporte da Oracle e você irá se surpreender! Já no PostgreSQL você não encontra este problema, você pode escolher a empresa que vai lhe prestar suporte. Se você não gostou do suporte de uma empresa… chame outra! Está com medo de ninguém segurar o rojão quando um problema mais sério acontecer? Quem disse que a Oracle não vai lhe deixar na mão? Bom, quer conhecer o suporte da Oracle, saiba o que mais de 90% das pessoas conhecem por suporte é na verdade apenas o acesso ao Metalink. Mas suponhamos que você precise de algo um pouco específico mais onde o Oracle não lhe atende? Bom, o mais provável é que a Oracle lhe diga NÃO ou se você der sorte estará diante de um orçamento monstruoso. Se você precisar de algo diferente no PostgreSQL, você pode entrar em contato com qualquer um dos seus desenvolvedores (existem alguns no Brasil) e solicitar uma nova funcionalidade. Você vai pagar apenas as horas de desenvolvimento dele e se ele achar que a funcionalidade é importante, você provavelmente verá ela implementada na Próxima versão do PostgreSQL e nunca mais terá de se preocupar com isso. Acredite ou não, várias funcionalidades do PostgreSQL que você usa hoje, surgiram assim. Veja o exemplo dos SkyTools. Existem empresas menores que tem contratos de manutenção com desenvolvedores do PostgreSQL e utilizam versões modificadas com particularidades mais bizarras e funcionam sem problemas. Um detalhe… se você não gostar do desenvolvedor, você simplesmente contrata outro, uma vez que você não precisa estar amarrado a ele.
• Acesso aos desenvolvedores. Você já perguntou alguma coisa a um desenvolvedor do Oracle? No postgreSQL isso é tranquilo, basta entrar na lista de discussão dos desenvolvedores. Um exemplo de como isso pode ser útil é saber o que esperar das próximas versões. Todo o ciclo de desenvolvimento é transparente, você sabe o que será implementado na próxima versão, e o que estão querendo implementar nas próximas. Saber para onde o seu SGDB vai dá muita segurança para o DBA.
• Acesso aos paths de correção independente de pagar licenciamento. Todo mundo fica com o orçamento apertado durante algum tempo. Mas se você deixar de pagar o suporte da Oracle, prepare-se para ficar vulnerável. As atualizações só estão disponíveis para quem está com seus pagamentos em dia;
• Você não precisa fazer um curso sobre licenciamento antes de iniciar o uso do PostgreSQL. Independente do custo das licenças, saber quais recursos você vai precisar licenciar com a Oracle, é um verdadeiro tormento. A cada versão as opções de licenciamento mudam e um número maior de opções pagas separadamente são oferecidas. O Oracle Forms começou como uma ferramenta gratúita que numa nova versão passou a ser paga e hoje está sendo descontinuada. Muitos orçamentos estouram porquê no meio do projeto se descobre que uma funcionalidade importante não foi prevista no contrato de licenciamento. Isso quando você não instala opções não licenciadas sem querer. Para licenciar um Oracle, você deve começar lendo “Software Investment Guide” que é um documento de 61 páginas explicando quando uma licença se aplica ou não, dependendo da arquitetura de SGDB que você quer montar. Depois precisa conhecer a diferença entre as 5 versões básicas do Oracle: “Express Edition”, “Personal Edition”, “Standard Edition”, “Standard Edition One” e “Enterprise Edition”. Aí você vai ter que conhecer cada uma das 15 opções do Enterprise Edition que são licenciadas a parte e ver se você vai precisar de algumas delas no seu projeto. Depois disso você precisa conhecer as opções de licenciamento e definir a melhor métrica a ser utilizada: por processador ou por usuários nomeados. Pronto, agora é definir o número de licenças para a sua arquitetura dentro da métrica escolhida e multiplicar pelo custo da licença de cada componente que você vai comprar. Não esqueça de incluir no mínimo o suporte standard da Oracle que custa em média 20% do custo total das suas licenças ao ano. Este custo só lhe dá acesso ao metalink, que inclui uma base de conhecimento, acesso aos paths de correção e pedidos de suporte via web. Se você quiser um suporte de verdade, aquele que você acha que o PostgreSQL não tem então você vai ter que fazer um novo estudo de custos baseado no SLA desejado.
• Linux é Linux, não importa qual distribuição você utilize. O Oracle roda em qualquer distribuição Linux atual. Eu já utilizei por um bom tempo em Debian e fiquei muito satisfeito com o resultado. Mas se você deseja ter qualquer nível de suporte da Oracle, você só vai poder utilizar 3 ou 4 distribuições homologadas por eles (incluindo a versão da própria Oracle que é uma cópia do Red Hat). Isto não significa que estas são as melhores distribuições Linux do mercado (embora sejam muito boas). A questão é que você não pode escolher. Da mesma forma, não é qualquer hardware que você pode utilizar para para rodar o Oracle, tem que se um hardware homologado. Estes dias vi que a Oracle homologava algumas soluções de NFS fornecido por terceiros. Isto significava que se você comprasse uma solução de NFS de um dos parceiros homologados pela Oracle, eles lhe dariam suporte. Depois a Oracle desistiu da parceria e deixou de homologar estas soluções (pois ela lançou sua própria versão de NFS). Quem comprou a solução indicada pela Oracle simplesmente deixou de ter uma solução homologada, o que significa: nada de suporte para você.
• Poder publicar benchmarks! Você já viu um artigo com uma comparação entre desempenho do PostgreSQL e o Oracle? Não? E provavelmente não verá. A Oracle pode processar qualquer um que publique testes de desempenhos comparativos com o Oracle sem a sua autorização. Isto faz parte do licenciamento do Oracle. Assim é fácil dizer que é mais rápido sempre! Aliás, vou te dizer que o PostgreSQL pode ser utilizado em projetos que envolvam tecnologia militar, pode ser utilizado por cubanos e iraquianos, brasileiros, etc, etc, etc…

Há alguns tempos eu postei aqui sobre dois novos blogs falando sobre PostgreSQL, hoje vou comentar sobre alguns artigos que andei sapeando neste fim-de-semana sobre bancos de dados. Não são muitos, portanto eu aceito novas contribuições.

• Vantagens de um DBA é de um blog novo com foco principalmente em MySQL;
• Comparação entre o PostgreSQL 8.2 e o Firebird 2.0 ;
• </depesz> este cara está no PlanetPostgreSQL mas tem se destacado por escrever artigos muito interessantes, sobre PostgreSQL numa velocidade impressionante!
• Entrevista com Bruce Momjian, desenvolvedor do PostgreSQL, na Information Week;
• Stream de audio de entrevista com Josh Berkus, desenvolvedor do PostgreSQL, feita pelos entrevistadores Randal Schwartz and Leo Laporte;
• Outro blog novo sobre PostgreSQL, desta vez de um mexicano;
• El nuevo paradigma de las bases de datos, artigo do site espanhol siliconnews.es discutindo a estratégia da Oracle, Microsft e IBM frente ao avanço dos SGDBs livres;
• DB Runas, site argentino especializado em artigos sobre Bancos de Dados. Já publiquei alguns artigos por lá no ano passado. Parece que de uns tempos para cá alguém anda linkando meus artigos deste blog. Não sei quem é exatamente, mas quero agradecer o interesse e aproveitar para dizer que muitos dos links daqui eu encontrei acompanhando este site. Parabéns pelo trabalho pessoal.

Agora só para lembrar… 15/09/2007 será o Software Freedom Day!