Escrevendo scripts de backup

Durante a década de 70, vários utilitários foram desenvolvidos para fazer backup de arquivos armazenados em servidores Linux. Os computadores da época eram muito limitados, por isso os utilitários precisavam ser simples e eficientes, e deveriam existir meios de agendar os backups para horários de pouco uso das máquinas.

Sugiram então utilitários como o tar e o gzip e mais tarde ferramentas como o rsync. Estes utilitários eram tão eficientes que continuaram sendo usados ao longo do tempo. Por incrível que possa parecer, são usados sem grandes modificações até os dias hoje.

Naturalmente, existem muitos utilitários amigáveis de backup, como o Amanda (para servidores) e o Konserve (um utilitário mais simples, voltado para usuários domésticos). Mas, internamente, eles continuam utilizando como base o o dump, tar, gzip e outros trigenários.

Mais incrível ainda, é que estes utilitários possuem uma penetração relativamente pequena. A maior parte dos backups ainda é feita através de scripts personalizados, escritos pelo próprio administrador. E, novamente, estes scripts utilizam o tar, gzip, rsync e outros.

É justamente sobre estes scripts personalizados que vou falar aqui. Vamos começar com alguns exemplos simples:

Para compactar o conteúdo de uma pasta, usamos o tar combinado com o gzip ou bzip2. O tar agrupa os arquivos e o gzip os compacta. Os arquivos compactados com o gzip usam por padrão a extensão "tar.gz", enquanto os compactados com o bzip2 usam a extensão "tar.bz2". O bzip2 é mais eficiente, chega a obter 10% ou mais de compressão adicional, mas em compensação é bem mais pesado: demora cerca de 3 vezes mais para compactar os mesmos arquivos. Você escolhe entre um e outro de acordo com a tarefa.

O comando para compactar uma parta é similar ao "tar -zxvf" que usamos para descompactar arquivos. Para compactar a pasta "arquivos/", criando o arquivo "arquivos.tar.gz", o comando seria:

$ tar -zcvf arquivos.tar.gz arquivos/

O "c" indica que o tar deve criar um novo arquivo e o "v" faz com que exiba informações na tela enquanto trabalha. Se preferir comprimir em bz2, muda apenas a primeira letra; ao invés de "z" usamos "j":

$ tar -jcvf arquivos.tar.bz2 arquivos/

Estes comandos seriam ideais para fazer um backup completo, de uma ou várias pastas do sistema, gerando um arquivo compactado que poderia ser armazenado num HD externo, gravado num DVD ou mesmo transferido via rede para outro servidor.

Imagine agora um outro cenário, onde você precisa fazer backup dos arquivos de uma pasta de trabalho diariamente. Os arquivos gerados não são muito grandes e você tem muito espaço disponível, mas é necessário que os backups diários feitos em arquivos separados e sejam guardados por um certo período, de forma que seja possível recuperar um arquivo qualquer a partir da data.

Ao invés de ficar renomeando os arquivos, você poderia usar um pequeno script para que os arquivos fossem gerados já com a data e hora incluída no nome do arquivo:

DATA=`date +%Y-%m-%d-%H.%M.%S`
cd /mnt/backup
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/

A primeira linha do script cria uma variável "DATA", contendo o resultado do comando "date +%Y-%m-%d-%H.%M.%S". O comando date retorna a data e hora atual, como em "Sex Set 16 12:36:06 BRST 2005". A saída padrão dele não é muito adequada para usar em nomes de arquivos, por isso usamos as opções para alterar o formato de saída, de modo que o resultado seja "2005-09-16-12.37" (ano, mês, dia, hora, minuto, segundo). Usamos este valor no nome do arquivo com o backup, de forma que, cada vez que você chame o script, seja gerado um arquivo com a data e hora em que foi gerado, sem a possibilidade de dois arquivos saírem com o mesmo nome.

O próximo passo é fazer com que este script de backup seja executado diariamente de forma automática, o que pode ser feito usando o cron.

Em primeiro lugar, salve os comandos num arquivo de texto, que vamos chamar de "backup.sh" e transforme-o num executável usando o comando "chmod +x backup.sh".

Para que ele seja executado automaticamente todos os dias, copie-o para dentro da pasta "/etc/cron.daily" e certifique-se de que o serviço "cron" esteja ativo:

# cp -a backup-sh /etc/cron.daily
# /etc/init.d/cron start

