Entrevista


O pinguim atinge a maioridade - entrevista com Linus Torvalds

Esta entrevista foi visualizada 23558 vezes.

Publicado em 14/05/2012 às 18:16

Versão para impressão Enviar por email



Linus Torvalds


Por Kemel Zaidan, editor da Linux Magazine.


Esta foi a segunda vez que tive o privilégio de entrevistar Linus Torvalds. Para minha própria surpresa (e sem que eu possa definir exatamente uma razão) ele mais uma vez se mostrou bastante à vontade durante a entrevista, respondendo a todas as minhas perguntas - mesmo àquelas mais embaraçosas - em uma conversa que esticou-se até o ponto em que não havia mais nada que eu quisesse saber.


Digo isso porque Linus é famoso por não ser muito afeito à entrevistas. Durante a LinuxCon Brasil 2011, quando tive a oportunidade de encontrá-lo com esse objetivo, não houve coletiva de imprensa, justamente porque esta foi uma exigência feita por ele para vir ao evento. No entanto, eu podia entrever nele, algum prazer ao perceber que eu acompanhava de perto as notícias sobre o desenvolvimento do kernel e portanto ele não precisaria responder às perguntas as quais ele certamente já estava habituado e cujo desagrado eu já tinha havia tido a oportunidade de presenciar: “como você sobrevive com software livre”, “é possível criar um negócio a partir de software livre” e assim por diante…


A impressão obtida pela primeira vez, confirmou-se novamente. A mesma sinceridade e objetividade que ele demonstra na lista de desenvolvimento do kernel (suas respostas, as vezes ríspidas, outras vezes apenas “direto ao ponto” já se tornaram famosas e parte de sua marca pessoal), são também claramente visíveis em uma conversa franca.


Ao contrário de outras figuras notórias do mundo da tecnologia, o que me fascina na personalidade de Linus é que ele não faz questão de esconder as contradições de sua personalidade. Sua inteligência acima da média é tão visível quanto seus defeitos e idiossincrasias, o que agrega um caráter muito humano a sua pessoa. Torvalds não se esforça para parecer menos inteligente (e talvez mais humilde) do que é de fato, mas também não faz força para ocultar traços menos nobres como orgulho, autoritarismo ou indiferença. Ele demostra ser em público aquilo que provavelmente é no trato pessoal.


Ao mesmo tempo, Linus também parece estar muito confortável com aquilo que é. Ou seja, Linus demonstra uma segurança e uma autenticidade acima da média. Digo isso porque é algo tão evidente, que fica visível ae mesmo em uma conversa de aproximadamente uma hora. O que dirá para alguém realmente próximo dele.


Certa vez, cheguei a compartilhar essa impressão com John Maddog, que o conhece a muitos anos e é, inclusive, padrinho de sua primeira filha. Maddog apenas me confirmou aquilo que eu já acreditava saber. Espero que através desta entrevista, o leitor possa tirar suas próprias conclusões e entender um pouco melhor uma figura-chave, não apenas para o futuro das distribuições baseadas em Linux, mas também para o próprio movimento de Software Livre como um todo. O resultado dessa conversa, você confere abaixo.


Linux Magazine » Qual foi a maior dificuldade durante esses 20 anos de desenvolvimento do Linux?


Linus Torvalds » Foi a mudança da minha própria atividade, do que eu fazia com relação a esse desenvolvimento antes para o que faço agora. Parei de escrever código para o kernel, já não faço mais isso. Claro, ainda tenho projetos paralelos, aos quais agora dedico meus esforços escrevendo código, como o software de registros de mergulho, ou o git - mas este último já não recebe tantas contribuições minhas. O programa de registros de mergulhos já está em código aberto e é o projeto em que mais estou contribuindo com escrita, mas é o kernel Linux que ainda toma a maior parte do meu tempo. E como já falei, o que faço hoje é completamente diferente do que fazia quando programava. Hoje recebo emails com correções e acréscimos ao kernel e tenho que decidir por implementar aquilo ou não, justificando essas decisões. Então meu próprio trabalho mudou.


LM » Você sente falta de escrever código para o kernel?


