Livre Acesso por Falcon_Dark

Despensa vazia
Pela primeira vez desde que troquei de notebook (isso foi em Dez 2007) eu decidi baixar uma nova imagem de Linux e queimar uma mídia. Precisava revisitar minha distro favorita, Mandriva, e ver como as coisas haviam ficado com o KDE 4 (que eu só havia visto em screenshots na internet). A HP não deixou. Meu HP Pavilion dv6650 não roda Linux nem com reza brava. E em algum lugar da minha mente as palavras “padrão PC” ressoavam vagamente. Tentei algumas tiradas clássicas como desligar o suporte a APIC e o SMP (meu notebook usa um Turion X2) mas o Mandriva One travava durante a inicialização. Depois eu descobriria que problemas com IRQ dos dispositivos USB eram a causa dos travamentos.

Decidi então baixar um live CD do Fedora 10, com KDE 4 pois nunca fui muito fã do Gnome. Nada feito. Após buscar muitas dicas na internet e usar diversos parâmetros de boot para desligar o suporte ao APIC ele deu boot, mas não iniciava o X. A mensagem “(EE) no device found” retornada pelo X.org indicava que o driver da nVidia não estava subindo corretamente. De fato o driver quebra com o problema de suporte ao APIC.

Estava, ao meu lado, um HP nx6535 também com Turion X2 mas com chipset (e vídeo) da ATI. Decidi testar o Fedora 10 live nesse notebook e testemunhei, pasmo, o início do sistema e interface gráfica com uma única modificação nos parâmetros de boot:

pci=routeirq pci=assign-busses noapic nosmp nolapic

Exato, no HP nx6535 com chipset ATI o Fedora 10 KDE rodou perfeitamente e iniciou a interface gráfica com o KDE 4 e tudo.

Estava eu, com dois notebooks da mesma marca. Um low-end para escritórios e um mid para uso pessoal, com o mesmo modelo de processador, mesma quantidade de memória, mesma placa wi-fi, chipsets diferentes. E o note com chipset ATI rodou o Linux sem problemas, aquele com chipset nVidia não. Lembrei que meu note antigo que rodava Linux com algumas modificações semelhantes nos parâmetros de boot e também tinha chipset ATI.

Independente disso, eu estava novamente jogado à mesma situação de três anos antes. Configurar o hardware de vídeo de um notebook da HP onde desejo usar Linux. Será que em 3 anos nada mudou? Fiquei fora por pouco mais de um ano (do mundo do software livre) e quando volto o que encontro? A despensa vazia!


O IDG Past
Justamente quando estou revendo esses velhos problemas bem diante de meu nariz aparece um artigo no IDG Now repetindo velhos bordões. Até ficou parecendo IDG Past, pois assim como meu problema de vídeo, ou de APIC, ou ambos, certas coisas naquele artigo deveriam estar renegadas ao passado. Mas não estão.

Não vou dedicar tempo ao artigo do IDG Past pois o Ricardo Bánffy já fez isso com uma destreza particular (e constante) dele. Com o artigo do Ricardo nada mais precisa ser dito sobre o que foi levantado no IDG. Vou à diante com a seguinte conclusão sobre o caso: é lamentável que um site sobre tecnologia que queira informar seu leitor publique com tanta naturalidade opiniões tão equivocadas sobre assunto tão importante. O mínimo que se poderia esperar seria argumentos mais sólidos ou uma postura mais crítica dos editores com relação ao que foi citado.


Enfim, os erros que cometemos
Com a experiência de quem usou OS/2 Warp e assistiu a IBM tentar ser responsável pelo desenvolvimento de todos os drivers e programas para a plataforma eu entendo que estamos chacoalhando a árvore errada no Linux.

A IBM desenvolveu uma API para criar drivers de impressoras, de vídeo, de rede, etc no OS/2 de tal forma que bastavam algumas especificações dos drivers de Windows 3.x para que eles funcionassem sobre a API do OS/2. A idéia era tornar o mais fácil possível para as empresas adaptares os drivers escritos para o sistema da Microsoft. Depois o conceito foi expandido para os programas de 32bit do Windows 95. Àquela época o OS/2 rodava programas Win16 pois possuía a API do próprio Windows dentro de si. O conceito gerou uma API chamada Open32 que, nos mesmos moldes do POSIX, pretendia ser uma ferramenta a partir da qual uma simples recompilação de um programa Win32 geraria código executável nativamente em OS/2.

A IBM estava sendo visionária, pois o Win32 ainda não era um padrão de mercado e o Windows95 estava chegando às lojas. O que se pretendia era que Adobe, AutoDesk e outras softwarehouses de programas Windows gastassem 10% a mais de tempo para recompilar binários para OS/2 usando a API Open32 que a Big Blue disponibilizava de graça. Saiu pela culatra porque com isso a IBM só fez fortificar o padrão do Windows. Em pouco tempo os desenvolvedores começaram a pensar que podiam apenas compilar para Windows, pois como sempre fizera antes a IBM em breve daria um jeito de fazer código Win32 rodar no OS/2 assim como o Win16 já rodava.

Estamos cometendo o mesmo erro no Linux. Vou explorar melhor esse aspecto logo, mas existe um outro ponto que eu gostaria de levantar. Chacoalhamos a árvore errada ao tentar fazer o Linux rodar em todo PC em que Windows roda. Isso tira o foco de coisas importantes. E vou detalhar isso em seguida também.