Se preferir que o script seja executado apenas uma vez por semana, ou mesmo uma vez por hora, use as pastas "/etc/cron.weekly" ou a "/etc/cron.hourly". Por padrão, os scripts dentro da pasta "/etc/cron.daily" são executados pouco depois das 6 da manhã (o horário exato varia de acordo com a distribuição). Para alterar o horário, edite o arquivo "/etc/crontab", alterando a linha:

25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

O "25 6" indica o minuto e a hora. Se quiser que o script seja executado às 11 da noite, por exemplo, mude para "00 23".

Neste exemplo usei a pasta "/mnt/backup" para salvar os arquivos. Esta pasta pode ser o ponto de montagem de um HD externo ou de um compartilhamento de rede por exemplo. O seu script pode conter os comandos necessários para montar e desmontar a pasta automaticamente.

Imagine, por exemplo, que o backup é sempre feito na primeira partição de um HD externo, ligado na porta USB, que é sempre detectada pelo sistema como "/dev/sda1". O script deve ser capaz de montar a partição, gravar o arquivo de backup e depois desmontá-la. Se por acaso o HD não estiver plugado, o script deve abortar o procedimento. Para isso precisamos verificar se o HD realmente foi montado depois de executar o comando "mount /dev/sda1 /mnt/sda1". Existem muitas formas de fazer isso, uma simples é simplesmente filtrar a saída do comando "mount" (que mostra todos os dispositivos montados) usando o grep para ver se o "/mnt/sda1" aparece na lista. Se não estiver, o script termina, caso esteja, ele continua, executando os comandos de backup:

mount /dev/sda1 /mnt/sda1
montado=`mount | grep /mnt/sda1`

if [ -z "$montado" ]; then
exit 1
else
DATA=`date +%Y-%m-%d-%H.%M`
cd /mnt/backup
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
umount /mnt/sda1
fi

A partir daí, sempre que você deixar o HD externo plugado no final do expediente, o backup é feito e estará pronto no outro dia. Se esquecer de plugar o HD num dia, o script percebe e não faz nada.

Se preferir que o script grave o backup num DVD, ao invés de simplesmente salvar numa pasta, você pode usar o "growisofs" para gravá-lo no DVD. Neste caso, vamos gerar o arquivo numa pasta temporária e deletá-lo depois da gravação:

DATA=`date +%Y-%m-%d-%H.%M`
rm -rf /tmp/backup; mkdir /tmp/backup; cd /tmp/backup
tar -zcvf trabalho-"$DATA".tar.gz /mnt/hda6/trabalho/
growisofs -speed=2 -Z /dev/dvd -R -J /tmp/backup/trabalho-"$DATA".tar.gz
rm -rf /tmp/backup

O "-speed=2" permite que você especifique a velocidade de gravação do DVD, enquanto o "-Z" cria uma nova seção. É possível usar o mesmo disco para gravar vários backups (se o espaço permitir) usando a opção "-M" a partir da segunda gravação, que adiciona novas seções no DVD, até que o espaço se acabe.

O "/dev/dvd" indica o dispositivo do drive de DVD. A maioria das distribuições cria o link /dev/dvd apontando para o dispositivo correto, mas, em caso de problemas, você pode indicar diretamente o dispositivo correto, como, por exemplo, "/dev/hdc". As opções "-R -J" adicionam suporte às extensões RockRidge e Joilet.

Se o cron for configurado para executar o script todos os dias, você só precisará se preocupar em deixar o DVD no drive antes de sair.

Se preferir fazer os backups em CDR ("em que século você vive?" ;), crie uma imagem ISO usando o mkisofs e em seguida grave-a no CD usando o cdrecord, como em:

mkisofs -r -J -o trabalho.iso /tmp/backup/trabalho-"$DATA".tar.gz
cdrecord dev=/dev/hdc trabalho.iso

Este comando do cdrecord funciona em distribuições recentes, que utilizam o Kernel 2.6 em diante (com o módulo ide-cd). No Kernel 2.4, era usada emulação SCSI para acessar o gravador de CD, fazendo com que ele fosse visto e acessado pelo sistema como se fosse um gravador SCSI. Neste caso, o comando de gravação seria "cdrecord dev=0,0,0 -data trabalho.iso", onde o "0,0,0" é o dispositivo do gravador, que você descobre através do comando "cdrecord -scanbus".