LT » Bem, na verdade não me importa para o quê escrevo código, contanto que eu esteja escrevendo e possa programar, coisa que ainda faço. Não sinto falta disso nesse sentido. Ao mesmo tempo, algumas das coisas que costumava fazer, eu considero, de fato, parte do passado. Já passei por problemas que não quero ver de novo, como por exemplo, escrever para algo terrivelmente mal documentado. É difícil, leva uma eternidade e você pode precisar de semanas para resolver a mais trivial das falhas. Algumas vezes pode ser até por conta do hardware, que também não está documentado. A falha pode estar nele. Tem certas coisas de desenvolvimento de que eu realmente gostava, mas das quais realmente não sinto mais falta. Há uma diferença entre ser um estudante de 20 anos de idade e um desenvolvedor de 40. Existem certas coisas que não preciso mais fazer (risos).


Mas gosto do que estou fazendo agora, realmente gosto de me comunicar com as pessoas e debater. Muitas das nossas discussões na lista são debates sobre se uma solução está correta ou não. É um processo de diálogos, argumentações e contra-argumentações. E eu aprecio isso.


LM » Algumas vezes dizem que você é bem direto e pragmático nos debates. Como é lidar com esse lado humano do desenvolvimento?


LT » Acho que essa minha atitude é importante, especialmente em um projeto como o Linux, em que as pessoas não se conhecem de fato. Não cara-a-cara. E quando se está trabalhando em um projeto de natureza técnica, é necessário ser bem direto. É necessário dizer “não gosto do que você está fazendo”, porque caso contrário, o outro perderá seu tempo desenvolvendo e criando algo que você e outras pessoas odeiam. Algumas vezes, penso até que as pessoas são muito educadas, que aceitam coisas de que não gostam sem se manifestar. Acho que é sempre melhor se comunicar. Mas isso é cultural, bem europeu da minha parte, aliás (risos). Os brasileiros também me parecem bem diretos nesse sentido. Então também tenho que levar isso em conta, que existem diferenças culturais até mesmo no ânimo de debate das pessoas.


LM » Você gosta disso? Não pensava que você gostasse desses conflitos.


LT » Não gosto quando os argumentos ficam agressivos e isso acontece de vez em quando. Mas a maioria das discussões é leve. Algumas vezes ficam um pouco emotivas, mas não chegam ao ponto em que os interlocutores passam a se odiar. Vez ou outra você se depara com discussões realmente ruins, mas na maior parte das vezes é apenas trabalho. E tem funcionado muito bem para um projeto como o Linux, que é extremamente técnico. Muitas vezes um dos dois lados será convencido por questões técnicas e isso facilita a existência de medidas objetivas de como as coisas deveriam ser feitas, pois o kernel é bem técnico e certas coisas funcionam melhor do que outras.


Em outros projetos você com certeza tem mais subjetividade, como no caso de interfaces de usuário. Algumas pessoas podem gostar de uma maneira de lidar com uma determinada interação, outras podem gostar de outra maneira, e é possível que ambos estejam certos, o que pode levá-los a discutir para sempre sem que haja qualquer coisa que venha a convencer um ou outro lado. As discussões sobre o kernel não engendram esse tipo de tensão. Claro que há questões de gosto, mas no final de tudo é sempre um problema de números que se apresentam para os dois lados.


LM » Quando decidiu trabalhar com código aberto e muitos outros contribuidores, você abriu mão de algumas decisões sobre o processo de desenvolvimento e as entregou para toda a comunidade. Como é esse processo?


LT » No final, a maioria das decisões é fácil de tomar, pois se resumem ao funcionamento – ou não – do código. As pessoas discutem e opinam, mas de fato não resolvem o problema. É fácil debater sem oferecer profundidade. E na maioria das vezes há alguém presente no debate que também escreve um código que funciona, esse é um caso comum na lista. Apesar dos argumentos, só existe um trecho de código, não há uma escolha entre duas soluções.


Dentre as minhas escolhas, tenho que considerar colocar o código na árvore de desenvolvimento ou não, e é uma opção. Ou posso reimplementar o código eu mesmo, que também é uma opção. Já fiz isso. Acontece bastante. E para mim é muito importante, pois tenho que considerar se posso fazê-lo e se dá para ser da maneira que eu desejo. Mas a maior parte das vezes não vejo isso como necessidade e resolvo arriscar, experimentar aquele código. Se surgirem problemas, então os resolvemos ou revertemos à situação anterior. Essa é outra vantagem das decisões de perfil técnico: sempre podemos voltar atrás. Basta admitir que algo de errado foi feito: vamos voltar atrás ou faremos certo na próxima vez.


