andrelop’s blog

A importância da comunidade

Os acontecimentos relacionados ao acordo entre Microsoft e Novell que circularam nos últimos tempos geraram uma grande enxurrada de comentários contra e a favor e, em alguns casos mais extremos, manifestações de boicotes contra a Novell.

Não acho que seja correto assumir que a Novell é 100% vilã nessa história toda. Tudo bem que agora ela possa estar tomando um posicionamento que uma grande parcela da comunidade não aprova, mas devemos sempre lembrar que ela ao menos contribuiu bastante com inúmeros projetos de softwares livres/abertos no passado recente e isso deve ser respeitado.

O que a Novell parece estar fazendo agora, porém, é algo perigoso. O problema é que a Novell, mesmo tendo incorporado empresas nascidas 100% ligadas ao software livre/aberto, parece ainda não ter conseguido entender algo crucial para quem pretende atuar como um participante do ecosistema livre : respeitar a comunidade é essencial.

E, por comunidade, não estou dizendo aqui os clientes Novell que utilizam softwares livres/abertos, mas sim as pessoas, empresas, grupos de pessoas e todo o restante que realmente fazem com que essa roda toda continue girando, produzindo tecnologia e soluções de qualidade diariamente, em todos os cantos do mundo.

É crucial que quem quer que pretenda jogar esse jogo entenda que, com software livre/aberto, nenhuma solução que forneçamos aos nossos clientes será composta 100% de tecnologia que criamos nós mesmos, sem a ajuda de ninguém. Por mais bem acabada que sua “casca”, sua “cola”, sua “interface” ou suas melhorias sejam, sempre haverá código de inúmeras outras pessoas/grupos sendo utilizado em algum nível em sua solução baseada em software livre/aberto.

A comunidade é composta de talentos brilhantes, que compartilham suas idéias e código livremente, mas que exigem no mínimo respeito. Assumir que somente seus clientes merecem algum tipo de “vantagem” e que a comunidade não é merecedora da mesma “vantagem” e, ainda por cima, assumir isso publicamente (talvez não diretamente, mas por entrelinhas), é um exemplo perfeito de um tiro no pé.

Digo isso porque, nesse caso, você está desrespeitando seu fornecedor principal, a fonte de onde grande parte da tecnologia que você utiliza em suas soluções é retirada. Dinheiro é bom e todo mundo gosta, mas aceitá-lo para se posicionar contra os ideais do grupo ao qual você publicamente faz parecer fazer parte é, no mínimo, muito ingênuo : ganha-se a curto prazo, mas de médio a longo prazo você mata seu próprio negócio.

Vários membros da comunidade já se posicionaram em relação ao assunto e tornaram públicas suas opiniões, mas o que me fez escrever este post foi algo que acabei de ler e que me serviu de inspiração. Pode parecer evidente para nós, que já convivemos em comunidade há tanto tempo, mas ainda parece ser algo difícil de se compreender para a maioria das empresas, mesmo aquelas com experiência no assunto (vide Novell) : o que importa é a comunidade.

Tenha boas relações com a comunidade e você terá sucesso, desrespeite-a e você terá o que não pediu, algumas vezes da pior forma possível e em uma velocidade extremamente rápida. Eu não sou ninguém para dar conselhos e, devido a isso, dificilmente alguém me ouviria, mas acho importante que quem quer que queira participar da comunidade entenda como as regras funcionam.

Por isso, achei que seria uma boa contribuição ajudar traduzindo o post mais recente do Greg Kroah Hartman, importante kernel hacker há tempos profundamente envolvido com a comunidade, contribuíndo em várias frentes com código e tentando deixar claro para as empresas como são as regras de convivência em uma comunidade formada ao redor de projetos de softwares livres/abertos.

Senhores e senhoras, com vocês, Greg Kroah Hartman :

Todo o ecosistema Linux é bastante estranho para pessoas que estão acostumadas a maneira “tradicional” que as empresas funcionam. Aqui está um guia suscinto para iniciantes para aqueles que precisam de um lembrete.