Outro grande aliado na hora de programar backups é o rsync. Ele permite sincronizar o conteúdo de duas pastas, transferindo apenas as modificações. Ele não trabalha apenas comparando arquivo por arquivo, mas também comparando o conteúdo de cada um. Se apenas uma pequena parte do arquivo foi alterada, o rsync transferirá apenas ela, sem copiar novamente todo o arquivo.

Ele é uma forma simples de fazer backups incrementais, de grandes quantidades de arquivos, ou mesmo partições inteiras, mantendo uma única cópia atualizada de tudo num HD externo ou num servidor remoto. Este backup incremental pode ser atualizado todo dia e complementado por um backup completo (para o caso de um desastre acontecer), feito uma vez por semana ou uma vez por mês.

Para instalar o rsync, procure pelo pacote "rsync" no gerenciador de pacotes. No Debian instale com um "apt-get install rsync" e no Mandriva com um "urpmi rsync".

Para fazer um backup local, basta informar a pasta de origem e a pasta de destino, para onde os arquivos serão copiados:

$ rsync -av /mnt/hda6/trabalho /mnt/backup/

A opção "-a" (archive) faz com que todas as permissões e atributos dos arquivos sejam mantidos, da mesma forma que ao criar os arquivos com o tar e o "v" (verbose) mostra o progresso na tela.

A cópia inicial vai demorar um pouco, mais do que demoraria uma cópia simples dos arquivos. Mas, a partir da segunda vez, a operação será muito mais rápida.

Note que neste comando estamos copiando a pasta "trabalho" recursivamente para dentro da "/mnt/backup", de forma que seja criada a pasta "/mnt/backup/trabalho". Adicionando uma barra, como em "/mnt/hda6/trabalho/", o rsync copiaria o conteúdo interno da pasta diretamente para dentro da "/mnt/backup".

Se algum desastre acontecer e você precisar recuperar os dados, basta inverter a ordem das pastas no comando, como em:

$ rsync -av /mnt/backup/trabalho /mnt/hda6/trabalho/

O rsync pode ser também usado remotamente. Originalmente ele não utiliza nenhum tipo de criptografia, o que faz com que ele não seja muito adequado para backups via internet. Mas este problema pode ser resolvido com a ajuda do SSH, que pode ser utilizado como meio de transporte. Não é à toa que o SSH é chamado de canivete suíço, ele realmente faz de tudo.

Neste caso o comando ficaria um pouco mais complexo:

$ rsync -av --rsh="ssh -C -l tux" /mnt/hda6/trabalho \
tux@192.168.0.1:/mnt/backup/

Veja que foi adicionado um parâmetro adicional, o --rsh="ssh -C -l tux", que orienta o rsync a utilizar o SSH como meio de transporte. O "-C" orienta o SSH a comprimir todos os dados (economizando banda da rede) e a se conectar ao servidor remoto usando o login tux (-l tux). Naturalmente, para que o comando funcione, é preciso que o servidor esteja com o SSH habilitado, e você tenha um login de acesso.

Em seguida vem a pasta local com os arquivos, o endereço IP (ou domínio) do servidor e a pasta (do servidor) para onde vão os arquivos.

Uma observação é que usando apenas os parâmetros "-av", o rsync apenas atualiza e grava novos arquivos na pasta do servidor, sem remover arquivos que tenham sido deletados na pasta local. Por um lado isto é bom, pois permite recuperar arquivos deletados acidentalmente, mas por outro pode causar confusão. Se você preferir que os arquivos que não existem mais sejam deletados, adicione o parâmetro "--delete", como em:

$ rsync -av --delete --rsh="ssh -C -l tux" /mnt/hda6/trabalho \
tux@192.168.0.1:/mnt/backup/

Para recuperar o backup, basta novamente inverter a ordem do comando, como em:

$ rsync -av --rsh="ssh -C -l tux" tux@192.168.0.1:/mnt/backup/ \
/mnt/hda6/trabalho

Originalmente, você vai precisar fornecer a senha de acesso ao servidor cada vez que executar o comando. Ao usar o comando dentro do script de backup, você pode gerar uma chave de autenticação, tornando o login automático. Esta opção é menos segura, pois caso alguém consiga copiar a chave (o arquivo .ssh/id_rsa dentro no home do usuário), poderá ganhar acesso ao servidor.

