Artigo

    

Linux-libre, kernel Linux totalmente livre

O kernel Linux e seu mascote pinguim são amplamente vistos como o símbolo do software livre e de código aberto. A verdade, porém, é que o kernel Linux é apenas parcialmente livre.


Por Bruce Byfield


De acordo com Alexandre Oliva, um dos fundadores da Free Software Foundation (FSF) América Latina [1], o kernel Linux era originalmente livre, quando foi relicenciado em 1992 sob a segunda versão da GNU General Public License (GPL). No entanto, desde 1996, tem-se aceitado o que são conhecidos como blobs de firmware - bits binários de código proprietário conhecidos por operar em drivers para wireless e outros periféricos. Como o código fonte para essas blobs não está disponível, Oliva e outros defensores do software livre argumentam que eles deixam de tornar o kernel livre.

É por isso que Oliva iniciou o projeto GNU Linux-libre [2], para que os defensores do software livre pudessem se tornar cientes do problema e usar um kernel verdadeiramente livre em seus sistemas operacionais. Oliva tem sido um membro ativo do Projeto GNU desde 1991. Ele começou reportando bugs e, depois de alguns anos, passou a mantenedor do Autotools e do GNU Compiler Collection. Após o trabalho lhe render uma contratação da Red Hat em 2000, ele também se envolveu com o binutils, glibc e o GNU Project Debugger. Desde então tornou-se conhecido como um palestrante regular sobre projetos de software livre.


Blobs


“Os primeiros blobs no Linux”, explica ele, “foram pedaços de objeto de código muito pequenos, disfarçados no código fonte como arrays de caracteres e licenciados sob licenças de software livre muito permissivas”. No entanto, ele diz:


Uma vez que as portas estavam abertas, outros blobs com vários inconvenientes começaram a fluir para as fontes do Linux: alguns tinham licenças que eram claramente proprietárias, declarando explicitamente que foram gerados a partir do código fonte secreto, proibindo a engenharia reversa e impondo restrições incompatíveis com várias outras GPL. Outros têm licenças de software livre, e são compatíveis com a GPL, exceto pela a falta do código fonte, mas não são mais pequenos: alguns são sistemas operacionais que executam em periféricos, maiores do que as versões iniciais do próprio Linux.

Ao longo dos anos, algumas tentativas foram feitas para submeter patches para reduzir a dependência de blobs no firmware, mas “eles não eram apenas rejeitados, eram também desacreditados”. O máximo que o projeto do kernel Linux faria seria mover os blobs para arquivos separados, o que os tornariam mais fáceis de encontrar, mas não faria nada para mudar o problema básico. A presença dos blobs passou despercebida até por volta de 2005, quando Ututo [3], a primeira distribuição Linux totalmente livre, notou a existência deles e começou a retirá-los de seus próprios releases. Logo depois, o gNewSense, outra distribuição gratuita, lançou sua primeira versão, que incluía ferramentas para ajudar a localizar blobs no código fonte, e Oliva então iniciou o Linux-libre.

Então, por que esse problema básico não foi abordado? “O projeto Linux não compartilha os valores do software livre”, afirma Oliva sem rodeios. “Os principais decisores lá não concordam que os usuários mereçam liberdade em todo o software que utilizam ou qualquer software que tire a liberdade é um problema, uma ferramenta criada para subjugar que pode e será abusada para estender o poder”. Ele observa, também, que muitas distribuições populares “enganam os usuários fazendo-os acreditar que são livres e que têm liberdade”, quando, na verdade, não são. Oliva não revela, mas, sem dúvida, a prática comum de se incluir software proprietário como o Acrobat Flash Player para a conveniência do usuário abre uma precedência para as distribuições não se preocuparem com blobs de firmware. Afinal, insistir em um kernel completamente livre ainda pode causar problemas de compatibilidade de hardware até hoje.


Criação e uso de um kernel livre


Atualmente, o Linux-libre ou seus scripts são usados ​​por todas as distribuições que a Free Software Foundation lista como completamente livres [4]. Voluntários também usam kernels do projeto para ajudar a criar kernels livres [5] para o Debian, Ubuntu e Fedora, que “oferece aos usuários a opção de recuperar a liberdade sem abandonar suas distribuições favoritas”. A maior parte do trabalho básico de criação de um kernel Linux-libre é feita por Oliva, embora a criação de binários para distribuições específicas seja muitas vezes feita por outros membros do projeto também.