Em uma empresa de tecnologia “tradicional”, você tem executivos tomando decisões estratégicas profundas, os gerentes seguindo essas decisões e dizendo aos engenheiros o que desenvolver (sim, existe marketing e vendas também, mas parece esse ensaio, vamos simplesmente ignorá-los por enquanto). Normalmente os executivos, os gerentes e os engenheiros estão focados em criar a “futura melhor solução” em sua área, e estão competindo diretamente com outras empresas de sua mesma área.

E isso funciona bem, todos estão acostumados a esse formato e grandes porções da economia mundial dependem deste modelo.

E então há o Linux.

E, por Linux, eu vou focar no kernel aqui, mas você pode extrapolar a idéia para qualquer outro componente do ecosistema de uma distribuição Linux também, pois todos funcionam praticamente da mesma maneira, de uma forma ou outra.

No Linux, as regras são diferentes, bem como a maneira que todo o ecosistema funciona.

Para o Linux, o “produto” é criado por engenheiros trabalhando na comunidade. Os membros da comunidade se reunem e trabalham para um projeto em comum, tornando-o o melhor que podem fazer. Esses engenheiros são um grupo bem grande, originados de um grande número de empresas e com experiências distintas.

Empresas entenderam que o Linux é algo bom para se usar e tentaram entender como ganhar dinheiro oferecendo-o como um sistema suportado semi-estável.

Essas empresas possuem executivos, gerentes e engenheiros, da mesma forma que uma empresa tradicional também os possui. Mas aqui é onde as coisas começam a funcionar de forma diferente. Esses executivos ainda tomam profundas decisões estratégicas, os gerentes trabalham para levar essas decisões em frente e dizem aos engenheiros o que desenvolver, mas os engenheiros tem que trabalhar com a comunidade para atingir seus objetivos. Esses engenheiros dependem da comunidade para serem capazes de criar algo que a empresa toda possa fornecer aos clientes e com o que possa ganhar dinheiro.

Devido a essa dependência da comunidade, as empresas tendem a serem divididas em duas grandes categorias (sim, existem mais categorias, mas, por enquanto, vamos simplificar as coisas) :

• empresas que ignoram a comunidade : Essas empresas meramente empacota seja lá o que for que a comunidade crie e vende isso. Assim, elas não possuem muita influência no produto e se tornam jogadores menores no mercado.
• empresas que abraçam a comunidade : Essas empresas contratam membros da comunidade ou permitem que seus funcionários entrem na comunidade, uma vez que elas entendem que essa é a única forma de possuem de guiar o Linux para direções que elas acreditam que ele deva seguir. Devido a isso, a empresa é capaz de oferecer soluções a seus clientes um pouco antes que as empresas na primeira categoria as oferecem e elas podem suportar seus clientes de forma muito melhor, uma vez que os membros da comunidade são capazes de auxiliá-los diretamente.

Empresas que se encaixam na primeira categoria podem agir da forma que desejarem, seus executivos podem fazer acordos com quem desejarem, elas podem tentar ser concorrentes diretos de outras empresas e ninguém na comunidade irá realmente se importar, uma vez que essas empresas são jogadores pequenos e não muito importantes.

Porém, empresas na segunda categoria devem se atentar a comunidade. Seus executivos não podem sair por aí fazendo coisas que não estejam nos melhores interesses da comunidade, seus gerentes não podem tentar competir diretamente com seus competidores e seus engenheiros não podem ignorar os desejos e opiniões da comunidade.

Caso alguma dessas coisas aconteça, a empresa logo será ignorada pela comunidade, forçada a implementar todas as grandes coisas que os executivos e os gerentes sonharam por si só e lentamente acabar se tornando uma empresa membro da primeira categoria, relegada a ser um jogador pequeno, uma vez que a comunidade e as empresas que são membros reais da comunidade as ultrapassam e seguem seu próprio caminho.

A história já está cheia de remanescentes de empresas que originalmente iniciaram abraçando a comunidade, mas então cometeram o erro de pensar, por algum razão, que eram empresas de tecnologia “tradicionais”.