O que realmente me preocupa nesse processo não é código, mas como o desenvolvimento é feito e como fazer com que as pessoas trabalhem em conjunto no projeto; afinal, não se pode corrigir pessoas como se fossem falhas no código.


LM » E quanto às modificações que marcaram o kernel e eram executadas com partes binárias, quando da mudança de versão do Linux para 3.0?


LT » Foi um dos momentos em que achei que todas as soluções até o momento não me agradavam, então surgiu a ideia de criar uma FLAG para marcar o kernel. Assim, qualquer erro com aqueles trechos binários poderia ser rapidamente descartado. E tínhamos aquele código, que de certa forma era bem estúpido. Somado a isso, precisávamos também mudar a versão. E não acho que nenhuma das decisões foi errada: a implementação da FLAG foi chata, mas ao mesmo tempo é um recurso importante para não quebrarmos a compatibilidade do sistema com as máquinas de trabalho dos outros.


Odiei aplicar essa mudança ao código, mas ao mesmo tempo precisava aplicá-la. E não era um código complexo; muito pelo contrário, era um código relativamente simples, e certamente chato. Não foi uma solução elegante, mas funcionou e não vai causar problemas no futuro.


A boa notícia é que, daqui a cinco anos, ninguém vai ligar para esses binários antigos, então no final das contas essa FLAG e o código que a implementou não importarão mais. Talvez nós o mantenhamos no kernel, mas muito provavelmente vamos olhar para ele, nos certificar que ninguém mais liga para ele e por fim nos livrar dessa FLAG.


Essa é uma prática bem comum no desenvolvimento do kernel. Existem pessoas que querem desenvolver o software perfeito. Eu não quero nenhum envolvimento com esse tipo de gente. O mundo real não funciona assim; o mundo real é complicado, feito de código funcional, mas feio. Não sou perfeccionista, mas tenho algumas exigências na maneira como as coisas são feitas. Quando você nomeia funções elas devem ser descritivas, e o código como um todo deve ser escrito de uma forma que, quando analisado, faça sentido. Ao mesmo tempo tento ser pragmático e perceber que o mundo não é um lugar perfeito. Tenho certeza que isso já partiu o coração de alguns desenvolvedores, mas temos que contornar situações e entender que há diversos aplicativos de usuários que são simplesmente propensos à falha; quem sabe eles dependam de uma versão antiga do sistema, e talvez nem mesmo apresentassem problemas há cinco anos, mas agora apresentam. Você tem que simplesmente aceitar. É como o mundo funciona.


Então não quero me envolver com pessoas que proclamam como querem que o mundo seja e trabalham com essa visão. Quero trabalhar gente que aceita a realidade e faz as coisas acontecerem da melhor forma possível, mesmo que a contragosto, às vezes.


LM » Mudando um pouco de assunto, o que você acha dos acordos que a Microsoft vem realizando com fabricantes e OEMs, cobrando deles royalties de patentes por usarem o Linux?


LT » Odeio essa prática, mas ao mesmo tempo não tenho nada a ver com isso. Não estou diretamente envolvido com isso, não estou vendendo o Linux e para falar a verdade, não me importo com essa prática. Além disso, o sistema americano de patentes está completamente quebrado. É a mesma história ridícula de como a Microsoft busca cobrar uma quantia fixa de todos os fabricantes de dispositivos Android por conta de patentes que não deveriam ter sido concedidas ao Windows CE. Acho que é errado e estúpido, mas só.


LM » E quanto à possibilidade dessa prática afetar negativamente o ecossistema Linux e acabar deixando o sistema pouco atraente para os fabricantes de hardware?


LT » Isso não afeta o que eu faço. Da minha perspectiva, o que quero é fazer o melhor sistema operacional que existe. O fato de existirem regras burras e inconvenientes, como as leis de patentes, é um problema deles e acabará sendo resolvido. Afinal, há tantas grandes empresas sendo prejudicadas pelo sistema de patentes… Para elas as patentes são um problema de fato.


Também não tenho sentimentos paternais com o sistema. Quero me concentrar no que sou bom em fazer. Não entendo de leis de patentes e acredito que a comunidade em código aberto e a mentalidade desenvolvida nesse meio são bem claras: não se deve tentar fazer tudo. Tento fazer o que me interessa e o que sou bom e espero que as empresas façam o que lhes interessa e sejam boas no que façam. Não só com patentes: pense em todo o trabalho de relações públicas e marketing que já fizeram. São coisas que também nunca quis fazer e estou feliz em ver o trabalho das empresas em relação a isso.