O trabalho de Oliva é atualizar os “scripts de deblobbing”, e então executá-los no código fonte do kernel Linux: a atualização é feita uma vez a cada grande ciclo de lançamento: "Pego uma nova versão, publicada por Linus Torvalds, executo o script de deblobbing da versão anterior sobre ele e ajusto o script até que seja executado sem erros. Então, executo o script de deblobbing no modo "busca de inconsistências", de modo que ele retorna todos os novos blobs ou requisições de blobs que não são cobertos, e ajusta os padrões de modo a não retornar uma flag de falsos positivos, e de forma a fazer o deblob de novos padrões corretamente, repetindo este passo até que toda a árvore seja considerada como blobfree. Finalmente, comparo as alterações introduzidas pelo deblobbing com as da versão anterior, e faço quaisquer ajustes para a manipulação de arquivos que estavam sob - ou sobre - o deblobbed.

Uma vez que este trabalho preliminar seja concluído, é feita a limpeza de um arquivo tar ou árvore de código fonte baseada no mesmo release, o que requer apenas a execução de scripts apropriados. Atualizar scripts de deblobbing geralmente leva um dia inteiro de trabalho, ao passo que o deblobbing de uma árvore fonte leva apenas alguns minutos - muitas vezes menos tempo do que arquivá-la em um arquivo tar.

O arquivo tar de um kernel deblobbed é compilado exatamente da mesma forma que qualquer outro kernel. Se os usuários percebem alguma coisa diferente dependerá da distribuição e do hardware. Em uma distribuição que esconde mensagens de boot, os usuários não notam nada, a menos que leiam os logs de inicialização. Em uma distribuição que mostra mensagens de boot, eles podem notar uma mensagem que o firmware livre está faltando para um dispositivo periférico. Esta mensagem, no entanto, não significa necessariamente que o dispositivo não é suportado – pode ser apenas que o driver livre seja carregado mais tarde no processo de boot. Alternativamente, “os poucos drivers Linux que ainda possuem blobs disfarçados de código fonte silenciosamente irão abster-se de fazer o upload dos blobs para o periférico”.


Além disso, diz Oliva, “uma série de dispositivos funcionarão mesmo na ausência de uma atualização de firmware, mas outros serão processados de maneira não-funcional pela ausência de firmware”. Esses casos podem ser irritantes, mas ele argumenta que esta situação não pode ser uma coisa totalmente ruim, lembrando que “se o dispositivo não funciona, ele provavelmente não vai controlar ou espionar o usuário”.


A razão disso tudo


O processo básico tem funcionado bem durante vários anos. Ao mesmo tempo, Oliva menciona vários problemas ou possíveis melhorias. Por exemplo, Oliva sugere que o bloqueio do carregamento de blobs não é uma característica de kernels Linux-libre tanto como “um erro que é muito difícil de corrigir”.

Ele sugere que isso interfere na capacidade do usuário de decidir se deve ou não carregar o firmware. Além disso, quando um blob se torna um driver livre - como aconteceu com o driver ath6k htc para placas wireless Atheros - os usuários tiveram que esperar por um kernel livre revisado antes que pudessem usar o driver livre recém-lançado. Ele está atualmente considerando uma revisão dos scripts de deblobbing que permita aos usuários fazer suas próprias escolhas sobre carregar blobs de firmware.

Oliva também gostaria de criar um repositório Git com uma história completa em que cada commit corresponde a um commit no kernel Linux em si. Com este arranjo, “usuários git que utilizam o repositório git livre poderiam colaborar com aqueles cujas árvores são montadas pelo blob, realizando merges e patches de uma forma que não requeiram que qualquer uma das partes tome os históricos de revisão inteiros”. No entanto, ele acrescenta que, “ainda não está claro qual infraestrutura precisa ser adicionada ao Git, se houver, para tornar possível esse tipo de interoperação”.

Mesmo sem essas melhorias, no entanto, Oliva continua convencido da importância do trabalho do Linux-libre. “Tenho muitas vezes ouvido argumentos de que há uma necessidade de comprometer a liberdade, por vezes, para ganhar massa crítica e mudar o jogo”.