Será interessante ver o quão bem as empresas atuais no ecosistema Linux realmente entendem o quão diferente seu ambiente de negócio realmente é.

Note que todas as idéias que você possa ter sobre qual empresa da mundo real se encaixa em qual categoria, ou porque este ensaio foi escrito em primeiro lugar é tudo algo que está em sua própria mente …

Perceba que, no início de seu ensaio, Greg diz : “Aqui está um guia suscinto para iniciantes para aqueles que precisam de um lembrete.” Eu creio que sua intenção foi tentar relembrar seu empregador que existem regras a serem respeitadas e quais são os riscos de não respeitá-las.

O último parágrafo é bastante irônico, já que o próprio autor do ensaio, além de ter as credencias já expostas anteriormente, também é um membro da comunidade sendo pago pela Novell para desenvolver projetos de software livre/aberto em comunidade, principalmente o kernel Linux.

Você tem alguma alguma dúvida de qual empresa faz parte da segunda categoria e porque o ensaio de Greg foi escrito ?

Aderindo ao Rec6

Conforme noticiado pelo BR-Linux, também estou aderindo ao Rec6, uma espécie de Digg nacional. Para isso, segui a dica para quem usa Wordpress no post do Bruno Alves apontado pelo BR-Linux e modifiquei os arquivos index.php e single.php dentro do diretório de meu tema (no meu caso, wp-content/themes/default, já que uso o tema padrão) e acrescentei o trecho de código para acrescentar o botão do Rec6 aos meus posts.

Agora, qualquer doido que por um desastre da natureza gostar do que escreve e quiser votar nos meus posts, fazendo com que os mesmos subam de posição no Rec6, ou ao menos apareçam por lá, é só clicar no botão Rec6 que aparecerá abaixo de cada um dos posts em meu blog.

Módulos de kernel binários e liberdade

Eu sei que não deveria estar escrevendo sobre isso sob pena de gerar infindáveis discussões e sei que o post que eu vou citar pode ser incluso como parte da guerra entre a Red Hat e a Novell que se iniciou após o acordo entre Novell e Microsoft vir a público, mas, deixando o fato de que ambas Red Hat e Novell estão cada uma tentando defender o seu peixe, é interessante citar o último post de Dave Jones, kernel hacker da Red Hat que mantém o kernel da distribuição Fedora.

Ele toca em um assunto importante, que é a liberdade, e critica o Ubuntu por aparentemente ter decidido incluir módulos binários por padrão no kernel da próxima versão do Ubuntu. Tente deixar de lado o fato que existe sim uma briga por trás dos bastidores e que, como funcionário da Red Hat, é improvável que ele defenderia as ações de um concorrente, mas tenha em mente que, antes de ser um funcionário da Red Hat, ele tem razão em relação a questão da liberdade.

Apesar de já ser algo bastante antigo, Dave foi astuto em notar um documento já antigo escrito por Arjan van de Ven há algum tempo atrás sobre módulos binários sendo incluídos no kernel Linux e os resultados futuros que isso poderia gerar.

Eu já havia lido esse documento na época que Arjan o tornou público, mas devido ao asunto parecer ter voltado à tona novamente e a pessoas já terem me perguntando várias vezes sobre drivers (módulos de kernel, na verdade) binários para Linux e porque os mesmos não são incluídos no kernel de uma vez para “facilitar” a vida dos usuários, resolvi traduzí-lo aqui.

É importante deixar claro que é uma tradução não oficial e feita de forma rápida e, como tal, pode conter erros. Conto com a ajuda de quem encontrá-los pra relatá-los e permitir que eu os corrija para tornar esse post o mais correto possível. Segue abaixo a tradução do documento do Arjan, antigo mais ainda bastante atual :

Linux em um mundo binário
=========================

O que aconteceria se … o que aconteceria se os desenvolvedores do kernel
Linux amanhã aceitassem que módulos de kernel binários estivessem OK e que os mesmos fossem essenciais para o progresso do Linux.

Um cenário hipotético do final dos tempos por Arjan van de Ven