De qualquer forma, para usar este recurso, rode o comando "ssh-keygen -t rsa" (que gera a chave de autenticação) usando o login do usuário que executará o script de backup, deixando a passprase em branco. Em seguida, copie-o para o servidor, usando o comando:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub tux@192.168.0.1

A partir daí, o script de backup pode ser executado diretamente, através do cron, pois não será mais solicitada a senha.

DOZE CONSELHOS PARA TER UM INFARTO FELIZ

Não resisti, e tive de postar esses ótimos conselhos. Sinto por fugir do foco do meu blog, mas é muito interessante.

Se segur a risca, será bem sucedido.
Espero que gostem :-)

1.Cuide de seu trabalho antes de tudo. As necessidades pessoais e familiares são secundárias.

2.Trabalhe aos sábados o dia inteiro e, se puder também aos domingos.

3.Se não puder permanecer no escritório à noite, leve trabalho para casa e trabalhe até tarde.

4.Ao invés de dizer não, diga sempre sim a tudo que lhe solicitarem.

5.Procure fazer parte de todas as comissões, comitês, diretorias, conselhos e aceite todos os convites para conferências, seminários, encontros, reuniões, simpósios etc.

6.Não se dê ao luxo de um café da manhã ou uma refeição tranqüila. Pelo contrário, não perca tempo e aproveite o horário das refeições para fechar negócios ou fazer reuniões importantes.

7.Não perca tempo fazendo ginástica, nadando, pescando, jogando bola ou tênis. Afinal, tempo é dinheiro.

8.Nunca tire férias, você não precisa disso. Lembre-se que você é de ferro. (e ferro , enferruja!!. .rs)

9.Centralize todo o trabalho em você, controle e examine tudo para ver se nada está errado. Delegar é pura bobagem; é tudo com você mesmo. Só vc sabe fazer.

10.Se sentir que está perdendo o ritmo, o fôlego e pintar aquela dor de estômago, tome logo estimulantes, energéticos e anti-ácidos. Eles vão te deixar tinindo.

11.Se tiver dificuldades em dormir não perca tempo: tome calmantes e sedativos de todos os tipos. Agem rápido e são baratos.

12.E por último, o mais importante: não se permita ter momentos de oração, meditação, audição de uma boa música e reflexão sobre sua vida. Isto é para crédulos, tolos sensíveis e para aqueles que querem apenas vida longa e saudável.

Repita para si: Eu não perco tempo com essas bobagens.

Entrevista com Linus Torvalds, criador do Linux

Como muitos leitores do DistroWatch Weekly devem saber, recentemente eu passei uma semana na Linux.conf.au em Hobart, na Austrália. Essa popular conferência anual atrai vários grandes nomes do mundo do código livre, incluindo Linus Torvalds (foto à direita), arquiteto-chefe e criador do kernel Linux. Em 1991, enquanto cursava a universidade de Helsinque, Linus lançou a primeira versão do kernel que batizara originalmente de 'Freax' - um jogo de palavras com 'Free' (gratuito/livre) e 'Unix'. "Estou fazendo um sistema operacional (gratuito/livre) (só por hobby, nada profissional como o GNU) para clones de ATs 386 (486)... Ele NÃO é portável (usa a troca de tarefas do 386), e provavelmente nunca suportará nada além de discos rígidos AT, e isso é tudo o que eu tenho :-(", escreveu Linux ao newsgroup comp.os.minix. Ironicamente, quase vinte anos depois, o Linux suporta mais hardware em sua configuração padrão do que qualquer outro sistema operacional, e é a espinha dorsal de muitos gigantes corporativos como o Google e a Amazon.

Na LCA deste ano eu tive o privilégio de encontrar Linus e bater um papo com ele. Dentre outras coisas, ele confirmou que 'aquele blog' é dele mesmo, e aceitou responder a algumas perguntas para os leitores do DistroWatch.

DW: Linus, muito obrigado por arranjar tempo em sua agenda lotada para conversar conosco. Ficamos muito agradecidos! Tenho certeza de que muitos de nossos leitores estão interessados em saber qual distribuição Linux você usa, e o motivo. Do que você gosta nela e o que precisa ser melhorado? Você usa a mesma distribuição nas máquinas de trabalho e de lazer?

LT: Como eu só "uso" mesmo um grupo bem limitado de programas, escolho distribuições de maneira bem arbitrária. Minha principal exigência é que a distribuição seja bem fácil de instalar e manter atualizada, para que eu possa ignorá-la na maior parte do tempo.