Mas, diz Oliva, “se a incompatibilidade entre partes específicas do hardware e a liberdade de um usuário é escondida do usuário, se distribuições populares levam os usuários a acreditarem que repositórios que escondem o blob contêm apenas software livre, e se desenvolvedores experientes se referem a todo o sistema pelo nome de um kernel, onde os blobs não são sequer considerados um problema, que esperança há de que os usuários possam aprender sobre o problema e tomar uma posição de liberdade?” Oliva pontuou, mas pelo menos com as incursões que o Linux-libre fez nos poucos anos de sua existência, há uma possibilidade de que os usuários - ou, pelo menos, os desenvolvedores das distribuições - possam educar-se sobre os problemas e fazer escolhas com base em informações mais precisas.


Mais informações


[1] FSF Latin America: http://www.fsfla.org/ikiwiki/


[2] Projeto GNU Linux-libre: http://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html


[3] Ututo: http://archive09.linux.com/articles/44411?theme=print


[4] Distribuições livres FSF: http://www.gnu.org/distros


[5] Kernels livres: http://www.gnu.org/philosophy/free‑system‑distribution‑guidelines.html

Notícias

Linux Developer Conference Brazil: faltam poucos dias!

Publicado em: 14/08/2018 às 11:57 | leituras |

Evento será realizado nas dependências da UNICAMP, em Campinas, nos dias 25 e 26 de agosto.

Leitor da Linux Magazine paga meia para entrar no FISL18

Publicado em: 06/07/2018 às 21:05 | leituras |

Parceria entre a ASL.org e a Linux Magazine disponibiliza código promocional que fornece 50% de desconto na inscrição para o FISL18.

DevOpsDays chega a Maringá pela primeira vez

Publicado em: 20/03/2018 às 18:25 | leituras |

O DevOpsDays terá sua sétima edição no Brasil sendo sediada na cidade de Maringá, no Paraná, dias 23 e 24 de março, no Sebrae. O evento acontece em mais de 40 países e nele foi criado o termo "DevOps" (em 2009, na cidade de Gante - Bélgica).

SENAI/Fatesg promove segundo Meeting Hacker Senai

Publicado em: 18/02/2018 às 12:47 | leituras |

No dia 24/02/2018 a partir das 8:00h, o SENAI/Fatesg realizará o segundo Meeting Hacker Senai, com a participação do LPI, da Infomach e da Barketilly.

Certificações LPI: o caminho para turbinar a sua carreira

Publicado em: 13/10/2017 às 15:50 | leituras |

O Linux Professional Institute (LPI) oferecerá provas de certificação na Latinoware, em Foz do Iguaçu, em outubro, na Poticon, em Natal e no FGSL em novembro. Fique antenado! Este artigo elenca as últimas novidades sobre o LPI.


Mais notícias

lançamento!

LM 119 | Backup e Restauração




Impressa esgotada
Comprar Digital  R$ 10,90 Digital

  1. Soluti Certificação Digital em busca de especialista Linux

    Publicado em 19/04/2017 às 17:18 | 584336 leituras

  1. Seminário sobre gestão de privilégios do Linux dá direito a certificado CPE

    Publicado em 23/05/2017 às 10:35 | 501935 leituras

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

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

  1. 4Linux abre vagas para Líder Técnico em São Paulo e Brasília

    Publicado em 25/07/2017 às 14:12 | 346243 leituras

  1. Novo evento "Universidade Livre" será realizado em Belém/PA em 06/05/2017

    Publicado em 28/04/2017 às 11:19 | 295686 leituras

  1. Novo GIMP em uma janela

    Publicado em 24/08/2011 às 10:23 | 14676 leituras

  1. Suporte comercial para o NGINX

    Publicado em 13/02/2012 às 12:59 | 10895 leituras

  1. Capgemini abre 30 vagas para profissionais de TI em São Paulo e Rio de Janeiro

    Publicado em 25/04/2014 às 12:07 | 8807 leituras

  1. Dualtec anuncia ingresso na comunidade OpenStack e parceria com StackOps

    Publicado em 24/04/2012 às 16:05 | 11674 leituras

  1. Primeiro beta do jQuery Mobile divulgado

    Publicado em 22/06/2011 às 10:42 | 15360 leituras

whitepapers

mais whitepapers