Au menu :
- L'intégration de FUSE, permettant de disposer de systèmes de fichiers implémentés en espace utilisateur;
- L'intégration de V9FS, un pilote pour le système de fichiers distribué de Plan9;
- L'intégration de RelayFS, un pseudo-système de fichiers permettant le transfert rapide de données entre le noyau et l'espace utilisateur;
- L'intégration du support pour DCCP, un nouveau protocole réseau, situé au même niveau qu'UDP et TCP. Il est orienté datagrammes, comme UDP, mais gère la congestion, comme TCP. Un document de l'IETF apporte de nombreuses précisions sur le sujet;
- Un meilleur mapping des claviers USB pour Apple PowerBook;
- Beaucoup de modifications d'usbnet qui vont ravir tous les utilisateurs de PocketPC. Maintenant, "Linux peux discuter avec divers matériel basé sur WinCE";
- Une correction permettant d'éviter les crashs sur les systèmes NFS à forte charge (meilleur gestion des inodes);
- On peut maintenant accéder à des Cartes CF (en PCMCIA sur ARM) lors du boot;
- Une meilleure gestion des cartes son en USB;
- Des mises à jour sur l'ACPI
- Ajout du pilote HostAP et du pilote ipw2100 et ipw2200;
- Un nettoyage du code;
On peut aussi noter la création d'un flux RSS pour suivre le développement du noyau. Le noyau 2.6.14 est le premier à avoir suivi le nouveau modèle de développement mis en place par Linus à la sortie du 2.6.13. Pour rappel, suite à la sortie d'une version du noyau, des ajouts de fonctionnalités et modifications importantes ne seront acceptés que pendant deux semaines. Au delà de ce délai, et jusqu'à la sortie de la prochaine version, le travail des développeurs sera consacré à la correction de bugs.
Aller plus loin
- Le changelog (8 clics)
- Le flux RSS (38588 clics)
- DLFP: Nouvelles du noyau : Git et modèle de développement (4 clics)
- Changelog résumé sur KernelNewbies (1 clic)
# ieee80211 !
Posté par superna (site web personnel) . Évalué à 7.
Enfin un premier pas pour l'intégration de rt2x00 (http://rt2x00.serialmonkey.com) !
[^] # Re: ieee80211 !
Posté par vincent LECOQ (site web personnel) . Évalué à 2.
[^] # Re: ieee80211 !
Posté par Antoine Jacquet (site web personnel) . Évalué à 8.
Ce n'est pas très bien vu par les "vrais" developpeurs ;-)
Par contre ça permet de faire marcher ces webcams JPEG avec V4L (video4linux) et donc avec la majorité des applications qui ne sont pas passé à V4L2...
http://mxhaard.free.fr/
http://royale.zerezo.com/zr364xx/
[^] # Re: ieee80211 ! (commentaire utile pour la navigation)
Posté par chl (site web personnel) . Évalué à 5.
[^] # Re: ieee80211 !
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: ieee80211 !
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: ieee80211 !
Posté par fmaz fmaz . Évalué à 1.
grzhtscki8394210 qui va enfin permettre d'espérer utiliser le
zfxkjy148942.
[^] # Re: ieee80211 !
Posté par fmaz fmaz . Évalué à 4.
Mais dites, les gens, c'est quoi ieee80211, rt2x00, spca5xxx et zr364xx ?
Parce que bon...
[^] # Re: ieee80211 !
Posté par un_brice (site web personnel) . Évalué à 5.
ieee80211 est une implémentation du protocole éponyme (802.11), utilisé par de nombreuses de ces cartes.
spca5xxx et zr364xx c'est des pilotes de webcam
# re
Posté par Sylvain (site web personnel) . Évalué à 0.
Un nettoyage du code;
Ca veut tout et rien dire ...
[^] # Re: re
Posté par Sylvain Sauvage . Évalué à 10.
[^] # Re: re
Posté par Jacquot Raphael . Évalué à -3.
# petite erreur
Posté par Prosper . Évalué à 9.
Non , c'est un meilleur support du touchpads des powerbooks sortis après février 2005 .
[^] # Re: petite erreur
Posté par barca . Évalué à 5.
Ca veut dire qu'il n'y aura plus le probleme de snd-usb-audio ?
Donc, que le micro de la webcam fonctionnera même avec le pilote de la carte son?
[^] # Re: petite erreur
Posté par etk . Évalué à 7.
Ceci est du au fait que le driver snd_usb_audio se charge avant le driver son du chipset, et se resoud en changeant simplement l'ordre de chargement des modules.
Si c'est ton probleme, ce n'est pas un probleme dans le noyau je doute que le nouveau ameliore les choses.
[^] # Re: petite erreur
Posté par barca . Évalué à 5.
Merci pour tes explications claires et pedagogiques.
# Claviers Powerbooks
Posté par Yves-Alexis Perez . Évalué à 5.
Il existe un patch qui désactive le nouveau système et revient à l'ancien, et qui est sensé pouvoir faire fonctionner la touche Fn. Il sera sans doute bientôt disponible sur le site [0].
Je finis de compiler, je teste, et je vous tiens au courant...
(à noter aussi que sur les powerbooks 15" avec la radeon 9600, on obtient du DRI avec le module du 2.6.14 (à condition d'avoir un Xorg cvs ([1] pour debian sid) et d'avoir libgl1-mesa-dri (à compiler soi même sous debian))
[0]: http://seehuhn.de/comp/powerbook/#fnkey-patch
[1]: http://people.debian.org/~luther/xorg-x11-6.8.99.901.dfsg.1-(...)
[^] # Re: Claviers Powerbooks
Posté par Xavier Bestel (site web personnel) . Évalué à 2.
[^] # Re: Claviers Powerbooks
Posté par Cyril . Évalué à 2.
Il a une Radeon 9700, mais en faite c'est une Radeon 9600 M10 je sais pas quoi, j'ai de la peine avec ces M quelque chose. La seule chose précise que je sais (que je crois savoir en tout cas) c'est que c'est une "RV350".
J'ai fais des recherches sur le site de dri, ils disent que le support du RV350 est expérimental et que le support pour la platforme ppc est encore un peu bugé.
(rendu OpenGL à la mauvaise place sur l'écran ou quelque chose comme ça), comme je sais pas du tout ou ça en est j'ai pas trop envi de tout casser ma distrib en essayant d'installer tout ça si c'est pour avoir un résultat complettement instable.
(il m'a déjà fallu un moment pour recompiler un linux 2.6.12 avec les bonnes options pour pouvoir faire fonctionner la mise en veille, le support du backlight, l'usb 2 et plein d'autre choses j'ai pas envi de tout recommancer)
Reste que la carte son que j'ai pas réussi à faire fonctionner et l'accélération 3D (en plus de la carte réseau BCM4306, mais y'a plus d'éspoire)
PS : voila, j'ai fini de raconter ma vie et celle de mon portable :-P (mille excuses si j'ai fais des fautes de français, j'ai toutes les peines du monde à ne pas en faire, j'ai déjà relu beaucoup de fois avant de poster)
[^] # Re: Claviers Powerbooks
Posté par chl (site web personnel) . Évalué à 3.
Franchement, pour quelqu'un qui dit qu'il fait des fautes, il n'a pas grand chose à redire ! Si tu n'avais pas dit que tu faisais des fautes, je ne les aurais même pas remarquées.
Il y a des gens qui font plus de fautes, qui le savent, mais qui n'en n'ont rien à foutre et qui ne se relisent pas. Bravo pour ta démarche.
Je n'ai juste vu que quelques fautes de frappe, mais rien de bien méchant :
s/en faite/en fait/
s/bugé/bugué/
s/envi/envie/
s/complettement/completement/
s/autre choses/autres choses/
s/éspoire/espoir/
[^] # Re: Claviers Powerbooks
Posté par Sylvain Sauvage . Évalué à 3.
complètement (avé l'assent, con ;o)
Il manque aussi le « y » et le trait d'union ou l'apostrophe¹ dans « il n'y a pas grand'chose à redire ! ».
¹ : il n'y a plus grand monde pour utiliser l'apostrophe pour marquer l'absence du e...
[^] # Re: Claviers Powerbooks
Posté par Markov . Évalué à 2.
Il marche bien pour la platforme PPC. Le site r300.sf.net n'est pas très à jour :) Donc tu peux tester ce driver, mais attention il est encore en développement et il a tendance à "freezer" la machine avec les screensavers.
[^] # Re: Claviers Powerbooks
Posté par Yves-Alexis Perez . Évalué à 2.
Sinon, heu, sur le 17 je sais pas, mais sur le 15:
suspend to ram > ok
backlight > ok
usb2 > ok
carte son > ok (snd_powermac)
Je ne saurais trop te conseiller le noyau 2.6.14-rc5 dispo sur http://people.debian.org/~luther/2.6.14-rc5/ (et bientot le 2.6.14 dispo dans unstable), ou y'aura tout ce qu'il faudra... ou presque.
Sinon, le patch fn-key pour 2.6.14 marche très bien, je sais pas quand il sera uploadé sur le site, mais en attendant il peut se trouver dans les archives de la liste debian-ppc:
http://lists.debian.org/debian-powerpc/2005/10/msg00470.html
(penser à virer les commentaires imbriqués du patch, gcc aime pas trop)
[^] # 2.6.14 dans debian
Posté par symoon . Évalué à 2.
à quelques heures près, l'image compilée aurait pu être disponible dans sid aujourd'hui :)
un peu plus de 6 heures depuis la publication officielle pour préparer les paquets, ils ont fait fort !
Quoi qu'il en soit, pour les impatients, ils peuvent trouver les .deb sur http://incoming.debian.org/ en cherchant linux-image-2.6.14
# Reiser4?
Posté par Yann012 . Évalué à 2.
Remarque en attendant y a toujours les patchs...
[^] # Re: Reiser4?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: Reiser4?
Posté par Jean Roc Morreale . Évalué à 5.
[^] # Re: Reiser4?
Posté par galactikboulay . Évalué à 5.
http://lkml.org/lkml/2005/9/16/178
et spécialement "Most of my customers remark that Namesys
code is head and shoulders above the rest of the kernel code.",
tu te dis que forcément il va y avoir des anicroches....
[^] # Re: Reiser4?
Posté par Jean Roc Morreale . Évalué à 4.
[^] # Re: Reiser4?
Posté par oliv . Évalué à 4.
[^] # Re: Reiser4?
Posté par oliv . Évalué à 10.
http://www.kerneltraffic.org/kernel-traffic/kt20051010_331.h(...)
Les développeurs de XFS n'ont rien à voir dans l'histoire. Les commentaires sur Reiser4 viennent surtout du responsable du VFS (virtual file system layer) de Linux, C. Hellwig. Il a listé des tâches que l'équipe de Namesys doit accomplir. Andrew Morton a pris note de cette liste. Les employés de Hans Reiser se sont mis au travail. Mais Reiser lui même a passé son temps à se plaindre.
Il avait fait la même chose pour Reiser3. Quand il avait enfin cessé de la ramener sans cesse pour calomnier les developeurs du noyau, ces employés avaient fait le boulot et Linus avait intégré le noyau. Hélas, il n'a pas appris de ces erreurs passées.
Le problème est qu'il n'y a que très peu de dévelopeurs Linux compétents dans ce domaine, avec du temps libre, et motivés pour relire un code aussi gros que celui de Reiser4. À vrai dire, il y en a 2. Et à chaque fois qu'ils mettent le doigt sur un problème, ils se font insulter.
# Netfilter
Posté par Jean . Évalué à 10.
On peut citer l'intgégration de nfnetlink et la sortie de la bibliothèque associée libnfnetlink[1]. Les deux ensemble forment un système permettant de faire communiquer des application userspace avec le noyau.
Utilisant libnfnetlink, les bibliothèques suivantes sont aussi sorties:
- libnetfilter_log[2] qui fournit une interface de log des paquets, et est notamment utilisée par ulogd2 [3].
- libnetfilter_queue[4] qui permet à une application de gérer les paquets mis en attente par le noyau et de choisir des actions sur leur destin (drop, reject, ...). Le firewall authentifiant nufw[5] est un bon exemple de ce type d'interaction.
- libnetfilter_conntrack[6]: cette bibliothèque fournit une API pour gérer le suivi des connexions. La commande conntrack l'utilise et permet de manipuler la table de suivi des connexions.
[0] http://netfilter.org/index.html
[1] http://netfilter.org/projects/libnfnetlink/index.html
[2] http://netfilter.org/projects/libnetfilter_log/index.html
[3] http://svnweb.gnumonks.org/branches/ulog/ulogd2/
[4] http://netfilter.org/projects/libnetfilter_queue/index.html
[5] http://nufw.org
[6] http://netfilter.org/projects/libnetfilter_conntrack/index.h(...)
[^] # Re: Netfilter
Posté par Julien CARTIGNY (site web personnel) . Évalué à 1.
Pourrais tu détailler un peu ?
# SD card
Posté par ribwund . Évalué à 3.
[^] # Re: SD card
Posté par Jacquot Raphael . Évalué à 1.
mon portable contient un ricoh R5C822, qui ne marchera donc pas :(
[^] # Re: SD card
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
Pour ma part je lis sans problème les cartes SD avec un lecteur de cartes et en passant par le module usb-storage !
[^] # Re: SD card
Posté par aboot . Évalué à -1.
Merci
[^] # Re: SD card
Posté par djibb (site web personnel) . Évalué à 3.
Par contre... les modules internes... c un autre probleme... aucun ne fonctionnait... la il semblkerait qu'un soit pris en compte.
[^] # Re: SD card
Posté par TazForEver . Évalué à -1.
[^] # Re: SD card
Posté par Cédric Blancher . Évalué à 6.
C'est le support d'un contrôleur SD Card intégré à la machine, et non externe, accessible en USB par exemple comme ce que tu décris. En effet, certains laptops arrivent avec des lecteurs de cartes flash, c'est assi le cas de PDAs (Zaurus par exemple), et il faut bien un driver pour pouvoir les utiliser.
En outre, mais on a tendance à l'oublier, une carte SD, ce n'est pas qu'un simple stockage de données. SD, ça veut dire Secure Digital, et le mot Secure n'est pas juste là pour faire joli :
http://actes.sstic.org/SSTIC05/Rump_sessions/SSTIC05-rump-Ke(...)
# ipw2100
Posté par gnumdk (site web personnel) . Évalué à 3.
J'ai tenté de le mettre à la main dans le .config mais make me le vire.
Bon, tant pis, j'en avais besoin, je vais faire avec un 2.6.13
[^] # Re: ipw2100
Posté par tipote . Évalué à 2.
Voici l'information qui t'intéresse tiré du README fourni sur http://ipw2100.sourceforge.net :
Une restriction néanmoins : la version incluse dans le kernel 2.6.14 est un peu plus ancienne que celle-ci (c'est le même README qui le dit). Donc il peut y avoir d'autres subtilités. Dans ce cas, direction /usr/src/linux/Documentation/...
Bonne compilation !
[^] # Re: ipw2100
Posté par mac_is_mac (site web personnel) . Évalué à 4.
CONFIG_IEEE80211=m
# FUSE ... qu'est ce que cela va apporter ?
Posté par Mildred (site web personnel) . Évalué à 6.
Concrètement, va-t-on enfin pouvoir ?
- monter un système de fichiers FTP/SSH/... ?
- monter une archive tar(.gz|.bz2)? et travailler directement dedans ?
- monter ce qu'on veut, par exemple un fichier de conf où chaque variable serait un fichier et sa valeur, le contenu du fichier ?
- ...
Si oui, ce serait vraimment bien ...
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Antoine Jacquet (site web personnel) . Évalué à 5.
C'est ça non ? http://fuse.sourceforge.net/sshfs.html
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Mildred (site web personnel) . Évalué à 1.
chez vous aussi ?
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par symoon . Évalué à 1.
chez vous aussi ?
chezmoicamarche
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par chl (site web personnel) . Évalué à 3.
- monter un système de fichiers FTP/SSH/... ?
J'avais testé il y a quelques mois, le montage de fichiers ftp, ca marchait bien. J'imagine donc que ça ne peut qu'aussi bien marcher.
Par contre, j'avais essayé de lancer qemu sur une image iso située sur un serveur ftp, montée via fuse (ben quoi ?), mais ca n'avait pas marché, et j'ai jamais trop compris pourquoi.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par farib . Évalué à 2.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par chl (site web personnel) . Évalué à 2.
Ensuite, j'etais bien conscient que la lecture aleatoire par ftp, cela n'allait pas etre génial et plutot lent, mais je voulais quand meme voir ce que cela allait donner. Au lieu d'etre super lent, j'avais des caracteres bizarres dans la fenetre de qemu, et j'ai jamais compris pourquoi.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Sebastien . Évalué à 2.
Je me demande si je comprends bien ce que ca veut dire : je vais pouvoir monter l'iso de mon cdrom n'importe ou, meme si je ne suis pas root et s'il n'y a pas d'entree dans le fstab.
J'ai bon ?
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Elrik de Melnibone . Évalué à 2.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Ph Husson (site web personnel) . Évalué à 3.
le monsieur a bien compris
(je viens de tester à l'instant avec sshfs téléchargement + compilation + essai le tout sans passer en root)
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par SuperDindon . Évalué à 1.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Snark_Boojum . Évalué à 1.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Bapt (site web personnel) . Évalué à 3.
http://wikitest.freebsd.org/moin.cgi/FuseFilesystem
d'ailleur il est dans les ports.
Pour le moment seulement sshfs.
Cela dit, tu as raison, gnome-vfs ou kio-slave (je crois que c'est ça sous KDE), donc est portable, et fonctionne sur un grand nombre de plateforme, ce qui n'est pas le case de fuse.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par reno . Évalué à 8.
Par ce que bon, les systèmes de fichiers virtuels intégrés au desktop plutôt que disponible pour tous, bof.
Je sais, c'est plus facile à dire qu'à faire, mais je me demande si ce serait possible..
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par klessou . Évalué à 3.
http://www.fosdem.org/2005/2005/index/interviews/interviews_(...)
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Victor STINNER (site web personnel) . Évalué à 6.
http://fuse.sourceforge.net/wiki/index.php/FileSystems
Quelques projets intéressants :
- WikipédiaFS : je vais passer au nouveau noyau juste pour ça :-) (le temps d'appliquer suspend2)
- GmailFS :-)
- SMB for SUSE (partage Samba / Windows)
- CvsFS (avec les différentes versions)
- DBtoy : accéder à un SGBD (MySQL pour l'instant) par des fichiers XML !
Vu qu'on peut coder ça en tout et n'importe quoi (ça va du C à Python en passant par Bash), on peut vraiment se lacher :-) Avant, écrire un système de fichier en Python aurait été très tordu, car il fallait embarquer un interpréteur Python dans le noyau ! Donc, merci aux développeurs de Hurd pour avoir (indirectement) trouvé l'idée de FUSE ;-)
Note : Fuse fonctionne à l'heure actuelle sous Linux 2.4, Linux 2.6, et FreeBSD.
Haypo qui met des smileys partout, mais FUSE le réjuit beaucoup
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Mildred (site web personnel) . Évalué à 1.
Je sens que je vais tester ca rapidement ... mais je préfèrerais un paquet kernel de ma distrib ubuntu, je crois que je vis passer un unstable rien que pour ca.
Sinon, je l'installerais à la main ... le problème c'est que ca prend de la place et du temps, alors je préfère un paquet
J'espère que cela ne va pas ralentir le hurd que j'espère pouvoir utiliser bientôt.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par tgl . Évalué à 1.
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par dco . Évalué à 2.
Pour l'installation, je vous conseille le blog :
http://ubuntu.wordpress.com/2005/10/28/how-to-mount-a-remote(...)
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Antoine . Évalué à 2.
Bonjour les performances...
[^] # Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
[^] # linker
Posté par z a . Évalué à 1.
Alors j'ai décidé de me faire mes "bindings" en faisant un programme en C qui appele différents scripts. Mon problème est que LD gère trop mal l'option "-wrap" qui m'aurait permis d'écraser en partie des fonctions de "libfuse" (faire que la mienne soit appelée à la place de l'autre, mais pouvoir accéder à l'ancienne à partir de la mienne)
# l'ATAPI-SATA
Posté par newbeewan (site web personnel) . Évalué à 1.
Un autre "nouvelle fonctionnalité" : il est désormais la possible d'activer l'ATAPI pour les lecteur CD/DVD en SATA, fonctionnalité qu'il fallait auparavant aller modifier manuellement dans les sources du noyau... Ceci veut dire qu'elle a beaucoup avancée (95% des fonctions SATA-ATAPI).
Je sais que cette fonctionnalité n'est pas une révolution, mais ça permettra au heureux détenteurs de laptop récent de profiter de leur lecteur CD ;)
@ +
# pilotes ipw2x00
Posté par Jésus Christ . Évalué à 3.
[^] # Re: pilotes ipw2x00
Posté par Cédric Blancher . Évalué à 4.
[^] # Re: pilotes ipw2x00
Posté par herodiade . Évalué à 2.
Le problème ne se résume pas en questions d'éthique/liberté/... mais aussi de qualité et de support: celà ajoute encore un composant dont les developpeurs n'ont pas le controle, ce qui commence à faire beaucoup pour les drivers ipw* et prism54 (les constructeurs respectifs n'ont jamais accepté de fournir aucune spec ou doc).
Leur intégration ne devrait pas être une raison pour ne pas boycotter ces chipsets (heureusement en ce qui les concerne, et en particulier prism54, on a d'autres raisons).
Par contre on peut faire une "echelle de pénibilité" des firmwares propriétaires selon que le constructeur autoriser ou non la libre redistribution du binaire (et avec ou sans signature d'accords).
Puisqu'on parle de cohérence dans les partis pris, il me semble que le cas pwc/pwcx (http://linuxfr.org/2005/05/31/19026.html ) n'était pas si différent mais à conduit au rejet du wrapper gpl par Linus ...
[^] # Re: pilotes ipw2x00
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: pilotes ipw2x00
Posté par M . Évalué à 4.
Tu conseilles quoi ?
Surtout pour faire du mode AP ?
Au passage il y a un projet pour faire un firmware libre pour les prism : http://jbnote.free.fr/islsm/doku.php
[^] # Re: pilotes ipw2x00
Posté par Jésus Christ . Évalué à 2.
[^] # Re: pilotes ipw2x00
Posté par Benjamin Zores (site web personnel) . Évalué à 2.
[^] # Re: pilotes ipw2x00
Posté par M . Évalué à 2.
Je ne citerais que le plus connu : le bios...
[^] # Re: pilotes ipw2x00
Posté par herodiade . Évalué à 2.
Dans ce cas il n'y a pas de contrainte sur la redistribution de l'OS.
Heu... cf. ma réponse à Nicolas qui dit la même chose ci-dessous (j'ai la flemme de le re-écrire ;)
[^] # Re: pilotes ipw2x00
Posté par niclone (site web personnel) . Évalué à 4.
Si on devait supprimer tout les drivers dans linux qui passent par un firmware proprio, il ne resterait plus grand chose de linux.
La seul difference ici (et qui se fait de plus en plus), c'est que le firmware doit être uploadé à la carte avant de pouvoir l'utiliser, contrairement aux autres, ou le firmware est en ROM/EEPROM.
A la limite, ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware (en te basant sur de reverse engenering par exemple, ou en ayant la chance de plus en plus rare d'avoir une doc).
Il ne faut pas confondre firmware proprio et driver proprio. Si les deux seraient certaienement mieux s'ils etaient documenté et libre, le firmware à au moins l'avantage d'être indépendant de l'OS qui tourne sur ta machine, en plus de tourner généralement sur un autre CPU (celui du peripherique en question), ce n'est pas le cas driver qui est dépendant de l'OS, et tourne en plus sur le CPU de ta machine.
[^] # Re: pilotes ipw2x00
Posté par herodiade . Évalué à 6.
Mais le problème n'est pas le même pour un bios intégré au périphérique et un périphérique dont le bios doit être chargé par le kernel.
Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.
Selon les constructeurs (mais c'est bien le cas pour intel et les firmwares ipw), celà pose des problèmes de distribution ; nous sommes soumis au bon vouloir des constructeur de nous accorder le droit de redistribuer le firmware. Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification. Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).
Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).
ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware
Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.
Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...
[^] # Re: pilotes ipw2x00
Posté par M . Évalué à 1.
Le driver ne contient pas le firmware, le chargement se fait de maniere dynamique avec l'interface firmware du noyau.
Apres si le firmware n'est pas libre, c'est a l'utilisateur de le mettre ou il faut, tout comme pour certains periphs il est necessaire de rebooter sous windows pour flasher une version qui marche sous linux.
Pir certains drivers suporte des chips qui n'ont pas besoin de firmware et d'autre qui en ont besoin...
Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).
Tu as toujours l'ancien ?
Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe (c'est ce qui est fait pour de nombreux firmware...)
Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...
Oui, de meme on retrouve de plus en plus de chips softmac (ie ou presque tout est fait dans le kernel, la carte se contant du minimun).
D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
-Le prix,
-une carte qui fait tout sur un hardware dedie (mais l'utilisateur a deja un proc dont il n'utilise pas la moitie des resources),
-une carte qui contient sont firmware (l'utilisateur lamda ne regarde pas comment sont fait les drivers, du moment que ca marche il s'en fou...)
[-une carte avec des specs et un driver libre]
PS : dans le meme genre economie de chandelle, certaines cartes n'ont pas assez de ram pour contenir tout le firmware et celui-ci est swappé dans la RAM de la machine hote...
[^] # Re: pilotes ipw2x00
Posté par herodiade . Évalué à 7.
Oui oops ma langue à fourchée ! je voulais dire bien sur dire : "Dans certains cas le firmware ne peut pas être inclus dans les distributions".
Tu as toujours l'ancien ?
Ou tu ne l'a jamais eu parceque tu vient d'acheter la carte. Et personne n'a le droit de te le refiler sans accord avec le constructeur ... dommage ;)
Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe
Oui, problable. Mais bon ... on sombre dans le très bricolo, très fragile, et fort peu intégré (c'est pas vraiment du fonctionnement out-of-the-box).
D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
-Le prix,
En l'occurence l'utilisateur trouvera vraissemblablement son chipset Intel intégré dans son portable centrino (ou autre), et je doute que les 1 ou 2 euros de la rom fassent la différence. Si l'utilisateur avait vraiment le choix et se préoccupait surtout du prix, il prendrait surement du ralink (avec firmware) et boycotterai, par ex, le prismgt/prism54 (sans firmware). Donc ça tomberai plutot bien ;) (par contre il raterait l'excellent atheros, qui est quand même très cher). Malheureusement l'utilisateur n'a pas le choix, et il se retrouvera souvent, par exemple, avec une carte graphique chère et au gpu surpuissant qui ne lui sert à rien (avec, à coté, un winmodem idiot, une carte wifi sans firmware, et bientot un chipset de drm tcpa ...).
Je ne sait pas pour vous, mais je trouve que l'évolution / l'utilisabilité des technos 802.11a/b/g (sous Linux & *BSD en particulier) est de plus en plus byzantine. On avait quand même moins de conneries avec les bons vieux chipsets ethernet je trouve. Mais il faut dire que c'etait une techno qui avait murit dans le monde pro avant de toucher le grand public ...
[^] # Re: pilotes ipw2x00
Posté par herodiade . Évalué à -2.
Oui oops ma langue à fourchée ! je voulais dire bien sur dire : "Dans certains cas le firmware ne peut pas être inclus dans les distributions".
Tu as toujours l'ancien ?
Ou tu ne l'a jamais eu parceque tu vient d'acheter la carte. Et personne n'a le droit de te le refiler sans accord avec le constructeur ... dommage ;)
Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe
Oui, problable. Mais bon ... on sombre dans le très bricolo, très fragile, et fort peu intégré (c'est pas vraiment du fonctionnement out-of-the-box).
D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
-Le prix,
En l'occurence l'utilisateur trouvera vraissemblablement son chipset Intel intégré dans son portable centrino (ou autre), et je doute que les 1 ou 2 euros de la rom fassent la différence. Si l'utilisateur avait vraiment le choix et se préoccupait surtout du prix, il prendrait surement du ralink (avec firmware) et boycotterai, par ex, le prismgt/prism54 (sans firmware). Donc ça tomberai plutot bien ;) (par contre il raterait l'excellent atheros, qui est quand même très cher). Malheureusement l'utilisateur n'a pas le choix, et il se retrouvera souvent, par exemple, avec une carte graphique chère et au gpu surpuissant qui ne lui sert à rien (avec, à coté, un winmodem idiot, une carte wifi sans firmware, et bientot un chipset de drm tcpa ...).
Je ne sait pas pour vous, mais je trouve que l'évolution / l'utilisabilité des technos 802.11a/b/g (sous Linux
[^] # Re: pilotes ipw2x00
Posté par Alexandre . Évalué à 2.
De même pour le Softmac, on corrige plus facilement du code que du matériel. Ceci étant, la finalité c'est bien de réduire les coûts.
[^] # Re: pilotes ipw2x00
Posté par BAud (site web personnel) . Évalué à 4.
Simplement, il faudrait avoir une licence correcte (genre au pire 2-clause BSD qui n'oblige pas forcément à fournir le code) pour la distribution : en effet, l'utilisateur qui a besoin d'envoyer le firmware à son équipement de connexion au réseau (LAN ou Internet) il se retrouve un peu comme un con pour aller le récupérer sur internet ce foutu firmware qui ne peut pas être intégré dans les distributions libres à cause d'une licence abracadabrantesque...
C'est tout de même l'utilisateur qui est le plus pénalisé dans cette affaire : une licence n'a jamais empêché les concurrents de décompiler / désassembler un firmware (ils utilisent en plus souvent les mêmes composants...). Autant ne pas le distribuer du tout dans ces conditions ! (ce qu'on pourrait penser de certains constructeurs vu la difficulté à retrouver le bon firmware pour le bon modèle, aucun changelog ni description n'étant fournis bien sûr...).
Bien sûr un firmware GPL simplifie tout : si un concurrent veut l'utiliser, il devra fournir le code à son tour lors de la distribution => les utilisateurs bénéficient de plus de fonctionnalités (le firmware n'est pas redéveloppés 15 fois...), les constructeurs bénéficient des fonctionnalités supplémentaires voire les correctifs plus rapidement et leurs équipements en viennent à mieux se vendre (robustesse / fiabilité reconnue toussa)... en plus avec l'approbation et les encouragements de la communauté, que demande le peuple !
[^] # Re: pilotes ipw2x00
Posté par ~ lilliput (site web personnel) . Évalué à 1.
Je pense que ca doit etre de plus en plus vrai dans la micro embarqué .. personne veut donner ca recette de cuisine car coup de dev trop cher, concurrence trop féroce au final au lieu d'accélérer l'innovation ca ralenti parce que les constructeurs n'ont pas le temps d'amortir leur coup.
Enfin c'est juste une pensée.
puis y'en a d'autre on va pas citer broadcom .. qui font des chipset @~~@~{~@:~@$:%~£@:%£ buguéS .. avec des bidouilles dans le driver.
Mes 3 sous.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: pilotes ipw2x00
Posté par Colin Leroy (site web personnel) . Évalué à 5.
drivers/net/wireless/ipw2200.c
Je n'ai effectivement pas trouvé de specs, mais prétendre que des constructeurs qui sortent des drivers GPL refusent de collaborer à tous niveaux, c'est un peu abusé.
[^] # Re: pilotes ipw2x00
Posté par herodiade . Évalué à 4.
Mais le problème n'est pas le même pour un bios intégré au périphérique et un périphérique dont le bios doit être chargé par le kernel.
Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.
Selon les constructeurs (mais c'est bien le cas pour intel et les firmwares ipw), celà pose des problèmes de distribution ; nous sommes soumis au bon vouloir des constructeur de nous accorder le droit de redistribuer le firmware. Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification. Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).
Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).
ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware
Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.
Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...
[^] # Re: pilotes ipw2x00
Posté par niclone (site web personnel) . Évalué à 1.
Oui, c'est vrai que ca pose toujours le problème de l'integration dans une distribution. Mais en ce qui concerne le choix de Linus (post initial), il aurait était idiot de le refuser.
Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.
Non, ce n'est pas aussi simple: flasher une EEPROM peut rendre le peripherique complétement inutilisable, mais surtout rendre le reflashage impossible. Ce n'est pas le cas ici, au pire, il suffit de reseter le periph, ou rebooter.
Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...
Il est evident que l'interet des constructeur n'est pas de permetre qu'on bidouille leur firmware ;) et avoir le firmware en ROM simplifirait les problèmes de license et d'integration pour les distributions.
[^] # Re: pilotes ipw2x00
Posté par superna (site web personnel) . Évalué à 6.
Le futur pilote en dev sera apparemment un des seul pilotes n'ayant aucun firmware a distribuer et sera intégré au kernel en intégralité :-)
=> http://rt2x00.serialmonkey.com
Ces cartes sont peu cheres, se trouvent facilement (Asus, MSI,..), et les pilotes actuels ont été fournis par Ralink en GPL avec des doc des cartes.
[^] # Re: pilotes ipw2x00
Posté par M . Évalué à 4.
heu...
les anciennes cartes wifi avaient aussi tout dans l'eeprom.
C'est le cas de mon aironet qui au passage se presente comme une simple carte ethernet et fait tout le boulot de conversion 802.3<->802.11 en interne.
Ces cartes sont peu cheres, se trouvent facilement (Asus, MSI,..), et les pilotes actuels ont été fournis par Ralink en GPL avec des doc des cartes.
Et ils ont meme fournis des cartes aux developpeurs bsd pour qu'il puisse developper leur pilotes.
# Fuse & encfs
Posté par spotty . Évalué à 4.
Le gros avantage est que si un utilisateur monte son système encrypté, seul lui peut en lire le contenu, personne d'autre même pas root (sauf avec un su évidemment).
Très bonne nouvelle :-D
encfs http://encfs.sourceforge.net/
# Disparition de devfs et ramdisks
Posté par tinodeleste . Évalué à 5.
Chez Debian, ca se joue pour le moment entre les outils initramfs (utilisés par Ubuntu) et les outils yaird, mais rien n'est vraiment décidé pour le moment, vu que ces deux outils sont assez jeunes.
Qu'en est-il chez les autres ?
http://www.xs4all.nl/~ekonijn/yaird/yaird.html
http://people.ubuntu.com/~jbailey/bzrtree/initramfs-tools/ (celle là est assez fruste, je n'ai pas trouvé mieux encore)
# Et cooker...
Posté par barca . Évalué à -5.
PS: Humour inside
# kernel-headers
Posté par err747 . Évalué à 1.
Parceque module-assistant ne trouve pas le pakcage et moi non plus :)...
C'est juste une question de temps avant qu'ils n'apparaissent dans l'archive Debian ou les kernel-headers ne sont pas inclus dans Sid?
Sinon, si quelqu'un sait où je peux les télécharger...
err747 qui se demande si il va devoir se passer de ses drivers... (pas une grosse perte mais quand même)
[^] # Re: kernel-headers
Posté par symoon . Évalué à 4.
Dans ton cas, tu peux utiliser linux-headers-2.6.14 disponible dans Sid.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.