A hipótese primária nesse cenário obviamente não vai acontecer, mas todas as hipóteses que a seguem são coisas que possuem uma base e que são verdadeiras em uma forma ou outra, mas é claro que nomes de “inocentes” foram omitidos.

Em 6 de Dezembro de 2005 os desenvolvedores do kernel decidem em massa que módulos binários são legalmente aceitos e também essenciais para o progresso do Linux e, dessa forma, são algo desejável. Em um primeiro momento, o processo de desenvolvimento do kernel Linux não muda muito além do fato de que alguns símbolos a mais são exportados, e o símbolo EXPORT_SYMBOL_GPL é removido.

Dentro de 3 semanas, distribuições como o Red Hat Linux Enterprise e o SuSE SLES começam a incluir uma ampla variedade de módulos binários em seus CDs de instalação. O Debian renuncia a isso e continua puro a sua causa, como o fazem outras distribuições abertas como o Fedora Core e o
openSuSE.

As distribuições corporativas (enterprise) só não incluem os módulos da nVidia e da ATI, mas incluem todos os módulos de distribuidores OEM de “fakeraid” (RAID falso, ou pseudo-RAID) e diversos módulos wireless, winmodem, winDSL e TCP-offloading. Porém, ao contrário da nVidia e da ATI, a maioria dos distribuidores de módulos binários não fornecem seus drivers em um formato de “camada de cola” (glue layer) : eles fornecem somente os binários finais.

Diversos distribuidores de hardware que foram amigáveis ao movimento de código aberto até então vêem seus competidores fornecer somente drivers binários e internamente começam a sofrer pressão para também manter sua propriedade intelectual (IP) privada e eles sabem que não usaram alguns recursos de seu hardware porque seus departamentos legais não queriam sua propriedade intelectual se tornando pública.

Como resultado eles acham que os drivers binários de seus competidores estão em vantagem teórica, ou que pelo menos seus próprios drivers poderiam estar em vantagem caso eles também fossem fechados, porque nesse caso eles poderiam utilizat aqueles outros recursos extras para
se manter a frente de seus competidores.

Em Fevereiro de 2006, por volta da metade dos distribuidores de hardware refocaram seus esforços internos para drivers Linux para criar valor agregado em drivers binários que lançarão além dos drivers abertos que já existem. Alguns distribuidores até mesmo pararam de suportar seus drivers abertos porque não possuem recursos suficientes para fazê-lo.

1 de Março. Todas as ntícias dos maiores distribuidores de hardware saem com a próxima geração de hardware de armazenamento e rede. Esse hardware é distribuído com drivers binários para as últimas 2 versões das distribuições RHEL e SLES e esses drivers já estão integrados nas atualizações de Fevereiro dessas distribuições

Um desses distribuidores de hardware lançam seu driver em um formato .o mais um formato de camada de cola, os outros não se importam e lançam somente versões binárias para essas duas distribuições. Dois dos fabricantes de placas de rede lançam uma atualização para seus drivers de código aberto para suportar minimamente as novas placas, os outros nem isso o fazem. Hardware destinado ao público em geral não é amplamente afetado : a maioria dos chipsets destinados ao público em geral padronizaram em AHCI para armazenamento SATA e mantiveram o conjunto de recursos existente em chipsets de rede.

1 de Abril. 2 dos fabricantes de chipsets destinado ao consumo geral atualizam seus chipsets para que os mesmos incluam novos e excitantes recursos de áudio que oferecem reprodução de DVD melhorada, mas infelizmente isso os levou a desviar da interface de hardware de áudio i810 ‘padrão’. Um deles lança um driver binário para algumas distribuições e o outro não considerou o Linux relevante para o desktop e ainda não se preocupou em desenvolver um driver para Linux.

1 de Maio. Todo hardware para servidores que você pode comprar requer pelo menos um, mas normalmente 2 ou 3 módulos binários para funcionar. Apesar de alguns desses módulos estarem disponíveis no formato BLOB+cola, diversos estão somente disponíveis para RHEL3, RHEL4 e SLES9 e em alguns casos o recém-lançado SLES10.

