C'est pour Manuel que je poste cet extrait (dans LKML à propos des webcam
philips)
we don't keep hooks that are there purely for binary
drivers. If somebody wants a binary driver, it had better be a whole
independent thing - and it won't be distributed with the kernel.
Linus
Bref, pas de drivers binaires, et pas de facilité pour les intégrer. Par
contre, pas de problème avec les firmware (qui ne tournent pas dnas le
noyau, mais bien sur un autre "cpu" que l'OS principal de la machine).
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
we don't keep hooks that are there purely for binary drivers. If somebody wants a binary driver, it had better be a whole independent thing - and it won't be distributed with the kernel.
Linus
Bref, pas de drivers binaires, et pas de facilité pour les intégrer.
Mais où diable as tu lu ça ?
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
On 2004-08-28, Emmanuel Florac <eflorac@imaginet.fr> wrote:
we don't keep hooks that are there purely for binary
drivers. If somebody wants a binary driver, it had better be a whole
independent thing - and it won't be distributed with the kernel.
Linus
Bref, pas de drivers binaires, et pas de facilité pour les intégrer.
Mais où diable as tu lu ça ?
--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.
we don't keep hooks that are there purely for binary drivers. If somebody wants a binary driver, it had better be a whole independent thing - and it won't be distributed with the kernel.
Linus
Bref, pas de drivers binaires, et pas de facilité pour les intégrer.
Mais où diable as tu lu ça ?
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
Sylvain POURRE
Bref, pas de drivers binaires, et pas de facilité pour les intégrer. Par contre, pas de problème avec les firmware (qui ne tournent pas dnas le noyau, mais bien sur un autre "cpu" que l'OS principal de la machine).
Bonjour
En général, la tendance est d'augmenter le nombre de matériels supportés. Dans ce cas, c'est une bonne partie des Webcams qui ne le seront plus (phillips et compatibles comme ma Quickcam 4000 pro);-(( Le driver est composé de 2 modules: PWC, incorporé dans l'arborescence du kernel et qui est libre. PWCX, qui gère les fonctionnalités plus avancées de la webcam (compression...) et qui n'est diffusé qu'en binaire à cause d'une clause de non divulgation (NDA) signée par l'auteur. Je pense que les mainteners du kernel/usb ont supprimé cette possibilité à cause du risque de procès pour viol de copyright dans la mesure où cette partie binaire n'est pas contrôlable. La démarche est différente pour Nvidia qui ne livre aussi qu'un module binaire mais qui n'est pas intégré dans le noyau. L'auteur des modules considère qu'en faire un module binaire non intégré dévaloriserait son travail en ramenant son module à un 2 ème rang et veut même faire retirer la partie PWC, qui permet une utilisation basique de la Webcam, des sources du kernel:
http://www.smcc.demon.nl/webcam/
(encore un beau problème de GPL en vue )
En plus de se prémunir contre d'éventuelles manoeuvres tordues à la sauce SCO et/ou M$; il y a peut-être aussi la volonté de peser sur les fabriquants. Maintenant que Linux est sorti de la clandestinité et commence à représenter un marché non négligeable, il est nécessaire de les conduire à sortir des drivers pour leurs matériels ou, au minimum, à fournir les specs.
-- Sylvain
Bref, pas de drivers binaires, et pas de facilité pour les intégrer. Par
contre, pas de problème avec les firmware (qui ne tournent pas dnas le
noyau, mais bien sur un autre "cpu" que l'OS principal de la machine).
Bonjour
En général, la tendance est d'augmenter le nombre de matériels
supportés. Dans ce cas, c'est une bonne partie des Webcams qui ne le
seront plus (phillips et compatibles comme ma Quickcam 4000 pro);-((
Le driver est composé de 2 modules:
PWC, incorporé dans l'arborescence du kernel et qui est libre.
PWCX, qui gère les fonctionnalités plus avancées de la webcam
(compression...) et qui n'est diffusé qu'en binaire à cause d'une clause
de non divulgation (NDA) signée par l'auteur.
Je pense que les mainteners du kernel/usb ont supprimé cette possibilité
à cause du risque de procès pour viol de copyright dans la mesure où
cette partie binaire n'est pas contrôlable. La démarche est différente
pour Nvidia qui ne livre aussi qu'un module binaire mais qui n'est pas
intégré dans le noyau.
L'auteur des modules considère qu'en faire un module binaire non intégré
dévaloriserait son travail en ramenant son module à un 2 ème rang et
veut même faire retirer la partie PWC, qui permet une utilisation
basique de la Webcam, des sources du kernel:
http://www.smcc.demon.nl/webcam/
(encore un beau problème de GPL en vue )
En plus de se prémunir contre d'éventuelles manoeuvres tordues à la
sauce SCO et/ou M$; il y a peut-être aussi la volonté de peser sur les
fabriquants. Maintenant que Linux est sorti de la clandestinité et
commence à représenter un marché non négligeable, il est nécessaire de
les conduire à sortir des drivers pour leurs matériels ou, au minimum, à
fournir les specs.
Bref, pas de drivers binaires, et pas de facilité pour les intégrer. Par contre, pas de problème avec les firmware (qui ne tournent pas dnas le noyau, mais bien sur un autre "cpu" que l'OS principal de la machine).
Bonjour
En général, la tendance est d'augmenter le nombre de matériels supportés. Dans ce cas, c'est une bonne partie des Webcams qui ne le seront plus (phillips et compatibles comme ma Quickcam 4000 pro);-(( Le driver est composé de 2 modules: PWC, incorporé dans l'arborescence du kernel et qui est libre. PWCX, qui gère les fonctionnalités plus avancées de la webcam (compression...) et qui n'est diffusé qu'en binaire à cause d'une clause de non divulgation (NDA) signée par l'auteur. Je pense que les mainteners du kernel/usb ont supprimé cette possibilité à cause du risque de procès pour viol de copyright dans la mesure où cette partie binaire n'est pas contrôlable. La démarche est différente pour Nvidia qui ne livre aussi qu'un module binaire mais qui n'est pas intégré dans le noyau. L'auteur des modules considère qu'en faire un module binaire non intégré dévaloriserait son travail en ramenant son module à un 2 ème rang et veut même faire retirer la partie PWC, qui permet une utilisation basique de la Webcam, des sources du kernel:
http://www.smcc.demon.nl/webcam/
(encore un beau problème de GPL en vue )
En plus de se prémunir contre d'éventuelles manoeuvres tordues à la sauce SCO et/ou M$; il y a peut-être aussi la volonté de peser sur les fabriquants. Maintenant que Linux est sorti de la clandestinité et commence à représenter un marché non négligeable, il est nécessaire de les conduire à sortir des drivers pour leurs matériels ou, au minimum, à fournir les specs.
-- Sylvain
Emmanuel Florac
Le Sat, 28 Aug 2004 14:44:24 +0000, Irvin Probst a écrit :
Mais où diable as tu lu ça ?
Sur lkml. Dans un thread consacré aux webcams philips et à l'abandon du support (explications dans mon post suivant).
-- Quidquid latine dictum sit, altum sonatur
Le Sat, 28 Aug 2004 14:44:24 +0000, Irvin Probst a écrit :
Mais où diable as tu lu ça ?
Sur lkml. Dans un thread consacré aux webcams philips et à l'abandon du
support (explications dans mon post suivant).
Sur lkml. Dans un thread consacré aux webcams philips et à l'abandon du support (explications dans mon post suivant).
Oui ça je sais :) C'est tes conclusions qui me laissaient dubitatif.
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
Emmanuel Florac
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
Je pense que les mainteners du kernel/usb ont supprimé cette possibilité à cause du risque de procès pour viol de copyright dans la mesure où cette partie binaire n'est pas contrôlable.
Non, en fait Linus a expréssement prévu de rejeter tout driver binaire hors des sources officielles du kernel 2.6. Dans le cas du driver PWC/PWCX, le problème vient du fait que le driver PWC (GPL) contient des "hooks" pour héberger le driver PWCX (propriétaire binaire) qui lui ajoute des fonctionnalités. Linus refuse qu'aucun driver intégré dans le noyau ne comporte ce genre de facilité pour s'intégrer avec un driver propriétaire, mais ce n'est pas non plus le coeur du problème : il était facile de modifier le PWC pour qu'il ne comporte plus les "hook" vers le driver proprio; cependant les développeurs du module ont demandé à ce qu'il soit retiré globalement du noyau (sur l'air de "si vous ne voulez pas PWCX, alors pas de PWC non plus"). À la suite de cela, Linus a obtempéré, considérant que si un développeur ne souhaite pas que son travail soit inclus dans le noyau , il ne doit pas l'être.
Pour ce qui est de la position des développeurs du driver, je ne sais plus trop pourquoi ils ont pris la mouche. De toute façon rien n'empèche de patcher le noyau avec le dernier driver existant. ILs ne souhaitent plus maintenir le module, cependant Linux a suggéré à ceux intéressés par ce driver de demander gentiment aux développeurs le droit de reprendre la maintenance de PWC (sans les hooks PWCX), ce qui selon lui a de bonnes chances d'aboutir et permettrait rapidement de réintégrer ce driver dans le sourcetree.
Il semblerait que certains intervenants de lkml soient par ailleurs décidés à faire un reverse-engineering de PWCX, pour faire un driver complet et GPL, ce qui réglerait la question définitivement.
-- Sutor ne ultra Crepidam.
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
Je pense que les mainteners du kernel/usb ont supprimé cette possibilité
à cause du risque de procès pour viol de copyright dans la mesure où
cette partie binaire n'est pas contrôlable.
Non, en fait Linus a expréssement prévu de rejeter tout driver binaire
hors des sources officielles du kernel 2.6. Dans le cas du driver
PWC/PWCX, le problème vient du fait que le driver PWC (GPL) contient des
"hooks" pour héberger le driver PWCX (propriétaire binaire) qui lui
ajoute des fonctionnalités. Linus refuse qu'aucun driver intégré dans
le noyau ne comporte ce genre de facilité pour s'intégrer avec un driver
propriétaire, mais ce n'est pas non plus le coeur du problème : il
était facile de modifier le PWC pour qu'il ne comporte plus les "hook"
vers le driver proprio; cependant les développeurs du module ont demandé
à ce qu'il soit retiré globalement du noyau (sur l'air de "si vous ne
voulez pas PWCX, alors pas de PWC non plus").
À la suite de cela, Linus a obtempéré, considérant que si un
développeur ne souhaite pas que son travail soit inclus dans le noyau ,
il ne doit pas l'être.
Pour ce qui est de la position des développeurs du driver, je ne sais
plus trop pourquoi ils ont pris la mouche. De toute façon rien
n'empèche de patcher le noyau avec le dernier driver existant. ILs ne
souhaitent plus maintenir le module, cependant Linux a suggéré à ceux
intéressés par ce driver de demander gentiment aux développeurs le
droit de reprendre la maintenance de PWC (sans les hooks PWCX), ce qui
selon lui a de bonnes chances d'aboutir et permettrait rapidement de
réintégrer ce driver dans le sourcetree.
Il semblerait que certains intervenants de lkml soient par ailleurs
décidés à faire un reverse-engineering de PWCX, pour faire un driver
complet et GPL, ce qui réglerait la question définitivement.
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
Je pense que les mainteners du kernel/usb ont supprimé cette possibilité à cause du risque de procès pour viol de copyright dans la mesure où cette partie binaire n'est pas contrôlable.
Non, en fait Linus a expréssement prévu de rejeter tout driver binaire hors des sources officielles du kernel 2.6. Dans le cas du driver PWC/PWCX, le problème vient du fait que le driver PWC (GPL) contient des "hooks" pour héberger le driver PWCX (propriétaire binaire) qui lui ajoute des fonctionnalités. Linus refuse qu'aucun driver intégré dans le noyau ne comporte ce genre de facilité pour s'intégrer avec un driver propriétaire, mais ce n'est pas non plus le coeur du problème : il était facile de modifier le PWC pour qu'il ne comporte plus les "hook" vers le driver proprio; cependant les développeurs du module ont demandé à ce qu'il soit retiré globalement du noyau (sur l'air de "si vous ne voulez pas PWCX, alors pas de PWC non plus"). À la suite de cela, Linus a obtempéré, considérant que si un développeur ne souhaite pas que son travail soit inclus dans le noyau , il ne doit pas l'être.
Pour ce qui est de la position des développeurs du driver, je ne sais plus trop pourquoi ils ont pris la mouche. De toute façon rien n'empèche de patcher le noyau avec le dernier driver existant. ILs ne souhaitent plus maintenir le module, cependant Linux a suggéré à ceux intéressés par ce driver de demander gentiment aux développeurs le droit de reprendre la maintenance de PWC (sans les hooks PWCX), ce qui selon lui a de bonnes chances d'aboutir et permettrait rapidement de réintégrer ce driver dans le sourcetree.
Il semblerait que certains intervenants de lkml soient par ailleurs décidés à faire un reverse-engineering de PWCX, pour faire un driver complet et GPL, ce qui réglerait la question définitivement.
-- Sutor ne ultra Crepidam.
Emmanuel Florac
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
e pense que les mainteners du kernel/usb ont supprimé cette possibilité à cause du risque de procès pour viol de copyright dans la mesure où cette partie binaire n'est pas contrôlable.
Ce n'est PAS DU TOUT la position officielle de Linus. La position officielle est purement technique et rigoureusement valide : un driver binaire est incontrôlable, il est inclus dans le noyau et peut y provoquer des bugs que les développeurs du noyau ne peuvent que difficilement tracer; de plus un driver binaire ne fonctionne que sur une version précise, une config noyau précise et compilée avec une version de gcc précise, bref c'est une véritable chierie pour l'utilisateur (voire une malédiction). Nvidia a contourné le problème avec une certaine élégance en fournissant un empaquetage compilable pour ses drivers binaires, ce qui ne règle que le dernier problème ci-dessus : je me suis farci un réseau pratiquement inutilisable sur une carte-mère nForce2 pendant plus d'un an, justqu'à ce que nVidia daigne fournir un driver correct (il y a 15 jours...). Qu'on ne me dise pas qu'il y a de fabuleux secrets dans une carte réseau 100Bt comme il en existe des dizaines de types...
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
e pense que les mainteners du kernel/usb ont supprimé cette possibilité
à cause du risque de procès pour viol de copyright dans la mesure où
cette partie binaire n'est pas contrôlable.
Ce n'est PAS DU TOUT la position officielle de Linus. La position
officielle est purement technique et rigoureusement valide : un driver
binaire est incontrôlable, il est inclus dans le noyau et peut y
provoquer des bugs que les développeurs du noyau ne peuvent que
difficilement tracer; de plus un driver binaire ne fonctionne que sur une
version précise, une config noyau précise et compilée avec une version
de gcc précise, bref c'est une véritable chierie pour l'utilisateur
(voire une malédiction).
Nvidia a contourné le problème avec une certaine élégance en
fournissant un empaquetage compilable pour ses drivers binaires, ce qui ne
règle que le dernier problème ci-dessus : je me suis farci un réseau
pratiquement inutilisable sur une carte-mère nForce2 pendant plus d'un
an, justqu'à ce que nVidia daigne fournir un driver correct (il y a 15
jours...). Qu'on ne me dise pas qu'il y a de fabuleux secrets dans une
carte réseau 100Bt comme il en existe des dizaines de types...
--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
e pense que les mainteners du kernel/usb ont supprimé cette possibilité à cause du risque de procès pour viol de copyright dans la mesure où cette partie binaire n'est pas contrôlable.
Ce n'est PAS DU TOUT la position officielle de Linus. La position officielle est purement technique et rigoureusement valide : un driver binaire est incontrôlable, il est inclus dans le noyau et peut y provoquer des bugs que les développeurs du noyau ne peuvent que difficilement tracer; de plus un driver binaire ne fonctionne que sur une version précise, une config noyau précise et compilée avec une version de gcc précise, bref c'est une véritable chierie pour l'utilisateur (voire une malédiction). Nvidia a contourné le problème avec une certaine élégance en fournissant un empaquetage compilable pour ses drivers binaires, ce qui ne règle que le dernier problème ci-dessus : je me suis farci un réseau pratiquement inutilisable sur une carte-mère nForce2 pendant plus d'un an, justqu'à ce que nVidia daigne fournir un driver correct (il y a 15 jours...). Qu'on ne me dise pas qu'il y a de fabuleux secrets dans une carte réseau 100Bt comme il en existe des dizaines de types...
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Emmanuel Florac
Le Sat, 28 Aug 2004 16:41:46 +0000, Irvin Probst a écrit :
Oui ça je sais :) C'est tes conclusions qui me laissaient dubitatif.
Quelles conclusions? Linus ne souhaite pas favoriser l'utilisation de drivers binaires, et par ailleurs aucun ne doit être inclus dans le sourcetree du noyau.
Un autre extrait :
Loading binary modules is considered OK in the kernel in case the binary module was implemented independently of the kernel.
Charger des modules binaires dans le noyau est considéré comme OK si le module était implémenté indépendamment du noyau (sans utilsier les sources du noyau je suppose).
So if the same logic was applied to mplayer and win32 codecs, then that would be considered OK.
Ainsi si on applique la même logique à mplayer et aux codecs win32, c'est OK.
What is not considered OK is to develop a module with the sole intent to use it with the kernel and then distribute it as binary only. While we kernel developers can't do much about it, at least we don't support it by allowing specific hooks for that.
Ce qui n'est pas considéré comme OK,, c'est de développer un module avec comme seule intention l'utilisation dans le noyau LInux, puis de la distribué sous forme binaire uniquement (Nvidia dans ce cas précis, prétend utiliser la même: base de code pour le driver windwos et Linux et donc ne pas devoir faire des drivers GPL... tu parles Charles). BIen que nous, développeurs du noyau, ne puissions rien y faire, au moins nous n'y aidons pas en autorisant des connecteurs spécifiques pour cela.
In the case of pwc+pwcx, pwcx (the decoder module) is completely useless without pwc (the driver module), and thus is obviously falling in the second class described above.
Dans le cas de PWC/PWCX, PWCX (le module décodeur proprio) est totalement inutilisable sans PWC (le pilote, en GPL), et par conséquent est de toute évidence dans le second cas décrit ci-dessus (donc en contradiction avec la GPL, donc interdit).
-- Les défauts n'apparaissent qu'après que le programme ait passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Sat, 28 Aug 2004 16:41:46 +0000, Irvin Probst a écrit :
Oui ça je sais :)
C'est tes conclusions qui me laissaient dubitatif.
Quelles conclusions? Linus ne souhaite pas favoriser l'utilisation de
drivers binaires, et par ailleurs aucun ne doit être inclus dans le
sourcetree du noyau.
Un autre extrait :
Loading binary modules is considered OK in the kernel in case the binary
module was implemented independently of the kernel.
Charger des modules binaires dans le noyau est considéré comme OK si le
module était implémenté indépendamment du noyau (sans utilsier les
sources du noyau je suppose).
So if the same logic was applied to mplayer and win32 codecs, then that
would be considered OK.
Ainsi si on applique la même logique à mplayer et aux codecs
win32, c'est OK.
What is not considered OK is to develop a module with the sole intent to
use it with the kernel and then distribute it as binary only. While we
kernel developers can't do much about it, at least we don't support it by
allowing specific hooks for that.
Ce qui n'est pas considéré comme OK,, c'est de développer un module
avec comme seule intention l'utilisation dans le noyau LInux, puis de la
distribué sous forme binaire uniquement (Nvidia dans ce cas précis,
prétend utiliser la même: base de code pour le driver windwos et Linux
et donc ne pas devoir faire des drivers GPL... tu parles Charles).
BIen que nous, développeurs du noyau, ne puissions rien y faire, au moins
nous n'y aidons pas en autorisant des connecteurs spécifiques pour cela.
In the case of pwc+pwcx, pwcx (the decoder module) is completely useless
without pwc (the driver module), and thus is obviously falling in the
second class described above.
Dans le cas de PWC/PWCX, PWCX (le module décodeur proprio) est totalement
inutilisable sans PWC (le pilote, en GPL), et par conséquent est de toute
évidence dans le second cas décrit ci-dessus (donc en contradiction avec
la GPL, donc interdit).
--
Les défauts n'apparaissent qu'après que le programme ait passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
Le Sat, 28 Aug 2004 16:41:46 +0000, Irvin Probst a écrit :
Oui ça je sais :) C'est tes conclusions qui me laissaient dubitatif.
Quelles conclusions? Linus ne souhaite pas favoriser l'utilisation de drivers binaires, et par ailleurs aucun ne doit être inclus dans le sourcetree du noyau.
Un autre extrait :
Loading binary modules is considered OK in the kernel in case the binary module was implemented independently of the kernel.
Charger des modules binaires dans le noyau est considéré comme OK si le module était implémenté indépendamment du noyau (sans utilsier les sources du noyau je suppose).
So if the same logic was applied to mplayer and win32 codecs, then that would be considered OK.
Ainsi si on applique la même logique à mplayer et aux codecs win32, c'est OK.
What is not considered OK is to develop a module with the sole intent to use it with the kernel and then distribute it as binary only. While we kernel developers can't do much about it, at least we don't support it by allowing specific hooks for that.
Ce qui n'est pas considéré comme OK,, c'est de développer un module avec comme seule intention l'utilisation dans le noyau LInux, puis de la distribué sous forme binaire uniquement (Nvidia dans ce cas précis, prétend utiliser la même: base de code pour le driver windwos et Linux et donc ne pas devoir faire des drivers GPL... tu parles Charles). BIen que nous, développeurs du noyau, ne puissions rien y faire, au moins nous n'y aidons pas en autorisant des connecteurs spécifiques pour cela.
In the case of pwc+pwcx, pwcx (the decoder module) is completely useless without pwc (the driver module), and thus is obviously falling in the second class described above.
Dans le cas de PWC/PWCX, PWCX (le module décodeur proprio) est totalement inutilisable sans PWC (le pilote, en GPL), et par conséquent est de toute évidence dans le second cas décrit ci-dessus (donc en contradiction avec la GPL, donc interdit).
-- Les défauts n'apparaissent qu'après que le programme ait passé (avec succès) la phase d'intégration. Loi de Klipstein.
TiTiX
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
À la suite de cela, Linus a obtempéré, considérant que si un développeur ne souhaite pas que son travail soit inclus dans le noyau , il ne doit pas l'être.
/s/Linus/Greg Kroah
Pour ce qui est de la position des développeurs du driver, je ne sais plus trop pourquoi ils ont pris la mouche. De toute façon rien n'empèche de patcher le noyau avec le dernier driver existant.
Il n'a pas pris la mouche subitement, ça fait deja quelques temps que Greg et Nemo se cherchent des poux (cf l'episode de PWC repertorié comme /broken/ a cause d'un petit warning dans le 2.6.6) Il fallait bien que ça explose un jour =)
Pour ce qui est de patcher, ça marchera bien pour pwc, mais on aura plus acces aux fonctions de compressions (vitales pour depasser le ) La plupart des excuses avancées par Nemo ne tiennent pas la route, et si chacun dans cette histoire y avait mis du sien le denouement aurait ete plus heureux pour tout le monde.
-- TiTiX
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
À la suite de cela, Linus a obtempéré, considérant que si un
développeur ne souhaite pas que son travail soit inclus dans le noyau ,
il ne doit pas l'être.
/s/Linus/Greg Kroah
Pour ce qui est de la position des développeurs du driver, je ne sais
plus trop pourquoi ils ont pris la mouche. De toute façon rien
n'empèche de patcher le noyau avec le dernier driver existant.
Il n'a pas pris la mouche subitement, ça fait deja quelques temps que
Greg et Nemo se cherchent des poux (cf l'episode de PWC repertorié comme
/broken/ a cause d'un petit warning dans le 2.6.6)
Il fallait bien que ça explose un jour =)
Pour ce qui est de patcher, ça marchera bien pour pwc, mais on aura plus
acces aux fonctions de compressions (vitales pour depasser le
160x120@10fps)
La plupart des excuses avancées par Nemo ne tiennent pas la route, et si
chacun dans cette histoire y avait mis du sien le denouement aurait ete
plus heureux pour tout le monde.
Le Sat, 28 Aug 2004 17:11:31 +0200, Sylvain POURRE a écrit :
À la suite de cela, Linus a obtempéré, considérant que si un développeur ne souhaite pas que son travail soit inclus dans le noyau , il ne doit pas l'être.
/s/Linus/Greg Kroah
Pour ce qui est de la position des développeurs du driver, je ne sais plus trop pourquoi ils ont pris la mouche. De toute façon rien n'empèche de patcher le noyau avec le dernier driver existant.
Il n'a pas pris la mouche subitement, ça fait deja quelques temps que Greg et Nemo se cherchent des poux (cf l'episode de PWC repertorié comme /broken/ a cause d'un petit warning dans le 2.6.6) Il fallait bien que ça explose un jour =)
Pour ce qui est de patcher, ça marchera bien pour pwc, mais on aura plus acces aux fonctions de compressions (vitales pour depasser le ) La plupart des excuses avancées par Nemo ne tiennent pas la route, et si chacun dans cette histoire y avait mis du sien le denouement aurait ete plus heureux pour tout le monde.
-- TiTiX
sylvain POURRE
Ce n'est PAS DU TOUT la position officielle de Linus. La position officielle est purement technique et rigoureusement valide : un driver binaire est incontrôlable, il est inclus dans le noyau et peut y provoquer des bugs que les développeurs du noyau ne peuvent que difficilement tracer; de plus un driver binaire ne fonctionne que sur une version précise, une config noyau précise et compilée avec une version de gcc précise, bref c'est une véritable chierie pour l'utilisateur (voire une malédiction). Nvidia a contourné le problème avec une certaine élégance en fournissant un empaquetage compilable pour ses drivers binaires, ce qui ne règle que le dernier problème ci-dessus : je me suis farci un réseau pratiquement inutilisable sur une carte-mère nForce2 pendant plus d'un an, justqu'à ce que nVidia daigne fournir un driver correct (il y a 15 jours...). Qu'on ne me dise pas qu'il y a de fabuleux secrets dans une carte réseau 100Bt comme il en existe des dizaines de types...
Bonsoir
Merci de ces précisions. Je comprends l'argument technique encore que le fait que les 3 fichiers livrés dans la bibliothèque de pwcx ne soient pas strippés devrait en faciliter le débugg. Ceci étant posé, au delà des arguments techniques ou politiques (au sens noble), il y a là le résultat d'ego surdimensionnés mais c'est ce qui fait la force, la faiblesse et le charme du libre ;-) Je vous rejoints aussi sur votre dernière remarque qui pourrait aussi s'appliquer au webcams.
-- Sylvain
Ce n'est PAS DU TOUT la position officielle de Linus. La position
officielle est purement technique et rigoureusement valide : un driver
binaire est incontrôlable, il est inclus dans le noyau et peut y
provoquer des bugs que les développeurs du noyau ne peuvent que
difficilement tracer; de plus un driver binaire ne fonctionne que sur une
version précise, une config noyau précise et compilée avec une version
de gcc précise, bref c'est une véritable chierie pour l'utilisateur
(voire une malédiction).
Nvidia a contourné le problème avec une certaine élégance en
fournissant un empaquetage compilable pour ses drivers binaires, ce qui ne
règle que le dernier problème ci-dessus : je me suis farci un réseau
pratiquement inutilisable sur une carte-mère nForce2 pendant plus d'un
an, justqu'à ce que nVidia daigne fournir un driver correct (il y a 15
jours...). Qu'on ne me dise pas qu'il y a de fabuleux secrets dans une
carte réseau 100Bt comme il en existe des dizaines de types...
Bonsoir
Merci de ces précisions. Je comprends l'argument technique encore que le
fait que les 3 fichiers livrés dans la bibliothèque de pwcx ne soient
pas strippés devrait en faciliter le débugg.
Ceci étant posé, au delà des arguments techniques ou politiques (au sens
noble), il y a là le résultat d'ego surdimensionnés mais c'est ce qui
fait la force, la faiblesse et le charme du libre ;-)
Je vous rejoints aussi sur votre dernière remarque qui pourrait aussi
s'appliquer au webcams.
Ce n'est PAS DU TOUT la position officielle de Linus. La position officielle est purement technique et rigoureusement valide : un driver binaire est incontrôlable, il est inclus dans le noyau et peut y provoquer des bugs que les développeurs du noyau ne peuvent que difficilement tracer; de plus un driver binaire ne fonctionne que sur une version précise, une config noyau précise et compilée avec une version de gcc précise, bref c'est une véritable chierie pour l'utilisateur (voire une malédiction). Nvidia a contourné le problème avec une certaine élégance en fournissant un empaquetage compilable pour ses drivers binaires, ce qui ne règle que le dernier problème ci-dessus : je me suis farci un réseau pratiquement inutilisable sur une carte-mère nForce2 pendant plus d'un an, justqu'à ce que nVidia daigne fournir un driver correct (il y a 15 jours...). Qu'on ne me dise pas qu'il y a de fabuleux secrets dans une carte réseau 100Bt comme il en existe des dizaines de types...
Bonsoir
Merci de ces précisions. Je comprends l'argument technique encore que le fait que les 3 fichiers livrés dans la bibliothèque de pwcx ne soient pas strippés devrait en faciliter le débugg. Ceci étant posé, au delà des arguments techniques ou politiques (au sens noble), il y a là le résultat d'ego surdimensionnés mais c'est ce qui fait la force, la faiblesse et le charme du libre ;-) Je vous rejoints aussi sur votre dernière remarque qui pourrait aussi s'appliquer au webcams.
-- Sylvain
Emmanuel Florac
Le Sat, 28 Aug 2004 19:51:31 +0200, TiTiX a écrit :
Pour ce qui est de patcher, ça marchera bien pour pwc, mais on aura plus acces aux fonctions de compressions (vitales pour depasser le )
Oui mais le driver pwcx est en contradiction flagrante avec la GPL, donc il est fatalement interdit (ou à réécrire). Puis la compression franchement... Sur une webcam je ne vois aps bien l'intérêt de dépasser le 160X120 :) (J'ai une webcam philips...)
La plupart des excuses avancées par Nemo ne tiennent pas la route, et si chacun dans cette histoire y avait mis du sien le denouement aurait ete plus heureux pour tout le monde.
Certes. De toute évidence il n'a pas encaissé le refus définitif du driver pwcx (qui encore une fois, n'aurait jamasi du être intégré dans le sourcetree).
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Sat, 28 Aug 2004 19:51:31 +0200, TiTiX a écrit :
Pour ce qui est de patcher, ça marchera bien pour pwc, mais on aura plus
acces aux fonctions de compressions (vitales pour depasser le
160x120@10fps)
Oui mais le driver pwcx est en contradiction flagrante avec la GPL, donc
il est fatalement interdit (ou à réécrire).
Puis la compression franchement... Sur une webcam je ne vois aps bien
l'intérêt de dépasser le 160X120 :) (J'ai une webcam philips...)
La plupart des excuses avancées par Nemo ne tiennent pas la route, et si
chacun dans cette histoire y avait mis du sien le denouement aurait ete
plus heureux pour tout le monde.
Certes. De toute évidence il n'a pas encaissé le refus définitif du
driver pwcx (qui encore une fois, n'aurait jamasi du être intégré dans
le sourcetree).
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Sat, 28 Aug 2004 19:51:31 +0200, TiTiX a écrit :
Pour ce qui est de patcher, ça marchera bien pour pwc, mais on aura plus acces aux fonctions de compressions (vitales pour depasser le )
Oui mais le driver pwcx est en contradiction flagrante avec la GPL, donc il est fatalement interdit (ou à réécrire). Puis la compression franchement... Sur une webcam je ne vois aps bien l'intérêt de dépasser le 160X120 :) (J'ai une webcam philips...)
La plupart des excuses avancées par Nemo ne tiennent pas la route, et si chacun dans cette histoire y avait mis du sien le denouement aurait ete plus heureux pour tout le monde.
Certes. De toute évidence il n'a pas encaissé le refus définitif du driver pwcx (qui encore une fois, n'aurait jamasi du être intégré dans le sourcetree).
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