Por exemplo, a Linux Foundation, ou a Open Innovation Network. Existem especialistas nesses grupos que estão trabalhando com os aspectos legais, e certamente há trabalho a ser feito nessa área. Porém, não é algo que tomo pessoalmente como trabalho meu.


Na minha opinião a ideia das patentes é boa. O que penso ser um problema é a forma como elas estão sendo usadas neste momento, o que prejudica todos os países de primeiro mundo. Afinal, os países que ignoram essas patentes vão construir e inovar sem restrições. Enquanto isso, nos países de primeiro mundo, as empresas estão envolvidas em uma guerra de patentes extremamente cara para todos.


Um caso, em especial, é curioso: o que envolve a luta da livraria Barnes & Noble contra patentes da Microsoft. A razão pela qual é tão importante está no fato de que a Barnes & Noble não é uma grande empresa de TI. Para eles as patentes parecem uma desvantagem competitiva, e eles são uma empresa americana tradicional, com um grande departamento jurídico para apoiá-los. É o contrário do que aconteceu com a HTC, que também depende de patentes como as que foram usadas contra eles, e acabaram dando de ombros para o problema e pagando.


Mas é importante dizer que eu sou otimista se penso nesse problema no longo prazo. Muitas das patentes que a Microsoft detém sobre certas tecnologias já têm poucos anos de validade e mesmo que eles criem novas patentes para substituir as antigas, o problema sempre terá uma data para acabar. Além disso, também tenho confiança de que veremos mudanças na forma como as patentes são tratadas nos Estados Unidos. Claro que esse é um pensamento de longo prazo; no curto prazo não vimos nenhuma mudança ou alteração que apresente qualquer ensejo para otimismo. Mas sou otimista assim mesmo.


LM » De quem foi a ideia de criar a Linux Foundation?


LT » A Linux Foundation começou como Open Source Development Labs (OSDL), uma organização que possuía uma série de projetos em código aberto sob sua tutela. Eles tentaram diversificar seu portfólio. Eu já trabalhava como parceiro, desenvolvendo o kernel Linux nos tempos da OSDL. Uma coisa que eles tinham era um laboratório de testes, em que os desenvolvedores podiam angariar todo o poder de processamento de uma fazenda de servidores para compilar seus projetos. A organização tinha em mente oferecer suporte aos desenvolvedores com essa espécie de infraestrutura. Mas não funcionou. Ao mesmo tempo havia outro grupo dedicado ao desenvolvimento de padrões abertos para as diferentes distribuições; para que os programas, drivers e ferramentas pudessem funcionar transversalmente em qualquer distribuição.


Ambos os grupos eram financiados pelos mesmos fornecedores Linux: empresas como IBM, Novell, Oracle e SUSE. Então eles decidiram juntar as duas organizações. Depois disso é uma história longa e complicada. Mas eu mal tive alguma coisa a ver com esse processo. Até mesmo o site que uso para publicar as diferentes compilações do kernel para todos, o kernel.org, não tem nada a ver comigo. Não fui o primeiro a colocá-lo no ar nem fui seu idealizador. Claro, posso dizer que agora tenho relação com o site. As pessoas perguntam minha opinião sobre as mudanças nele, e tecnicamente sou membro da diretoria do kernel.org, mas sou eu quem trabalha para ele. E prefiro assim. Acho que existe gente boa em colocar sites no ar. Eles sabem exatamente o que fazer, que equipamentos usar, onde colocar tudo e sabem fazer tudo isso de trás pra frente. Outras pessoas são boas em programar e desenvolver; e outras são boas nos aspectos legais ou relações públicas. Eu me concentro em programar e coordenar o desenvolvimento do kernel.


LM » E quanto à invasão ao site kernel.org? Já é seguro para as pessoas voltarem a usá-lo?


LT » Ah sim, uma das lições que aprendemos é que temos que ser mais cautelosos. Antes, o objetivo central do site era que todos tivessem acesso ao desenvolvimento e com isso, quero realmente dizer todos. Mas chegamos, em certo momento, a ter mais de 200 desenvolvedores do kernel. Ninguém ali conhecia todo mundo e todos tinham contas e acesso ao shell, que era configurado e organizado por poucas pessoas que faziam isso em seu tempo livre.