Usuários Linux terão a sua escolha 4 kernels para esses servidores ao mesmo tempo, mas nenhuma esperança de poder usar um kernel oficial do kernel.org nesses servidores. O pessoal do Ubuntu está bem desapontado e trabalhando duro, com sucesso variado, conseguir disponibilizar drivers para sua
distribuição. Devido ao sucesso desse lobby, por volta de 50% desses servidores tambpem podem ser usados com o kernel do Ubuntu.

1 de Junho. Uma grande discussão (flamewar), a quarta sobre esse assunto desde Janeiro, acontece na lista de discussão linux-kernel. Usuários e alguns desenvolvedores estão querendo que o kernel do site kernel.org adote a ABI de módulos do RHEL ou do SLES. Investigações mostram que isso não é possível, e a discussão se torna uma discussão sobre o design de uma nova ABI versus congelar a ABI existente.

Muitos desenvolvdores do kernel acham que que a ABI ad-hoc existente não é adequada para congelamente e que uma nova ABI e uma nova API, criada para que possam ser tornadas estáveis de forma mais fácil é o caminho certo a ser seguido, enquanto outros dizem que isso iria requerer muito tempo e que isso não ajudaria pelos próximos 2 anos até que o RHEL e o SLES tenham adotado essa ABI, e pelo menos demandaria um congelamento imediato da ABI do kernel do site kernel.org de forma que o futuro RHEL5 talvez a utilizasse, o que levaria a drivers serem desenvolvidos para a mesma. Usuários normalmente usam o RHEL ou o SLES para servidores de produção e clones como o CentOS, que lançaram kernels compatíveis binariamente.

1 de Julho. É crescemente difícil rodar Linux sem módulos binários na maioria do novos PCs destinados ao público em geral. Enquanto que um ano atrás as pessoas teriam que abdicar da aceleração 3D para isso rotineiramente, agora até mesmo suporte a 2D não funciona sem drivers
binários, nem rede (ambos rede cabeada e wireless) ou som. Para metade das máquinas não existe suporte a Linux disponível de forma geral, enquanto 20% utilizam camadas de tradução como o ndiswrapper para rodar os drivers de som e rede do Windows.

O Debian, incapaz de rodar na maioria das máquinas atuais, está perdendo quantidades massivas de usuários para o Ubuntu e os híbridos Ubuntu-Debian. A lista de discussão debian-legal e outras listas do projeto Debian são impossíveis de serem lidas por pessoas não interessadas nesse tópico
inflamatório em particular. A maioria dos distribuidores que mantinham seus drivers de código aberto ao menos parcialmente atualizados pararam de fazê-lo.

14 de Julho. Linus declara a ABI do kernel estável mas também inicia a série 2.7 do kernel e declara que o kernel 2.8 terá uma ABI diferente. Na prática, somente pessoas que mantiveram suas máquinas antigas podem ajudar o desenvolvimento da série 2.7, uma vez que nenhum dos distribuidores
de drivers, nem mesmo aqueles que ainda possuem uma construção BLOB+cola, se importa com a árvore de desenvolvimento que se move de ‘muito rápida’.

21 de Agosto. Uma série falha de segurança é encontrada na série 2.6, que finalmente se dscobre ser uma falha de design em uma API sysfs chave. Corrigir essa falha iria requerer que a ABI de módulos e que praticamente todos os módulos fossem quebrados, e não corrigir essa falha deixaria uma falha que poderia ser explorada com privilégios de root aberta.

Uma correção rápida é disponibilizada sob a forma de uma opção CONFIG_ no kernel, mas usuários que precisam de drivers binários não tem outra escolha a não ser deixar seus sistemas vulneráveis. Diversas discussões na lista linux-kernel aparecem novamente, dizendo que Linus cometeu um
erro em congelar a ABI ao invés de criar uma nova desenhada para ser congelada. O desenvolvimento da série 2.7 estagnou quase que totalmente e um patch para que a série 2.7 utilize a ABI da série 2.6 novamente é proposto, revertendo diversas melhorias em subistemas chave de memória
virtual e os patches de tempo-real do Ingo.

