Eu prefiro quando é livre.: Se o kernel é livre, porque não? Mas prefiro drivers com código aberto.

O problema...: O problema é quando esse componente proprietário usa funções GPLadas do kernel. Temos o mesmo problema da linkagem de programas proprietários com bibliotecas GPL. Aliás, os drivers binários atuais "conspurcam" o kernel (aquele 'kernel tainted').

a solução é simples: mande os japoneses programarem seus drivers para a família BSD e sua licensa liberal...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

O dia em que ess absurdo acon: O dia em que esse absurdo acontecer, será hora de forkar o kernel.
sem mais comentários.

Só está faltando agora colo: Só está faltando agora colocarem o kernel sob BSD para que alguém feche o código e a comunidade seja forçada a criar um fork. =/

Fico me perguntando... pq logo com o kernel do linux? Pq não vão pedir isso pro kernel do BSD? O que estaria muito mais de acordo.
Até quando essa "pressão" pra cima do pessoal do kernel vai durar? Ou melhor, até quando eles (do kernel) irão resistir? Já que essas empresas devem ter muitíssimo interesse que isso seja implementado e com certeza vão jogar pesado para conseguirem ( leia-se $$ ). Afinal, desenvolvedor também precisa comer não é mesmo?

O Raymond é que deve estar adorando tudo isso e aproveitando pra "meter mais um pauzinho" na GPL =P

Só pra entender...: Isso não seria bom para o usuário final ? Assim não teríamos "drivers" mais facilmente para todo e qq hardware ? Ou não é por ai ?

Não é por ai.: Não é por ai. Se um fabricante não tem interesse em disponibilizar o driver fechado com o kernel evoluindo, fixar no kernel uma API não garante que o driver continue sendo disponibilizado indefinidamente, quando o produto estiver em "end of lifetime period", "obsolete", "deprecated". Abrir o código sim.

Afinal para o fabricante é mais fácil simplesmente abrir o código e dizer para comunidade: "--Está aberto o código, esperamos que dividam conosco a tarefa de mantê-lo com qualidade e em pleno funcionamento;"

Lembre-se que a GPL nasceu quando o fabricante resolveu que determinada arquitetura não era mais rentável e deveria ser abandonada. Enquanto o driver for fechado existe a chance de perder-se o funcionamento do hardware, quer o kernel tenha ou não uma API fixa .

Isso não está tão longe assim: O kernel tem código fonte aberto mas não necessariamente é GPL. Aliás, existe muito código dito "Dual BSD/GPL".

Vários trechos do código do kernel incluem licenças como por exemplo Dual BSD/GPL
Dual MPL/GPL
GPL and additional rights
MIT ( ipaq-flash.c )

Existe a interpretação de que duas licenças como por exemplo BSD+GPL são incompatíveis, motivo pelo qual o fork do kernel já existe, por exemplo o GNU/Debian e seus derivados são as únicas distro que oficial e nativamente não depende exclusivamente do kernel linux.

...: Usar drivers proprietários é um mal, mas creio que é um que pode ser necessário, quem sabe se fosse feito um acordo.

Os drivers podem ser desenvolvidos sob código fechado, porém após 1 ano o código dele precisa ser aberto.

Creio que algo do tipo seria intessante, fechado, mas por tempo já definido.

Drivers de código fechado para o kernel: Essa "Estória" de "possibilitar binários" abre um espaço enorma para uma coisa que para muitos é impensável.

E S P I O N A G E M

Imagine por exemplo o tamanho do orçamento dos EUA com armas

Imagine outra situação. Grandes empresas proibindo usuários Livres
de usar coisas dentro do linux, ou pior ainda tornando lentos programas
que concorram com os deles. Acho mesmo é que se esta gente que algo fechado deveria usa W I N D O W S mesmo.

O dia em que ess absudo acontecer: É por essas e outras que acho necessário a comunidade começar novos projetos de kernel ou mesmo um fork. Para que se um idiota desses conseguir impor esta heresia, nós tenhamos para onde correr.

Alguém entendeu errado: Alguém está entendendo algo errado, não sei se sou eu ou quem.

Ocorreria a inclusão dessa api, mas junto com o kernel não iria vir nada fechado, apenas os drivers livres assim como ocorre hoje.

Essa API não seria apenas para que drivers proprietários como o Nvidia e alguns outros tenham uma compatibilidade mais duradoura?