Se você fizer o trabalho de alguém esse alguém vai fazer outra coisa
Temos centenas de bons programadores voluntários que nesse exato momento estão criando drivers de dispositivo para submeter ao kernel Linux. O primeiro impulso é de agradecer a esses colaboradores por seu empenho e dedicação. Sem comentar sua nobreza em submeter o driver da minha placa de rede para que eu possa usar Linux. Isso é ótimo.

Mas o efeito colateral disso é que grandes fabricantes de hardware virtualmente onipresente não são a mínima para o Linux porque entendem que outros farão seu trabalho de graça. A Broadcom é o primeiro nome que me vem a cabeça. Temos o driver de wi-fi da Broadcom que é desenvolvido por programadores sem o suporte oficial do fabricante. Além disso temos o ndiswrapper que usa o driver original de Windows para operar o hardware sob Linux. Essa segunda solução funciona particularmente tão bem que a Broadcom vai evitar ao máximo pagar um funcionário próprio para escrever um driver de verdade para Linux. E enquanto isso funcionar muitos notebooks usarão hardware Broadcom oficialmente não suportado no Linux.

Um pássaro na mão é melhor do que dois pássaros voando
Responda rápido, você prefere um sistema que suporte 10mil dispositivos de forma meia-boca ou um que suporte 2mil de forma plena? Os dados de crescimento do MacOS X e redução na utilização de Linux podem até estar errados como sugeriu o Ricardo Bánffy ou distorcidos.

Entretanto me parece mais fácil vender um sistema em um hardware onde ele funciona absolutamente bem, mesmo que o hardware em si seja uma droga (Intel, desculpe, mas essas placas de vídeo dos Macs são muito safadas). Ao menos mais fácil do que vender um sistema que, após instalado anule a funcionalidade daquelas teclas bonitinhas que seu notebook de R$3Mil tem além do teclado. Se tivéssemos 40 distribuições diferentes de Linux e cada uma tivesse um propósito bem definido eu concordaria com o Linus de que a Pluralidade é 100% positiva.

Mas não vejo vantagem prática em ter 5 distribuições de renome internacional e nenhuma delas conseguir lidar com o APIC quebrado dos notebooks da HP. Parece que estamos todos trabalhando sempre sobre os mesmos problemas (e chacoalhando juntos as árvores erradas) que ficam se repetindo quando essa redundância encontra o disposto no item anterior. Três anos se passaram e o driver de vídeo ainda é um problema porque temos vários grupos de trabalho e dezenas de programadores independentes tentando fazer aceleração 3D funcionar em 400 modelos de placas de 4 fabricantes de chipsets.

Penso que restringir isso a 20 modelos de placas de um único fabricante seria restritivo e até contra os preceitos do software livre. Mas não teríamos mais chances de colocar o Linux no desktop se tivéssemos 100% de certeza que o Linux vai funcionar em uma certa gama (pequena!) de hardware do que fazendo isto aqui?

Já ouvi falar de colegas que, quando decidem comprar um novo notebook, vão à loja com um Live CD de sua distro Linux e testam nos modelos para antever os problemas e optar de forma mais acertada. Não é irônico que os usuários mais exigentes sejam aqueles (únicos!) que não podem se dar ao luxo de efetuar uma compra on-line? Um usuário de Windows e mesmo um usuário de Mac pode entrar na sua loja on-line predileta e comprar um notebook sem sair de casa. Um usuário de Linux não, porque ele vai querer testar o sistema antes pra ter certeza de que ele irá rodar(!).

Hardware funcional
Se tivéssemos uma lista de hardware que é 100% funcional e ignorássemos o resto (chega que ficar apelando à fabricante X para que libere a especificação, vamos abandonar esse hardware) não conseguiríamos progredir de forma mais positiva? Talvez não. Mas entendo que é isso que tem dado ao MacOSX visibilidade. Existe uma gama muito restrita de hardware sobre o qual esse sistema roda. Mas ele roda absolutamente bem sobre esse hardware. Isso é pouco freqüente com o Linux.

Porque não temos uma distribuição de grande porte focada em notebooks? Da mesma forma que temos algumas focadas em servidores? Em vez disso temos dezenas de sites falando sobre quais modelos de notebooks rodaram melhor ou pior esta ou aquela distribuição de Linux. Isso te parece um bom trabalho? Também não parece bom aos olhos do usuário médio.

O usuário de MacOSX sabe qual computador comprar para rodar seu sistema predileto e isso é uma vantagem para um sistema que deseja ser mais usado no futuro. O usuário de Windows sabe qual computador comprar (virtualmente qualquer PC). O usuário de Linux precisa de uma lista de compatibilidade, conferir modelos, e se o fabricante tiver mudado o chipset a lista de compatibilidade vira fumaça.

É por isso que o casamento do Linux com o desktop não vingou. Temos um excelente sistema operacional e hardware incompatível cujos fabricantes não se importam. Estamos tentando fazer o trabalho dos fabricantes e esquecemos de fazer o que nos cabia como usuários (exigir nossos direitos e boicotar fabricantes que não atendem nossas expectativas). E no IDG Past também estão chacoalhando a árvore errada.