E a parte de "manter atualizada" realmente quer dizer que eu quero que a distro esteja atualizada e que seja bem abrangente (incluindo a facilidade de instalação de Flash, MP3 e outros plugins); do contrário, ela acabaria me fazendo ter trabalho baixando e compilando componentes com os quais eu nem me importo muito.

E sim, quero usar a mesma distribuição em todas as minhas máquinas, incluindo as dos meus filhos e da esposa, pelos mesmos motivos: eu me importo com o kernel (e com pouquíssimos programas), do resto eu quero que a distribuição cuide para mim.

Eis um exemplo dos pequenos detalhes que eu quero que a distribuição cuide para mim regularmente: comprei uma câmera DSLR mais moderna, já que nossa antiga já estava defasada em três gerações. Por isso, eu espero que a distro tenha suporte ao formato RAW, que ele seja recente e que suporte a última geração do [programa] UFRaw. E mais uma vez, se isso não acontecer, a distribuição não tem nenhuma utilidade para mim.

Ao mesmo tempo, eu quero ter a sensação de que a distribuição não é só um apanhado aleatório de programas novíssimos extraídos de uma espécie de 'repositório SVN aleatório do mês'. Errar é humano, mas quero sentir que a distribuição tenta se manter atualizada sem fazer coisas totalmente alucinadas.

O resultado disso é que eu quero uma das distribuições com comunidades "grandes o suficiente" e que eu possa baixar, instalar e atualizar pela internet de maneira trivial; que seja proativa, mas não doida, no que tange às atualizações. Isso praticamente restringe minhas opções ao openSUSE e ao Fedora, com o Ubuntu possivelmente em terceiro lugar.

E nos últimos anos, tenho usado o Fedora.

DW: Já que o Fedora abandonou o suporte ao KDE 3.x recentemente, que desktop você está usando? Você migrou para o KDE 4.x, ou posso ousar dizer que escolheu o GNOME? Se for o caso, como foi a transição?

LT: Como uso o Fedora, fui afetado pela (má) transição para o KDE4, e por isso venho usando o GNOME desde o ano passado. Isso ainda é um martírio, principalmente quando estou no laptop, pelo mesmo motivo de sempre: no GNOME não dá para ajustar os botões do mouse (isso é pior para mim em laptops porque na maioria das vezes eles só tem dois botões, e fica bem mais difícil pressionar o botão do meio, usado para a ação de 'enviar para o fundo' uma janela).

Eu escrevi o patch (incluindo a ferramenta gráfica de gerenciamento), enviei-o e ele foi rejeitado por seu "muito complicado para os usuários". Bando de idiotas (e não estou me referindo aos supostos usuários).

Mas atualmente, o KDE é pior. Eu gostaria de explorar alternativas, mas se você acompanhou minhas respostas até agora e é observador já deve ter percebido que os programas envolvidos não estão na lista de coisas com as quais eu me preocupo tanto assim.

Tenho fama de não gostar do GNOME, mas o que eu não gosto não é bem de usá-lo, mas sim da aparente mentalidade da equipe do GNOME, achando que todos os usuários são idiotas, limitando o que posso fazer com o desktop por causa disso.

Entende a diferença?

Logo, eu uso o que quer que funcione melhor na minha máquina e no meu fluxo de trabalho, e o gerenciador de janelas não é algo profundamente importante para mim.

DW: O lançamento do Eee PC apresentou o Linux a um grupo mais amplo de consumidores comuns. O que você acha de ter o Linux rodando nos sistemas desses consumidores, e você acha que isso vai ajudar o Linux a ganhar mais pique no desktop? Você tem um netbook?

LT: Na verdade eu levei um Eee PC comigo para a LCA da Tasmânia, não porque ele é um 'dispositivo para os consumidores', mas porque faz tempo que estou ao lado daqueles que acham que os laptops devem ser pequenos e leves, e não serem usados com substitutos aos desktops. Na minha opinião, os netbooks são o que os laptops deveriam ser.

E sim, eu acho que o Linux se encaixa muito bem nesse espaço, em parte por funcionar melhor em hardware ultrapassado do que o Vista, por exemplo, e em parte porque acho que ele é uma boa forma de conquistar as pessoas que, como eu, não querem necessariamente um laptop que substitua o desktop, mas sim algo pequeno que possam levar em suas viagens. As pessoas não necessariamente esperam de um netbook o mesmo que esperam de um desktop, e não falo só em desempenho. E essas espectativas diferentes podem fazer com que seja mais fácil para as pessoas fortemente ligadas à Microsoft dizerem "Ok, quero algo pequeno e fácil para usar nas viagens, e se não rodar exatamente os mesmos aplicativos que rodo no meu desktop, eu não ligo".

