J'ai acheté une carte wifi pcmcia Peabird (très peu cher ~39 euros) pour
l'utiliser sur mon powerbook. Parce qu'il n'y aura probablement jamais
de driver libre pour airport extreme, malgré la pétition chez Broadcom.
Après un petit coup de google, j'ai trouvé des sources pour compiler un
module qui devait aller bien (en passant par dlfp et le journal de
boa13) , mais le problème c'est que tout semble fait pour x86, et pas
pour powerpc.
Autre chose, j'ai bien evidemment mis le nez dans les sources, et
modifié ce qu'il fallait (sauf oubli). Résultat, la compilation se passe
très bien (0 warning), l'installation aussi, mais impossible de charger
le module. J'ai aussi tenté un strace qui ne m'a pas appris grand chose,
sauf qu'il ne peut pas créer/qu'il n'existe pas de device (périphérique)
d'un type donné. Faut-il créer (mknod) un/des périphériques spéciaux ?
Je n'ai pas encore essayé le 802.11g, mais en 802.11b, les drivers que j'ai cité marchent bien sur Mac: j'ai testé les chipset ATMEL en USB et le prism avec l'airport sur mon Ibook...
Oui, tu fais bien de le signaler : la carte airport est excellente. Si je comprends bien, c'est un chipset prism, qui est dedans ? Et c'est le module/pilote orinoco avec hermes et airport.
Et ATMEL, tu l'utilises avec quelle carte ?
En ce qui me concerne, j'ai réussi à utiliser le MA111 (mini-usb) de Netgear avec linux-wlan (oui je sais c'est moins bien), mais j'arrive enfin à utiliser le wifi avec mon powerbook.
Y'a juste le wep128 qui ne fonctionne pas encore. Enfin, il fonctionne presque (des paquets sont perdus....),j'ai du rater une "oooption" avec wlan-tcl-ng...
Ceci dit, c'est super important que le 802.11g fonctionne sous Linux.
@+
-- NON AUX BREVETS SUR LES LOGICIELS. Voir http://swpat.ffii.org/
eric b
Salut,
J. Mayer a écrit:
On Tue, 11 Nov 2003 23:50:11 +0100, ericb wrote:
Je n'ai pas encore essayé le 802.11g, mais en 802.11b, les drivers
que j'ai cité marchent bien sur Mac:
j'ai testé les chipset ATMEL en USB et le prism avec l'airport
sur mon Ibook...
Oui, tu fais bien de le signaler : la carte airport est excellente. Si
je comprends bien, c'est un chipset prism, qui est dedans ? Et c'est le
module/pilote orinoco avec hermes et airport.
Et ATMEL, tu l'utilises avec quelle carte ?
En ce qui me concerne, j'ai réussi à utiliser le MA111 (mini-usb) de
Netgear avec linux-wlan (oui je sais c'est moins bien), mais j'arrive
enfin à utiliser le wifi avec mon powerbook.
Y'a juste le wep128 qui ne fonctionne pas encore. Enfin, il fonctionne
presque (des paquets sont perdus....),j'ai du rater une "oooption" avec
wlan-tcl-ng...
Ceci dit, c'est super important que le 802.11g fonctionne sous Linux.
@+
--
NON AUX BREVETS SUR LES LOGICIELS. Voir http://swpat.ffii.org/
Je n'ai pas encore essayé le 802.11g, mais en 802.11b, les drivers que j'ai cité marchent bien sur Mac: j'ai testé les chipset ATMEL en USB et le prism avec l'airport sur mon Ibook...
Oui, tu fais bien de le signaler : la carte airport est excellente. Si je comprends bien, c'est un chipset prism, qui est dedans ? Et c'est le module/pilote orinoco avec hermes et airport.
Et ATMEL, tu l'utilises avec quelle carte ?
En ce qui me concerne, j'ai réussi à utiliser le MA111 (mini-usb) de Netgear avec linux-wlan (oui je sais c'est moins bien), mais j'arrive enfin à utiliser le wifi avec mon powerbook.
Y'a juste le wep128 qui ne fonctionne pas encore. Enfin, il fonctionne presque (des paquets sont perdus....),j'ai du rater une "oooption" avec wlan-tcl-ng...
Ceci dit, c'est super important que le 802.11g fonctionne sous Linux.
@+
-- NON AUX BREVETS SUR LES LOGICIELS. Voir http://swpat.ffii.org/
eric b
J. Mayer
On Wed, 12 Nov 2003 09:52:08 +0100, ericb wrote:
Salut, Salut,
J. Mayer a écrit:
On Tue, 11 Nov 2003 23:50:11 +0100, ericb wrote:
Je n'ai pas encore essayé le 802.11g, mais en 802.11b, les drivers que j'ai cité marchent bien sur Mac: j'ai testé les chipset ATMEL en USB et le prism avec l'airport sur mon Ibook...
Oui, tu fais bien de le signaler : la carte airport est excellente. Si je comprends bien, c'est un chipset prism, qui est dedans ? Et c'est le module/pilote orinoco avec hermes et airport.
Oui, c'est un chipset Prism. Le seul défaut est que la config est bridée par le firmware Apple. Grrr...
Et ATMEL, tu l'utilises avec quelle carte ?
Avec des adaptateurs divers et variés en USB: Belkin, Netgear, et autres (je n'ai plus les références en tête). Le pack ADSL-Wifi Wanadoo utilise un device avec ce chipset, également.
En ce qui me concerne, j'ai réussi à utiliser le MA111 (mini-usb) de Netgear avec linux-wlan (oui je sais c'est moins bien), mais j'arrive enfin à utiliser le wifi avec mon powerbook. Il faut que je mette à jour mon CVS, alors ! Je n'y suis jamais arrivé !
Il est bien, ce petit adaptateur ! Domage que le driver ne respecte pas l'API du kernel (c'est honteux de la part des developpeurs...). Ils auraient mieux fait d'étendre le driver standard (du kernel) pour supporter le Prism 3, je pense, mais bon...
Y'a juste le wep128 qui ne fonctionne pas encore. Enfin, il fonctionne presque (des paquets sont perdus....),j'ai du rater une "oooption" avec wlan-tcl-ng... Ca marche avec les prism standard et les Atmel...
C'est une bonne info...
Ceci dit, c'est super important que le 802.11g fonctionne sous Linux. Oui, c'est toujours bien de voir que Linux n'est pas trop à la traine
malgré le manque de coopération des fabricants de chips !
On Wed, 12 Nov 2003 09:52:08 +0100, ericb wrote:
Salut,
Salut,
J. Mayer a écrit:
On Tue, 11 Nov 2003 23:50:11 +0100, ericb wrote:
Je n'ai pas encore essayé le 802.11g, mais en 802.11b, les drivers
que j'ai cité marchent bien sur Mac:
j'ai testé les chipset ATMEL en USB et le prism avec l'airport
sur mon Ibook...
Oui, tu fais bien de le signaler : la carte airport est excellente. Si
je comprends bien, c'est un chipset prism, qui est dedans ? Et c'est le
module/pilote orinoco avec hermes et airport.
Oui, c'est un chipset Prism. Le seul défaut est que la config est
bridée par le firmware Apple. Grrr...
Et ATMEL, tu l'utilises avec quelle carte ?
Avec des adaptateurs divers et variés en USB:
Belkin, Netgear, et autres (je n'ai plus les références en tête).
Le pack ADSL-Wifi Wanadoo utilise un device avec ce chipset, également.
En ce qui me concerne, j'ai réussi à utiliser le MA111 (mini-usb) de
Netgear avec linux-wlan (oui je sais c'est moins bien), mais j'arrive
enfin à utiliser le wifi avec mon powerbook.
Il faut que je mette à jour mon CVS, alors ! Je n'y suis jamais arrivé !
Il est bien, ce petit adaptateur !
Domage que le driver ne respecte pas l'API du kernel (c'est honteux
de la part des developpeurs...).
Ils auraient mieux fait d'étendre le driver standard (du kernel) pour
supporter le Prism 3, je pense, mais bon...
Y'a juste le wep128 qui ne fonctionne pas encore. Enfin, il fonctionne
presque (des paquets sont perdus....),j'ai du rater une "oooption" avec
wlan-tcl-ng...
Ca marche avec les prism standard et les Atmel...
C'est une bonne info...
Ceci dit, c'est super important que le 802.11g fonctionne sous Linux.
Oui, c'est toujours bien de voir que Linux n'est pas trop à la traine
malgré le manque de coopération des fabricants de chips !
Je n'ai pas encore essayé le 802.11g, mais en 802.11b, les drivers que j'ai cité marchent bien sur Mac: j'ai testé les chipset ATMEL en USB et le prism avec l'airport sur mon Ibook...
Oui, tu fais bien de le signaler : la carte airport est excellente. Si je comprends bien, c'est un chipset prism, qui est dedans ? Et c'est le module/pilote orinoco avec hermes et airport.
Oui, c'est un chipset Prism. Le seul défaut est que la config est bridée par le firmware Apple. Grrr...
Et ATMEL, tu l'utilises avec quelle carte ?
Avec des adaptateurs divers et variés en USB: Belkin, Netgear, et autres (je n'ai plus les références en tête). Le pack ADSL-Wifi Wanadoo utilise un device avec ce chipset, également.
En ce qui me concerne, j'ai réussi à utiliser le MA111 (mini-usb) de Netgear avec linux-wlan (oui je sais c'est moins bien), mais j'arrive enfin à utiliser le wifi avec mon powerbook. Il faut que je mette à jour mon CVS, alors ! Je n'y suis jamais arrivé !
Il est bien, ce petit adaptateur ! Domage que le driver ne respecte pas l'API du kernel (c'est honteux de la part des developpeurs...). Ils auraient mieux fait d'étendre le driver standard (du kernel) pour supporter le Prism 3, je pense, mais bon...
Y'a juste le wep128 qui ne fonctionne pas encore. Enfin, il fonctionne presque (des paquets sont perdus....),j'ai du rater une "oooption" avec wlan-tcl-ng... Ca marche avec les prism standard et les Atmel...
C'est une bonne info...
Ceci dit, c'est super important que le 802.11g fonctionne sous Linux. Oui, c'est toujours bien de voir que Linux n'est pas trop à la traine
malgré le manque de coopération des fabricants de chips !
isanaud
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai un X86 ;-)) ?
"ericb" a écrit dans le message de news:3fae0f7e$0$2798$
[suivi sur fr.comp.os.linux.configuration]
Bonjour,
J'ai acheté une carte wifi pcmcia Peabird (très peu cher ~39 euros) pour l'utiliser sur mon powerbook. Parce qu'il n'y aura probablement jamais de driver libre pour airport extreme, malgré la pétition chez Broadcom.
Après un petit coup de google, j'ai trouvé des sources pour compiler un module qui devait aller bien (en passant par dlfp et le journal de boa13) , mais le problème c'est que tout semble fait pour x86, et pas pour powerpc.
Autre chose, j'ai bien evidemment mis le nez dans les sources, et modifié ce qu'il fallait (sauf oubli). Résultat, la compilation se passe très bien (0 warning), l'installation aussi, mais impossible de charger le module. J'ai aussi tenté un strace qui ne m'a pas appris grand chose, sauf qu'il ne peut pas créer/qu'il n'existe pas de device (périphérique) d'un type donné. Faut-il créer (mknod) un/des périphériques spéciaux ?
Pour info, au niveau matériel, j'ai ça :
1) Pour prendre en compte les cartes pcmcia :
10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
2) La carte à proprement parler (et c'est visiblement une realtek 8180 déguisée en rt2400 ?) :
11:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8180 (rev 20) Subsystem: Realtek Semiconductor Co., Ltd.: Unknown device 8180 Flags: medium devsel, IRQ 53 I/O ports at 4000 [size%6] Memory at f3200000 (32-bit, non-prefetchable) [sizeQ2] Capabilities: [50] Power Management version 2
La carte airport extreme (c'est dommage, quand même...) :
10:12.0 Network controller: Broadcom Corporation BCM94306 802.11g (rev 03) Subsystem: Apple Computer Inc.: Unknown device 004e Flags: bus master, fast devsel, latency 16, IRQ 52 Memory at a0006000 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities: [40] Power Management version 2
lsmod me dit que les modules ds, yenta_socket et pcmcia_core sont correctement chargés (d'après dmesg)
Donc, si quelqu'un avait un tuyau, des infos, je suis content d'avance.
Et merci aussi
-- NO ePATENTS / NON AUX BREVETS SUR LES LOGICIELS. Voir / See http://swpat.ffii.org/
eric b
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai
un X86 ;-)) ?
"ericb" <eric@b.org> a écrit dans le message de
news:3fae0f7e$0$2798$626a54ce@news.free.fr...
[suivi sur fr.comp.os.linux.configuration]
Bonjour,
J'ai acheté une carte wifi pcmcia Peabird (très peu cher ~39 euros) pour
l'utiliser sur mon powerbook. Parce qu'il n'y aura probablement jamais
de driver libre pour airport extreme, malgré la pétition chez Broadcom.
Après un petit coup de google, j'ai trouvé des sources pour compiler un
module qui devait aller bien (en passant par dlfp et le journal de
boa13) , mais le problème c'est que tout semble fait pour x86, et pas
pour powerpc.
Autre chose, j'ai bien evidemment mis le nez dans les sources, et
modifié ce qu'il fallait (sauf oubli). Résultat, la compilation se passe
très bien (0 warning), l'installation aussi, mais impossible de charger
le module. J'ai aussi tenté un strace qui ne m'a pas appris grand chose,
sauf qu'il ne peut pas créer/qu'il n'existe pas de device (périphérique)
d'un type donné. Faut-il créer (mknod) un/des périphériques spéciaux ?
Pour info, au niveau matériel, j'ai ça :
1) Pour prendre en compte les cartes pcmcia :
10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus
Controller
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai un X86 ;-)) ?
"ericb" a écrit dans le message de news:3fae0f7e$0$2798$
[suivi sur fr.comp.os.linux.configuration]
Bonjour,
J'ai acheté une carte wifi pcmcia Peabird (très peu cher ~39 euros) pour l'utiliser sur mon powerbook. Parce qu'il n'y aura probablement jamais de driver libre pour airport extreme, malgré la pétition chez Broadcom.
Après un petit coup de google, j'ai trouvé des sources pour compiler un module qui devait aller bien (en passant par dlfp et le journal de boa13) , mais le problème c'est que tout semble fait pour x86, et pas pour powerpc.
Autre chose, j'ai bien evidemment mis le nez dans les sources, et modifié ce qu'il fallait (sauf oubli). Résultat, la compilation se passe très bien (0 warning), l'installation aussi, mais impossible de charger le module. J'ai aussi tenté un strace qui ne m'a pas appris grand chose, sauf qu'il ne peut pas créer/qu'il n'existe pas de device (périphérique) d'un type donné. Faut-il créer (mknod) un/des périphériques spéciaux ?
Pour info, au niveau matériel, j'ai ça :
1) Pour prendre en compte les cartes pcmcia :
10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
2) La carte à proprement parler (et c'est visiblement une realtek 8180 déguisée en rt2400 ?) :
11:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8180 (rev 20) Subsystem: Realtek Semiconductor Co., Ltd.: Unknown device 8180 Flags: medium devsel, IRQ 53 I/O ports at 4000 [size%6] Memory at f3200000 (32-bit, non-prefetchable) [sizeQ2] Capabilities: [50] Power Management version 2
La carte airport extreme (c'est dommage, quand même...) :
10:12.0 Network controller: Broadcom Corporation BCM94306 802.11g (rev 03) Subsystem: Apple Computer Inc.: Unknown device 004e Flags: bus master, fast devsel, latency 16, IRQ 52 Memory at a0006000 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities: [40] Power Management version 2
lsmod me dit que les modules ds, yenta_socket et pcmcia_core sont correctement chargés (d'après dmesg)
Donc, si quelqu'un avait un tuyau, des infos, je suis content d'avance.
Et merci aussi
-- NO ePATENTS / NON AUX BREVETS SUR LES LOGICIELS. Voir / See http://swpat.ffii.org/
eric b
Thomas Clavier
J. Mayer wrote:
C'est avant tout un problème légal:
ça m'étonerais fortement que broadcom n'ai pas le droit de diffuser les spec de leur chipset .... AMHA, ils ne veulent tout simplement pas partager :-(
car on pourrait s'en servir pour écouter des fréquences militaires
la bande des 2,4 Ghz est libre d'utilisation (sous certaines conditions, PIRE < 100mW) justement parceque les militaires ne l'utilise plus :-))
par ex... Idem pour le Centrino
Sauf erreur de ma part, dans le centrino c'est du broadcom.
J. Mayer wrote:
C'est avant tout un problème légal:
ça m'étonerais fortement que broadcom n'ai pas le droit de diffuser les
spec de leur chipset .... AMHA, ils ne veulent tout simplement pas
partager :-(
car on pourrait s'en servir pour écouter des fréquences militaires
la bande des 2,4 Ghz est libre d'utilisation (sous certaines conditions,
PIRE < 100mW) justement parceque les militaires ne l'utilise plus :-))
par ex... Idem pour le Centrino
Sauf erreur de ma part, dans le centrino c'est du broadcom.
ça m'étonerais fortement que broadcom n'ai pas le droit de diffuser les spec de leur chipset .... AMHA, ils ne veulent tout simplement pas partager :-(
car on pourrait s'en servir pour écouter des fréquences militaires
la bande des 2,4 Ghz est libre d'utilisation (sous certaines conditions, PIRE < 100mW) justement parceque les militaires ne l'utilise plus :-))
par ex... Idem pour le Centrino
Sauf erreur de ma part, dans le centrino c'est du broadcom.
J. Mayer
On Wed, 12 Nov 2003 23:22:31 +0100, Thomas Clavier wrote:
J. Mayer wrote:
C'est avant tout un problème légal:
ça m'étonerais fortement que broadcom n'ai pas le droit de diffuser les spec de leur chipset .... AMHA, ils ne veulent tout simplement pas partager :-(
car on pourrait s'en servir pour écouter des fréquences militaires
la bande des 2,4 Ghz est libre d'utilisation (sous certaines conditions, PIRE < 100mW) justement parceque les militaires ne l'utilise plus :-))
par ex... Idem pour le Centrino
Sauf erreur de ma part, dans le centrino c'est du broadcom.
C'est possible, ce n'est pas ce que j'ai lu, mais c'est un détail.
Le problème légal de ces chips, c'est que justement, il est capable de tuner des fréquences qui ne sont pas du tout dans les bandes autorisées à 2.4 Ghz et 5.(?) Ghz. En fait, pour être plus souple, la partie RF est capable de couvrir un très large spectre de fréquence et d'être reprogrammée en fonction de l'utilisation. Ca leur évite de développer un nouveau chips à chaque fois qu'un nouveau standard apparait, sur une fréquence différente du précédent (802.11a...). Donc, tant que le firmware et le driver sont controlés et vérifiés, Broadcom (et autres) peut certifier que le driver sera utilisé uniquement sur des fréquences autorisées et non sensibles. Si ils ouvrent leurs specs, quelqu'un pourra facilement développer un driver qui pourra utiliser le device dans des bandes de fréquences non légales, et, par exemple, des bandes de fréquences réservées aux services d'urgences, aux services d'état (police...), à l'aviation ou aux militaires... Si ça arrive, les fabricants risquent de devoir retirer leurs chips du marché, puisque toute la sécurité repose sur le fait que personne d'autre ne sait reprogrammer la partie RF...
C'est aussi bête que ça...
On Wed, 12 Nov 2003 23:22:31 +0100, Thomas Clavier wrote:
J. Mayer wrote:
C'est avant tout un problème légal:
ça m'étonerais fortement que broadcom n'ai pas le droit de diffuser les
spec de leur chipset .... AMHA, ils ne veulent tout simplement pas
partager :-(
car on pourrait s'en servir pour écouter des fréquences militaires
la bande des 2,4 Ghz est libre d'utilisation (sous certaines conditions,
PIRE < 100mW) justement parceque les militaires ne l'utilise plus :-))
par ex... Idem pour le Centrino
Sauf erreur de ma part, dans le centrino c'est du broadcom.
C'est possible, ce n'est pas ce que j'ai lu, mais c'est un détail.
Le problème légal de ces chips, c'est que justement, il est capable
de tuner des fréquences qui ne sont pas du tout dans les bandes
autorisées à 2.4 Ghz et 5.(?) Ghz. En fait, pour être plus souple,
la partie RF est capable de couvrir un très large spectre de fréquence
et d'être reprogrammée en fonction de l'utilisation.
Ca leur évite de développer un nouveau chips à chaque fois qu'un nouveau
standard apparait, sur une fréquence différente du précédent (802.11a...).
Donc, tant que le firmware et le driver sont controlés et vérifiés,
Broadcom (et autres) peut certifier que le driver sera utilisé uniquement
sur des fréquences autorisées et non sensibles. Si ils ouvrent leurs
specs, quelqu'un pourra facilement développer un driver qui pourra
utiliser le device dans des bandes de fréquences non légales, et,
par exemple, des bandes de fréquences réservées aux services d'urgences,
aux services d'état (police...), à l'aviation ou aux militaires...
Si ça arrive, les fabricants risquent de devoir retirer leurs chips
du marché, puisque toute la sécurité repose sur le fait que personne
d'autre ne sait reprogrammer la partie RF...
On Wed, 12 Nov 2003 23:22:31 +0100, Thomas Clavier wrote:
J. Mayer wrote:
C'est avant tout un problème légal:
ça m'étonerais fortement que broadcom n'ai pas le droit de diffuser les spec de leur chipset .... AMHA, ils ne veulent tout simplement pas partager :-(
car on pourrait s'en servir pour écouter des fréquences militaires
la bande des 2,4 Ghz est libre d'utilisation (sous certaines conditions, PIRE < 100mW) justement parceque les militaires ne l'utilise plus :-))
par ex... Idem pour le Centrino
Sauf erreur de ma part, dans le centrino c'est du broadcom.
C'est possible, ce n'est pas ce que j'ai lu, mais c'est un détail.
Le problème légal de ces chips, c'est que justement, il est capable de tuner des fréquences qui ne sont pas du tout dans les bandes autorisées à 2.4 Ghz et 5.(?) Ghz. En fait, pour être plus souple, la partie RF est capable de couvrir un très large spectre de fréquence et d'être reprogrammée en fonction de l'utilisation. Ca leur évite de développer un nouveau chips à chaque fois qu'un nouveau standard apparait, sur une fréquence différente du précédent (802.11a...). Donc, tant que le firmware et le driver sont controlés et vérifiés, Broadcom (et autres) peut certifier que le driver sera utilisé uniquement sur des fréquences autorisées et non sensibles. Si ils ouvrent leurs specs, quelqu'un pourra facilement développer un driver qui pourra utiliser le device dans des bandes de fréquences non légales, et, par exemple, des bandes de fréquences réservées aux services d'urgences, aux services d'état (police...), à l'aviation ou aux militaires... Si ça arrive, les fabricants risquent de devoir retirer leurs chips du marché, puisque toute la sécurité repose sur le fait que personne d'autre ne sait reprogrammer la partie RF...
C'est aussi bête que ça...
ericb
Bonjour,
isanaud a écrit:
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai un X86 ;-)) ?
Oui, tu as bien compris : cette carte à de bonnes chances de fonctionner sur architecture x86. Le driver est sous gpl (except un fichier), et les sources sont propres. Une restriction possible ( *à vérifier* avant tout achat) : la version du noyau.
Les références sont dans l'enfilade, et si tu as des problèmes, tu peux reposter.
Cordialement
-- NO ePATENTS / NON AUX BREVETS SUR LES LOGICIELS. See / Voir http://swpat.ffii.org/
eric b
Bonjour,
isanaud a écrit:
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai
un X86 ;-)) ?
Oui, tu as bien compris : cette carte à de bonnes chances de fonctionner
sur architecture x86. Le driver est sous gpl (except un fichier), et les
sources sont propres. Une restriction possible ( *à vérifier* avant tout
achat) : la version du noyau.
Les références sont dans l'enfilade, et si tu as des problèmes, tu peux
reposter.
Cordialement
--
NO ePATENTS / NON AUX BREVETS SUR LES LOGICIELS. See / Voir
http://swpat.ffii.org/
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai un X86 ;-)) ?
Oui, tu as bien compris : cette carte à de bonnes chances de fonctionner sur architecture x86. Le driver est sous gpl (except un fichier), et les sources sont propres. Une restriction possible ( *à vérifier* avant tout achat) : la version du noyau.
Les références sont dans l'enfilade, et si tu as des problèmes, tu peux reposter.
Cordialement
-- NO ePATENTS / NON AUX BREVETS SUR LES LOGICIELS. See / Voir http://swpat.ffii.org/
eric b
J. Mayer
On Thu, 13 Nov 2003 13:34:47 +0100, ericb wrote:
Bonjour,
isanaud a écrit:
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai un X86 ;-)) ?
Oui, tu as bien compris : cette carte à de bonnes chances de fonctionner sur architecture x86. Le driver est sous gpl (except un fichier), et les sources sont propres. Une restriction possible ( *à vérifier* avant tout achat) : la version du noyau.
NON: le driver est propriétaire et il y a juste une "glue" en GPL... Cette glue permet d'éviter: - que le driver soit vu par le noyau comme un driver propriétaire (tainted), et ça, c'est mal ! - des problèmes de license, vu que le code en question est tiré d'autres drivers qui, eux, sont en open-source (GPL) - d'éviter d'avoir des problèmes de version de kernel, justement.
On Thu, 13 Nov 2003 13:34:47 +0100, ericb wrote:
Bonjour,
isanaud a écrit:
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai
un X86 ;-)) ?
Oui, tu as bien compris : cette carte à de bonnes chances de fonctionner
sur architecture x86. Le driver est sous gpl (except un fichier), et les
sources sont propres. Une restriction possible ( *à vérifier* avant tout
achat) : la version du noyau.
NON: le driver est propriétaire et il y a juste une "glue" en GPL...
Cette glue permet d'éviter:
- que le driver soit vu par le noyau comme un driver propriétaire
(tainted), et ça, c'est mal !
- des problèmes de license, vu que le code en question est tiré
d'autres drivers qui, eux, sont en open-source (GPL)
- d'éviter d'avoir des problèmes de version de kernel, justement.
si j'ai bien compris, la carte peabird à 39? est suportée sous linux (j'ai un X86 ;-)) ?
Oui, tu as bien compris : cette carte à de bonnes chances de fonctionner sur architecture x86. Le driver est sous gpl (except un fichier), et les sources sont propres. Une restriction possible ( *à vérifier* avant tout achat) : la version du noyau.
NON: le driver est propriétaire et il y a juste une "glue" en GPL... Cette glue permet d'éviter: - que le driver soit vu par le noyau comme un driver propriétaire (tainted), et ça, c'est mal ! - des problèmes de license, vu que le code en question est tiré d'autres drivers qui, eux, sont en open-source (GPL) - d'éviter d'avoir des problèmes de version de kernel, justement.
Vincent Bernat
OoO En cette fin de matinée radieuse du jeudi 13 novembre 2003, vers 11:39, "J. Mayer" disait:
Cette glue permet d'éviter: - que le driver soit vu par le noyau comme un driver propriétaire (tainted), et ça, c'est mal !
Si la "glue" indique une licence GPL au noyau, je pense qu'on est en droit de demander le code source. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette fin de matinée radieuse du jeudi 13 novembre 2003, vers
11:39, "J. Mayer" <l_indien_no_more_spams@magic.fr> disait:
Cette glue permet d'éviter:
- que le driver soit vu par le noyau comme un driver propriétaire
(tainted), et ça, c'est mal !
Si la "glue" indique une licence GPL au noyau, je pense qu'on est en
droit de demander le code source.
--
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette fin de matinée radieuse du jeudi 13 novembre 2003, vers 11:39, "J. Mayer" disait:
Cette glue permet d'éviter: - que le driver soit vu par le noyau comme un driver propriétaire (tainted), et ça, c'est mal !
Si la "glue" indique une licence GPL au noyau, je pense qu'on est en droit de demander le code source. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan & Plaugher)
J. Mayer
On Thu, 13 Nov 2003 16:48:01 -0800, Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du jeudi 13 novembre 2003, vers 11:39, "J. Mayer" disait:
Cette glue permet d'éviter: - que le driver soit vu par le noyau comme un driver propriétaire (tainted), et ça, c'est mal !
Si la "glue" indique une licence GPL au noyau, je pense qu'on est en droit de demander le code source.
J'aimerai bien ! En fait, je pense qu'on peut leur demander d'enlever cette info, mais le parametre MODULE_LICENSE du kernel est interne au noyau et n'a aucune existence "légale"... Mais j'ai vérifié, ils ont bien mis: MODULE_LICENSE("GPL"); MODULE_DEVICE_TABLE(pci, rtl8180_pci_id_tbl);
On pourrait au moins aller les taner pour ça, ça fait une raison valable pour les emmerder :=)
On Thu, 13 Nov 2003 16:48:01 -0800, Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du jeudi 13 novembre 2003, vers
11:39, "J. Mayer" <l_indien_no_more_spams@magic.fr> disait:
Cette glue permet d'éviter:
- que le driver soit vu par le noyau comme un driver propriétaire
(tainted), et ça, c'est mal !
Si la "glue" indique une licence GPL au noyau, je pense qu'on est en
droit de demander le code source.
J'aimerai bien !
En fait, je pense qu'on peut leur demander d'enlever cette info,
mais le parametre MODULE_LICENSE du kernel est interne au noyau
et n'a aucune existence "légale"...
Mais j'ai vérifié, ils ont bien mis:
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, rtl8180_pci_id_tbl);
On pourrait au moins aller les taner pour ça, ça fait une raison
valable pour les emmerder :=)
On Thu, 13 Nov 2003 16:48:01 -0800, Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du jeudi 13 novembre 2003, vers 11:39, "J. Mayer" disait:
Cette glue permet d'éviter: - que le driver soit vu par le noyau comme un driver propriétaire (tainted), et ça, c'est mal !
Si la "glue" indique une licence GPL au noyau, je pense qu'on est en droit de demander le code source.
J'aimerai bien ! En fait, je pense qu'on peut leur demander d'enlever cette info, mais le parametre MODULE_LICENSE du kernel est interne au noyau et n'a aucune existence "légale"... Mais j'ai vérifié, ils ont bien mis: MODULE_LICENSE("GPL"); MODULE_DEVICE_TABLE(pci, rtl8180_pci_id_tbl);
On pourrait au moins aller les taner pour ça, ça fait une raison valable pour les emmerder :=)
ericb
Bonjour,
J'avais pas vu la suite :-)
J. Mayer a écrit:
On Thu, 13 Nov 2003 16:48:01 -0800, Vincent Bernat wrote: J'aimerai bien ! En fait, je pense qu'on peut leur demander d'enlever cette info, mais le parametre MODULE_LICENSE du kernel est interne au noyau et n'a aucune existence "légale"...
Bien vu. Prochaine fois, je lirais mieux. :-/
Mais j'ai vérifié, ils ont bien mis: MODULE_LICENSE("GPL"); MODULE_DEVICE_TABLE(pci, rtl8180_pci_id_tbl);
J'ai redémarré sous Linux pour vérifier...
En fait, j'ai trois versions des sources :
- la première avec toutes (il me semble que tout y est) les sources, mais sous licence Ralink Tech Inc (non GPL) :
N.B. : le nom des répertoire vient de l'arborescence du tar.gz, que j'ai décompressé avec mc ;-)
Alors que d'après les sources, c'est autre chose :
:/usr/src/rt2400_linux/Module$ cat assoc.c | head -15 /**************************************************************************** * Ralink Tech Inc. * 4F, No. 2 Technology 5th Rd. * Science-based Industrial Park * Hsin-chu, Taiwan, R.O.C. * (c) Copyright 2002, Ralink Technology, Inc. * * All rights reserved. Ralink's source code is an unpublished work and the * use of a copyright notice does not imply otherwise. This source code * contains confidential trade secret material of Ralink Tech. Any attemp * or participation in deciphering, decoding, reverse engineering or in any * way altering the source code is stricitly prohibited, unless the prior * written consent of Ralink Technology, Inc. is obtained.
La troisième, que j'ai trouvée je ne sais plus où, contient des fichiers en c sous GPL (c'est écrit), ainsi qu'un fichier type firmware appelé priv_part.o.
En plus, j'ai essayé de contacter M. Paul Lin, et il n'habite plus à l'adresse indiquée..
J'ai pourtant fait attention à l'adresse...
On pourrait au moins aller les taner pour ça, ça fait une raison valable pour les emmerder :=)
Oui, c'est vrai. En tout cas bravo pour ta perspicacité. Moi, je n'avais rien vu.
amha, ils ont peut-être mis sur le marché les sources, et se rendant compte du problème de la GPL, ils ont séparé ce qui pouvait être divulgué (à leurs yeux) de ce qui ne le pouvait pas.
Enfin, comme c'est pas sous Licence libre, ce code est inutile, et je ne l'utiliserai pas.
Tout n'est pas bon à jeter : j'ai quand même bien apprécié le readme, parce que j'ai appris plein de choses sur iwconfig et ifpriv en lisant ce fichier.
:-)
-- NON AUX BREVETS SUR LES LOGICIELS. Voir http://swpat.ffii.org/
eric b
Bonjour,
J'avais pas vu la suite :-)
J. Mayer a écrit:
On Thu, 13 Nov 2003 16:48:01 -0800, Vincent Bernat wrote:
J'aimerai bien !
En fait, je pense qu'on peut leur demander d'enlever cette info,
mais le parametre MODULE_LICENSE du kernel est interne au noyau
et n'a aucune existence "légale"...
Bien vu. Prochaine fois, je lirais mieux. :-/
Mais j'ai vérifié, ils ont bien mis:
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, rtl8180_pci_id_tbl);
J'ai redémarré sous Linux pour vérifier...
En fait, j'ai trois versions des sources :
- la première avec toutes (il me semble que tout y est) les sources,
mais sous licence Ralink Tech Inc (non GPL) :
N.B. : le nom des répertoire vient de l'arborescence du tar.gz, que j'ai
décompressé avec mc ;-)
Alors que d'après les sources, c'est autre chose :
eric@alube:/usr/src/rt2400_linux/Module$ cat assoc.c | head -15
/****************************************************************************
* Ralink Tech Inc.
* 4F, No. 2 Technology 5th Rd.
* Science-based Industrial Park
* Hsin-chu, Taiwan, R.O.C.
* (c) Copyright 2002, Ralink Technology, Inc.
*
* All rights reserved. Ralink's source code is an unpublished work and the
* use of a copyright notice does not imply otherwise. This source code
* contains confidential trade secret material of Ralink Tech. Any attemp
* or participation in deciphering, decoding, reverse engineering or in any
* way altering the source code is stricitly prohibited, unless the prior
* written consent of Ralink Technology, Inc. is obtained.
La troisième, que j'ai trouvée je ne sais plus où, contient des fichiers
en c sous GPL (c'est écrit), ainsi qu'un fichier type firmware appelé
priv_part.o.
En plus, j'ai essayé de contacter M. Paul Lin, et il n'habite plus à
l'adresse indiquée..
J'ai pourtant fait attention à l'adresse...
On pourrait au moins aller les taner pour ça, ça fait une raison
valable pour les emmerder :=)
Oui, c'est vrai. En tout cas bravo pour ta perspicacité. Moi, je n'avais
rien vu.
amha, ils ont peut-être mis sur le marché les sources, et se rendant
compte du problème de la GPL, ils ont séparé ce qui pouvait être
divulgué (à leurs yeux) de ce qui ne le pouvait pas.
Enfin, comme c'est pas sous Licence libre, ce code est inutile, et je ne
l'utiliserai pas.
Tout n'est pas bon à jeter : j'ai quand même bien apprécié le readme,
parce que j'ai appris plein de choses sur iwconfig et ifpriv en lisant
ce fichier.
:-)
--
NON AUX BREVETS SUR LES LOGICIELS. Voir http://swpat.ffii.org/
On Thu, 13 Nov 2003 16:48:01 -0800, Vincent Bernat wrote: J'aimerai bien ! En fait, je pense qu'on peut leur demander d'enlever cette info, mais le parametre MODULE_LICENSE du kernel est interne au noyau et n'a aucune existence "légale"...
Bien vu. Prochaine fois, je lirais mieux. :-/
Mais j'ai vérifié, ils ont bien mis: MODULE_LICENSE("GPL"); MODULE_DEVICE_TABLE(pci, rtl8180_pci_id_tbl);
J'ai redémarré sous Linux pour vérifier...
En fait, j'ai trois versions des sources :
- la première avec toutes (il me semble que tout y est) les sources, mais sous licence Ralink Tech Inc (non GPL) :
N.B. : le nom des répertoire vient de l'arborescence du tar.gz, que j'ai décompressé avec mc ;-)
Alors que d'après les sources, c'est autre chose :
:/usr/src/rt2400_linux/Module$ cat assoc.c | head -15 /**************************************************************************** * Ralink Tech Inc. * 4F, No. 2 Technology 5th Rd. * Science-based Industrial Park * Hsin-chu, Taiwan, R.O.C. * (c) Copyright 2002, Ralink Technology, Inc. * * All rights reserved. Ralink's source code is an unpublished work and the * use of a copyright notice does not imply otherwise. This source code * contains confidential trade secret material of Ralink Tech. Any attemp * or participation in deciphering, decoding, reverse engineering or in any * way altering the source code is stricitly prohibited, unless the prior * written consent of Ralink Technology, Inc. is obtained.
La troisième, que j'ai trouvée je ne sais plus où, contient des fichiers en c sous GPL (c'est écrit), ainsi qu'un fichier type firmware appelé priv_part.o.
En plus, j'ai essayé de contacter M. Paul Lin, et il n'habite plus à l'adresse indiquée..
J'ai pourtant fait attention à l'adresse...
On pourrait au moins aller les taner pour ça, ça fait une raison valable pour les emmerder :=)
Oui, c'est vrai. En tout cas bravo pour ta perspicacité. Moi, je n'avais rien vu.
amha, ils ont peut-être mis sur le marché les sources, et se rendant compte du problème de la GPL, ils ont séparé ce qui pouvait être divulgué (à leurs yeux) de ce qui ne le pouvait pas.
Enfin, comme c'est pas sous Licence libre, ce code est inutile, et je ne l'utiliserai pas.
Tout n'est pas bon à jeter : j'ai quand même bien apprécié le readme, parce que j'ai appris plein de choses sur iwconfig et ifpriv en lisant ce fichier.
:-)
-- NON AUX BREVETS SUR LES LOGICIELS. Voir http://swpat.ffii.org/
