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.

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.

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.

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.

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

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.

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.

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

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.

Olha a Intel provando o contrário à muita gente…