Essa mudança para computadores menores pode ser uma forma das pessoas se disporem a aprender algo novo, sendo apresentadas ao Linux num momento em que elas supostamente não estariam prontas para dar esse passo.

DW: Você acha que é bom termos tantas distribuições? Deveria existir um esforço colaborativo para uma única distribuição "voltada para o novo usuário" ou os novos usuários é que têm que se acostumar com o "jeitão do Linux"?

LT: Não só acho que ter várias distribuições é algo bom, como acho que é absolutamente essencial! Temos centenas de distros, e muitas delas são para nichos de mercado. E você precisa disso, simplesmente porque mercados diferentes têm necessidades diferentes, e não há distro que atenda a todas elas.

Claro que muita gente diz "mas você precisa de várias distros para o mesmo mercado?" quando pensam no mercado de desktop convencional, e só se prendem na questão do openSUSE, do Fedora e do Ubuntu dividirem o mesmo espaço. Mas você tem as distribuições focadas em questões específicas (e a competição é sempre desejável), permitindo que os mercados decidam quais questões são as mais importantes.

Além disso, ter vários times em jogo mantém a honestidade de todos e permite compará-los. Pode parecer tudo meio bagunçado e complexo, mas eu acho bem melhor ter um sistema feito por vários grupos do que por um só. Mesmo que seja mais complicado.

DW: E quais são as barreiras que impedem os novos usuários de manter o Linux no desktop? Depois que elas forem derrubadas, quando você acha que teremos "o ano do Linux no desktop"?

LT: Não acho que haja uma barreira, nem que haverá "um ano". É uma combinação de várias coisas pequenas. Trata-se de uma caminhada lenta e constante rumo a uma solução mais completa, e de fazer as pessoas irem aos poucos experimentando algo diferente. Isso leva um bocado de tempo mesmo.

A maioria das pessoas acha que o desenvolvimento do software livre é bem rápido, mas não é. Sim, há grandes avanços acontecendo numa velocidade incrível, mas ao mesmo tempo, com freqüência certas questões se movem muito lentamente. Pense, só para pegar um exemplo totalmente aleatório que vem sendo discutido há anos, em algo como a interface do GIMP. Ela mudou tão rapidamente quanto as pessoas gostariam? Será que deveria?

E ao mesmo tempo, a questão são as pessoas, e não a tecnologia. Às vezes você precisa fazer as pessoas se acostumarem a uma nova idéia e a uma nova maneira de fazer as coisas, e isso também leva um bocado de tempo. Talvez a interface do GIMP não seja tão horrenda assim, e as pessoas é que tenham que mudar? Isso acontece.

Vamos pegar um exemplo na minha própria esfera de desenvolvimento — no git, uma das maiores barreiras era o fato dele ser diferente do que as pessoas estavam acostumadas; os que queriam outro CVS ou SVN tiveram muita dificuldade. Essa era uma questão constante que exigia explicações na lista de discussão do git.

A turma do git obviamente estava convencida de que essa questão de desenvolvimento distribuído era tão tecnicamente superior que era necessário entendê-la, e que não havia jeito de tornar o git centralizado de forma a atender às expectativas das pessoas. Com o git, a questão era ensinar as pessoas, mesmo que até um certo ponto seja bem mais difícil mudar as expectativas das pessoas com relação ao software do que mudar o software para corresponder ao que elas esperam.

Deu certo? Parece que sim. Essa história toda de gerenciamento distribuído de código fonte e a forma como ele muda fundamentalmente sua maneira de pensar sobre certas coisas parece estar acalmando um pouco. As pessoas estão se acostumando ao git, e têm reclamado menos sobre ele ser difícil de aprender. Mas levou tempo, literalmente. Muito tempo. E ainda não acabou.

E esse é um exemplo bem técnico, onde havia alguns argumentos contrários bastante fortes. Quando as pessoas estão se adaptando a toda uma experiência de desktop (bem mais imprecisa) e com tudo o que isso implica, leva ainda mais tempo.