26 de Agosto. Um exploit pré-deenvolvido para a falha de segurança aparece na lista de discussão bugtraq e o mesmo passa a atuar sendo usado por diversos rootkits. Um exploit PHP utiliza-o para se tornar root a partir do usuário httpd. Usuários estão colocando pressão nos distribuidores de
módulos para que os mesmos lancem módulos para a nova ABI e diversos deles na verdade fazem isso nas três semanas que se seguem. Outros, a maioria no mercado do público em geral, dizem que o hardware em questão não é mais vendido e que eles não vão mais gastar tempo algum em esforços para escrever drivers para o mesmo.

Esse cenário pode parecer irreal para você. E, felizmente, é improvável que a hipótese principal (o evento de 6 de Dezembro) aconteça.

Porém, e isso infelizmente, diversos outros “saltos” não são assim tão improváveis. De fato, alguns dos resultados provavelmente acontecerão independente do evento inicial : observe as discussões acaloradas na lista de discussão linux-kernel sobre quebrar a API/ABI de módulos.

Observe o efeito do ndiswrapper em distribuidores que agora dizem “nós suportamos o Linux porque o ndiswrapper pode usar nosso driver Windows.” Eu espero que nada disso aconteça. Algumas dessas esperanças serão esperanças perdidas, mas eu acredito que as vantagens da liberdade no final são fortes o bastante para suplantar as forças opostas.

Ok, acho que minha posição sobre o assunto é bem clara a esse ponto

Microsoft e Novell

Não preciso dizer nada sobre o caso, já disseram por mim

Tradução pt_BR das Release Notes do Debian Etch

O anúncio do início do trabalho no Release Notes para o Etch saiu. Hoje segui as instruções na mensagem do anúncio e fiz o checkout do que existe no CVS do debian-doc no momento. O bom é que o Release Notes do Sarge foi utilizado como base e, por isso, não é algo que tenha que ser traduzido do zero.

A tradução para Português do Brasil estava na versão 1.20, mas após essa versão, a versão original em Inglês foi sendo atualizada e hoje está na versão 1.74 (lógico, a versão vai ir aumentando a medida que novo conteúdo for acrescentado). Relembrei um pouco os velhos tempos e, depois de tanto lidar com Subversion, lembrei a sintaxe CVS para conseguir um diff da versão 1.20 para a versão 1.74 do original em inglês.

Os comandos que usei para conseguir o diff foram :

export CVSROOT=”:pserver:anonymous@cvs.debian.org:/cvs/debian-doc”

cvs co ddp/manuals.sgml/release-notes/

cvs diff -uN -r 1.20 -r 1.74 ddp/manuals.sgml/release-notes/en/release-notes.en.sgml > release-notes.en.sgml.patch

Após isso, é só conferir o arquivo release-notes.en.sgml.patch gerado e, com base nele, ir atualizando a tradução local no arquivo ddp/manuals.sgml/release-notes/pt_BR/release-notes-.pt_BR.sgml . Já foi possível ver que tenho bastante trabalho pela frente.

Vou ver se consigo trabalhar nisso nos próximos dias e, caso a situação fique preocupante (leia-se : eu chegue a conclusão de que não vou conseguir dar conta de tudo a tempo), entro em contato com a lista debian-l10n-portuguese e peço ajuda ao pessoal por lá para que consigamos coordenar um trabalho em equipe para colocar nossa tradução em dia.

Quem quiser começar a ajudar desde já, esteja a vontade para começar o trabalho, mas, antes de mais nada, anuncie suas intenções na lista debian-l10n-portuguese para que não exista o risco de duas pessoas trabalharem no mesmo projeto e fatalmente o trabalho de pelo menos um seja perdido.

Eu leio diariamente a lista e, portanto, não há necessidade de entrar em contato diretamente comigo, sem contar que o local correto para discussões de assuntos relacionados a tradução e internacionalização para nosso idioma é a lista debian-l10n-portuguese.

mutt and offlineimap to the rescue