As pessoas ali conheciam a segurança e entendiam disso, só não ligavam para ela no site. Quando a invasão aconteceu, foi de fato bem embaraçoso; afinal, fomos invadidos. Aparentemente nada foi feito no site, mas as pessoas ficaram paranoicas. A árvore de desenvolvimento do kernel foi realmente simples de verificar, pois não realizo meu trabalho nos servidores do kernel.org. Eu simplesmente subo as alterações da árvore de desenvolvimento da minha máquina pessoal para os servidores git. A minha máquina está por trás de um firewall, então não poderia ser acessada facilmente. Pudemos verificar com o git que a árvore de desenvolvimento do kernel não foi alterada. Mas o kernel.org também hospeda uma série de outras coisas, entre elas arquivos compactados de kernels antigos. Como verificar todos esses arquivos? Na realidade nada mudou e nada aconteceu, mas as pessoas ficaram apreensivas e não queriam que um evento como esse se repetisse.


Agora ninguém mais tem acesso ao shell dos servidores. Também mudamos as regras de como se deve subir alterações e código: tudo agora tem que ser assinado com sua chave GPG; caso contrário os servidores no kernel.org nem receberão esse arquivo. Houve diversas mudanças em como interagimos com o kernel.org como consequência dessa invasão. E essas alterações demoraram dois meses, pois todo o sistema foi reconstruído. Não foi nada do gênero “vamos apenas reinstalar o sistema e deixar tudo como estava”. Poderiam ter feito isso bem rápido, mas os administradores queriam novas máquinas e uma nova arquitetura para organizar as coisas. Agradecemos à Linux Foundation por ter nos ajudado com isso. Afinal, apenas duas pessoas mantêm o kernel.org e elas não tinham condições de comprar novos servidores e contratar profissionais de segurança para trabalhar com o site. A Linux Foundation ajudou muito nesse caso e eu não me envolvi nisso. Quero dizer: eu me envolvi nas discussões que determinaram como mudaríamos os processos no site, mas foi só.


Porém, com certeza não fui afetado em grande parte: outras pessoas tiveram que trabalhar duro para colocar o site de volta no ar.


LM » Você já leu alguma vez a GPLv3? Você não acha que ela é adequada ao sistema operacional Linux?


LT » Sim, já a li e acho que ela é horrível. Existem condições e termos nessa nova licença de que eu discordo de forma bem elementar. Uma delas é: quando disponibilizo meu software, quero esse software de volta, quero que as mudanças e melhorias sejam devolvidas à árvore de desenvolvimento e sejam disponibilizadas para todos também; assim outros desenvolvedores também podem trabalhar com esse código. Mas o que você faz com o software e o hardware em que você o instala - e como eles interagem - não me interessa.


Para mim, a TiVo sempre fez a coisa certa, pois eles disponibilizaram as mudanças que executaram no código mesmo que elas não tenham sido tão interessantes. A única coisa que eles fizeram foi tentar travar o software com o hardware. Na minha opinião isso é simples: é o hardware deles. Se você quer que seu hardware opere com apenas um tipo de software, essa escolha é sua. Posso pegar o software de volta, só não consigo esse hardware. Isso fundamentalmente não me agradou, não quero controlar o hardware.


As pessoas que não concordam com essa maneira de proceder das empresas não precisam comprar o hardware, mas Richard Stallman estava certo em sua opinião de que uma das coisas que ele queria controlar era impossibilitar que as pessoas fizessem coisas como o que foi feito pelo TiVo. Ele certamente apresentará parte de sua perspectiva pessoal e ele vê essa prática como algo ruim de fato. Então a principal mudança da versão 3 da GPL foi exatamente em relação a isso. Ela tem outras mudanças também, que não são nada ruins, como a limpeza da linguagem e dos termos. Mas o fato de que a GPLv3 diz expressamente que você não pode travar seu hardware para mim não é importante.