DW: O quanto as várias distribuições influenciam na direção do kernel?

LT: Não tenho como fornecer dados razoáveis, mas as distros tendem a ter influência bastante direta pelo fato de seus desenvolvedores também trabalharem no kernel. Há vários desenvolvedores de nome do kernel trabalhando para a Red Hat e a Novell.

Outra coisas que as distros fazem é interagir com a depuração: um aspecto geralmente subestimado de uma distribuição é a forma como lida com os relatórios de problemas dos usuários e como os repassa para o upstream. E isso não acontece só com o kernel. Uma distribuição ativamente envolvida na solução de bugs e de problemas dos usuários obviamente irá influenciar bastante o projeto upstream.

Mais uma vez, as distribuições obviamente podem cuidar disso bem ou mal. Um dos motivos para que eu goste do Fedora é saber que eles são particularmente ativos nas duas coisas, contando com os desenvolvedores e tentando acompanhar o mais de perto possível o kernel mais recente, envolvendo-se ativamente nos relatos de bugs.

DW: É atribuída a você a frase de que lançar o Linux sob a GPL foi a melhor coisa que você já fez. Que forma você acha que o Linux teria assumido se não fosse pelas ferramentas GNU e pela GPL?

LT: Sinceramente, é difícil de imaginar. Eu tinha uma licença antes da GPL, que era algo bem rigoroso do tipo "use a mesma licença ao contribuir com código e nada de dinheiro circulando", e a primeira parte dessa licença era a mesma coisa que a GPLv2 em espírito, talvez até em termos legais. Logo, a GPL não é tão "única" nesse sentido.

O mesmo vale para boa parte das ferramentas GNU — havia toneladas de ferramentas BSD, e quando comecei o Linux as versões BSD eram as melhores, embora isso seja discutível. A exceção era o compilador: o GCC (além da suíte Binutils) era única, e eu certamente percebi isso logo no início. Um dos maiores motivos para eu ter escolhido a GPL foi ter reconhecido a importância que o GCC tinha para o Linux.

Mas essa especulação de "como teria sido" é complicada. Impossível, eu diria. Muitas das questões envolvendo a escolha da licença dizem respeito ao efeito em rede, ou seja, da mesma forma que eu escolhi a GPL em parte por causa do GCC, outros projetos escolhem suas licenças por causa de outros que também escolheram. E não necessariamente porque as licenças em si são especiais, mas por causa do efeito em rede.

O que teria acontecido sem a GPL? Quem sabe? Outra licença como ela poderia ter aparecido, e atraído os mesmos tipos de seguidores. Ou não. Nunca saberemos.

DW: Você se lembra do primeiro patch que recebeu para o Linux? Você esperava por isso? Como você se sentiu?

LT: Eu não lembro exatamente do primeiro patch, e lembro que nos primeiros meses eu tinha uma tendência a não "aplicar" realmente os patches, mas sim reescrevê-los. Levou um tempo para que eu me sentisse confiante para aplicar as mudanças de outras pessoas no que era um projeto bastante pessoal. Claro que isso dependia do patch — e ainda depende, em escala bem pequena: ainda acontece de eu receber um patch e decidir que quero aquilo que o patch faz, mas feito de maneira diferente.

Mas eu diria que comecei a receber patches por volta de novembro de 1991. Não foi imediatamente após o lançamento da primeira versão. Leva um tempo para que as pessoas dêem uma boa olhada no projeto e enviem suas alterações.

DW: Quais são as coisas mais empolgantes que virão por aí no kernel Linux?

LT: As coisas com as quais eu me importo pessoalmente geralmente nem aparecem no radar da maioria das pessoas. As mudanças nos níveis mais baixos do modelo de suspensão são um exemplo de algo que acompanho de perto e que me interessa. A maioria das pessoas acha que essas coisas não têm importância, desde que a gente não quebre seus laptops na hora da suspensão ;) Das coisas que têm algum impacto visível para os usuários, acho que a área interessante é a de todos esses sistemas de arquivos de nova geração que estão chegando e vão partir para a briga. "Ext4 contra Btrfs na cúpula do trovão."

DW: Para encerrar, o que você faz para se divertir?

LT: Geralmente eu leio.

DW: Mais uma vez obrigado por sua atenção e por seu trabalho, Linus. Desejamos tudo de bom para você!

Créditos a Chris Smart - distrowatch.com
Tradução por Roberto Bechtlufft