Articles précédents : Développeur
- [116] Rendre GNOME rapide
- [82] Flash player 8 recherche son ingénieur linux
- [16] Le projet BBClone cherche un repreneur
- [3] Préparation de l'atelier Netfilter 2005
- [6] Nouvelles du noyau : Git et modèle de développement
- [47] FFmpeg et MPlayer : Appel au dons pour un nouveau serveur
- [56] Bilan du sommet 2005 des développeurs du noyau Linux
- [66] Le moteur de Gecko en version serveur ?
- [11] JSAN : un « CPAN » pour JavaScript
- [74] Sortie de Qt 4
Liens connexes
- Le changelog (807 hits)
- Le flux RSS (157573 hits)
- DLFP: Nouvelles du noyau : Git et modèle de développement (793 hits)
- Changelog résumé sur KernelNewbies (709 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Sortie du noyau 2.6.14
Posté par Louis Nyffenegger (page perso, ). Modéré le 28 octobre 2005.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;
Le changelog (807 hits)
Le flux RSS (157573 hits)
DLFP: Nouvelles du noyau : Git et modèle de développement (793 hits)
Changelog résumé sur KernelNewbies (709 hits)
> Lire la suite (94 commentaires, moyenne: 3,2). [dépêche : 419 caractères]
ieee80211 !
Enfin l'intégration du stack ieee80211 :-)
Enfin un premier pas pour l'intégration de rt2x00 (http://rt2x00.serialmonkey.com) !
-
[^]Re: ieee80211 !
Posté par vincent LECOQ (Jabber id, page perso, ) le 28/10/2005 à 12:31. (lien). Évalué à 2.a quand le spca5xxx ?
--
Ma signature ici-
[^]Re: ieee80211 !
Posté par Antoine Jacquet (page perso, ) le 28/10/2005 à 13:14. (lien). Évalué à 8.Le problème de spca5xx (comme zr364xx sur lequel j'ai travaillé), c'est que le driver inclut un décodeur JPEG dans le noyau.
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 (page perso, ) le 28/10/2005 à 12:39. (lien). Évalué à 5.L'url sans la parenthèse de fin : http://rt2x00.serialmonkey.com
-
[^]Re: ieee80211 !
Posté par Colin Leroy (page perso, ) le 28/10/2005 à 14:32. (lien). Évalué à 4.À propos de wifi, quelqu'un sait-il pourquoi le driver ipw2200 intégré est la version 1.0.0 ? alors qu'upstream, sur http://ipw2200.sf.net , ils en sont à la version 1.0.8 ?
-
[^]Re: ieee80211 !
Posté par Colin Leroy (page perso, ) le 28/10/2005 à 15:30. (lien). Évalué à 4.Je me réponds à moi-même... C'est parce que seules les versions x.y.0 sont considérées stables par Intel.
-
-
[^]Re: ieee80211 !
Posté par fmaz fmaz () le 30/10/2005 à 15:56. (lien). Évalué à 1.Tu oublies aussi l'impact ENORME que va avoir l'intégration du
grzhtscki8394210 qui va enfin permettre d'espérer utiliser le
zfxkjy148942.-
[^]Re: ieee80211 !
Posté par fmaz fmaz () le 31/10/2005 à 11:29. (lien). Évalué à 4.Visiblement, mon commentaire ne plait pas. Tant pis.
Mais dites, les gens, c'est quoi ieee80211, rt2x00, spca5xxx et zr364xx ?
Parce que bon...-
[^]Re: ieee80211 !
Posté par Brice Arnould ( un_brice ) (page perso, ) le 02/11/2005 à 18:18. (lien). Évalué à 5.rt2x00 c'est un pilote libre pour des puces présentes dans un grand nombre de cartes wifi. Il est encore trop crade pour être intégrés dans l'arbre de Linus.
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--
Respect à RMS.
-
-
re
J'ai toujours aimé la feature :
Un nettoyage du code;
Ca veut tout et rien dire ...
-
[^]Re: re
Posté par Sylvain Sauvage () le 28/10/2005 à 15:13. (lien). Évalué à 10.J'espère que ça veut pas dire qu'ils ont mis de l'ajax dans le noyau...
-
[+] [^]Re: re
Posté par Jacquot Raphael () le 28/10/2005 à 15:16. (lien). Évalué à -3.erf, ils auraient ajouté du javascript dans le noyau ? au secours :P
-
petite erreur
Un meilleur mapping des claviers USB pour Apple PowerBook;
Non , c'est un meilleur support du touchpads des powerbooks sortis après février 2005 .
-
[^]Re: petite erreur
Posté par barca () le 28/10/2005 à 13:30. (lien). Évalué à 5.Une meilleure gestion des cartes son en USB
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 () le 28/10/2005 à 15:55. (lien). Évalué à 7.Un probleme courant est qu'avec certains chipsets de carte mère (Nforce2, entre autres), le micro intégré de la webcam peut être détectée comme carte son principale, ce qui a pour effet, logiquement, de faire planter le moteur de son Alsa.
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
-
-
Claviers Powerbooks
À noter que le "meilleur mapping des claviers USB pour Apple PowerBook" fait surtout que le patch [0] pour activer la gestion de la touche Fn ne marche plus. Il faudra attendre d'avoir un X qui gère le nouveau systeme.
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 (Jabber id, page perso, ) le 28/10/2005 à 14:45. (lien). Évalué à 2.Ben .. j'ai une radeon 9600 sur un Athlon64, et la seule chose à recompiler c'était les modules DRM. Tout le reste est venu par apt-get (kernel 2.6.13, Xorg 6.8.99, libgl1-mesa-dri), de sid ou d'experimental. Et ça fonctionne pas trop mal, ma foi.
-
[^]Re: Claviers Powerbooks
Posté par Cyril (page perso, ) le 28/10/2005 à 17:29. (lien). Évalué à 2.Es-ce que DRI a des chance de fonctionner aussi sur mon PowerBook 17" ?
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 (page perso, ) le 28/10/2005 à 17:49. (lien). Évalué à 3.(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)
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 () le 28/10/2005 à 22:48. (lien). Évalué à 3.Corollaire de la loi de Murphy : il y a toujours des fautes dans un message sur l'orthographe.
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 () le 28/10/2005 à 19:04. (lien). Évalué à 2.Le driver DRI pour r300 supporte toutes les cartes RADEON de la 7500 à la X850 (je ne sais plus quoi) en AGP. Il subsiste encore quelques problèmes avec le PCI-E.
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 (page perso, ) le 28/10/2005 à 23:41. (lien). Évalué à 2.Je dirais que, oui, t'as tout interet à tenter. Celà dit, peut être qu'effectivement ca marchait déjà avec le 2.6.13, comme dit au dessus. Moi j'ai eu besoin de la combinaison 2.6.14 + xorg 6.9.0RC1 + compilation propre de libgl1-mesa-dri (vu qu'il est pas dispo en ppc/unstable actuellement).
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 (page perso, ) le 29/10/2005 à 09:08. (lien). Évalué à 2.http://lists.debian.org/debian-kernel/2005/10/msg01103.html
à 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?
Et reiser4 il sera intégré quand?
Remarque en attendant y a toujours les patchs...
Mon JID est yannbng@jabber.fr
-
[^]Re: Reiser4?
Posté par Nicolas Boulay () le 28/10/2005 à 14:14. (lien). Évalué à 7.il n'est pas près d'être intégrer. Son système de plugin est vue comme une violation d'interface par les dev noyaux. En gros, il lui demande d'intégrer le bidule au niveau vfs.
-
[^]Re: Reiser4?
Posté par Morreale Jean Roc () le 28/10/2005 à 16:31. (lien). Évalué à 5.Par les devs noyaux ou par les devs de XFS ? Parce que généralement à chaque fois que le sujet est abordé sur la lkml c'est eux qui sortent cet argument. R4 propose tout plein de trucs tout "ouuuh shiny!" et c'est vraiment dommage qu'on ne puisse pas en profiter en vanilla.
-
[^]Re: Reiser4?
Posté par galactikboulay () le 28/10/2005 à 16:35. (lien). Évalué à 5.Sauf que quand tu vois ce genre de message:
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 Morreale Jean Roc () le 28/10/2005 à 16:46. (lien). Évalué à 4.En réponse à Christoph Hellwig, dev XFS, disant que le code de R4 est tout pourri. Je trouve d'ailleurs la réponse de Hans assez marrante, enfin bon quand ils auront fini de se mettre sur la gueule après toutes ces années on finira bien par avoir R4 en-dehors de -mm...quoique vu les 2 lascars ça risque de prendre du temps.
-
[^]Re: Reiser4?
-
-
-
[^]Re: Reiser4?
Posté par oliv () le 28/10/2005 à 17:07. (lien). Évalué à 10.Tu reprends les calomnies de Hans Reiser à l'égard des devs de Linux. Si tu lisait mieux la LKML, tu te rendrais compte que le seul vrai obstacle à l'intégration de Resier4, c'est Hans Reiser. cf.
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
Du côté du filtrage de paquets[0], les nouveautés sont nombreuses.
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 (page perso, ) le 07/11/2005 à 09:12. (lien). Évalué à 1.Qu'est ce que cela apporte par rapport au netfilter/iptables classique ? Est ce que j'ai l'impression qu'on veut déplacer netfilter au niveau user ?
Pourrais tu détailler un peu ?--
"Nobody expects the spanish inquisition"
SD card
Et aussi le support des cartes SD (pratique pour les utilisateurs d'appareils photos).
-
[^]Re: SD card
Posté par Jacquot Raphael () le 28/10/2005 à 15:16. (lien). Évalué à 1.malheureusement, seul le controlleur Winbond W83L51xD est supporté.
mon portable contient un ricoh R5C822, qui ne marchera donc pas :(
-
[^]Re: SD card
Posté par Christophe Merlet (page perso, ) le 28/10/2005 à 15:56. (lien). Évalué à 5.C'est quoi le "support des cartes sd" ?
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 () le 28/10/2005 à 19:46. (lien). Évalué à -1.Comment fais-tu ? Tu as un lien ?
Merci-
[^]Re: SD card
Posté par djibb (Jabber id, page perso, ) le 28/10/2005 à 19:55. (lien). Évalué à 3.tous les lecteurs de carte externes fonctionnent. (presque tous..moi j'en ai jamais vu un ne pas fonctionner)
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 () le 28/10/2005 à 21:33. (lien). Évalué à -1.je branche et gnome-volume-manager fais tout ce qu'il faut. Il m'ouvre une appli pour tout importer.
-
-
[^]Re: SD card
Posté par Cédric Blancher (page perso, ) le 29/10/2005 à 12:00. (lien). Évalué à 6.C'est quoi le "support des cartes sd" ?
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(...)--
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help m
-
ipw2100
Le code est bien dans le noyau, mais pas moyen de l'activé via menuconfig.
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 () le 28/10/2005 à 14:16. (lien). Évalué à 2.Il doit te manquer une dépendance...
Voici l'information qui t'intéresse tiré du README fourni sur http://ipw2100.sourceforge.net :
MAKE SURE THAT THE FOLLOWING CAPABILITIES ARE ENABLED:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_NET_RADIO 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Failure to enable this will result in the Wireless Tools (iwconfig, iwlist,
etc.) not functioning. In 2.6.x, this is enabled via menuconfig:
Device Drivers ->
Networking support ->
Network device support ->
Wireless LAN (non-hamradio) ->
Wireless LAN drivers (non-hamradio) & WE
~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_FW_LOADER 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
ipw2100 loads firmware via the Linux firmware hotplug capability (see later
section on firmware loading). In 2.6.x, this is enabled via menuconfig:
Device Drivers ->
Generic Driver Options ->
Hotplug firmware loading support
~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_CRYPTO 1
#define CONFIG_CRYPTO_ARC4(_MODULE) 1
#define CONFIG_CRC32(_MODULE) 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
ipw2100 uses the WEP encryption and decryption algorithms provided
by the Linux kernel. To use WEP you must enable the Crypto library support
(CONFIG_CRYPTO) and the ARC4 cipher algorithm (CONFIG_CRYPTO_ARC4) via:
Cryptographic options ->
ARC4 cipher algorithm
You also need to enable the CRC32 (CONFIG_CRC32) algorithm via:
Library routines ->
CRC32 functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_CRYPTO_MICHAEL_MIC(_MODULE) 1
#define CONFIG_CRYPTO_AES_586(_MODULE) 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you wish to enable (optional) WPA support, you also need to enable the
following Crypto library modules (in addition to those required for WEP above):
Cryptographic options ->
Michael MIC keyed digest algorithm
AES cipher algorithms (i586)
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 (page perso, ) le 28/10/2005 à 14:33. (lien). Évalué à 4.Il te faut aussi
CONFIG_IEEE80211=m
FUSE ... qu'est ce que cela va apporter ?
Il semblerait que FUSE permette de monter des systèmes de fichiers en espace utilisateur ...
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 (page perso, ) le 28/10/2005 à 14:27. (lien). Évalué à 5.- monter un système de fichiers FTP/SSH/... ?
C'est ça non ? http://fuse.sourceforge.net/sshfs.html-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Mildred (Jabber id, page perso, ) le 28/10/2005 à 14:55. (lien). Évalué à 1.Je pense mais chez moi, fuse.sf.net ne répond pas ...
chez vous aussi ?-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par symoon (page perso, ) le 28/10/2005 à 15:24. (lien). Évalué à 1.Je pense mais chez moi, fuse.sf.net ne répond pas ...
chez vous aussi ?
chezmoicamarche
-
-
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par chl (page perso, ) le 28/10/2005 à 14:31. (lien). Évalué à 3.Concrètement, va-t-on enfin pouvoir ?
- 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 () le 28/10/2005 à 15:14. (lien). Évalué à 2.peut etre parce que les accès random en écriture, c'est pas trop super efficace en FTP ?
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par chl (page perso, ) le 28/10/2005 à 15:40. (lien). Évalué à 2.Heu non, par FTP ce n'etait que de la lecture seulement, et il n'y avait pas d'ecriture puisque c'etait un liveCD.
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 Binet () le 28/10/2005 à 15:15. (lien). Évalué à 2.Usable by non privileged users
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 () le 28/10/2005 à 15:48. (lien). Évalué à 2.Non, ca veut juste dire que tu peux coder un FS en espace user (root) et non en espace noyaux. Tu peux utiliser la glibc par exemple. C donc plus simple et moins dangereux (sécu et crash). Par contre c moins rapide.
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Krunch (Jabber id, page perso, ) le 04/11/2005 à 12:06. (lien). Évalué à 2.Á noter qu'il est aussi possible d'écrire un fs en userland sans FUSE ni privilège particulier en bidouillant LD_PRELOAD. http://svn.clifford.at/shadowfs/trunk/
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Snark_Boojum () le 28/10/2005 à 15:52. (lien). Évalué à 1.Pas sûr... FUSE est spécifique à linux... est-ce que gnome-vfs ne fonctionne pas aussi sous les *BSD ?
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Bapt (page perso, ) le 28/10/2005 à 16:15. (lien). Évalué à 3.FUSE fonctionne sous FreeBSD :
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 () le 28/10/2005 à 19:59. (lien). Évalué à 8.Je me demande s'il ne serait pas possible de faire que gnome-vfs et kio-slave soient une "surcouche" de FUSE sur les systèmes qui l'ont et gardent le comportement actuel sur les systèmes qui ne l'ont pas?
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 (Jabber id, ) le 29/10/2005 à 09:00. (lien). Évalué à 3.Une interview de Alexander Larsson, nous éclaire sur les différences entre l'approche de gnome-vfs et celle de FUSE.
http://www.fosdem.org/2005/2005/index/interviews/interviews_(...)
-
-
-
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Victor STINNER (page perso, ) le 29/10/2005 à 04:02. (lien). Évalué à 6.La liste des projets est longue :
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 (Jabber id, page perso, ) le 29/10/2005 à 09:18. (lien). Évalué à 1.Et même un MboxFS pour le ransformer en maildir ?
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 () le 29/10/2005 à 10:58. (lien). Évalué à 1.T'as regardé si il n'y avais pas des packages du module FUSE de dispo pour le kernel Ubuntu ? Ou sinon, si t'as les headers de ton noyau, tu peux toujours te le compiler à la mimine. Enfin bref, tout ça pour dire que y'a pas besoin d'un 2.6.14 pour jouer avec FUSE. Perso, ça fait bien plus d'un an que je l'utilise comme ça, compilé à côté.
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par dco () le 05/11/2005 à 10:26. (lien). Évalué à 2.Fuse, sshfs, encfs et gmailfs sont dans des packages ubuntu Breezy badgers....
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 ?
-
-
[^]Re: FUSE ... qu'est ce que cela va apporter ?
Posté par Adrien BUSTANY (Jabber id, page perso, ) le 02/11/2005 à 12:07. (lien). Évalué à 1.WikipediaFS plante chez moi, et Gmailfs est leeeeeeeeeeeeent. Mais sshfs marche très bien.
-
[^]linker
Posté par z a (Jabber id, ) le 09/11/2005 à 16:38. (lien). Évalué à 1.Le site officiels des "bindings" SH de FUSE ne marche plus depuis un moment (ça fait une semaine que j'essaye d'y aller).
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
Bonjour,
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
Je suis assez decu qu'on intègre des pilotes comme ipw2x00. Etant donné le firmware ca aurait été un signe assez fort de les laisser en dehors.
-
[^]Re: pilotes ipw2x00
Posté par Cédric Blancher (page perso, ) le 29/10/2005 à 13:01. (lien). Évalué à 4.Et le fait que prism54, qui nécessite également le chargement d'un firmware propriétaire, soit intégré depuis longtemps maintenant ne te fait pas grincer des dents ?
--
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help m-
[^]Re: pilotes ipw2x00
Posté par herodiade () le 29/10/2005 à 13:31. (lien). Évalué à 2.Bin moi ça me fait grincer des dents dans les deux cas.
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 () le 29/10/2005 à 14:21. (lien). Évalué à 3.Rien à voir, le wrapper était destiné à faire tourner du code dans le processeur principal, et non pas à transmettre un firmware au périphérique.
-
[^]Re: pilotes ipw2x00
Posté par Matthieu C () le 29/10/2005 à 15:46. (lien). Évalué à 4.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).
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 (page perso, ) le 29/10/2005 à 15:00. (lien). Évalué à 2.si biensur, pourquoi encore un de plus ?
-
-
[^]Re: pilotes ipw2x00
Posté par Benjamin Zores (page perso, ) le 29/10/2005 à 15:55. (lien). Évalué à 2.Dans ce cas, tu peux aussi abandonner le support de 2/3 des cartes DVB parce que là je peux te dire qu'il y en a un paquet des firmwares non libres ...
-
[^]Re: pilotes ipw2x00
Posté par Matthieu C () le 29/10/2005 à 16:40. (lien). Évalué à 2.Et n'oublions pas tous les firmwares non libre qui sont stockés dans des flash/eeprom de nos PC.
Je ne citerais que le plus connu : le bios...-
[^]Re: pilotes ipw2x00
Posté par herodiade () le 29/10/2005 à 19:22. (lien). Évalué à 2.Non, ce n'est pas le même problème pour les périphériques qui intègrent déjà leur bios.
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 (Jabber id, page perso, ) le 29/10/2005 à 17:37. (lien). Évalué à 4.Il va falloir faire du ménage alors, parcequ'il n'y a pas beaucoup de periphs qui n'ont pas de firmware proprio. Le bios bien sur, mais aussi les disques dur ont un firmware proprio, tout comme les lecteurs/graveur cd/dvdrom, les scanner, imprimantes, chips audio, jusqu'a ta souris optique.
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 () le 29/10/2005 à 19:17. (lien). Évalué à 6.Je suis d'accord avec le fait qu'on ne peut pas se passer de BIOS propriétaires distribué dans les périphériques, et que ce n'est pas gravissime.
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 Matthieu C () le 29/10/2005 à 20:06. (lien). Évalué à 1.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.
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 () le 29/10/2005 à 21:38. (lien). Évalué à 7.Le driver ne contient pas le firmware
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 () le 29/10/2005 à 21:48. (lien). Évalué à -2.Le driver ne contient pas le firmware
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 LISSY (Jabber id, ) le 29/10/2005 à 20:51. (lien). Évalué à 2.Le problème des firmware chargés par le driver, je pense plutôt que c'est pour faciliter la maintenance. Mettre à jour le firmware se résume à une mise à jour du driver, alors que dans le cas d'un firmware dans une EEPROM, c'est diablement plus compliqué.
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 baud123 (Jabber id, page perso, ) le 29/10/2005 à 23:51. (lien). Évalué à 4.Effectivement pour la maintenance c'est sympatique.
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 (page perso, ) le 04/11/2005 à 15:27. (lien). Évalué à 1.sans lancer du troll bcp de compagnie utilise du GPL, mais ont tellement peur des concurrents qu'elles ne liberent pas le code ou meme mentionne qu'elle utilise un system a base de linux/bsd ou autre.
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.
-
-
-
[^]Re: pilotes ipw2x00
Posté par Colin Leroy (page perso, ) le 31/10/2005 à 09:16. (lien). Évalué à 5.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).
drivers/net/wireless/ipw2200.c
Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
Contact Information:
James P. Ketrenos <ipw2100-admin@linux.intel.com>
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
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 () le 29/10/2005 à 19:29. (lien). Évalué à 4.Je suis d'accord avec le fait qu'on ne peut pas se passer de BIOS propriétaires distribué dans les périphériques, et que ce n'est pas gravissime.
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 (Jabber id, page perso, ) le 29/10/2005 à 21:23. (lien). Évalué à 1.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.
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 (Jabber id, page perso, ) le 30/10/2005 à 09:52. (lien). Évalué à 6.Comme le cas des cartes Ralink RT2500/RT2400/RT2570 qui intégrent l'intégralité du firmware dans l'EEPROM.
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 Matthieu C () le 30/10/2005 à 11:24. (lien). Évalué à 4.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é :-)
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
Génial, je pourrais arrêter de compiler fuse en module et séparément pour des filesystem encryptés.
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
avec le 2.6.13 déjà, les lignes de codes de devfs avaient été commentées ou effacées. Un des plus gros changements est que les ramdisks ne peuvent plus être générés par les outils initrd classiques et que les distributions doivent chercher des alternatives pour générer ces images (utile pour éviter l'inflation du noyau quand on veut pouvoir démarrer sur tout type de système, pour un noyau maison, il reste souvent plus simple de choisir ses propres modules/drivers noyau sans utiliser /initrd).
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...
kernel-headers
Heu et pour compiler les modules nvidia on fait comment?
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 (page perso, ) le 05/11/2005 à 20:22. (lien). Évalué à 4.Afin de préparer l'arrivée de noyaux autres que Linux dans Debian, c'est maintenant linux-headers* ainsi que linux-image* au lieu des kernel*.
Dans ton cas, tu peux utiliser linux-headers-2.6.14 disponible dans Sid.



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.