Contra drivers de código fechado: desenvolvedores do Linux esclarecem sua posição
Um conjunto de dezenas dos mais ativos e presentes desenvolvedores do kernel Linux publicou e divulgou um comunicado esclarecendo sua posição contrária aos fabricantes de hardware que mantêm e distribuem drivers de código fechado para suportar seus dispositivos em ambientes Linux.
Publiquei uma imagem reduzida da versão corrente para que todos possam ver o tamanho da lista de signatários, em 3 colunas, abaixo:
Leia o texto na íntegra no site da Linux Foundation, e perceba que a lista de signatários é grande, e inclui vários nomes conhecidos na comunidade de desenvolvedores (exemplos: Alan Cox, Jens Axboe, Dave Jones, Greg Kroah-Hartman, Ingo Molnar, Andrew Morton, Marcelo Tosatti, Ted Tso, Arjan van de Ven e Bartlomiej Zolnierkiewicz), e reforça o posicionamento anterior de Linus Torvalds contrário à prática de determinados fabricantes – que hoje é a exceção, já que o número de drivers disponibilizado em código aberto pelos fabricantes é crescente.
A publicação não é uma mudança dos termos de licenciamento, mas sim uma resposta a questionamentos que vêm ficando cada vez mais comuns. A página de perguntas e respostas da Linux Foundation tem vários detalhes a mais. A Linux Foundation, aliás, expressou seu apoio à posição dos desenvolvedores, e endossou o posicionamento sobre os problemas causados aos usuários pelos drivers proprietários rodando em ambientes Linux.
Saiba mais (lwn.net).
@brlinuxblog
Feed RSS
No Brasil, o Mac está no “canto” há muito tempo, e não vai sair disso. Os fãs da Apple fazem bastante barulho, é verdade, mas a fatia de mercado do Mac no Brasil não é lá grande coisa. Não que isso seja sinal de superioridade ou inferioridade, é só uma constatação.
Como anda o suporte aos drivers livres das radeon? Já suportam 3D? E como anda o gpgpu no Linux?
http://www.meiobit.com/apple-e-mac/colegio-implementa-um-macbook-por-aluno
No caso da Nvidia, não tem como você ignorar o driver proprietário (que aliás é o único que uso aqui).
O driver proprietário versão Linux dela, funciona na mesma performance do driver versão Ruindow$.
É verdade Isaac, se você tem uma placa de vídeo NVidia não dá pra usar o driver OSS, que tem uma performance muito ruim.
O chamado à ação publicado pelos desenvolvedores não é voltado a que os usuários abandonem os drivers proprietários, e sim para que os fabricantes abram o código dos seus drivers.
Augusto, isso nunca vai acontecer, no caso dos drivers das placas de vídeo.
A Nvidia estaria entregando o ouro para a AMD/ATI, que não faz um driver tão bom quanto a da Nvidia.
Isaac, note que a campanha dos desenvolvedores é um chamado aos fabricantes, não é uma afirmação de que a totalidade deles irá aceitar, e nem uma afirmação de que algum deles especificamente irá aceitar.
Na verdade, a abertura em si deveria ser feita para os módulos do Kernel, pois é a coisa que mais dá trabalho num sistema Linux, principalmente quando decidem mudar as APIs do Kernel, já que as empresas não acompanham ;)
O driver em si, como o driver do X, se funciona, então está blz :)
Olha a Intel provando o contrário à muita gente…
a Intel só fabrica video on-board que é superior às soluções dessa cateroria dos concorrentes. Mas por outro lado, essas soluções nao são comparáveis as placas de video “discretas”, como as da Nvidia ou ATI, entre outras.
Ótima iniciativa.
Por que os desenvolvedores Linux estão fazendo isso? Eles não sabem o que estão fazendo, isto não faz sentido.
Se é a fabricante que mantém o driver, tanto faz se é livre ou proprietário, será ruim, incompreensível e impossível de manter da mesma maneira.
As fabricantes são incapazes de suportar todos os sistemas operacionais e todas as arquiteturas. A equipe Linux pensa que o mundo gira em torno deles e se esquece do resto do mundo.
O que interessa é a documentação. Com ela realmente somos livres, porque temos controle sobre o nosso hardware.
Leiam mais sobre o assunto:
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6558
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=7559
Jack, a página de perguntas e respostas da Linux Foundation trata desse assunto, especialmente a parte sobre ser a fabricante que continua mantendo o driver – a intenção é justamente não fazer as coisas dessa forma que você descreveu (e que alguns dos signatários de fato praticam), e sim incluir o módulo na árvore oficial da forma correta, com análise e reescrita onde necessário.
Só porque foi proposto assim não significa que de fato será executado, mas também não justifica simplesmente assumir o contrário. Acredito que a maioria dos desenvolvedores preferem que os drivers sejam de fato limpos, além de abertos.
Se o processo de inclusão for feito de uma maneira que ninguém entenda o que o código faz, sem documentação sobre o hardware, aceitando assinar NDAs, etc., pouco adianta para o avanço dos drivers independentes, mesmo. Mas pedir a abertura do código dos drivers oficiais e sua inclusão na árvore do kernel não equivale a rejeitar a documentação, ou a se comprometer a aceitar qualquer código ofuscado que o fabricante se dignar a enviar. Os signatários da declaração estão priorizando um lado do problema, que é o da abertura dos drivers mantidos pelos fabricantes. Outras pessoas priorizam outro lado, que é o dos drivers independentes, e cada um age na direção que selecionou.
Não acredito que aquelas dezenas de desenvolvedores não saibam o que estão fazendo – creio que eles fizeram uma escolha consciente de lutar pela abertura do código dos drivers existentes para o kernel que eles desenvolvem.
Mas já que estamos falando de opiniões, não acho que haja algo de mal ou prejudicial em os desenvolvedores do Linux pedirem a abertura de código e a inclusão dos drivers oficiais para Linux existentes – e até faz bastante sentido. Também na minha opinião, se o fabricante dá a desculpa de que não precisa entregar documentação porque já dispõe de um driver livre (que ninguém mais entende ou consegue manter/portar), ele sabe que está dando uma desculpa, e não entregaria a documentação facilmente se não existisse o driver livre, também.
O erro possível é outro: é aceitar incluir código ofuscado, contendo blobs, NDAs e outras armadilhas. Esta atitude, que desenvolvedores já adotaram, também conta com a minha desaprovação (não que ela faça alguma diferença para os desenvolvedores em questão). Mas desaprovar isso não se expande até o ponto de desaprovar também pedidos de abertura de código.
O maior problema é justamente esse , o driver que eles liberam pra Linux ter as mesmas funcionalidades que o pra Windows , no caso da Lexmark por exemplo na impressora T644 ( e acho que em todas as corporativas ) você tem a opção de impressão retida somente no driver pra Windows , pra Linux eles liberam um driver que mais parece genérico que não faz mais nada além de imprimir…. e pelo menos nas minhas buscas não encontrei um solução pra isso.
Off topic:
Quando uso as impressoras HP no Linux (outras não tenho experiência para afirmar), a impressão é muito mais lenta do que no windows, uso sempre hplip e cups mas a impressão é muito mais demorada, além de gastar mais tinta mesmo se configuro para modo econômico. Acredito que o problema também é de driver, né? O Linux pra mim tá cada dia dando mais trabalho… o suporte não melhora com a mesma velocidade dos bugs… Não é flame, adoro Linux, mas infelizmente é uma constatação.
Um excelente artigo, que eu traduzi, explicando os reais motivos de termos poucos drivers livres: http://raelcunha.com/packages/blog/pages/index.tpl.php?post=19
Qual (ou quais) modelos, laurocesar você tem percebido isso?
Ok, os desenvolvedores qerem liberação do código dos drivers. Mas o que eles propôem para que esta liberação não cause prejuízos gigantescos para as empresas que liberarem os drivers?
Não podemos pensar apenas em nós mesmos, temos que tentar viabilizar que as empresas façam o que pedirmos. Nessa área de placas de vídeo, o segredo de algumas especificações realmente faz parte do diferencial competitivo do produto. Eu pessoalmente já comprei uma marca e não a outra por ter siporte a pixel shading 2.0. Se o driver fosse aberto, o concorrente também teria esta característica sem ter gastado com o desenvolvimento dessa.
Neste caso a abertura total seria um tiro no pé, pois levaria as empresas a não desenvolver, e sim esperar o código do outro ser lançado e aplicá-lo aos seus produtos.
Talvez um compromisso para as placas low end até que seria viável se não houvessem casos onde a diverença entre a placa low end e a high end fosse exatamente o driver bloqueando algumas funcionalidades
Paulo, eles vão até além, e na pergunta “Why should vendors open source these modules? What advantages do they get from that?”, na página de perguntas e respostas da Linux Foundation, existe uma resposta sobre o que eles propõem como vantagens para os mantenedores de drivers proprietários, no contexto da atuação deles, que é o de desenvolvimento e disponibilização de software.
Mas acredito que essas vantagens não estejam direcionadas a empresas que possam ter “prejuízos gigantescos” pela revelação de segredos industriais (não apenas por meio do código-fonte aberto), mesmo. Mas certamente a proposta deles não é direcionada especificamente à indústria de GPUs, e tem muitos mais casos de drivers de código fechado por aí, com bem menos visibilidade.
Complementando, discordo que os autores do software para o qual estes fabricantes criam módulos precisem eles mesmos viabilizar que os fabricantes atendam os seus termos ou as suas intenções. Eles são os autores, e simplesmente escolhem as intenções, assim como escolhem os termos de licenciamento. Cada fabricante analisa se vai ou não atender, especialmente porque no momento não há nenhuma obrigação adicional de natureza legal no sentido de atender a esta intenção expressa ontem.
Quem teria obrigação (prática) de procurar achar um modelo que viabilizasse essa atitude por parte de fabricantes específicos seria algum eventual terceiro (não-desenvolvedor do kernel em questão) chato que resolvesse fazer campanha para “exigir” destes fabricantes específicos a abertura do código fechado deles, sem estar apoiado em algum termo de licenciamento e posicionamento dos autores que de fato gerasse a obrigação. Mas não é o caso – nem meu, nem seu, nem dos autores do kernel, pelo que percebo.
Mac OS X nunca vendeu tanto (até no Brasil) quanto após a utilização dos processadores Intel, isso é fato. Prever que o Mac OS X continuará no canto eternamente é cartomancia e total desconhecimento de tecnologia, onde não existe verdade absoluta se tratando de mercado.
Laurocesar,
Administro 8 servidores de impressão, com impressoras HP 2200, HP 4050, HP 1300 e HP 4200. O driver HPIJS é excelente e dá ótimos recursos de economia de tonner, com melhor performance que o driver pra Windows. Nas 2200 (duplex), por exemplo, se você setar no driver for linux o uso de apenas um lado da página, a impressão sai mais rápida do que a mesma alteração feita no driver for Windows. De maneira que, a impressora não repuxa a folha sem precisar imprimir nada.
Nas Lexmark em driver for Linux não tem como configurar muita coisa, mesmo.
No geral, achei uma excelente iniciativa.
O Documento, a priori, é apenas uma forma de mostrar a insatisfação com a situação atual de alguns drivers de dispositivos que são fornecidos apenas em sua versão “binary”.
Certamente há muitas considerações práticas envolvidas, mas creio que nenhum de nós tenha a intenção de “resolver o problema” com a simples publicação deste documento. É tão somente uma forma de se posicionar frente à indústria, e esclarecer nossa posição.
É preciso lembrar que o mercado é um jogo de forças, e nenhuma ação sozinha empurrará por completo uma indústria ou parte dela de súbito na direção da produção de drivers livres.
Vendo tantas oposições, é curioso lembrar que há 10 anos não tinhamos um décimo da penetração que temos hoje. Nem em termos de mercado quanto em termos de conhecimento das soluções em software livre por parte do público. E na época, ficavamos firmes em nossas posições de exigir a liberdade sempre que possível.
Hoje, infelizmente, vemos muitos ignorando por completo essa questão, justamente quando temos muito mais poder de barganha do que tinhamos antes.
Drivers livres são importantes, são uma parte crucial do ecossistema do software livre. Não são diferentes de nenhum outro software para que nos contentemos com algo fechado mas “que funcione”. Da mesma forma que sempre foi característica dessa comunidade, vamos continuar nos posicionando a favor do software livre sempre que possível.
Alguém perguntou sobre os drivers da Nvidia e da ATI. Eu uso uma ATI Radeon 9200 SE (sim, é uma placa velha), e o driver livre. Tenho aceleração 3D normalmente, e pelo que testei, também tenho saída para TV funcionando, embora nesse micro aqui n testei. N testei o driver proprietário, justamente por não precisar dele. Mas faz falta um centro de controle, eu tive q sair configurando “na mão”, o xorg.conf.
No meu notebook (velho), o vídeo é uma Radeon Mobility U1, uma placa que o driver proprietário (fglrx) não suporta (cômico, não?). Mas o driver livre supre minhas necessidades completamente (inclusive Compiz, que fica desativado para não comprometer a performance). Inclusive preciso testar o TV-out.
Qto às NVidia, eu briguei ontem com o driver proprietário, ao preparar a imagem de instalação das máquinas da escola, com o Linux para o resto do ano. Versão de módulo do kernel, etc. Finalmente funciona. O centro de controle dele é impressionante, e a saída para TV funciona lindamente. O driver livre n tem 3D, e nem TV-out. Mas fiquei tentado a colocá-lo, pois os alunos adoram o Compiz e enquanto eu explico a interface, tem sempre um gaiato brincando de escrever com fogo na tela, ou fazer chover, coisas assim. =)
Prefiro usar drivers livres, mas se não tiver opção, vamos de proprietário mesmo, até que os livres estejam tão bons quanto. É o jeito.
ora, quem mais sairá ganhando ao abrir o código dos drivers serão as próprias empresas, pois terão excelentes desenvolvedores melhorando seus codigos sem custo.