Le GROS avantage d'avoir le code (même très simple) c'est d'être en mesure de le compiler avec des versions récentes du kernel (ou d'activer des options spécifiques, ou de le compiler avec preempt-rt, ou autre).
Et j'insiste sur le fait qu'il faut TOUTE les sources, pas seulement un bout comme fait NVidia ou ATI: Dans ces 2 cas, il est *impossible* d'utiliser un kernel preempt-RT par exemple: Il y a du code proprio qui tourne SUR le processeur de la machine. Et ça, c'est rédhibitoire , en plus d'être dangereux en terme de sécurité: Si quelqu'un trouve un exploit dans ce code, il est SUR que ca peux marcher quelque soit la version du kernel.... sympa non ?
Sans compter que ces drivers sont livrés que pour X86: Si j'ai une machine PowerPC par exemple, bah Nvidia n'ayant pas fait l'effort (conséquent) de portage du code proprio, c'est juste mort.
Donc le mouvement de broadcom est bienvenue. Mais attention, il ne concerne QUE les code des périphériques PCI, & non pas ceux des System-On-Chip qui sont, eux, basé sur un bus broadcom spécifique appelé "SSB". (On espère que ca ne saurait tarder).
Le problème des firmwares pas libre se situe au niveau des fonctionnalités: par exemple, pendant longtemps (c'est peut-être encore le cas), Intel livrais des cartes qui ne marchais qu'en mode ad-hoc et Infrastructure, et ne pouvaient pas passer en mode AP: leur firmware ne permettais pas ça, et ca les intéressaient pas de le faire. La carte le pouvait, la preuve quelques années après des firmwares hackés sont sortis pour faire cela.
A l'heure actuelle, les cartes broadcom un peu plus vieilles (bcm4318 par exemple) ont un driver libre, récent, avec un firmware libre reverse-engineeré qui fait presque tout.
(La seule fonction qui manque est le Multi-SSID - dommage ! C'est la seule chose qui leur manque pour devenir une alternative crédible aux chip Atheros)
Le plus drôle c'est que le firmware reverse-engineeré est bien plus simple que l'original; et sans les bugs de ce dernier...
Marvell, par exemple avec ses chipsets embarqué (libertas) ca va encore plus loin, il y a des tas de firmwares, chargés en fonction du contexte d'utilisation.
Au final, nous ce qu'on voudrait idéalement c'est un tranceiver 2.4Ghz et/ou 5Ghz , avec un code libre coté CPU (*)
Mais alors, le vrai problème, c'est comment, pour un constructeur, se différencier des autres ?
C'est à ça que rime tous ces firmwares, ces messes-basses: Faire semblant que tel constructeur est meilleurs que tel autre.
Au final, on dit toujours que les meilleurs chipsets sont les atheros: La raison derrière, c'est parce que ce sont les plus *libre*, donc les plus facile pour ajouter des nouvelles fonctions. C'est pas un hasard si c'est par ces chipsets que sont arrivé le Mesh, le multi-SSID, le ad-hoc beaconless, dans le kernel linux.
(*) Je caricature un peu : en réalité il y a aussi un bon paquet de traitement du signal, de la sélection de fréquence, du filtrage numérique.... Si le CPU devais prendre tout ca a sa charge il ne ferais plus que ca. Mais ca existe, cependant : http://gnuradio.org/redmine/wiki/gnuradio + http://www.ettus.com/products
[^] # Re: Bonne nouvelle
Posté par C. OB (site web personnel) . En réponse au journal Cout de ton air dans le landerneau. Évalué à 3.
Et j'insiste sur le fait qu'il faut TOUTE les sources, pas seulement un bout comme fait NVidia ou ATI: Dans ces 2 cas, il est *impossible* d'utiliser un kernel preempt-RT par exemple: Il y a du code proprio qui tourne SUR le processeur de la machine. Et ça, c'est rédhibitoire , en plus d'être dangereux en terme de sécurité: Si quelqu'un trouve un exploit dans ce code, il est SUR que ca peux marcher quelque soit la version du kernel.... sympa non ?
Sans compter que ces drivers sont livrés que pour X86: Si j'ai une machine PowerPC par exemple, bah Nvidia n'ayant pas fait l'effort (conséquent) de portage du code proprio, c'est juste mort.
Donc le mouvement de broadcom est bienvenue. Mais attention, il ne concerne QUE les code des périphériques PCI, & non pas ceux des System-On-Chip qui sont, eux, basé sur un bus broadcom spécifique appelé "SSB". (On espère que ca ne saurait tarder).
Le problème des firmwares pas libre se situe au niveau des fonctionnalités: par exemple, pendant longtemps (c'est peut-être encore le cas), Intel livrais des cartes qui ne marchais qu'en mode ad-hoc et Infrastructure, et ne pouvaient pas passer en mode AP: leur firmware ne permettais pas ça, et ca les intéressaient pas de le faire. La carte le pouvait, la preuve quelques années après des firmwares hackés sont sortis pour faire cela.
A l'heure actuelle, les cartes broadcom un peu plus vieilles (bcm4318 par exemple) ont un driver libre, récent, avec un firmware libre reverse-engineeré qui fait presque tout.
(La seule fonction qui manque est le Multi-SSID - dommage ! C'est la seule chose qui leur manque pour devenir une alternative crédible aux chip Atheros)
Le plus drôle c'est que le firmware reverse-engineeré est bien plus simple que l'original; et sans les bugs de ce dernier...
Marvell, par exemple avec ses chipsets embarqué (libertas) ca va encore plus loin, il y a des tas de firmwares, chargés en fonction du contexte d'utilisation.
Au final, nous ce qu'on voudrait idéalement c'est un tranceiver 2.4Ghz et/ou 5Ghz , avec un code libre coté CPU (*)
Mais alors, le vrai problème, c'est comment, pour un constructeur, se différencier des autres ?
C'est à ça que rime tous ces firmwares, ces messes-basses: Faire semblant que tel constructeur est meilleurs que tel autre.
Au final, on dit toujours que les meilleurs chipsets sont les atheros: La raison derrière, c'est parce que ce sont les plus *libre*, donc les plus facile pour ajouter des nouvelles fonctions. C'est pas un hasard si c'est par ces chipsets que sont arrivé le Mesh, le multi-SSID, le ad-hoc beaconless, dans le kernel linux.
(*) Je caricature un peu : en réalité il y a aussi un bon paquet de traitement du signal, de la sélection de fréquence, du filtrage numérique.... Si le CPU devais prendre tout ca a sa charge il ne ferais plus que ca. Mais ca existe, cependant :
http://gnuradio.org/redmine/wiki/gnuradio + http://www.ettus.com/products