Se você começa seu próprio projeto e decide que não quer vê-lo preso ao hardware de ninguém, então deve optar pela GPLv3. Não acho que seja uma péssima licença, só não é algo que quero para o meu projeto. Foi uma coisa que a FSF não entendeu e ela foi realmente desonesta ao apresentar essa licença e tentar empurrá-la à força para os desenvolvedores. Chegaram até mesmo a mentir sobre as mudanças da licença para fazer com que os projetos aderissem à GPLv3. Para mim, disseram que eu poderia colocar o projeto em GPLv3, mas manter o kernel em GPLv2, pois elas coexistiriam, o que não é verdade: todos os novos desenvolvimentos ficariam atrelados à nova licença. Além disso, depois soube que, quando recusei essa alteração, houve boatos sobre intenções de tirar o projeto das minhas mãos.


Assim, as coisas não correram bem com essa nova licença e eles não entenderam que meu projeto não tem o mesmo intuito que o deles, e que eu não compartilhava da mesma opinião que eles sobre a natureza do que quero fazer. Lembro-me que, quando adotei a GPLv2 para meu projeto, já havia debates acirradíssimos sobre qual licença seria a melhor, BSD ou GPL. Hoje me parece que essas discussões foram todas superadas. Mas, de qualquer maneira, os que acham que a licença BSD, ou Apache, é melhor para seu projeto, estão certos: eles querem algo diferente e isso depende da escolha de cada um.


LM » E quanto às recentes mudanças tecnológicas, como computação em nuvem e a ascensão dos dispositivos móveis? Você não imagina ser prejudicial o fato de que as pessoas podem passar a usar software proprietário sobre as plataformas abertas e livres?


LT » Não acho que tudo o que é executado em uma plataforma aberta será proprietário, mas também não acho que a discussão aqui deva ser “proprietários OU código aberto”. Às vezes o software proprietário preenche melhor as necessidades de alguém. Eu não tenho mais interesse em trabalhar com aplicativos proprietários, mas já os desenvolvi. Antes da minha parceria com a OSDL eu trabalhei com Transmeta, uma empresa de software de onde nunca se liberou um código, mas foi uma experiência boa.


Gosto de trabalhar com código aberto e prefiro fazê-lo. Acho que é um modelo excelente para se fazer coisas que funcionam bem. Não existem preocupações ligadas à tentativa de manter um software proprietário, não são necessários acordos de confidencialidade ou gastos com advogados para tentar manter seu código fechado. Então, por essa facilidade é que eu prefiro o código aberto, mas fora isso, na verdade, eu não me importo com o que as empresas estão usando em plataformas abertas. Eu mesmo não uso software proprietário, mas essa é uma escolha minha.


LM » E quanto à vindoura UEFI?


LT » É só uma nova BIOS que terá tantas falhas quanto uma BIOS comum. As pessoas que acham que poderão ficar livres desses problemas mudando para um novo ambiente estão erradas. As falhas não estão no código da BIOS: estão nas tabelas de descrição de hardware. A UEFI enfrentará exatamente os mesmos problemas: as tabelas descrevendo o hardware da máquina. Elas parecem diferentes e são mais complexas, o que significa que terão mais problemas.


Mas é uma mudança que vai acontecer e já está acontecendo, e possui vantagens sobre a BIOS, como ser escrita em código C, o que simplifica a construção de interfaces mais amigáveis e ambientes gráficos. Muito da UEFI faz sentido, mas alguns dos argumentos usados em seu favor são um pouco dúbios.


Um exemplo é o Secure Boot. Eu mesmo adoraria ter esse recurso na minha máquina, mas quero poder configurar minha própria chave. Um problema que todos os usuários têm, e que é um problema imenso para usuários comuns, são os rootkits. Eles são difíceis de encontrar no Linux e praticamente impossíveis de serem detectados no Windows. Existem malwares tão bons em se esconder, colocando-se abaixo do sistema operacional, que os programas antivírus são incapazes de encontrá-los. Até mesmo o kernel pode ter problemas em se proteger de código carregado antes dele. O Secure Boot não vai resolver todos os problemas de segurança, não vai resolver o problema de pessoas que clicam em um arquivo anexo cuja origem é questionável e infecta sua máquina; ele deixará o processo de contaminação mais trabalhoso para os desenvolvedores desses malwares.


Além disso, o Secure Boot pode se tornar inconveniente em alguns casos, mesmo que coloquem uma opção simples nas configurações da BIOS que desabilite a exigência de uma chave digital para inicialização. As pessoas comuns não vão saber que para instalar o Linux precisam entrar na BIOS e habilitar ou desabilitar aquela opção. Isso pode ser um pequeno inconveniente. Mas também, muito do que se pensou para chegar ao Secure Boot é realmente válido. O uso de chaves criptográficas parece sempre uma boa ideia, mas há casos em que esses recursos podem ser usados de forma negativa.