Os drivers no Linux são arquivos que ficam na pasta /etc/modules/****

Se você copia esse modulo de um PC para outro usando o mesmo kernel costuma funcionar normalmente, pelo que eu entendi essa API iria fazer com que um modulo compilado no kernel 2.6.10 depois pudesse ser copiado para o kernel 2.6.13 sem ser necessário fazer adaptações e nova compilação.

Principalmente em softmodem existem muitos casos de funcionar apenas em algumas versões bem especificas do kernel, tem driver que funciona no 2.6.8 e no 2.6.10 já não funciona.

Então a gente ia comprar um softmodem ou uma web cam e com ela viria um CD que a gente executava um script, ele pedia a senha de Root, copiava o módulo pra pasta de modulos do pc e então é so carregar o módulo.

Hoje já existem drivers desse tipo, mas eles ficam incompatíveis muito rápido, creio que a única coisa que ia mudar é que eles iriam durar por mais versões.

Ai o usuário decide se compra um Hardware com suporte aberto e nativo no kernel ou qualquer um que vem com driver binário.

Penso assim também...: Não tenho entendimento de APIs e hardware + kernel, porém, penso que há MUITA falta de hardware para o linux por causa disso. Vejam que muitos drives do linux NÃO são oficiais! O própio drive da minha placa de rede (forcedeth) é "extra-oficial" e feito por engenharia reversa, e claro, faz parte da árvore oficial do kernel.

Acho que o Linux deve se tornar um pouco mais comercial, gostaria sim que todos os drives focem livres! Mas realmente NÃO posso imaginar que continuemos a usar drives feitos sob engenharia reversa, com funções pela metade! É triste mas é isso!

O mundo é perfeito? Gostaria que foce...


A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

.: Facilitar a criação de drivers fechados para que venham CDs com drivers fáceis de instalar sim.

Mas incluir driver que não seja livre na árvore do kernel ai concordo que vai ser a hora de trocar de kernel.

driver com código fechado para o kernel: sou contrário, pois ao deixarmos drivers com código fechado funcionar no kernel não há a possibilidade de outros examinarem este e adicionarem melhorias, como também se uma empresa deixa de existir não há como continuarmos com o driver deste.

Justificativa: Aqui está um link explicando os motivos do não uso de drivers binários/proprietários no kernel.

http://www.kroah.com/log/linux/stable_api_nonsense.html
Talvez o problema é que a curto prazo o uso de drivers proprietários seja uma boa mas a longo prazo acabe se tornando uma "pedra no sapato".


"Só sei que nada sei" Sócrates

"O Homem está condenado a ser livre" Jean Paul Sartre

API Drivers - Kernel Linux: Sou a favor do comentário anterior, que se querem tanto complicar a abertura dos drivers atuais, mais do que os problemas que já temos com ela, com licenças diferentes, ou drivers mal acabados em função da engenharia reversa, que esse pessoal considere Windows como uma opção excelente para eles, e deixem nossa árvore GPL em paz. Sou a favor tambem do fortalecimento do trabalho da Linux Standard Base, para incluirmos nos hardwares novos o selo "Linux Enabled, Using for life" compatível com GPL.

Pô assim o pessoal me assusta: Pô assim o pessoal me assusta. O espírito do linux é a liberdade e propagação do conhecimento como vamos aceitar que pouco a pouco vá se incorporando código fechado? Sempre falamos das vantagens do software livre ... quer usar código fechado no kernel ? Ótimo vá usar windows!
O fonte fechado é uma aberração para a sociedade pois o conhecimento humano fica restrito a uma meia dúzia não para o benefício social e sim para o lucro ... assim quando alguém tivesse que desenvolver um navegador novo num mundo onde só existisse navegadores fechados teria que reinventar a roda ... um absurdo é contra isso que o software livre se opôe ... como vamos aceitar que deturbem isso? O conhecimento deve ser compartilhadom não escondido.

Isso tudo é uma faca de dois: Isso tudo é uma faca de dois "legumes", pq: A possibilidade de adicionar driver proprietarios, normalmente mais elaborados, quero dizer elaborados e não melhor (ex: os drivers para impressoras normalmente não tem todas as opções que o drive para windows, uso uma Sharp AR-450, e é muito diferente) seria uma ajuda muito grande para que empresas com equipamentos muito estranho, ou muito caras para pode trocar por uma mais novo e com suporte no linux.

O problema é que como falaram ai em cima, isso abre um precedente pra o pessoal do kernel ser precionado por mais coisas, e depois mais e mais..

Sinceramente acho que as empresas e que deveria ter a preecupação com isso, afinal compro uma impressora de R$ 100,00, é não posso ter acesso a um drive? Aonde ta a logica disso, porque não liberar um código que não é tanta coisa assim, que iria melhorar com isso, sem falar que terião mais suporte? Pra isso é tudo suborno da concorrencia.

Em vez di ficarmos dicutindo isso, deveriamos vazer pressão contra as empresas, para liberar o código do seus drivers afinal eles nem vendem driver...

Liberdade:

Vai parecer estranho meu comentário, mas ja que falamos em liberdade, acho que esquecemos a possibilidade de dar a liberdade ao usuário de usar um driver fechado ou não.... vamos acabar nos tornando aquilo que mais condenamos ???
Também acho que fabricante de hardware ganha dinheiro com o hardware e não com os drivers.
Mas também acho que o kernel deve se abstrair da decisão dar suporte a drivers proprietarios ou não, afinal quem vai comprar e precisa do hardware não é o desenvolvedor e sim o usuário, e se ele precisar muito vai da cabeça do usuário de procurar outro harware ou trocar de sistema operacional e ai não adianta fazer flame na cabeça do usuário.

Por isso ....: ... o módulo PWC foi retirado do kernel? Antes estava inserido e agora é um módulo externo para compilação?

Cesar A. Ramina
- LU#225159 - Debian

Concordo plenamente com a vis: Concordo plenamente com a visão do Nuxlli, eles estão vendendo, pegando como exemplo a impressora, a tecnologia do hardware ou do driver????, isso é um absurdo.

Concordo plenamente com a vis: Concordo plenamente com a visão do Nuxlli, eles estão vendendo, pegando como exemplo a impressora, a tecnologia do hardware ou do driver????, isso é um absurdo.

Temos que precionsar os fabricantes: Na minha opniao, tambem sou contra incluir codigo fechado no kernel.

Ainda acho que a solucao, e precionarmos os fabricantes.
Imaginem se cada pessoa, gerente de TI, etc, quando for comprar ou pesquisar algum hardware, perguntar ao fabricante qual a compatibilidade dele com o Linux.

Aos poucos vamos precionando e uma hora eles vao ter que se render, que o sofware livre e o futuro isso todo mundo ja sabe e nao tem mais volta. Nao temos que nos adaptarmos a eles, eles tem que se adaptar a nos.

Nao e so o kernel do linux, ou a gpl que vai mudar algo nesse mundo. Nos tambem temos que fazer algo, e sinceramente ja esta mais do que na hora.

Abracos...

gnu hurd: na verdade o sucessor do kernel ja existe, o gnu hurd
http://www.gnu.org/software/hurd/hurd.html

ele esta sendo feito com conceitos mais avançados do que o kernel atual.

não é bem assim também: A ideia ate que é bonita mas no mundo corporativo não é bem assim.
Empresas que dependem do codigo de seus drivers como diferencial do seu produto jamais irão pensar em abrir o código.
Imagine a Nvidia disponibilizar o codigo do seu driver? Seria como a coca-cola disponibilizar sua formula.

Por isso que a comunidade se rebola pra desenvolver drivers a base de engenharia reversa, que nem sempre são 100%.

Nunca vai acontecer: O que me deixa tranquilo é que Linus *nunca* deixaria isso acontecer.

Não pelo lado filosófico, mas pelo hacker - ele *nunca* permitiria uma rotina ser imbutida no kernel que não pudesse ler o código. E ponto final.

Realmente, não tinha me aten: Realmente, não tinha me atentado pra esse detalhe.
Se drivers binarios entrarem na ARVORE OFICIAL do kernel, então a brecha estara a aberta, virus , spywares, programas espioes e cia começaram a surgir. Afe, to com um mau pressentimento =(

Exemplo de porque drivers binários são ruins: Olá,

Dêem uma lida aqui. Uma opinião (que compartilho) de porque drivers binários são ruins.

Maturidade: Olá pessoal,

Acho que isso precisa ser visto com seriedade.
Se for aceito, teremos um precedente. Por um lado, diversos fabricantes que não concordam o a "liberdade" do Linux e seu Kernel, poderão criar drivers fechados. Assim, teriamos rapidamente a mesma quantidade de drivers do Windows.
Entretanto, fechasse uma coisa aqui, outra ali e teriamos um kernel fechado a longo prazo. Perdendo, assim, a liberdade de alterar e modificar códigos de drivers importantes.
Temos que pesar os pós e contras da proposta.

[ ]s

Sou a favor. : Sou a favor.
Tecnicamente falando:
Uma API onde o usuário possa optar por pendurar drives proprietários fechados, vá lá, por mim passa. Agora, código fechado embutido na árvore do kernel, jamais.
Filosoficamente falando: Liberdade é isso; muitas vezes ela vai além da nossa vontade. Se tentarmos brecar não é mais liberdade.

Só falta funcionar na prática: Será que o Hurd sairá antes da próxima era glacial?

Quem usa Linux há muitos ano: Quem usa Linux há muitos anos, como eu, deve se lembrar que um dos softwares mais utilizados, e acredito importante, há uns 6 ou 7 anos atrás em qualquer distro se chamava Netscape Navigator. Não havia nada parecido com ele livre (fora os browsers em modo texto), se não fosse o Netscape certamente o Linux no Desktop estaria sendo menos utilizado e menos desenvolvido do que hoje. Então eu paro e penso "nossa, mas havia um software fechado de uma empresa e era tão importante assim?" Pois é. E foi por meio do Netscape que hoje temos os derivados do Mozilla fazendo frente aos programas comerciais de sua área.
Outro exemplo, o StarOffice.
Assim sendo, permitir uma maior compatibilidade com drivers proprietários é necessário. Isso pode alavancar o desenvolvimento de um equivalente livre muito m ais facilmente, porque a base de usuários daquele hardware em Linux vai aumentar.
Dizer simplesmente "fabricante, abra o código e não encha o saco" é uma leviandade. O fabricante prefere perder vendas do que perder seu segredo. Isso é fato, somado ao fato que a imensa maioria de seus usuários utilizam Windows, o fabricante vai preferir gastar dinheiro desenvolvendo o driver para Windows e que se dane se você pertencer à minoria que usa Linux.

Então, o que eu vejo é que no frigir dos ovos, isso é positivo, porque a base de usuários vai aumentar, consequentemente mais desenvolvedores vão participar do desenvolvimento, mais empresas poderão contribuir com o kernel indicando falhas encontradas durante o desenvolvimento de seus drivers, e o desenvolvimento de drivers equivalentes livres vai se acelerar.

A questão não é essa: "Mas incluir driver que não seja livre na árvore do kernel ai concordo que vai ser a hora de trocar de kernel."

A questão não é essa! Um driver fechado não vai ser nunca incluso na arvore kernel. O que os fabricantes querem é uma forma de um driver fechado funcionar garantidamente 100% em um sistema, sem que ele precise ser aberto.

Sendo assim vc receberia os drivers diretamente do fabricante e teria certeza que ao instala-los eles estariam funcionando

Eu também acho que o ideal seria que os drivers fossem todos livres, mas não sou radical. Drivers fechados nada mais são do que segredo industrial. Como ja foi citado muitas empresas tem isso como um diferencial. Hehe coca-cola.. nvidia e por ai vai!

Simples: Exatamente, o Linus não tolera isso, ele começou o Linux por fazer
questão que as pessoas o ajudassem, e caso você fizesse uma modificação ou correção, que você compartilhasse isso com ele. Camada para drivers binários? NUNCA!

Cara agora vc captou perfeita: Cara agora vc captou perfeitamente a idéia :)

Uma API que não sofresse mudanças constantes, coisa que ocorre quando a API fica madura garantiria, na teoria, o funcionamento de drivers com versões do kernel bem diferentes.

Imagine um driver que foi projetado no kernel atual 2.6.14 funcionando no 2.7.x, 2.8.x e etc.

Existem muitos pros e contras, mais se atualmente os fabricantes de hardware não desenvolvem drivers livres não acho que não fornecendo essa API irá força-los a liberar os fontes dos drivers.

E pessoalmente eu aceitaria usar um driver fechado sabendo que meu dispositivo iria funcionar 100% da forma como foi projetado e não estaria tendo que usar um driver feito por engenharia reversa que não me proporcionaria toda a funcionlidade desejada.

bom, pelo pouco que eu entend: bom, pelo pouco que eu entendi, já já, os BSD Flavors vão fazer a festa, já que possuem uma licensa menos restritiva. E como mais "drivers" significa mais periféricos facilmente compativeis, acredito em um crescimento no número de usúarios dos mesmos...Será que eu devo aprender a mexer no FreeBSD ?

BESTEIRA!: Não vejo onde isso vai ajudar o GNU/LINUX!
Seja incluso no kernel, seja por API para posterior utilização, não faz o menor sentido!
Quer dizer que, agora com o GNU/LINUX chegando em maior escala no mercado, os fabricantes querem impor suas vontades?!
Eles que continuem com as suas copyright no Windows, ou decidam de vez liberar o código dos drive para a Comunidade!!
Alguém aí pode me explicar qual o outro sentido disso?
João Melo

Eu não sou contra, sou muito é a favor!: Eu não sou contra, sou muito é a favor!

Meu ponto de vista é o seguinte, seria interessante ter uma API que habilitasse o desenvolvimento de drivers fechados para certos hardwares.

O código da API, que faria parte da árvore do kernel seria código aberto!!! Várias pessoas estão confundindo isso, dizendo que código fechado seria incluido no kernel. Convenhamos que isso é um absurdo.

A API daria suporte a drivers fechados fossem instalados e funcionassem em qualquer linux independente da versão e da distribuição.

Sendo assim esses drivers fechados nunca viriam a fazer parte da árvore do kernel, outro absurdo pensar nisso. Só que você poderia ficar feliz quando adiquirisse algum produto que no site do fabricante existe um driver oficial e não precisaria se preocupar em fazer sua webcam ou impressora funcioar atravez de alguma gambiarra.

Outra coisa, os drivers feitos para funcionar na tal API poderiam ser disponibilizados pelo fabricante sobre licença GPL ou qualquer outra licença livre. Logo a preocupação que surge quando um produto sai de linha e os drivers passam a não ser mais fornecidos pelo desenvolvedor seriam as mesmas que temos atualmente.

Espero ter contribuido :)

Um coisa que ninguém pensou...: É que uma API abrindo as pernas do kernel para drivers binários indiscriminadamente pode literalmente arrasar com a segurança do kernel. Um driver proprietário mal escrito (existem muitos, pode acreditar) pode introduzir um monte de brechas de segurança não-detectáveis pelo simples fato de o código não poder ser auditado e no final das contas quem vai acabar levando a má fama é o kernel.
Um outro fato à considerar é que o linux vem crescendo muito, e os fabricantes de hardware, que não são bobos, estão percebendo isso.
Eu acho que este é o momento do software livre se impor, pois somente assim os fabricantes de hardware vão considerar rever seus conceitos, se abrir as pernas agora pode esquecer qualquer chance de os fabricantes sequer pensar em abrir as especificações.
Somente com especificações abertas poderemos ter drivers realmente decentes para linux.

--------------------------------------------------------------
Marco Carvalho
http://arrakis.no-ip.info
Maceio - Alagoas - Brazil
Debian GNU/Linux - GNU-PG ID:08D82127
Linux Registered User #141545

componentes de software: O Unix sempre foi desenhando para funcionar com uma arquitetura de componentes interdependentes.

Se esta API for inserida como uma nova interface para drivers binários segundo uma arquitetura de componentes, não há mal algum. O isolamento será garantido.

Tudo que os caras estão pedindo é uma interface para interagir com um kernel de forma modularizada, o que representa um avanço na arquitetura do Kernel.

É claro que se a coisa for feita porcamente o isolamento não vai existir, e aí se justifica o medo com virus e tudo mais. Mas se uma boa arquitetura de componentes for usada para estabelecer esta camada, será muito bom.

Gosto da idéia de existir uma interface assim, pois isto significa um avanço na arquitetura do kernel do linux, o que vai trazer muitos benefícios no futuro.

Mais importante do que não usar software fechado, é ter consiência de que eles não representam ganho algum para a evolução do software. Dessa forma, os drivers proprietários não representam uma contribuição para o software livre, mas permitem que individuo X consiga usar seu equipamento ainda hoje. É uma vantagem menor, mas é uma vantagem e gostaria que tal interface fosse implementada.

Dessa forma, a API beneficiaria a arquitetura do kernel, os drivers fechados não representariam uma vitória, os drivers fechados representariam uma opção funcional. É só ter conciência disso.

Vamos deixar de ser xiitas: Vamos deixar de ser xiitas.
Acho muito positivo essa iniciativa. Vejo com muito bons olhos para o crescimento do Linux no desktop.
Sou usuário de longa data e tenho experiência para falar que o que mais me frustra em usar o Linux é o suporte a hardware. Estou com uma placa de TV em casa, PixelView TV-Pro ULTRA, que está parada pois o suporte no Linux é muito ruim e funciona lindamente no XP com os drivers do fabricante. Adoraria que o fabricante tivesse disponibilizado o driver para ela independente se fosse fechado ou não.

"Outra coisa, os drivers feit: "Outra coisa, os drivers feitos para funcionar na tal API poderiam ser disponibilizados pelo fabricante sobre licença GPL ou qualquer outra licença livre. Logo a preocupação que surge quando um produto sai de linha e os drivers passam a não ser mais fornecidos pelo desenvolvedor seriam as mesmas que temos atualmente."

Para que a bendita API no Kernel então, se os drivers tem o código fonte livre? O problema é justamente a falta de acesso ao código. Somente o acesso ao código garante a compatibilidade do harware com futuras versões do kernel. Ou você acha que os fabricantes de hardware estão preocupados com isso?

Já tentou instalar um hardware de 8 anos de idade no winXP?

Marcelo Vivan Borro

"Outra coisa, os drivers feit: "Outra coisa, os drivers feitos para funcionar na tal API poderiam ser disponibilizados pelo fabricante sobre licença GPL ou qualquer outra licença livre. Logo a preocupação que surge quando um produto sai de linha e os drivers passam a não ser mais fornecidos pelo desenvolvedor seriam as mesmas que temos atualmente."

Para que a bendita API no Kernel então, se os drivers tem o código fonte livre? O problema é justamente a falta de acesso ao código. Somente o acesso ao código garante a compatibilidade do hardware com futuras versões do kernel. Ou você acha que os fabricantes de hardware estão preocupados com isso?

Já tentou instalar um hardware de 8 anos de idade no winXP?

Marcelo Vivan Borro

O que é mais importante, conquistar a liberdade ou ...: O que é mais importante, conquistar a liberdade ou ser capaz mantê-la?

Eu concordo com a OSD quando afirma que um software livre não precisa "contaminar" um software proprietário para ser livre (cláusula 9), mas quando um software proprietário contaminar software livre, será que podemos continuar a considerar este software livre?

Nós (comunidade do software livre) temos obrigação respeitar as "liberdades" dos software proprietários e quanto o contrário? Respeito é uma via de mão dupla e sem exceções.

É público e notório que NENHUM fabricante de impressoras ganha dinheiro fabricando/vendendo impressoa, a mina de ouro desse mercado está na venda tintas/toner, para mim esse "chororô" de API para driver proprietário nem merecia atenção.

No caso das webcams, o que move este mercado é o MSN, Yahoo Messenger e provavelmente Google Talk no futuro, mas estes softwares não são propriedade nenhum fabricante de webcam. Uma empresa de segurança pode até utilizar uma webcam em uma recepção de prédio, mas via de regra o software de captura das imagens não o que vem cam a câmera, e este apenas faz uso do driver, a única justificativa (pero no mucho)se aplicaria as webcams com sensor de movimento mas este equipamento é muito caro quem tem dinheiro para gastar quase R$ 1.000 em uma webcam não deve sofrer para comprar um windows.

Já placas de rede, vídeo e softmodems até dependem da qualidade dos drivers mas mesmo assim eu acredito que o precedente é muito arriscado.

Se isso acontecer (...se isso acontecer...) quem ganharia é a Microsoft e a Apple porque se o Kernel do linux começaria a perder liberdade e eu acho que o número de programadores que contribúem pode diminuir, reduzindo a velocidade das melhorias que o Kernel vem recebendo.

Isso seria bom para o GNU/Hurd e BSD's também, os contribuidores mais engajados na causa do software livre que abandonassem o Linux, poderiam engrossar o número de contribuidores destas outras alternativas.

Mostre a sua cara!
Get Mono!
Eu quero World of Warcraft!

Você pesquisou se funcionava no Linux?: Apenas por curiosidade, ao adquirir a placa você pesquisou o suporte ao Linux?

Ou começou a usar Linux após ter comprado a placa?

A medida que aumenta o nº de usuários Linux, os fabricantes serão FORÇADOS a fornecer melhor suporte. Isto já está acontecendo, e para que criar uma API no kernel e dançar de acordo com a música deles (com todas as preocupações de segurança e instabilidade que isso acarreta) quando basta esperar um pouco mais e forçá-los a mostrar o código?

Alguns fabricantes já contribuem como desenvolvimento dos drivers abertos e tem a minha preferência quando vou adquirir um hardware. Quando todos fizerem isso, você não acha que vão preferir contribuir comum código aberto ao invés de perder mercado?

Marcelo Vivan Borro

SIM: Uma definição de API, que estabeleça facilidades para os programadores de drivers é extremamente útil. Veja o exemplo da ALSA, não se faz mais drivers de SOM Linux, sim drivers ALSA. Por isso que os drivers de son, progrediram tanto.

A criação de uma estrutura (API) bem fundamentada, é vital para o desenvolvimento do Linux. Isso não significa necessáriamente que algo assim, irá travar o desenvolvimento do kernel, ou ser uma fonte de bugs e skywares. Basta que a API seja bem definida.

Veja o caso do Minix3, todos os drivers funcionam em usermod, e em caso de bug, ele da autoreload.

SEM ISSO, o Linux em Desktop nunca acontecerá.

É claro, muitos podem argumentar sobre a questão de se disponibilizarem as SPECS dos equipamentos, mas, muitas vezes essas specs, podem ser fonte de dados para concorrencia, por isso a recusa de muitos fabricantes. Isso realmente é discutível.

Mas a API não, pois a mesma é util tanto para drivers Abertos ou Fechados.

> Apenas por curiosidade, ao: > Apenas por curiosidade, ao adquirir a placa você pesquisou o suporte ao Linux?
Você quer dizer se o fabricante tinha ou não driver para Linux? Se for, por conta disso, nem o monitor do meu micro daria para comprar.
Se a pergunta for para drivers GPL para linux. Sim! Tem suporte... Naquelas. Agora faz funcionar!

>Ou começou a usar Linux após ter comprado a placa?
Foi o que me motivou a usar o Linux! A placa de TV...

Eu acho que deveriam fazer 2: Eu acho que deveriam fazer 2 kerneis.
1 - totalmente livre e aberto
2 - com a possibilidade de colocar os drives fechados

Pois como usuario eu nao faço questao absoluta de ter tudo livre e aberto. quero algo que funcione e queria usar linux, mas nao uso justamente pq nao tem suporte a todo hardware utilizado

O kernel é livre e passível: O kernel é livre e passível de alteração por qualquer um.

Por que uma empresa dessas ou então um grupo delas não pega o kernel mais atual e estável, cria a API, lança seus drivers e vê no que dá?

Eles querem incutir suas idéias de lucratividade a qualquer custo e artimanhas de negócios na árvore de desenvolvimento do Linux, apenas isso.

Por que não fazem como a Apple, e criam sua própria versão do BSD? Não é tão fácil sem milhares de desenvolvedores ao redor do mundo, trabalhando virtualmente a 24 horas por dia.

Poe que não fazem como a NVidia e a ATI, que lançam seus drivers proprietários avulsos ao kernel?

Sinceramente! Compararam os drivers de código fechado com a Coca-Cola. A questão é que assim como a Coca-Cola, tais drivers podem fazer mal ao organismo (no caso o kernel), e ninguém vai saber exatamente por que, pois ninguém sabe o conteúdo da fórmula ou suas quantidades.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

...: O problema maior é que a quantidade mínima de usuários Linux não da pra forçar os criadores de hardware a liberarem seus drivers.

Até a gente ter força para isso vai precisar de anos.

Vale lembrar que a criação de driver proprietários não impede a criação de um driver livre.

Existem drivers proprietários para Nvidia e ATI, porém os drivers para essas mesmas placas em sua versão livre continuam sendo evoluídos.

Falta lembrar de uma coisa, atualmente é possível criar drivers proprietários e eles existem.

A criação dessa API seria apenas algo para facilitar a criação de drivers e é muito provável que ela possa ajudar na criação de drivers livres também.

Seria muito melhor usar essa API do que usar o atual Ndiswrapper para placas wireless ou ficar sem nenhum suporte como ocorre ainda com vários hardwares.

Alias, o Ndiswrapper está incluso no kernel, não?

Ele faz Drivers proprietários do Windows funcionarem para placas Wireless no Linux.

Também é bom lembrar que existem projetos para criação de hardware livre, onde qualquer um pode fabricar, modificar os drivers e fazer o que bem entender.

Mulas e hackers.: O driver disponibilizado pela nVidia(que é fechado) é muito superior ao aberto, isso porque não foi feito com engenharia reversa às cegas. Quem tem essa placa sabe. O pessoal pelo jeito não compreendeu o grande avanço que é a criação dessa API para os fabricantes de hardware desenvolverem drivers para o Linux. esses drivers não serão inclusos na árvore oficial do kernel do Linux, somente a API. Quem quiser usar driver aberto que use, mas liberdade é isso poder escolher o que usar.(quem não quiser usar drivers dos fabricantes continu usando drivers abertos, simples)

Eles podem muito bem escolher: Eles podem muito bem escolher usar o Windows ou o MacOS X, ou o BSD...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

utopia: Acho que a realidade para quem quer trabalhar com linux , ou quem já trabalha com o mesmo, sabe que uma das grandes dificuldades para implantação e migração de sistemas são os drivers que muitas vezes não funcionam 100%. Considero o Linux Livre e poderiam deixar essa opção no Kernel de usar binarios e as distros decidiriam "Livremente" de usar ou não. E cada um escolhe a distro que desejar. Porque a realidade de cada um é diferente do outro. Para mim seria muito util esse recurso.

Só uma observação.... : Só uma observação....

Segundo a entrevista de um glaciologista.. a próxima era Glacial já deveria estar acontecendo, pq acontecem a cada 10 mil anos, então ela estaria atrasada, assim como o Hurd :D

Concordo contigo quanto ao fa: Concordo contigo quanto ao fato de que se isso acontecer, muitos vão ficar revoltados e vão abandonar a ajuda que dão ao kernel ou a qualquer outra "peça". Eu mesmo, que não concordo com essa inclusão de uma API, se fosse algum desenvolvedor do kernel ou contribuinte de alguma outra forma, largaria mão.

Quando a ser bom para o kernel Hurd e BSD. Pro Hurd seria ótimo, já que o desenvolvimento dele poderia ser alavancado com a possível saída de pessoal do Kernel Linux.

E outra, se isso acontecer, sem problemas. Use Debian, e ele tem suporte ao HURD. =)

se voce é tão a favor da li: se voce é tão a favor da liberdade, então porque restringir drivers binários fechados ? não seria contráditório.
Podem falar mal da internet por causa de tantas coisas horriveis que se passa por ela, mas nela encontramos liberdade tanto para coisas boas como ruins.

Vai ser inevitável o linux um dia suportar drivers binários a questão é se vai ser por meio dum fork ou uma evolução gradativa. Porque todos os fabricantes abrirem seus códigos é impossivel, principalmente empresas americanas que tem tanto a esconder.

Acho que são os usuários e: Acho que são os usuários e as empresas (de hardware ou não) que devem se adaptar ao sistema, e não o contrário. Linux nasceu e cresceu numa comunidade. Não é certo fazer com que essa comunidade tenha que aceitar coisas só por causa do interesse econômico de empresas.

Se o Linux não é tão bom para ti pq não suporta todo o hardware que tu tens, parta para outro sistema então! Agora querer forçar com que o Linux (e toda a comunidade envolta dele) se adapte, e aceite essa adaptação, a ti não me parece muito certo. Tanto para o aspecto tecnico quanto para o aspecto da filosofia do Software Livre, principalmente a principal delas: GNU e GPL.

Ah, mas ninguém vive de filosofia. Bem, se quiser usar o Linux, terá que se adaptar a ela, ou use o Windows, Mac, BSDs, etc.

O problema é que o Linux está perdendo sua graça pq está caindo no mundo desktop. Usuário desktop, em sua imensa maioria, não está nem ligando se é livre ou não. Basta ver em fóruns de distros "user-friendly" a quantidade de tópicos que tratam de rodar jogos, emular coisas pelo wine, cedega, fazer o drive proprietário rodar certo... Se esses usuários realmente entendessem o que é software livre e sua filosofia, fazer isso seria heresia. Seria ir contra os princípios a que se dispõe o software livre.

Isso é legal ??: a criação de uma API para os drivers é uma ideia genial!! Mas criar a API não significa liberar drivers proprietarios, pois essa API por se ligar diretamente ao kernel devera ser GPL, e portanto os drivers que se liguem a ela também. Portanto independente da questão moral de ter dirvers livres ou não, iso seria ilegal. ( Se há uma "brexa" que permite que se criem drivers proprietarios eu não consigo enxerga-la )

API para drivers proprietários para o Linux: O Linux tinha de ter API para drivers de código fechado desde há 5 anos atrás. Isso não foi feito ainda porque muitos desenvolvedores de software livre em posições importantes têm dois defeitos graves: um é agir ideologicamente (aquela coisa GNU/chata e distante do planeta Terra, "vamos fazer uma Moscou digital!" etc.). O outro defeito é não ter disciplina para manter uma API estável ao longo de um major version, seja do kernel, seja das inúmeras bibliotecas presentes numa distribuição Linux típica. Quebra de API infelizmente ainda é uma constante no mundo do software livre.

Vejam quantos usuários e desenvolvedores o Windows arregimentou, apesar de ser um péssimo sistema operacional e ter uma péssima API, mas que tem a simples preocupação de manter essa péssima API estável...

E de qualquer forma, o gênio do driver proprietário para Linux já está fora da garrafa: aí temos a NVidia com aquele kit para instalar seu driver em qualquer kernel, temos o ndiswrapper que permite usar drivers de rede para Windows (muita gente só consegue usar Wi-Fi no Linux por conta do ndiswrapper) etc.

A idéia não é embutir codi: A idéia não é embutir codigo fechado no kernel do linux, a discussão é se deve ou não criar uma API nesse kernel que pudesse carregar drivers binários externos (codigo fechado), uma espécie de wrapper para executar um código que pode ser desde malicioso até winmodem, cameras usb, etc...

Na minha opnião é inevitável o uso desses drivers proprietários para o crescimento do linux como desktop competindo com o windows, mas entra a filosofia opensource que alguns acham estar sendo estuprada. Eu acredito que cada um deveria escolher o que coloca na maquina, eu não ligaria se meu micro fosse apenas 90% livre, que independente do kernel já é assim com sun-java, flash, skype,...

Algo para se lembrar...: Eu me lembrei de algo que acho muito importante neste debate, grande parte desta estrutura que hoje chamamos de software livre cresceu a partir do descontentamento do Richard Stallman quando tentou MELHORAR um DRIVER de uma impressora (aconteceram mais eventos e já se falava em Software LIVRE, mas o próprio RS sempre dá enfase a este fato).

Este pode ser considerado por muitos um fato apenas emblemático, mas na minha opnião não é, drivers livres é uma das bandeiras mais antigas defendidas pela comunidade do software livre, de qualquer kernel.

Se algumas empresas começam a demonstrar interesse agora, é porque elas estão prevendo que é um mercado que irá se expandir e elas querem entrar neste mercado com risco ZERO.

Para não dizer que isso é ridículo, eu diria que é no mínimo irritante, elas querem uma plataforma mais "CONFORTÁVEL" para criar alguns drivers, se seus produtos decolarem continuam a suportar, senão elas puxam o carro e nós ficamos na mão. Uma mão lava a outra.

Não existe investimento com risco ZERO e se gigantes como a IBM, Computer Associates, Sun e Novell estão liberando algumas patentes para desenvolvimento livre, não pode ser um grupo menor que deve conseguir essa flexibilização da nossa parte.

Se elas estão vendo um mercado promissor, a primeira investida será sempre tentando o risco zero, mas esperam para ver, se a OSI, o OSDL, a LI e alguns medalhões da comunidade como John "maddog" Hall, Eric Raymond, e principalmente Linus Torvalds se manisfestarem contra esta "abertura" unilateral, com certeza haverão outras propostas. Uma "patentezinha" ali, um "padrãozinho" proprietário acolá, e assim caminha a humanidade.

Mostre a sua cara!
Get Mono!
Eu quero World of Warcraft!

E o direito de escolha, onde: E o direito de escolha, onde fica ?
É mais fácil optar por equipamentos que tenham driver aberto (ou esperar que eles chegem) para os mais adeptos da filosofia FSF.
Seria uma opção a mais para aquele que não tem um driver livre optar por uma solução de driver proprietário até que a livre chegue (se chegar).

Marcelo, empresas americanas: Marcelo, empresas americanas não fornecem o código, não adianta teimar com isso. Em alguns casos são até mesmo proibidas disso.

Uma API dentro do kernel que permitisse o uso dum driver externo seria a única solução sem esperar por uma engenharia reversa ou a boa vontade de empresas de hardware.

Um driver binário do fabricante seria uma opcao a mais para quem usa linux, e não uma opção já embutida no kernel. Mesmo o windows quando se instala um driver do fabricante há um alerta e pede uma confirmação onde voce fica ciente dos riscos. É por aí.

O direito de escolha está co: O direito de escolha está continua preservado, a filosofia do software livre se transformou em um modelo de desenvolvimento.

E neste modelo de desenvolvimento não entram drivers binários, pronto, se você não gosta deste modelo de desenvolvimento não dê suporte a ele.

Isto é mesma coisa que ficar colocando a culpa pela Microsoft não lançar uma versão do Microsoft Office para GNU/Linux no desenvolvimento do kernel.

O modelo de desenvolvimento livre não agrada a MS e ela não dá suporte (apesar que isso pode mudar, ver acordo com a JBoss), ponto final, ela fica lá no sistema dele, desenvolvendo a tecnologia dela, quem quiser usar windows tem se que adaptar ao que a MS acha conveniente, porque conosco tem que ser diferente?

Liberdade deve ser bilateral, estas empresas tem o direito de pedir uma API e os desenvolvedores do kernel tem o direito de negar, quer mais liberdade do que isso? Para mim este debate é um pouco irrelevante.

Mostre a sua cara!
Get Mono!
Eu quero World of Warcraft!

não: o Hurd já existia quando o Linux começou, ele não é seu sucessor, apenas o kernel utópico de um sistema GNU utópico e ideal. Ele foi reescrito diversas vezes mas nunca parece sair do papel. É o problema de quando se é ambicioso demais: você acaba tropeçando...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

E neste modelo de desenvolvim: E neste modelo de desenvolvimento não entram drivers binários, pronto, se você não gosta deste modelo de desenvolvimento não dê suporte a ele.
Isto é mesma coisa que ficar colocando a culpa pela Microsoft não lançar uma versão do Microsoft Office para GNU/Linux no desenvolvimento do kernel.

Voce ainda não entendeu, não se esta pedindo para colocar drivers binarios no (no sentido de dentro de) kernel do linux, apenas que se inclua no kernel uma API para que drivers externos sejam carregados. O kernel continua a ser tocado da mesma maneira.

Isso concederia à alguns a opção de desenvolver código fechado e a outros de usa-lo ou não. Uma API bem feita de driver é a do windows, os fabricantes sabem como fornecer um .INF e qual o formato que ele deve ter, informacoes básicas PnP e compatibilidade de versoes.

Da mesma forma fica a cargo do linux apenas fornecer orientação e uma API básica e se alguém desejar desenvolver um driver proprietário sob tais especificaçoes poderá faze-lo.

Ou seja precisamos apenas duma API básica e especificacoes o restante deixa para o mercado produzir. Se a genius fornecer um driver para o scanner dela e for fechado, ótimo e ainda haverá a opção dela abrir o código algum dia.

Não quero desmenti-lo, mas d: Não quero desmenti-lo, mas driver binário ou opensource pode ser bom ou ruim, dependendo do angulo de visão, quase todos os argumentos sobre ser ruim ou bom podem ser invertidos para ambos os lados.
Faça o teste voce mesmo e verá.

Para Lembrar ou Para não Esquecer ?: Se existir um Kernel com partes (drives) não livres e outro 100% livre, fico 100% livre.
Se o problema é manter o 'segredo' do código, eles podem criar uma distribuição "Não-GNU/Linux" com os códigos secretos e disponibilizarem apenas os binários para a comunidade.

Usa quem quiser


Adailton
Linux Registered User 107410

É usuário de Linux? Mostre a sua cara!

retrocesso?: Nao sei se existe muito o q acrescentar na discussao, mas toda essa historia de linux e software livre nao começou pela insatisfação de algumas pessoas pela situação q as grandes empresas impunham aos usuarios? E toda a comunidade de software livre nao se juntou pra 'combater' tudo isso, e fazer a diferença? E esse nao vem sendo o objetivo há tempos? O debian, por exemplo, que vem totalmente com programas abertos e tal.. isso é maravilhoso! Agora, sendo só uma API ou nao.. o linux vai estar abrindo as pernas realmente, como se estivesse se rendendo... ou seja, isso foge de toda a ideia original do projeto.. é um retrocesso... mesmo q seja somente uma 'interface' pra que as grandes empresas se 'infiltrem' no sistema.. nao sei se to viajando, mas é o q acho.

chinaski_

Tem que ter API para Drivers Fechados, SIM!: __Uma API que desse suporte a Drivers Binários seria excelente...Essa API seria isolada do restante do Kernel e adverteria o usuário quanto a possibilidade de danos ocasionados por drivers mal escritos...Um simples acesso ao binário seria suficiente para o hardware funcionar...Em caso de mal funcionamento uma reversão simples para o driver livre, desenvolvido pela comunidade, como os Drivers nvidia do XFree, seria oferecida para compatibilidade...

__E digo mais, tais drivers seriam testados pelas distribuições antes de serem inclusos como opção, selos poderiam ser criados, para recomendar ou não. A API poderia também ser extra Kernel, ficando num repositório opcional, a mesma também seria enjoada, não aceitando qualquer tipo de driver ou porcaria mal escrita. As possibilidades são infindas...Caberia aos desenvolvedores do Kernel garantir compatiblidade com a versão anterior do Driver Fechado, o que não é tãaao díficil...Cito um exemplo, compilei o Driver para Winmodem PCtel, no Kernel 2.4.21 e depois copiei os binários no Kernel 2.4.25, sem nenhuma compilação no Kurumin 3.0, qual foi minha surpresa ao saber que o Driver funcionou!Ou seja o Linux suportou um driver binário!

__Drivers binários podem acessar diretamente dispositivos internos, como entradas USB, sem necessidade de mudanças loucas no Kernel a cada nova compilação...

__Não sejam ingênuos, fabricantes não vão abrir o código de seus drivers, para que possamos fazer nossa ¨revolução¨.Isso nunca vai acontecer, é muito utópico...Já existem Wrappers como o NidisWrapper que permitem que redes Bluetooth seja usadas, aposto que os usuários dessas redes com Linux adoram...

__A comunidade Linux é muito exigente, grampos, BUGs, vírus e outras anomailias acabariam queimando a empresa desenvolvedora...Se você programa lixo para Linux você acaba indo para lá...Basta ver os drivers da ATI, são ruins e todo mundo mete o pau...Nenhum linuxer se engana, pois os drivers não prestam mesmo...Não há o que temer, é preciso analisar a relação custo benéficio...Fico triste e p**o quando chego numa loja de informática e o vendedor diz que não funciona no Linux tal hardware...Uma vez o vendedor que era técnico disse: ¨Não funciona porque o Linux não suporta drivers fechados, e o fabricante não abre o código!¨.O Scanner Color-Page Vivid PRO-II tá comendo poeira aqui em casa, e o fabricante, a Genius,sempre vai usar este artíficio como justificativa....No final a nossa ideologia não apresentou benéficio algum, além de inflar nosso ego com MOral e ética. Onde está a relação custo-benéficio...Já sei, É melhor ficar com hardware em casa parado, porque o fabricante não abre o código...Que idiotice!As possíveis vantagens sobrepujam em muito os eventuais efeitos colaterais...Que podem ser contornados com uma fiscalização severa, coisa que os usuários do WIndows não fazem.

O Linux já está comercial.: O Linux já está comercial. E até demais para o meu gosto. Incluir código fechado no kernel, além de ferir a própria GPL, será uma porta para acabar com o Software Livre. O que temos de fazer ? Nós somos o mercado. Eles dependem de nós, e não o contrário. Se ele não quer abrir o código, comprem na mão de outro.

Onde vc viu isso?: Incluir código fechado no Kernel???

Felipe Raposo

Quem não entende o quê?: Meu amigo,

Você é que não entende o modelo de desenvolvimento do software livre, no caso do kernel quem decide como é, o que entra e o sai e como deve acontecer é o Linus Torvalds, se ele disser NÃO, é não e ponto final.

Pode ser que ele ou outras pessoa nos níveis mais "altos" dos desenvolvedores do kernel já tenham alguma proposta para isso ou até com esta proposta, pode ser que ele pense em outra forma que não seja uma API, isso meu amigo, só que participa das listas do desenvolvimento do kernel sabe.

A liberdade que o software livre dá é que se ele resolver que não quer nem saber, "nada" (entre aspas porque depende de licença) impede que apareça um fork do kernel, só que isso não acontece porque todo mundo sabe que é tecnicamente inviável.

E eu continuo com a opinião de que muitos conceitos tradicionais do universo de T.I. estão mudando por causa da "revolução" do software livre, a pergunta é:

Qual o problema que mesmo sendo possível criar esta API, não fazer por questões ideológicas e continuar a pressiosar os fabricantes por drivers livres?

Qual o problema nissso? O Linux cresceu e chamou a atenção por causa dessa ideologia, porque abandonar estas bandeiras por popularidade?

Estes questionamentos só estão aumentando agora porque mais e mais técnicos estão começando a trabalhar com o sistema, e é normal que eles procurem as soluções mais tradicionais, mas o Linux (e o Software Livre de maneira geral) não veio para ser tradicional, ele veio para ser diferente e na medida do possível melhor.

Então porque não levar em consideração a ideologia por trás do software livre deste movimento?

Quando falamos em ideologia as pessoas associam com esquerda e comunismo por condicionamento, mas se esquecem que o captalismo, neo-liberalismo e direita também são ideologias e não há mal nenhum nisso.

Os modelos de negócio são diferentes sim e isso é saudável, cada um tem a liberdade de gostar e trabalhar com aquele que se identificar mais.

Mostre a sua cara!
Get Mono!
Eu quero World of Warcraft!

(Estou sem acentos) : (Estou sem acentos)
Linux esta contido no Software Livre.
Linux nao eh o conjunto de Software Livre...

(Estou sem acentos) : (Estou sem acentos)
O Theo de Raadt estah fazendo isso, de ujm lado ele conseguiu que alguns fabricantes liberassem o driver sob licença BSD, do outro algumas empresas deixaram ateh de disponibilizar/atualizar os drivers que faziam pro OpenBSD.

Disse tudo e mais um pouco!: Depois de trocentos comentários, você disse tudo, Bebeto. Quem quiser Linux para usar apenas GPL que fique com o kernel e seus drivers de engenharia reversa.
Garanto que um anos após essa liberação da API para drivers proprietarios, teremos drivers tão bons quantos os da Apple.

(Estou sem acentos) : (Estou sem acentos)
O perigo eh o seguinte, Linus eh o que se chama de "despota benevolente", ele manda no projeto, o que ele quer vai pro kernel, mas ele jah se deixou levar por pressao de outros desenvolvedores, ele manda, mas ele nao faz tudo. Um exemplo eh que ele nao eh contra inserir o suporte a DRM no kernel, mas a maioria absoluta dos desenvolvedores sao, por isso ele ainda nao incluiu este suporte. Muitos desses desenvolvedores trabalham em companhias de hardware, se eles tomarem partido desta briga e ficarem do lado das companhias duvido que Linus aguentara a pressao por muito tempo.

(Estou sem acentos) : (Estou sem acentos)
Isso para mim eh mais um sofisma do que realidade, varias empresas usam Linux no desktop corporativo, a sensaçao do momento no mercado corporativo eh o Wifi, basicamente hoje eh usado por empresas, pois bem o uso do Wifi por estas empresas cresce a cada dia, nem um mercado potencial em expansao (empresas que usam Linux e Wifi) estah fazendo com que as companhias doem codigo para o kernel. A galera dos BSDs sairam na frente desta vez, Theo de Raadt comecou a fazer pressao em cima dessas fabricantes de hardware e jah conta com um numero consideravel de drivers de codigo aberto para placas e roteadores Wifi, o FreeBSD 6 tem um bom suporte a Wifi depois de um 5 ter deixado a desejar. Aumento de numero de consumidores nao significa que alguem va doar codigo por ai.

" Você é que não entende o: " Você é que não entende o modelo de desenvolvimento do software livre, no caso do kernel quem decide como é, o que entra e o sai e como deve acontecer é o Linus Torvalds, se ele disser NÃO, é não e ponto final."

ISSO é LIBERDADE ??? Até o Bill Gates ficou pasmo com essa...

(Estou sem acentos) : (Estou sem acentos)
Eu ia chegar a isso num comentario que vou fazer mas vou pegar um gancho no seu comentario.
Em tese a API nao seria obrigatoria, voce pode muito bem desativar o suporte na hora da compilacao. Eu acho que isso geraria dois tipos de distribuicao as com suporte a API e as sem suporte, alem de que muitas distribuicoes colocam alguns recursos como modulos e outras como recurso "built in" na imagem do kernel, a API, a meu ver, nao faria com que todos os drivers funcionassem 100% em qualquer distribuiçao. Outra observacao eh de que um driver binario que funcionasse no Linux poderia facilitar a engenharia reversa pois usaria recursos do sistema, voce nao teria de ficar fuçando num driver de Windows ou Mac para descobrir algo, por outro isso nao significaria drivers livres 100% funcionais, O fato da Nvidia ter um driver binario para Linux nao fez o driver livre ter alguns recursos essenciais que o hardware oferece, se bem que o driver para o X independe do time do kernel.

(Estou sem acentos) : (Estou sem acentos)
O pessoal fala que os fabricantes deviam eh usar BSD, pois eles sao "liberais". Eu considero isso um engano, a comunidade BSd eh mais purista no sentido de abertura de codigo. Theo de Raddt anda presionando empresas de placas e roteadores Wifi para liberarem o driver sob licença BSD. O pessoal do FreeBSD quando quer o suporte a algum hardware arregaça as mangas e fazem um trabalho de qualidade por conta propria. Apesar de o FreeBSD e o NetBSD serem abertos ao uso de drivers binarios eles preferem codigo aberto.

A maioria destes caras do lin: A maioria destes caras do linux é um bando de retardado mental. Por isso que o linux está a 10 anos para se tornar um desktop viável e até agora não emplacou. Eles realmente não querem enxergar. Veja por exemplo, a análise comparativa que saiu sobre o MS-office e o openoffice ( java sucks). E estes retardados ainda querem comparar os dois. Bem, quem usa linux e gosta de linux precisa de drivers bons e os melhores são obviamente os fornecidos pelas empresas que fazem o hardware. Logo se esta é a melhor solução nesta direção vamos usá-la. Nós temos quye ter uma forma de se relacionar com a visão das empresas e não querer que todos eles pensem que nem a gente. Abraços a todos. Esta idéia me parece muito boa a menos que alguém tenha outra melhor.

Liberdade: É sim, pois qualquer um que discordar pode criar um fork a qualquer momento. Só que esse fork não será, provavelmente, muito popular. Você pode fazer o que quiser na sua árvore, só não pode mexer na do tio Linus sem a permissão dele. Nada mais justo.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Exatamente!: Outra fenômeno significativo é que o Linux chegou em um estágio de evolução que muitos hardwares possuem drivers desenvolvidos sob a GPL antes que sejam lançados drivers proprietários. É só olhar os drivers que funcionam nas diversas plataformas para as quais as distribuições Linux são portadas ou para as quais são desenvolvidas.

Hoje, sem medo de errar, o kernel do Linux é o software mais avançado do planeta. Foi uma dura corrida até este ponto, mas chegamos lá.

Saludos!

Magno K - LinUser # 142.324

Nunca vi...: Nunca vi fabricante de harware ganhar dinheiro com os drivers. Tanto Nvidia quanto vários outros fabricantes de Hardware escondem a tecnologia no hardware. Os drivers apenas intergem com o SO. A comparação com a Coca-Cola na minha opinião é infeliz, pois a fórmula é o próprio produto em si. Ademais se a comunidade faz engenharia reversa, não venha me dizer que isso não ocorre com software comercial. É por isso que as empresas high-end estão sempre com novidades, correndo na frente pois os produtos novos são facilmente copiados. Não vejo sentido em não abrirem os fontes. Certa vez comprei uma placa de vídeo que não tinha suporte para PAL-M embora o chipset tivesse suporte para tal. Tive que brigar por duas semanas com o fabricante para que simplesmente abrisse uma opção para este sistema de cor no driver. Felizmente ele me atendeu mas se não quisesse, simplesmente eu estava até hoje vendo coisas em P&B porque o driver era fechado. Eis o porque penso que os drivers para Linux devem ser abertos.

Um porém.: Quando não se tenta ser ambicioso, também se tropeça. E muito mais.

-- ofranja

Por isso eu não concordo com: Por isso eu não concordo com essa nomenclatura da GNU de chamar a GPL de "livre". Ela é livre por obrigação, não por opção, o que é uma liberdade a menos. Livre mesmo só a BSD.

E é isso.

-- ofranja

Uma coisa é os drivers serem: Uma coisa é os drivers serem abertos, o que também prefiro, outra é o Linux não dá suporte aos fechados, o que não agrada e também não é produtivo.

O Linux tem de ser compatível com os dois!

"Imagine a Nvidia disponibili: "Imagine a Nvidia disponibilizar o codigo do seu driver? Seria como a coca-cola disponibilizar sua formula."

Sempre achei que o negócio deles fosse fazer placas de vídeo e GPUs, não drivers.

-- ofranja

E daí que a GPL força o sof: E daí que a GPL força o software a continuar sendo livre? Se um país é democrático por obrigação (100% dos casos) isso não o torna menos democrático.

Se você quer reclamar que a GPL tira a sua "liberdade" de tirar a liberdade dos outros, aí tudo bem. Mas ela é livre sim.

Sei que não foi o que você: Sei que não foi o que você quis dizer, mas só para deixar o claro o sistema GNU está longe de ser utópico! Começou faz um bom tempo (1983), e hoje praticamente só uma parte não está pronta para produção (o kernel).

É interessante notar que o kernel do sistema GNU (GNU Mach+Hurd) é parecido com o XNU do OS X (Mach+FreeBSD). E se não bastasse, o GNUstep (criado no início da década de 90) foi criado para ser compatível com o OPENSTEP, padrão adotado pela Apple em 96, que hoje é o Cocoa do OS X. Ou seja, o GNU e o OS X teriam kernels e ambientes gráficos bem parecidos, não fosse o insucesso em popularizar essas duas partes do GNU, as duas pelo mesmo motivo: demora no desenvolvimento.

API: Nada como um bom isolamento com uma API para resolver este problema.

Manter um software livre/aberto propositalmente menos modular, para evitar softwares proprietários utilizando pedaços deste primeiro, é uma faca de dois gumes: dificulta sim este uso indesejado, mas também dificulta o desenvolvimento e complica o projeto / a manutenção. Eu, pessoalmente, não faria isso em software nenhum que eu mantivesse.

E é isso.

-- ofranja

GNU/Debian não existe; exist: GNU/Debian não existe; existe o Debian GNU/Linux, que usa o Linux como kernel.
Existem sub-projetos no Debian que não usam o Linux como kernel, como o Debian GNU/Hurd e GNU/kFreeBSD.

I may say I'm a dreamer: I may say i'm a dreamer but i'm not the only one

Sonhar com un SO Linux com todos drivers nas distros ou
disponibilizados com o cd do fabricante, penso que não
seja um sonho só meu.

Quantos novos possíveis usuários ainda não migraram para
o SO Linux e ainda que não se fixaram nele devido a esses
drivers. Principalmente os do Winmodens já que a grande
quantidade deles, ainda usa conexão discada.

O Carlos Morimoto fechou um tópico no fórum do Kurumin Linux
porque um usuário, que não era mal-educado mas não parecia
entender certas dificuldades de suporte para todos os
winmodens na praça em relação ao novo kernel(s)
Nesse caso de winmodens, usuários como eu sou também apesar
de ter conexão banda larga (uso meu modem intel) quando dá chabú
na dsl. Um winmodem custa em média R$ 35,00 reais e se os nossos
caros usuários fizessem uso apenas de dois ou três modelos para
padronizar, ajudaria muito. Querem aproveitar os modens que vem
nas placas on board ou gastam este valor em coisas desnecessárias
mas não compram os modens que tem suporte fácil no Linux.

Há muitos usuários que sabem lidar com isso. Mas esses já são
usuários que sabem como fazer ou pelo menos fazem um esforço.

Só não concordo com Carlos Morimoto quando ele disse que a
maioria dos usuários estão migrando para conexôes de banda larga
Isso aqui é Brasil, então vamos com calma.

Porém, aí porém, lendo os comentários dos leitores, com todas
essas observações e argumentos, eu nem sei como posicionar-me
a respeito de...

Vamos de acordo como pensam a comunidade ou as empresas Linux.

----------------------------------------------------------------
O Planeta Terra é Debian-Azul amado pela Rosa Cor. Gira em .RPM
com um céu iluminado por flocos luminosos em .TGZ
SO LINUX
No mais, tudo jaz porque os Teretetês são ETeTês dos Teterês

Driver da Nvidia?: Olha, o driver da Nvidia não interessa. Eles podem ficar com os drivers. Existem centanas de pessoas que podem escrever outros. Não é esse o problema. A dificuldade dos desenvolvedores de software livre é que a empresas que fabricam os hardwares não disponibilizam as especificações de seus produtos, dos processadores, da placa, etc, dificultando o trabalho deles.

Saludos!

Magno K - LinUser # 142.324

Nota de R$ 100,00, vida extra: Nota de R$ 100,00, vida extraterrestre e Hurd são três coisas que tem gente que garante que existe, alguns juram até que ja viram mas sei não ,acho que é tudo lenda para contar para as crianças...

Liberdade precisa de um contexto: A GPL visa a liberdade primordialmente sobre a comunidade/sociedade. Isto é, a licença presa pela garantia da liberdade considerando-se o todo.

Por exemplo, fazendo uma analogia, podemos instituir a liberdade para que cada cidadão faça o que quiser, inclusive seja tão "livre" que possa tirar a liberdade alheia --esta é sua concepção.

Nos moldes da GPL, teríamos uma liberdade mais agrangente, que concede regalias ao cidadão com restrições, objetivando preservar as liberdades alheias, do conjunto.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Resposta: Coloquei minha opinião sobre esse assunto aqui.

O que vocês acham?

certo: concordo plenamente

Completamente de acordo: Completamente de acordo

vou me preocupar com isso...: "Eu, pessoalmente, não faria isso em software nenhum que eu mantivesse."

...quando vc estiver mantendo software do calibre do kernel Linux.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Uau...: "Sempre achei que o negócio deles fosse fazer placas de vídeo e GPUs, não drivers."

Essa foi muito boa!

Ué, os BSD têm suporte a ha: Ué, os BSD têm suporte a hardware semelhante ao do Linux...

Livre como?: Você diz software livre ou código aberto? Por exemplo, o SUSE desde a versão 9.1 (acho que antes até), tem vários kerneis sendo o non-gpl um deles (que inclui fontes de proprietários). Acho que a relevância é mais do fato de se é ou não é código aberto, e não se é estritamente GPL ou não (convenhamos que essa flexibilização é importante, acredito). Apesar disso, em um desktop comum, poucos são os elementos totalmente fechados, afinal, a maioria dos módulos são mantidos pela própria comunidade (mesmo quando a empresa não revela absolutamente NADA sobre o hardware).
Alguém pode me citar algo importante que poderia ser perdido se o Linus não aceitar mais código fechado (binários) no kernel (acho que no caso de softwares não GPL poderiamos ter um grande problema, vocês não acham?).
Eu não tenho um posição ainda quanto a questão de uso de código apenas GPL, mas uma quanto a proposta dos japoneses é incabível atualmente.
Pra eles é muito mais fácil liberar a fonte, é quase garantia de que aquilo vai funcionar 'a vida toda' (com a comunidade mantendo sem cobrar por isso).

Essa API "estável" nunca vai: Essa API "estável" nunca vai existir.

É só observar como anda o desenvolvimento da árvore 2.6 do kernel, dita *estável*. Muitas vezes há mudanças na API de uma microversão para outra.

Acho muito difícil que isso funcione, e que seja aceito pelos desenvolvedores do Linux.

..: Existem centenas de pessoas que podem escrever outros caso tivessem o material (especificações mencionadas por você) para fazê-lo.. coisa que não acontece, sendo assim, os drivers fechados como os da NVidia continuam sendo a melhor opção...

Quanto ao comentário do carinha que falou que havia pensado que o negócio da NVidia é hardware, fica uma dúvida...
Porque será que as placas da NVidia, mesmo tendo um hardware, na melhor das hipóteses parecidos com o da ATI (IMHO o hardware da ATI é superior) possui um desepenho tão melhor que a ATI quando está rodando sob plataforma linux... humm é, acho que a unica coisa que influência no desempenho é o hardware utilizado mesmo... a forma como ele se comunica com o restante do sistema não faz diferença, essa diferença de desepenho entre ATI e NVidia no linux deve ser por causa de algum outro fator não conhecido pela humanidade

Putz, eu só tomei vergonha n: Putz, eu só tomei vergonha na cara pra ler o artigo original depois que li seu post ew fui checar na fonte (e no google). E achei a idéia genial. Putz, o X.org se modularizou, o kernel bem que poderia fazer o mesmo.

BSD Livre: Sempre tem alguém pra falar que "BSD é mais livre que GPL"...

...da mesma forma que uma prostituta é mais livre que uma pessoa consciente de suas necessidades e das necessidades dos outros que dependem dela.

Liberdade total e irrestrita é contraditória. Deve-se buscar o que realmente vale.

Por fim, se empresas não quiserem seguir as regras do jogo, teram que arcar com o prejuiso de não ter seu hadware suportado pelo kernel mais portável e completo já feito.

blah blah blah: Quanta falacao inocua...

Para cada 10 linhas de comentario, deveria haver 1 linha de codigo commitado. Ou um send-pr(1) feito.

Não gostei da atitude, apesa: Não gostei da atitude, apesar de não me caber jugá-la. Seu comentário foi interessante e contundente em certos aspectos.
Mas o que eu realmente não gostei foi o título do blog e o início do texto, acho desnecessário e não ajuda a comunidade, mas isso é tão subjetivo quando uma premissa, seja ela qual for.
Acredito que aqui seja o espaço para que a comunidade troque idéias, experiências e informações sobre assuntos relacionados ao software livre (até um pouco além disso, claro). Lembre-se: Unanimidade não se faz com a maioria, e sim com todos. Se você não pensa como vários outros pensam, então, pelo que me consta, não existe unanimidade, logo, não existe a burrice (além da dos ignorantes - que não é o seu caso NMHO).

NMHO = na minha humilde opinião

> E o direito de escolha, ond: > E o direito de escolha, onde fica ?

Você tem toda a liberdade para criar um fork do kernel Linux e providenciar sua própria API.

O termo "liberdade" está sendo usado de forma indiscriminada, isso é ruim. E a liberdade do desenvolvedor de fazer o que quer no seu código, oras?

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

RE:API para drivers proprietários para o Linux: Elvis, essa é uma idéia que venho defendendo há anos e o resultado sempre foi esse: discussões religiosas e acaloradas. Sem essa API/Interface estável para drivers binários (mesmo os livres), o avanço do linux no desktop está comprometido. Mesmo em ambiente de servidor as coisas se complicam. Já tive a necessidade de instalar um sistema proprietário, que usa módulos do kernel proprietário, em um servidor e ser obrigado a manter kernel com vulnerabilidade porque o driver não funcionou com a atualização. Isso em um kernel que sofreu apenas uma atualização de segurança, de uma distribuição enterprise. Foi necessário esperar uma nova atualização do fabricante, para que o sistema pudesse ser inicializado com o novo kernel.

Em ambiente desktop não é diferente. Fiz uma atualização de kernel essa semana (fornecido pela própria distribuição) que fez com que minha máquina não inicializasse em modo gráfico pois o driver da NVidia apresentou erros devido à versão do kernel ser diferente daquela para a qual o módulo foi compilado. O VMware Player também parou de funcionar, assim como o cliente vpn. Alguns vão dizer que isso só ocorreu porque estou utilizando drivers e softwares proprietários proprietários. Sim. E no mundo real é impossível você trabalhar e se manter produtivo e competitivo sem fazer uso de alguma ferramenta proprietária.

Outra coisa: Queremos que o desktop linux atinja as massas? Não estou me referindo a sistemas vendidos a baixo custo, em supermercados ou financiados que, antes de dar o primeiro boot, sofre uma mudança de sistema operacional (geralmente "genérico") pois o sistema que veio instalado é difícil de se utilizar e não suporta aquele modelo de scanner que acabou de ser lançado.

Se quisermos que o desktop linux se torne realidade, é essencial o suporte a drivers binários pois:

- Facilita para o usuário leigo/não interessado em compilar seus drivers. Pense naquela professora que acabou de comprar um scanner novinho, veio o cdrom com o driver (código fonte) e instruções sobre como instalá-lo. Além de saber como compilar e instalar drivers através de código fonte, ainda é necessário ter as ferramentas de desenvolvimento instaladas. Um absurdo do ponto de vista de um usuário leigo/não técnico.

- Mesmo quando há o código fonte de determinado dispositivo, se o mesmo for recente e não estiver incluído em sua distribuição, você terá que recompilá-lo (e será obrigado a saber como se faz isso) para que tenha seu dispositivo funcionando. Se atualizar o kernel, seja por qual razão, terá que recompilar o driver novamente. Um colega de trabalho adquiriu um laptop de modelo recente. Praticamente todos os dispositivos são suportados (wireless, rede), entretanto, por ser modelo novo, os drivers, apesar de disponíveis em código fonte, não fazem (não faziam, me parece que já foram incluídos) parte do kernel, portanto, não estavam disponíveis. Para ter a rede funcionando foi necessário baixar o driver em outro computador, gravar em um pen drive e transferir para latpot, instalar ambiente de desenvolvimento e compilar. Procedimento que toma tempo e ainda exige a presença de um técnico ou nerd (caso você não seja nenhum dos dois) para manter um ambiente que é utilizado primariamente como desktop básico.

Se o pessoal não tratar muito bem dessa questão de suporte a drivers, o linux continuará com presença bem restrita no ambiente desktop. Um sistema que talvez possa vir a ser uma resposta a isso é o OpenSolaris. O Solaris sempre teve excelente compatibilidade binária e espero que o linux a tenha um dia.

Texto do Stallman sobre a LGPL: Richard Stallman escreveu um excelente texto intitulado Por que você não deveria usar a LGPL para sua próxima biblioteca.

Basicamente ele defende que o desenvolvedor deveria disponibilizar seu trabalho sob uma licença menos restritiva (como a LGPL) somente se não há um diferencial atrativo em relação aos concorrentes proprietários. Porque do contrário, isto é, usando por exemplo a GPL, provavelmente não compensaria aos desenvolvedores que utilizarão sua biblioteca ficarem restritos a não poderem fechar o código. Mas se o software se destaca notoriamente, licenciá-lo como GPL pode induzir seus utilizadores a fazerem o mesmo, pois caso negativo terão que providenciar outra solução --talvez seja inviável.

O Stallman cita o exemplo da importante biblioteca Readline (GPL) que, dada sua exclusividade, acaba forçando os desenvolvedores (que requerem a funcionalidade da Readline) a liberarem seu código (GPL), simplesmente porque a qualidade é tal que não existe substituto LGPL (ou BSD-like) à altura.

O Linux hoje já tem seu nicho, principalmente no que tange os servidores. Isto é, pode-se afirmar que o Linux passou de "apenas mais um kernel" para uma solução importante e fundamental para muitos. Sendo assim, dificultar a inclusão de drivers binários pode criar um efeito parecido com o referido pelo Stallman, ou seja, tenderia a pressionar os desenvolvedores de hardware ou a liberarem as especificações ou já providenciarem o driver em uma licença livre. E isso é excelente!

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

A questão é sem duvida pole: A questão é sem duvida polemica.
Mas vale lembrar que já usamos alguns "modulos" para o kernel que são de codigo fechado. O driver de alguns modems tem que ser compilados para cada kernel, não podem ser distribuidos em formato binario.

O pedido por uma API faz sentido no contexto do desktop domestico. O usuario comercial tem alguma liberdade na hora da escolha do hardware que ele quer plugar no seus PCs. Uma empresa pode se dar ao luxo de uma impressora PostScript nativa; um usuario domestico nem sempre pode.

Uma API permitiria a distribuição de drivers binarios que funcionassem em qualquer distribuição (até onde eu entendo).

Mas o quê seria melhor? Os desenvolvedores do Kernel criarem esta API ou a industria se reunir e criar esta API (como um modulo?)? Porque nada impede a industria de fazer sua propria incursão no codigo do kernel e deixar que as distros decidam se usam o Patch ou não.

E, a proposito, o quê tem de errado com "drivers" no "user space" ? Alguns dizem que são mais seguros do que embutidos no Kernel. Por que ninguem mais discute o assunto? Confesso minha falta de informção sobre o assunto porque ninguem mais discute isto.

Mas uma coisa é certa; esta API tem que ser de código completamente aberto e tem que ser um patch ou modulo, não pode ser inserida no kernel compulsoriamente !!!!!!!!!

Quado eu tiver grana vou comprar uma impressora PostScript. Mas por enquanto uso uma que não tem drive nativo para Linux. O driver original para Windows tem mais recursos e tem uma interface propria que oferece alguns luxinhos. Isto pesaria na hora da compra para um usuario domestico.

Para finalizar:

Entre um hardware com driver codigo fechado e um que fosse opensource
eu não pensaria duas vezes em usar o opensource, mesmo tendo que compilar o codigo para cada PC que eu tivesse que usar o hardware. Segurança é palavra de ouro no mundo Linux.

- Facilita para o usuário le: - Facilita para o usuário leigo/não interessado em compilar seus drivers. Pense naquela professora que acabou de comprar um scanner novinho, veio o cdrom com o driver (código fonte) e instruções sobre como instalá-lo. Além de saber como compilar e instalar drivers através de código fonte, ainda é necessário ter as ferramentas de desenvolvimento instaladas. Um absurdo do ponto de vista de um usuário leigo/não técnico.

Para mim isso reflete qual distribuição você esta usando pois as que facilitam a vida do usuário como o SUSE, não requer que você compile um grande número de módulos, já que a própria distro fica com essa responsabilidade, incluindo fixes para atualizações futuras.
O fato aqui não é se o Kernel deve suportar o binário fechado, mas sim se a empresa libera ou não o código. Se o código é liberado, as distros e a comunidade fazem o resto.
No Linux você tem uma área imensa a ser explorada pelo usuário. Compilar um módulo é muito legal e indica o nível de liberdade que você consegue ter no Linux, não tente tirar isso ou abrandar. Linux não é Windows! Mas como eu disse ainda sim você DEVE escolher o hardware adequado (e existe uma gama ENORME de hardware suportado oficialmente e com fonte livres). Não é mais caro nem mais penoso, apenas necessita do uso de alguma pequena porção de massa cinzenta. A situação da NVIDIA aqui é muito complicada mesmo, não dá pra ser GPL, infelizmente. Esse é o maior contra ponto.

Mesmo quando há o código fonte de determinado dispositivo, se o mesmo for recente e não estiver incluído em sua distribuição, você terá que recompilá-lo (e será obrigado a saber como se faz isso) para que tenha seu dispositivo funcionando. Se atualizar o kernel, seja por qual razão, terá que recompilar o driver novamente. Um colega de trabalho adquiriu um laptop de modelo recente. Praticamente todos os dispositivos são suportados (wireless, rede), entretanto, por ser modelo novo, os drivers, apesar de disponíveis em código fonte, não fazem (não faziam, me parece que já foram incluídos) parte do kernel, portanto, não estavam disponíveis. Para ter a rede funcionando foi necessário baixar o driver em outro computador, gravar em um pen drive e transferir para latpot, instalar ambiente de desenvolvimento e compilar. Procedimento que toma tempo e ainda exige a presença de um técnico ou nerd (caso você não seja nenhum dos dois) para manter um ambiente que é utilizado primariamente como desktop básico.

Se você está instalando um novo kernel das fontes, compilar um módulo seria o de menos nesse caso... No windows você teria que simplesmente jogar fora o seu hardware, no Linux não, o pior dos piores seria digitar ./configure, make;make install (já que o resto é só clique&clique).
Fico imaginando quantas coisas boas poderiam ser perdidas se tudo daqui pra frente fosse na base dessa API. De fato, o BSD sempre é uma opção.

Só para dar o contra-ponto (: Só para dar o contra-ponto (já que os argumentos estão excelentes): E o mundo 'lá fora'? E as patentes dos fabricantes e de seus parceiros, e os "segredos" que fazem A diferença para com a concorrência (que também não libera nada sob GPL). É difícil, não?
Para ser totalmente GPL o mundo inteiro teria que mudar (e sabemos que isso não ocorrerá durante o nosso período de vida...) :)

Exato: O negócio da NVidia é exatamente esse: fazer placas. Ela não sabe fazer software, nem é muito boa em fazer drivers. É exatamente por esse motivo que os drivers da NVidia - bem como da maioria das empresas fabricantes de hardware - é repleto de código produzido de outras empresas, que a NVidia licencia para incluir no seu driver.

A NVidia pode utilizar esse código, e distribuir o driver binário, mas ela não pode distribuir o código-fonte da outra empresa, já que o negócio dessa hipotética outra empresa é exatamente esse: vender códigos que empresas como a NVidia utiliza em seus drivers. Uma empresa com esse modelo de negócio nunca ofereceria à NVidia uma licença que permita à NVidia distribuir sob uma licença livre aquilo que é o seu ganha-pão.

Pouco importa se a NVidia quer ou não distribuir seu driver sob uma licença livre. Ela simplesmente não pode fazê-lo.

--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante

Nunca diga nunca: Essa API "estável" nunca vai existir.

Mentira. Estabilização de API eventualmente TEM que acontecer. As syscalls, por exemplo, estão estáveis a anos.

É aceitável que, em grandes mudanças do kernel, como da série 2.4 para a 2.6, a API mude, e que, com isso, seja necessário novos drivers. Mas é totalmente possível manter a API intacta durante uma série. Isso é consequência da maturidade do código, e não uma utopia inatingível.


--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante

Não se pode cair nessa armad: Não se pode cair nessa armadilha de conquistar o Desktop a qualquer custo. Vários comentários lembraram o ponto crucial da questão.

Isso impedirá a auditoria nos códigos das tais APIS que mesmo, apenas acessando o kernel podem por erro ou maldade fazelo retornar a velha mensagem "Kernel panic", aí estaríamos começando a fazer como no outro sistema que se tem que dar 3000.000.000 de control+alt+del por dia.

Se o preço da popularidade para o linux for esse estaremos fazendo o jogo deles (cedendo) e não o contrário.

Não tem que ter API NÃO!: Esses tais deveriam dar suporte a um sistema que se encaixe no seu perfil, já que não podem abrir o código. Querem fazer do linux igual "a casa da mãe joana" que roda tudo de forma oculta.

O preço para a conquista do Desktop não pode ser este. Quem deve ceder?
A comunidade permitindo isso? Ou eles abrindo seus códigos?

SOU CONTRA SIM, QUER CÓDIGO SECRETO CRIA UM SO CARA!

Engraçado, há mais de dez a: Engraçado, há mais de dez anos o sistema desses retardados roda em supercomputadores pois pelo fato dos códigos serem auditáveis os erros são corrigidos de verdade.

Sou contra sim. Se eles querem manter os códigos secretos, que abandonem o Linux, ele sobreviverá sem eles!

Não só mais alguém.: Não concordo com essa do "sempre tem mais alguém". Eu prefiro GPL, no sentido etimológico da palavra "preferir", mas não deixo de conhecer suas características.

"Liberdade total e irrestrita é contraditória. Deve-se buscar o que realmente vale."

Esse é o discurso comum da maioria dos "seguidores" da GPL [e de algumas certas correntes políticas].

Liberdade total e irrestrita não é contraditória: contraditório é você ter liberdade e fazer mau uso dela, de forma que alguém tenha que restringí-la. Infelizmente, isso é algo comum, mas não deixa de ser a principal contradição.

Gostaria de saber, no seu contexto, "o que realmente vale". Para mim, o que vale é a liberdade, em primeiro lugar. Mas essa é minha opinião, não obrigo ninguém a concordar com ela.

É interessante notar que a GPL é uma licença prática, feita para funcionar em meio ao "mundo globalizado". Por isso, ela abre mão de um pouco de liberdade para dar a segurança do código aberto aos desenvolvedores. É algo que funciona, mas.. terei que citar Benjamin Franklin? ;-)

-- ofranja

Deste calibre, impossível.: Não se preocupe. Provavelmente nunca vou manter um software deste calibre, já que não costumo programar em linguagens de médio-nível nem escrever softwares não-modulares propositalmente. ;-)

-- ofranja

Hm?: Não querendo ser rude, mas que parte do meu comentário você não entendeu? Para te dar uma ajuda: falei de engenharia de software, não de licenças.

-- ofranja

Experiência.: Nota de R$ 100,00 eu já vi, e já bootei uma versão do GNU/Hurd também. Acho que só os extra-terrestres escaparam ilesos dessa. :-)

-- ofranja

"Uma empresa com esse modelo: "Uma empresa com esse modelo de negócio nunca ofereceria à NVidia uma licença que permita à NVidia distribuir sob uma licença livre aquilo que é o seu ganha-pão."

Conheço empresas de software que desenvolvem software livre. Se a nVidia não vai ganhar nada diretamente com isso, muito bem poderia fazer um contrato com uma dessas, não concorda? A escolha é do cliente, dizem.

-- ofranja

aplicatiavos: Existe no Linux um mecanismo que proiba o usuário de USAR aplicativos proprietários?

Dessa forma, também acho que não deva haver um mecanismo que proíba o usuário de USAR drivers proprietarios.

o Mundo perfeito ?: O problema é que eles NUNCA vão abrir o código.

Fico pasmo, como alguem pode: Fico pasmo, como alguem pode supor um fork como contra-argumentação apenas para encerrar a conversa que objetiva melhorar algo que outros tem interesse.
Deixa o fork para quando estão esgotadas as opçoes, como essa discussão que está sendo feito aqui. Como foi o caso do Interbase, XFree, Xoops, phpnuke,.... enquanto for discussão deixem as luzes de idéias aparecerem e supliquem por um merge de idéias e não um fork.

Não estou contente com o pre: Não estou contente com o presidencialismo, posso fazer um fork ?
Não estou contente com a forma com que os juizes demonstram parciliadade, posso fazer um fork ?

Nem todos, tem a habilidade técnica suficientes para fazer tudo na vida, mas tem capacidade de julgar o que parece estar errado e discutir o assunto, alguns sugeriram "isto" outros "aquilo", voce sugeriu um "fork", no que um "fork" ajudaria ? ou voce acha que desprender esforços num fork é muito bom para quando não se tem opnião sobre o que é melhor ?

não modular??!: já experimentou usar lsmod? E se tiver com vontade de algo mais, experimente insmod. Da man page:

"insmod installs a loadable module in the running kernel."

in the _running_ kernel...

Não muito diferente de uma arquitetura de plugins...

A maioria absoluta dos programadores do planeta nunca vai criar software do calibre do Linux. Nem usando técnicas extremas de modularização, linguagens de mais alto nível ou a última "ferramenta de produtividade" da M$...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Drivers proprietários antigos em kernels novos: olhem o meu caso de problemas com drivers proprietários antigos em versões de kernel mais novas;

http://www.susebr.org/newbb+viewtopic.topic_id+253+forum+6+post_id+1056.htm#forumpost1056

Acho que tem relação com essa discussão e inclusive aproveito o ensejo para que digam se a minha suspeita é valida ou não.

Obrigado,

Anderson.
http://www.zlinux.com.br
http://www.smsystems.com.br

Drivers proprietários antigos em kernels novos: olhem o meu caso de problemas com drivers proprietários antigos em versões de kernel mais novas;

http://www.susebr.org/newbb+viewtopic.topic_id+253+forum+6+post_id+1056.htm#forumpost1056

Acho que tem relação com essa discussão e inclusive aproveito o ensejo para que digam se a minha suspeita é valida ou não.

Obrigado,

Anderson.
http://www.zlinux.com.br
http://www.smsystems.com.br

Não precisa ser uma única p: Não precisa ser uma única pessoa --embora acredito que um bom desenvolvedor possa criar essa API e mantê-la numa espécie de patch. Veja o que aconteceu com o XFree, sofreu um fork por um grupo e este está prosperando. Está é a liberdade.

Essas empresas que desejam incluir uma API no kernel, que juntem-se e façam um fork. Mas é demais obrigar o desenvolvedor do código a colocar e manter algo que definitivamente não lhe agrada.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Mas quem sabe isso pode ser t: Mas quem sabe isso pode ser também uma pressão contra patentes? Uma empresa que depende de código GPL não poderá patentear o seu software se pretende distribui-lo. Se for LGPL e outras que podem ser fechadas, a empresa terá um motivo a mais para pensar em patentes.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Que assunto polêmico !!!: Eu estava esperando a hora em que isso fosse acontecer.
Isso é a primeira grande batalha na guerra pelo Desktop LINUX.
É terrível que as coisas tenham se deturpado a tal ponto que nós não tenhamos mas direito a tomar nossas próprias decisões.
As empresas de hardware estão querendo fazer a força com o LINUX o que elas sempre fizeram com os outros SO's na base de acordos comerciais.

O problema é que as pessoas nunca pararam para pensar nisso.
Quem já teve que instalar um hardware antigo em uma versão nova do WIN ou pasmem, algum muito novo, sabe que muitas vezes a única opção é trocar de hardware.
Mas como nunca houve opção, simplesmente ficávamos fulos da vida, reclamávamos aos quatro ventos, enchiamos o saco de todos ao nosso redor e ...... trocávamos o hardware (não havia mais nada a fazer).

Agora, com o LINUX e o OPENSOURCE, esse problema está vindo a tona com cada vez mais frequencia. Infelizmente as pessoas não sabem havaliar o preço das escolhas que fazem e acabam escolhendo o caminho mais fácil.

Acho que mesmo que fosse viável, o que acho que não é, esse tipo de artifício apesar de oferecer alguma vantagem inicial pode acabar nos privando de várias vantagens a longo prazo.

Essa briga vai ser boa e longa. Infelizmente em muitas áreas de hardware estamos presos em monopólios ou cartéis (2 ou 3 empresas grandes é que mandam e desmandam).

Quando a concorrência pesar sobre essa turma eles vão aderir com certeza a filosofia do OPENSOURCE, mas até lá muita agua vai rolar e muita pressão vai ser feita.

Sim, nao modular.: O termo "modular", no meu comentario, nao foi usado no sentido de "kernel modular/monolitico", mas no sentido atribuido pela Engenharia de Software: "software modular" eh aquele cuja resolucao do problema eh dividida em partes, sendo que cada parte eh responsavel por resolver um segmento e/ou conjunto de segmentos especificos do problema. Diz a regra da boa abstracao que voce pode (e deve) ter camadas tambem, sendo que as mais altas utilizam os servicos das mais baixas, entre outros varios ensinamentos [que o Google indexa muito bem].

O caso aqui eh que o Linux nao eh um bom exemplo de modularidade. Exemplo: internamente, voce vai ver [se olhar o codigo fonte] que ele tem function calls entre modulos diferentes e independentes, o que vai totalmente contra a boa pratica de programacao [isso acontece em alguns drivers de som ALSA, se nao no proprio soundcore.ko]. Alem disso, a possibilidade de carregar arquivos-objeto em tempo de execucao nao ajuda em nada nessa modularidade da ES: conheco um SO para sistemas embutidos que consiste apenas numa inicializacao [especifica de arquitetura] e num conjunto de binarios ELF, sem qualquer separacao user/kernelspace, e cujo codigo esta anos-luz a frente do Linux em termos de modularidade, boas praticas de programacao, e independencia de arquitetura. Ah sim, e esse sistema eh monolitico. :-)

A maioria absoluta dos programadores do planeta nunca vai criar software do calibre do Linux. Nem usando técnicas extremas de modularização, linguagens de mais alto nível ou a última "ferramenta de produtividade" da M$...

Se nao me engano, alguns projetos como o Mozilla ou o OpenOffice sao maiores que o kernel, mesmo usando linguagens de mais alto nivel.

Tambem eh bom lembrar que o Linux eh deste tamanho porque se mantem todos os drivers de todas arquiteturas junto com o codigo do kernel em si. Codigo "generic" ou "common", que realmente conta para os mantenedores principais, eh algo pequeno, e eh mantido por pessoal especifico [com muitas colaboracoes de fora].

E eh isso.

--
http://semanticas.blogspot.com
- Opiniões sobre mundo tecnológico.

http://tlang.blogspot.com
- Pesquisas e experiências sobre tecnologia.

Humm...: Quem achar que o GNU/Linux não é bom para seus drivers, então passe a usar outro sistema operacional. Ninguem é obrigado a usa-lo. Nós (usuarios ou empresas) escolhemos o sistema que melhor se adequar ao seu perfil. Para muitos este é o Windows e para outros o GNU/Linux. A filosofia do Software Livre é completamente contra o desenvolvimento de programas fechados, porque ela deveria dar suporte nativo a este tipo de coisa?!

Aceitar uma API para melhorar o suporte a drivers binarios fechados é renunciar ao seu discurso e ser completamente contraditorio. Muitos anos já se passaram nesta luta por um desenvolvimento aberto entre programadores/empresas/usuarios e nós estamos chegando lá (veja o quanto já caminhamos) e agora um grupo quer mudar tudo em que acreditamos por que é do interesse deles?! Porque eles podem nos exigir aceitar codigo fechado e nós não podemos exigir que eles abram o codigo?!

Quanto ao problema do fork: ele é uma opção de liberdade sim. Você pode fazer um fork do Windows ou do Mac OS X? Software Livre não significa que os desenvolvedores tenham que adotar tudo que o usuarios quer e bem entende, significa que se você não está gostando pode ir lá e fazer o seu ou pegar de um grupo/empresa que fez um diferente e modificar a vontade.

No mais, é apenas isso.

_________________

Live free or die.

"Todo coração é uma célula revolucionaria." - Os educadores
"Suenan los tambores de la rebelion, sueña mi pueblo, sueña mi razon." - Manu Chao

Eu adoraria: Eu adoraria utilizar TODOS os drivers para o meu hardware fornecidos pelos fabricantes. Eu utilizo o da NVIDIA - e nenhuma alternativa livre me dá desempenho semelhante; 3d então, nem se fala.

Hoje, se acho que algo está errado na minha placa de som, simplesmente não posso reclamar com o fabricante. Nem com minha placa wireless. É fato, eles não são suportados.

Quem diz que possuir uma camada de abstração que possibilite drivers proprietarios é ruim é o mesmo que dizer que nenhum software proprietário deveria rodar sob Linux. Inclua na lista coisas como Oracle, por exemplo. Isso é simplesmente ridículo.