Como eu havia comentado em um post anterior, eu havia mudado de cliente de e-mail padrão, do mutt para o Thunderbird (agora IceDove, ao menos no Debian), principalmente porque, ao menos no Debian, o Thunderbird já vinha com o patch que permitia que a funcionalidade de Reply-To-List fosse acrescentada somente com a instalação de uma extensão (plugin).

Essa funcionalidade (além de muitas outras) era algo que o mutt me oferecia e à qual eu já estava extremamente acostumado. Algo de que eu realmente não poderia abrir mão. Usei o Thunderbird durante alguns meses, mas estava sentindo falta de algo que me permitisse ter a mesma visão de minha caixa-postal, incluíndo pastas, mensagens removidas, respondidas, encaminhadas, lidas, etc, usando mais de um cliente de e-mail.

Eu geralmente usava o Thunderbird em casa e, quando estava fora e sem notebook, usava o Webmail. Poderia resolver meu problema sempre usando o Webmail, mas, francamente, prefiro recorrer a ele somente em último caso, visto que considero Webmails bastante limitados em termos de funcionalidades se comparados a clientes de e-mail habituais.

Passei a utilizar IMAP (na verdade, IMAPS), o que me permitiu ter a mesma visão de minha caixa-postal tanto pelo Thunderbird quanto pelo Webmail. Porém, depois de algum tempo, comecei a notar que o Thunderbird estava se tornando muito lento. Na verdade, a medida que a quantidade de mensagens a serem gerenciadas aumentava, ele ficava mais lento e parecia consumir mais memória e processador, mesmo com as tradicionais faxinas removendo mensagens antigas e não mais necessárias.

Sem contar que tive alguns problemas com o Thunderbird que me fizeram perder várias mensagens importantes, o que me fez ter que entrar em contato com diversas pessoas pedindo para que as mesmas reenviassem suas mensagens, algo não muito bonito de se fazer, acreditem. Tudo bem, parte disso foi bobeira minha, mas mesmo assim isso me deixou com a pulga atrás da orelha com relação ao Thunderbird, algo que nunca havia acontecido em todo o tempo que usei o mutt.

Hoje, feriado, um pouco de tempo livre, comecei a tentar a usar o mutt via IMAPS e, após acertar algumas configurações em um dos perfis que criei para isso, tudo passou a funcionar como eu queria. Lógico, por se tratar de manipulação remotas das pastas, é algo um pouco lento, mas extremamente mais rápido do que o Thunderbird, sem contar que o consumo de memória e processador nem se compara : quase nada em relação ao Thunderbird. Minha máquina de uma forma geral ficou bem mais utilizável.

Outra coisa que eu queria fazer, independente de cliente de e-mail, é uma solução que me permitisse ler minhas mensagens desconectado (em modo offline), mas sem que para isso tivesse problemas com a sincronização do estado das mensagens e outros detalhes com o servidor IMAP. O modo offline do Thunderbird não me parecia tão eficiente.

Passei a usar o offlineimap (pacote Debian de mesmo nome), que me permite fazer sincronização bidirecional de minhas pastas de mensagens da minha estação com o servidor IMAP. Agora, se eu acrescento, removo, respondo, movo ou faço qualquer outra operação com mensagens, o offlineimap sincroniza essas operações de e para o servidor IMAP, de forma bastante rápida, em questão de segundos, e de forma segura, via SSL.

Já criei um alias de nome sync-mail, que dispara o offlineimap, onde forneço minha senha (que trafega de modo seguro entre minha máquina e o servidor IMAP) e tenho todo o conteúdo de minhas pastas sincronizado de forma rápida e fácil. Deste ponto em diante, é śo usar o mutt localmente, apontando com fonte a estrutura Maildir criada pelo offlineimap. Agora sim, a coisa toda está um avião de tão rápido e eu tenho acesso a todas as funcionalidades interessantes do mutt que não conseguiria encontrar em nenhum outro cliente de e-mail.

Ah ! O autor do offlineimap é um desenvolvedor Debian. Ele desenvolve o software e também mantém o pacote Debian dele