Eu não teria problemas em usar o Secure Boot na minha máquina e acredito que as questões com a tecnologia não estão resolvidas, então não vou sair por aí pregando que o céu está desabando. Eu certamente critiquei a tecnologia e meu problema com ela é que muitos dos proponentes que participaram do consórcio que definiu a proposta final da tecnologia coloriram seus discursos e os motivos pelos quais optaram pelo Secure Boot. Havia motivos escusos que foram ocultos pelas palavras. Na verdade não acredito que todas aquelas empresas estavam de fato preocupadas com a segurança das máquinas, mas queriam sim controlá-las.


Além disso, muitos dos recursos propostos foram muito mal desenvolvidos. Um exemplo disso são os chipsets Intel que vêm também com hardware de criptografia para o disco rígido, o que é incrível! As pessoas querem poder criptografar as informações em seus discos de forma transparente, sem overhead de software ou a preocupação de fazer tudo manualmente. E você pode fazê-lo, mas a forma como isso foi implementado praticamente impede o uso honesto dessa tecnologia. Eu quero criptografar meus discos com um algoritmo comprovadamente seguro, no qual controlo a chave. Assim, se eu tiver que mover o disco de máquina e tiver essa chave, posso descriptografá-lo por software. Mas não é possível fazer isso: eles criaram seu próprio mecanismo de criptografia. Escondem a chave, que é única para cada máquina. Eles implementaram tudo isso de forma errada, pois estavam tentando resolver outro problema: queriam trancar o hardware em vez de torná-lo mais seguro.


Outra falha foi o fato de que não documentaram como a criptografia funcionava. Assim, não sabemos de fato o que acontece com nossos discos, qual é a força da chave ou mesmo se existem outras pessoas que podem ter acesso aos nossos arquivos. Eles tinham um hardware excelente, mas a maneira como criaram a interface e disponibilizaram a utilização do hardware só favoreceu o mau uso da tecnologia, o que em si, bem triste.


LM » Algum recado para os desenvolvedores brasileiros?


LT » Parem de mandar emails perguntando o que precisa ser feito e descubram o que lhes interessa. O kernel não precisa de estagiários escrevendo código; precisa de mantenedores: pessoas interessadas em uma parte do código e que continuarão escrevendo aquele trecho por muitos ciclos de desenvolvimento. Claro, não são todos os desenvolvedores que contribuem para o kernel dessa maneira. Existem sim aqueles que, ao longo de todo um ciclo ou até mais, vão contribuir com pouco mais de uma ou duas alterações no código. Mas mesmo esses desenvolvedores estão trabalhando no que gostam. Essa é a natureza do projeto: faça algo de que gosta e você estará nos ajudando. Não quero indicar onde estamos precisando de ajuda.


Comentários

lançamento!

LM 119 | Backup e Restauração




Impressa esgotada
Comprar Digital  R$ 10,90 Digital

  1. Baixe o curso de shell script do Julio Cezar Neves

    Publicado em 07/04/2008 às 19:41 | 404101 leituras

  1. Resultado do concurso "Por que eu mereço ganhar um netbook?"

    Publicado em 30/09/2009 às 3:00 | 174919 leituras

  1. Software público brasileiro na Linux Magazine Especial

    Publicado em 29/07/2011 às 15:07 | 154428 leituras

  1. Lançado o phpBB 3

    Publicado em 13/12/2007 às 18:42 | 153407 leituras

  1. TeamViewer disponível para Linux

    Publicado em 26/04/2010 às 1:27 | 121854 leituras

  1. Dataprev programa megalicitação de sistema em nuvem

    Publicado em 04/06/2014 às 13:35 | 5089 leituras

  1. O primeiro "Chromiumbook"

    Publicado em 06/06/2011 às 16:21 | 9873 leituras

  1. Canonical adiciona novos recursos de imagem ao Ubuntu One

    Publicado em 17/12/2012 às 11:06 | 7224 leituras

  1. Linus Torvalds pode invalidar patente da VFat

    Publicado em 30/03/2012 às 17:17 | 10316 leituras

  1. Google Chrome torna-se o navegador número 1 do mundo na preferência dos usuários

    Publicado em 21/05/2012 às 15:58 | 9182 leituras

whitepapers

mais whitepapers