Sun est surtout très fort pour les coups d'éclats et la com.
Les developpeurs d'OS libres attendent toujours les spécifications d'un certains nombres de chipsets ultrasparc assez vérouillés. Et le verilog du T1 n'aide en rien.
On explique que certains logiciels de p2p (mldonkey fait ça, je ne sait pas trop pour aMule) font volontairement des gros fichiers "à trous" (aka "fragmentation").
Alors moi je trouve très bien que Linux (comme les autres systèmes POSIX en fait) permette de fseek()er comme un salop après la fin d'un fichier lorsque je (ou une appli) le souhaite, et surtout qu'il ne "defragmente" dans mon dos.
On dit souvent que Linux (sur ext3) (et les *BSD sur ffs et ufs2 d'ailleur) ne fragmente pas trop: il faut comprendre qu'il sait bien gérer les fichiers tout seul et se debrouille pour les aranger proprement, lorsqu'on ne lui donne pas de contre-directives à ce sujet.
Celà étant posé, il n'empêche pas la fragmentation intentionelle, volontaire, décidée par l'utilisateur, car elle peut être justifiée.
Bref, la conclusion de tout ce fil, c'est : "les applis de p2p sont de grosses cochonnes avides de ressources", rien de neuf, et pas de quoi fouetter un chat ...
j'avais vu le départ du dev de Sendmail X, mais je pense qu'on perd alors l'expérience et le caractère éprouvé du code actuel.
Pour le recettage du code, c'est assez vrai. Hum, qui va essuyer les platres des premières releases ?
Mais concernant l'expérience, je ne crois pas qu'Eric Allman vas oublier ses 20+ ans de developpement de MTA, (pièges, évolutions, erreurs de design, sécurisation à posteriori ...) du jour au lendemain ;)
mais licence GPL donc peut-être guerre de religion ?
Non, ils considérent la licence de Sendmail comme une GPL-like (c'est d'ailleur pour ça qu'il est dans l'arbo "gnu/" du dépôt cvs d'OpenBSD), donc pas de différence de ce point de vue pour eux.
À l'époque Sendmail était le seul MTA évolué et (suffisamment) libre. Je crois qu'Exim n'est devenu une alternative suffisamment évoluée que par la suite (par ailleurs, des devs d' OpenBSD ont expliqué qu'ils le trouvaient très mal conçu et atrocement codé). Postfix et Qmail ne sont pas assez libres selon Theo de Raadt.
D'autre part les choses ont aussi beaucoup évolué pour Sendmail: l'équipe de dev était très réceptive aux patchs proposés par l'équipe d'OpenBSD (à contrario de l'équipe d'Apache), et ils ont fait énormément d'efforts pour sécuriser leur logiciel.
Il est maintenant très rare que de nouvelles failles soient découvertes dans Sendmail: la dernière date d'il y a deux ans (faille patchée par Todd C. Miller, de l'équipe d'OpenBSD justement). Les dernières failles découvertes dans Exim sont beaucoup plus récentes en comparaison (au moins deux en 2005). Encore une preuve que l'audit, ça paie :)
De plus un énorme refactoring est dans les tuyaux pour Sendmail X (dans le sens d'une modularisation etc.), actuellement en version alpha.
Quand à la config, elle est maintenant facilitée par un jeu de macros m4 bien fait et assez complet, si bien qu'on peut maintenant considérer le fichier (très simple) sendmail.mc comme le vrai fichier de conf, et ignorer le sendmail.cf. Voir par ex. http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendm(...)
Bref, il est temps de réviser l'horrible réputation de Sendmail. Surtout si c'est pour lui opposer Exim.
Quoiqu'il en soit, postfix et Exim sont dans les ports (à la différence d'apache 2.0/2.2) et le remplacement de Sendmail est facilité grâce à un jeu de scripts. cf. mailer.conf(5).
Ah si Wietse Venema et IBM plaçaient Postfix sous licence MIT/X11 ou BSD ...
Je ne sait pas si ce modèle (la version 'L' des WRT54G) intègre lui aussi un chipset Broadcom, mais on peut regretter que Linksys (comme Apple, d'ailleur) n'ai pas fait pression sur Broadcom pour qu'ils nous filent des specs... la sortie du WRT54GL, bien que louable en soi, révèle un linksys plutôt opportuniste.
Il existe une petition pour obtenir de Broadcom un driver Linux : http://www.petitiononline.com/BCM4301/
La forme de la pétition est -légèrement- contestable: un « driver Linux » n'est pas suffisant, s'il est binaire seulement, ou pas modifiable, ou i386 seulement, ou pas légalement redistribuable, ou pas portable sur les kernels 2.6, ou pas accomapgné de docs pour les corrections de bugs et l'implementation sur les autres OS libres, etc... ; d'ailleur il existe déjà un driver : celui récupéré dans les WRT54G et retro-engeneeré. Sans parler du driver win + ndiswrapper.
Il aurait été préférable que la petition réclame clairement et uniquement des specs complètes (au moins, ça serait profitable aux *BSD aussi, et ça permettrai à la communauté de debugguer le driver), mais le boulot de rétro-ingénierie des pilotes binaires Linux a visiblement atteint cet objectif sans l'aide de Broadcom.
Bravissimo ! et honte à Broadcom !
Maintenant, une question subsidiaire: ces périphériques necessitent-ils le chargement à chaud d'un firmware ? si oui, le firmware est-il librement redistribuable (sinon libre et opensource) ?
Si tu as une carte PrismGT, les résultats de ton test sont les bienvenus :)
Ouille, désolé, j'ai toujours évité ce chipset du fait du manque de support ...
Effectivement, la conséquence c'est que ça n'aide pas ce support à avancer :( . La poule, l'oeuf, toussa...
Ça a été expliqué publiquement, tu trouvera les discussions à ce sujet dans les archives de la mailing-list misc@. Entre autres raisons:
- C'est un projet BSD, celà signifie qu'il privilégie les licences les moins contraignantes possible. La licence d'apache 1.3 était très acceptable pour la communauté BSD, mais celle d'apache 2.x impose des contraintes plus strictes (raison aussi de la décision d'abandonner, à peut près à la même époque, XFree86 pour x.org).
- En outre les devs d'Open n'aiment pas les licences longues et compliquées, et préfèrent maintenant les licences à la MIT/X11/ISC (plus facile à comprendre sans ambiguité, surtout pour des non-juristes).
- L'apache inclus dans leur système avant le changement de licence était déjà largement modifié pour sécurisation (révocation des privilège plus stricte, chroot par défaut des processus fils etc.) et convenait suffisament bien au projet et à ses utilisateurs.
- Certainsdeveloppeurs d'OpenBSD attendaient une bonne occasion pour ne plus avoir a suivre l'évolution d'apache (merger les nouvelles versions), pour avoir la latitude de faire de plus grosses modifications dans l'arbre des sources, comme: virer les wrappers ap_* afin de faciliter l'audit et la relecture du code, assainir le traitement des chaines et des signaux etc ... toujours dans l'objectif d'améliorer la sécurité du serveur httpd.
Les résultats concrets sont déjà visibles. Par exemple leur version d'apache n'était pas affectée par la récente faille CAN-2004-0700, ce bug ayant été corrigé bien avant dans l'arbre des sources d'OpenBSD lors d'une série d'audits/renforcements/nettoyages de routine sur le traitement des chaines dans apache (cf. le commit sur ssl_engine_ext.c qui corrige cette faille: revision 1.10, date: 2003/06/01 15:53:41; author: deraadt; "various format string cleanups; tedu ok"). Il y a d'autres exemples de ce type.
Bref, maintenir une fork d'apache 1.3 (sans casser l'API, pour rester compatible avec les modules externes) était la solution la plus pertinente étant donné leurs priorités (préférences pour les logiciels aux licences très permissives, priorité à la sécurité et l' "auditabilité" stricte du codeplutôt qu'aux fonctionnalités amenées par la version 2) de la même façon que de nombreux admins préfèrent apache 1.3 pour sa robustesse éprouvée.
Les devs du driver ralink libre sous linux trainent un peu car ils souhaitent l'intégrer proprement dans le framework 802.11 logiciel en cours d'integration dans le noyau linux (si je ne me trompe pas, la partie intégrée dans 2.6.14 n'inclus pas encore le support hostap logiciel).
Donc je tempère ta remarque: le mode hostap sera géré par le drivers libre ralink sous linux mais les devs de ralink/linux ne veulent pas coder un AP logiciel redondant avec celui que préparent les gars du framework 802.11, ce qui est bien compréhensible, c'est un gage de meilleure qualité/maintenabilité, à moyen terme. Ce chipset est d'ailleur pleinement supporté dans tout les modes (y compris master/hostap) dans les *BSD (qui il est vrai ont un framework 802.11 logiciel depuis un moment déjà), donc c'est tout à fait faisable.
Bref, ça reste un chipset très prometeur (et bon marché) sur les unix libres. Pour le mode hostap, il suffit d'attendre un peu, ou d'utiliser OpenBSD. Ou acheter une atheros en attendant (très performant, mais c'est beaucoup plus cher).
Au passage, l'unification du framework wifi sous linux est vraiment une bonne chose: celà évitera les implémentations redondantes (pour quasiment tout les chipsets wifi modernes, qui délègue la gestion du protocole au kernel pour des raisons d'économies), celà permetra d'unifier les extensions WE et les outils de gestion des interfaces (ifconfig, iwconfig, ...) ou d'autres fonctionalités wifi (aircrack, kismet etc.).
Pour le moment il faut reconnaitre que le wifi sous linux, c'est vraiment le bordel (on est loin de l' « unité » du monde fast-ethernet par exemple); et le fait que les constructeurs puissent produire des produits ayant les mêmes références mais des chipsets différents n'arrange rien.
Pour revenir à la dépêche: le boulot sur FreeMac est vraiment vraiment impressionant ! y a-t-il projet de supporter le chipset prismGT aussi (ou est-ce déjà le cas) ?
Le support webcam marche super et les gens n'auront plus d'excuses pour utiliser Linux à la place de Windows à cause de Messenger.
J'utilise (en fait: fait utiliser ;) depuis quelques temps la version cvs de amsn, qui (depuis peu) supporte aussi la webcam sous MSN.
Mais avec amsn il reste un problème bloquant pour les Messenger addicts: seul le texte et maintenant la webcam sont supportés. Pas l'audio.
Est-ce que Kopete nous affranchi de cette limitation ? supporte-t-il le proto de voip de MSN ?
Ça marche super bien (vraiment !).
Par contre il faut payer des royalties pour les licences, donc c'est plutôt orienté « usage professionel ».
Peut-être que le binding PyQt sur Qt4 changera la donne ? (car le port win32 de Qt4 est maintenant GPL et gratuit lui aussi).
La news explique très justement que ce pool de brevet peut servir d'arme pour contre attaquer.
C'est un point interessant. Mais il y a quelque chose de beaucoup plus fascinant (et aussi moins polémique je crois, "la fin justifie-t-elle les moyens ? etc."), c'est que tout les adhérents sont aussi protégés par le simple fait qu'ils se sont engagés à ne pas s'entre-attaquer !
Le texte indique (traduit vite fait):
"Les brevets détenus par Open INvention Network seront disponibles gracieusement (sans frais) pour toute compagnie, institution ou individu qui accepte de ne pas utiliser les brevets dont il dispose contre le systeme d'exploitation Linux ou certaines applications en relation avec Linux".
Et je trouve ça absolument fascinant ! ça ouvre des abymes de questions et d'idées:
- Certains groupes sont fermement opposés aux brevets logiciels et n'acceptent pas l'idée d'utiliser des brevets, même pour contre attaquer.
Par contre je pense qu'ils souscriront volontier à cette idée: j'adhère à OIN et je m'engage a ne pas attaquer les autres adhérents , en contreparti je ne serait pas attaqué par les autres adhérents (dont IBM, Sony etc.). C'est donc une excellente garantie, même pour les simples individus, et on n'est pas forcé d'utliser OIN pour contre-attaquer (donc on peut rester intègre sur sa position).
- Pour de nombreuses compagnies, adhérer a OIN peut être un bon moyen de se protéger contre ces énormes boites (IBM dispose de milliers de brevets) à moindre cout (négocier avec IBM, à l'amiable ou devant un tribunal, même si on a des brevets a leur opposer où si on est dans son droit, c'est couteux et long).
- Du coup, OIN pourrait croitre exponentiellement: chaque nouvelle société qui y adhère apporte son lot de brevet, rendant ainsi OIN plus fort et dangereux pour les autres boites utilisant les brevets, qui seraient alors encouragées à adhérer. Je fantasme ? peut-être, mais ce serait superbe non ? et ce n'est pas impensable !
exemple: si je me fait attaquer par Sony, IBM ou Phillips, je crois que je serait très tenté de régler ça en 5mn en adhérant à OIN ! ou bien encore: si j'ai envi d'utiliser gratuitement une techno (linux related) de Sony ou IBM, je commencerai par adhérer à OIN pour ne pas être attaquable.
- Linux pourrai devenir très vite, grace à OIN, un système inattaquable tellement le nombre de brevets le protégeant seront nombreux.
- Le status quo (non attaque entre les grosses compagnies) est déjà plus ou moins effectif dans le monde du brevet logiciel. Mais ce qui pèse toujours lourd, ce n'est pas tant d'être attaqué que d'être attaquable.
Les compagnies attaquables perdent la confiance des investisseurs, les particuliers et sociétés s'empechent d'utiliser des technos brevetés à cause des incertitudes (cf. par ex. la lecture mp3, souvent exclus des distros bien que Frauhnofer ai indiqué qu'ils n'attaqueraient que les encodeurs).
Les brevets excercent déjà leur nocivité à plein régime par le simple FUD (fear uncertainty and doubt).
- Sera-t-il possible pour de simples individus adhérants d'utiliser OIN pour menacer des sociétés detenant des brevets, et les forcer à adhérer à leur tours ? (non plus contre-attaquer, mais prendre les devants !).
Je verai bien un tir groupé et massif sur Fraunhofer, divx, Apple, Secure Computing etc.
- Ce qui est couvert par l'alliance, "Linux operating system or certain Linux-related applications" est un concept à géométrie variable ... comment définisse-t-ils ceci ? Par ex. est-ce que l'ensemble de Debian GNU/Linux est compris dans cette définition ?
- Nokia s'est déjà engagé à ne pas attaquer les developpeurs et utilisateurs du noyau Linux. Pourquoi n'adhèrent-ils pas ? Et Sun ?
- La non décision du parlement Européen concernant la brevetabilité logicielle ne rend elle pas caduque cette initiative en Europe ? Un particulier n'aura alors pas les moyen de se défendre (en faisant valoir l'illégalité du brevet) ni de contre-attaquer (puisque ces brevets n'ont pas de valeur).
Heu oui mais ce dont vous parliez c'est du besoin d'avoir le machin graphique de conception d'interface intégré à un éditeur (ce que j'ai compris par "IDE" en tt cas).
Parce que sinon: Qtdesigner est vraiment très bien pour faire ses interfaces à la souris. Et ensuite, effectivement, n'importe quel éditeur convient pour écrire le code C/C++ en dessous.
Et concrètement dans la pratique, il existe quelles IDE valables pour du Qt/C++ ? Aussi aboutis que Sharp Develop par exemple.
sous Linux & *BSD au moins, je ne dev pas sous d'autres plateformes on trouve notament kdevelop , assorti de tout le bazard pour les besoins précis (assistant pour l'aide/la doc, designer pour la gui, linguist pour l'internationalisation ...), ou XCode sous mac.
Hum, il n'y a qu'un hôte qui utilise l'ip alors ? C'est simplement pour permettre le remplacement d'un hôte à chaud ? (redondance)
Oui exact.
Mais tu peut avoir deux (ou plus) IP flottantes gérées de la sorte par CARP et faire ainsi de la répartition de charge en proffitant de la puissance des deux (ou plus) machines: chaque machine utilise une des IP, on peut répartir le traffic par rr dns ou autre (et lorsque l'une des machines est en panne, l'autre récupère son traffic).
Bref, dans l'esprit de simplicité et minimalisme BSD, CARP a été conçu pour ne gérer que le failover/redondance, mais tout de même pour ne pas empécher la répartition de charge.
Dans la boite à outils complémentaires il y a aussi pfsync, qui permet de synchroniser les tables d'états et rulesets des firewalls entre les diverses machines et sasyncd pour synchroniser les SA IPsec (je ne crois pas que ce denier soit déjà porté d'OpenBSD 3.8 à FeeBSD 6). Le tout permettant de faire, par ex lorsque couplé à CARP, des firewalls et passerelles VPN redondants avec reprise de traffic automatique et sans interuption.
Un plus pour qt4 si la portabilité est un objectif important (c'est un peu comme ça que je comprend le "dont le but sera notamment d'être distribuée le plus largement possible").
À ma connaisance mono (donc C#) n'est pas encore porté sur la plupart des systèmes *BSD (et en particulier sur les architecture non i386) ; Idem pour java (surtout si tu a besoin d'un jdk1.5, qui par ex n'est pas porté sur Mac OS X, mais gcj n'est pas encore très portable non plus). Par ailleur la large audience que tu semble vouloir toucher sera certainement heureuse de n'avoir pas à installer des interpréteurs pour faire tourner l'appli, surtout les non informaticiens.
La légereté (économie de mémoire) est aussi un bon argument en faveur de qt par rapport à java/mono.
Dans tout les cas (heu, en fait pour java et qt au moins) il y a des bindings opengl à disposition et ont toutes les widgets nécéssaires pour faire des "interfaces bien léchées", donc semblent remplir les (trop peu détaillées) contraintes techniques que tu indique.
Au rayon des changement, il faut signaler une amélioration très sensible des performances, en parficulier sur les accès au systeme de fichier et de façon générale sur les systèmes SMP (d'ailleur de très nombreux drivers, surtout pour les cartes réseau, sont maintenant, depuis la branche 6, mpsafe et leur travail est partiellement parallélisable ...).
Il semblerait que l'énorme travail effectué sur l'écriture et l'intégration du nouveau scheduler, l'elimination de giant lock etc. mis en place avec la branche 5 commence à peine à porter ses fruits avec la branche 6 qui vient d'arriver.
C'était un travail de longue haleine, mais c'est agréable de constater que les choix faits des années plus tôt étaient réalistes et pertinents !
Un autre changement sympa: le proto carp est maintenant supporté.
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
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 ...
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...
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 ;)
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...
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 ...
# pure com'
Posté par herodiade . En réponse au journal Sun pense au libre pour le hard. Évalué à 4.
Les developpeurs d'OS libres attendent toujours les spécifications d'un certains nombres de chipsets ultrasparc assez vérouillés. Et le verilog du T1 n'aide en rien.
[^] # Re: Réponse groupée
Posté par herodiade . En réponse au journal Fait n°1 : Linux n'est pas sujet à la fragmentation.... Évalué à 3.
On explique que certains logiciels de p2p (mldonkey fait ça, je ne sait pas trop pour aMule) font volontairement des gros fichiers "à trous" (aka "fragmentation").
Alors moi je trouve très bien que Linux (comme les autres systèmes POSIX en fait) permette de fseek()er comme un salop après la fin d'un fichier lorsque je (ou une appli) le souhaite, et surtout qu'il ne "defragmente" dans mon dos.
On dit souvent que Linux (sur ext3) (et les *BSD sur ffs et ufs2 d'ailleur) ne fragmente pas trop: il faut comprendre qu'il sait bien gérer les fichiers tout seul et se debrouille pour les aranger proprement, lorsqu'on ne lui donne pas de contre-directives à ce sujet.
Celà étant posé, il n'empêche pas la fragmentation intentionelle, volontaire, décidée par l'utilisateur, car elle peut être justifiée.
Bref, la conclusion de tout ce fil, c'est : "les applis de p2p sont de grosses cochonnes avides de ressources", rien de neuf, et pas de quoi fouetter un chat ...
[^] # Re: La license d'Apache 2
Posté par herodiade . En réponse à la dépêche Sortie de Apache 2.2.0. Évalué à 2.
[^] # Re: La license d'Apache 2
Posté par herodiade . En réponse à la dépêche Sortie de Apache 2.2.0. Évalué à 3.
Oops, j'ai fait un copié/collé dans le correcteur d'orthographe de gmail avant de poster, sans faire attention au "(...)ssage" de templeet, et *paf* le lien !
C'était: http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendm(...)
j'avais vu le départ du dev de Sendmail X, mais je pense qu'on perd alors l'expérience et le caractère éprouvé du code actuel.
Pour le recettage du code, c'est assez vrai. Hum, qui va essuyer les platres des premières releases ?
Mais concernant l'expérience, je ne crois pas qu'Eric Allman vas oublier ses 20+ ans de developpement de MTA, (pièges, évolutions, erreurs de design, sécurisation à posteriori ...) du jour au lendemain ;)
mais licence GPL donc peut-être guerre de religion ?
Non, ils considérent la licence de Sendmail comme une GPL-like (c'est d'ailleur pour ça qu'il est dans l'arbo "gnu/" du dépôt cvs d'OpenBSD), donc pas de différence de ce point de vue pour eux.
[^] # Re: La license d'Apache 2
Posté par herodiade . En réponse à la dépêche Sortie de Apache 2.2.0. Évalué à 5.
D'autre part les choses ont aussi beaucoup évolué pour Sendmail: l'équipe de dev était très réceptive aux patchs proposés par l'équipe d'OpenBSD (à contrario de l'équipe d'Apache), et ils ont fait énormément d'efforts pour sécuriser leur logiciel.
Il est maintenant très rare que de nouvelles failles soient découvertes dans Sendmail: la dernière date d'il y a deux ans (faille patchée par Todd C. Miller, de l'équipe d'OpenBSD justement). Les dernières failles découvertes dans Exim sont beaucoup plus récentes en comparaison (au moins deux en 2005). Encore une preuve que l'audit, ça paie :)
De plus un énorme refactoring est dans les tuyaux pour Sendmail X (dans le sens d'une modularisation etc.), actuellement en version alpha.
Quand à la config, elle est maintenant facilitée par un jeu de macros m4 bien fait et assez complet, si bien qu'on peut maintenant considérer le fichier (très simple) sendmail.mc comme le vrai fichier de conf, et ignorer le sendmail.cf. Voir par ex.
http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendm(...)
Bref, il est temps de réviser l'horrible réputation de Sendmail. Surtout si c'est pour lui opposer Exim.
Quoiqu'il en soit, postfix et Exim sont dans les ports (à la différence d'apache 2.0/2.2) et le remplacement de Sendmail est facilité grâce à un jeu de scripts. cf. mailer.conf(5).
Ah si Wietse Venema et IBM plaçaient Postfix sous licence MIT/X11 ou BSD ...
# Utile pour le WRT54GL ?
Posté par herodiade . En réponse à la dépêche Support des chipsets bcm-43xx. Évalué à 2.
Je ne sait pas si ce modèle (la version 'L' des WRT54G) intègre lui aussi un chipset Broadcom, mais on peut regretter que Linksys (comme Apple, d'ailleur) n'ai pas fait pression sur Broadcom pour qu'ils nous filent des specs... la sortie du WRT54GL, bien que louable en soi, révèle un linksys plutôt opportuniste.
# petition insuffisante, reverse-engeneering virtuose
Posté par herodiade . En réponse à la dépêche Support des chipsets bcm-43xx. Évalué à 10.
La forme de la pétition est -légèrement- contestable: un « driver Linux » n'est pas suffisant, s'il est binaire seulement, ou pas modifiable, ou i386 seulement, ou pas légalement redistribuable, ou pas portable sur les kernels 2.6, ou pas accomapgné de docs pour les corrections de bugs et l'implementation sur les autres OS libres, etc... ; d'ailleur il existe déjà un driver : celui récupéré dans les WRT54G et retro-engeneeré. Sans parler du driver win + ndiswrapper.
Il aurait été préférable que la petition réclame clairement et uniquement des specs complètes (au moins, ça serait profitable aux *BSD aussi, et ça permettrai à la communauté de debugguer le driver), mais le boulot de rétro-ingénierie des pilotes binaires Linux a visiblement atteint cet objectif sans l'aide de Broadcom.
Bravissimo ! et honte à Broadcom !
Maintenant, une question subsidiaire: ces périphériques necessitent-ils le chargement à chaud d'un firmware ? si oui, le firmware est-il librement redistribuable (sinon libre et opensource) ?
[^] # Re: bonne nouvelle mais...
Posté par herodiade . En réponse à la dépêche Les nouvelles puces Wifi Prism54 maintenant supportées sous Linux et FreeBSD. Évalué à 2.
Ouille, désolé, j'ai toujours évité ce chipset du fait du manque de support ...
Effectivement, la conséquence c'est que ça n'aide pas ce support à avancer :( . La poule, l'oeuf, toussa...
[^] # Re: La license d'Apache 2
Posté par herodiade . En réponse à la dépêche Sortie de Apache 2.2.0. Évalué à 10.
- C'est un projet BSD, celà signifie qu'il privilégie les licences les moins contraignantes possible. La licence d'apache 1.3 était très acceptable pour la communauté BSD, mais celle d'apache 2.x impose des contraintes plus strictes (raison aussi de la décision d'abandonner, à peut près à la même époque, XFree86 pour x.org).
- En outre les devs d'Open n'aiment pas les licences longues et compliquées, et préfèrent maintenant les licences à la MIT/X11/ISC (plus facile à comprendre sans ambiguité, surtout pour des non-juristes).
- L'apache inclus dans leur système avant le changement de licence était déjà largement modifié pour sécurisation (révocation des privilège plus stricte, chroot par défaut des processus fils etc.) et convenait suffisament bien au projet et à ses utilisateurs.
- Certainsdeveloppeurs d'OpenBSD attendaient une bonne occasion pour ne plus avoir a suivre l'évolution d'apache (merger les nouvelles versions), pour avoir la latitude de faire de plus grosses modifications dans l'arbre des sources, comme: virer les wrappers ap_* afin de faciliter l'audit et la relecture du code, assainir le traitement des chaines et des signaux etc ... toujours dans l'objectif d'améliorer la sécurité du serveur httpd.
Les résultats concrets sont déjà visibles. Par exemple leur version d'apache n'était pas affectée par la récente faille CAN-2004-0700, ce bug ayant été corrigé bien avant dans l'arbre des sources d'OpenBSD lors d'une série d'audits/renforcements/nettoyages de routine sur le traitement des chaines dans apache (cf. le commit sur ssl_engine_ext.c qui corrige cette faille: revision 1.10, date: 2003/06/01 15:53:41; author: deraadt; "various format string cleanups; tedu ok"). Il y a d'autres exemples de ce type.
Bref, maintenir une fork d'apache 1.3 (sans casser l'API, pour rester compatible avec les modules externes) était la solution la plus pertinente étant donné leurs priorités (préférences pour les logiciels aux licences très permissives, priorité à la sécurité et l' "auditabilité" stricte du codeplutôt qu'aux fonctionnalités amenées par la version 2) de la même façon que de nombreux admins préfèrent apache 1.3 pour sa robustesse éprouvée.
[^] # Re: bonne nouvelle mais...
Posté par herodiade . En réponse à la dépêche Les nouvelles puces Wifi Prism54 maintenant supportées sous Linux et FreeBSD. Évalué à 4.
Donc je tempère ta remarque: le mode hostap sera géré par le drivers libre ralink sous linux mais les devs de ralink/linux ne veulent pas coder un AP logiciel redondant avec celui que préparent les gars du framework 802.11, ce qui est bien compréhensible, c'est un gage de meilleure qualité/maintenabilité, à moyen terme. Ce chipset est d'ailleur pleinement supporté dans tout les modes (y compris master/hostap) dans les *BSD (qui il est vrai ont un framework 802.11 logiciel depuis un moment déjà), donc c'est tout à fait faisable.
Bref, ça reste un chipset très prometeur (et bon marché) sur les unix libres. Pour le mode hostap, il suffit d'attendre un peu, ou d'utiliser OpenBSD. Ou acheter une atheros en attendant (très performant, mais c'est beaucoup plus cher).
Au passage, l'unification du framework wifi sous linux est vraiment une bonne chose: celà évitera les implémentations redondantes (pour quasiment tout les chipsets wifi modernes, qui délègue la gestion du protocole au kernel pour des raisons d'économies), celà permetra d'unifier les extensions WE et les outils de gestion des interfaces (ifconfig, iwconfig, ...) ou d'autres fonctionalités wifi (aircrack, kismet etc.).
Pour le moment il faut reconnaitre que le wifi sous linux, c'est vraiment le bordel (on est loin de l' « unité » du monde fast-ethernet par exemple); et le fait que les constructeurs puissent produire des produits ayant les mêmes références mais des chipsets différents n'arrange rien.
Pour revenir à la dépêche: le boulot sur FreeMac est vraiment vraiment impressionant ! y a-t-il projet de supporter le chipset prismGT aussi (ou est-ce déjà le cas) ?
[^] # Re: Kopete et la webcam : OUI !
Posté par herodiade . En réponse à la dépêche Publication de KDE 3.5. Évalué à 2.
J'utilise (en fait: fait utiliser ;) depuis quelques temps la version cvs de amsn, qui (depuis peu) supporte aussi la webcam sous MSN.
Mais avec amsn il reste un problème bloquant pour les Messenger addicts: seul le texte et maintenant la webcam sont supportés. Pas l'audio.
Est-ce que Kopete nous affranchi de cette limitation ? supporte-t-il le proto de voip de MSN ?
[^] # Re: Ou est le troll ?
Posté par herodiade . En réponse à la dépêche Gtk en natif pour Mac OS X. Évalué à 3.
Ça marche super bien (vraiment !).
Par contre il faut payer des royalties pour les licences, donc c'est plutôt orienté « usage professionel ».
Peut-être que le binding PyQt sur Qt4 changera la donne ? (car le port win32 de Qt4 est maintenant GPL et gratuit lui aussi).
[^] # Re: Support de Xen ?
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 6.0. Évalué à 2.
Exact.
Q1? Est-ce que FreeBSD 6 tourne en hôte virtuel sur Xen ?
Oui.
Q2? Est-ce qu'en terme de sécurité FreeBSD est équivalent à OpenBSD ?
Non.
Mais le niveau de sécurité est tout de même très bon.
# protection: contre-attaque ET engagement de non agression mutuelle
Posté par herodiade . En réponse à la dépêche Création de l'Open Invention Network (OIN). Évalué à 10.
C'est un point interessant. Mais il y a quelque chose de beaucoup plus fascinant (et aussi moins polémique je crois, "la fin justifie-t-elle les moyens ? etc."), c'est que tout les adhérents sont aussi protégés par le simple fait qu'ils se sont engagés à ne pas s'entre-attaquer !
Le texte indique (traduit vite fait):
Et je trouve ça absolument fascinant ! ça ouvre des abymes de questions et d'idées:
- Certains groupes sont fermement opposés aux brevets logiciels et n'acceptent pas l'idée d'utiliser des brevets, même pour contre attaquer.
Par contre je pense qu'ils souscriront volontier à cette idée: j'adhère à OIN et je m'engage a ne pas attaquer les autres adhérents , en contreparti je ne serait pas attaqué par les autres adhérents (dont IBM, Sony etc.). C'est donc une excellente garantie, même pour les simples individus, et on n'est pas forcé d'utliser OIN pour contre-attaquer (donc on peut rester intègre sur sa position).
- Pour de nombreuses compagnies, adhérer a OIN peut être un bon moyen de se protéger contre ces énormes boites (IBM dispose de milliers de brevets) à moindre cout (négocier avec IBM, à l'amiable ou devant un tribunal, même si on a des brevets a leur opposer où si on est dans son droit, c'est couteux et long).
- Du coup, OIN pourrait croitre exponentiellement: chaque nouvelle société qui y adhère apporte son lot de brevet, rendant ainsi OIN plus fort et dangereux pour les autres boites utilisant les brevets, qui seraient alors encouragées à adhérer. Je fantasme ? peut-être, mais ce serait superbe non ? et ce n'est pas impensable !
exemple: si je me fait attaquer par Sony, IBM ou Phillips, je crois que je serait très tenté de régler ça en 5mn en adhérant à OIN ! ou bien encore: si j'ai envi d'utiliser gratuitement une techno (linux related) de Sony ou IBM, je commencerai par adhérer à OIN pour ne pas être attaquable.
- Linux pourrai devenir très vite, grace à OIN, un système inattaquable tellement le nombre de brevets le protégeant seront nombreux.
- Le status quo (non attaque entre les grosses compagnies) est déjà plus ou moins effectif dans le monde du brevet logiciel. Mais ce qui pèse toujours lourd, ce n'est pas tant d'être attaqué que d'être attaquable.
Les compagnies attaquables perdent la confiance des investisseurs, les particuliers et sociétés s'empechent d'utiliser des technos brevetés à cause des incertitudes (cf. par ex. la lecture mp3, souvent exclus des distros bien que Frauhnofer ai indiqué qu'ils n'attaqueraient que les encodeurs).
Les brevets excercent déjà leur nocivité à plein régime par le simple FUD (fear uncertainty and doubt).
- Sera-t-il possible pour de simples individus adhérants d'utiliser OIN pour menacer des sociétés detenant des brevets, et les forcer à adhérer à leur tours ? (non plus contre-attaquer, mais prendre les devants !).
Je verai bien un tir groupé et massif sur Fraunhofer, divx, Apple, Secure Computing etc.
- Ce qui est couvert par l'alliance, "Linux operating system or certain Linux-related applications" est un concept à géométrie variable ... comment définisse-t-ils ceci ? Par ex. est-ce que l'ensemble de Debian GNU/Linux est compris dans cette définition ?
- Nokia s'est déjà engagé à ne pas attaquer les developpeurs et utilisateurs du noyau Linux. Pourquoi n'adhèrent-ils pas ? Et Sun ?
- La non décision du parlement Européen concernant la brevetabilité logicielle ne rend elle pas caduque cette initiative en Europe ? Un particulier n'aura alors pas les moyen de se défendre (en faisant valoir l'illégalité du brevet) ni de contre-attaquer (puisque ces brevets n'ont pas de valeur).
[^] # Re: portabilité
Posté par herodiade . En réponse au journal .Net vs Qt vs Java. Évalué à 2.
Parce que sinon: Qtdesigner est vraiment très bien pour faire ses interfaces à la souris. Et ensuite, effectivement, n'importe quel éditeur convient pour écrire le code C/C++ en dessous.
[^] # Re: portabilité
Posté par herodiade . En réponse au journal .Net vs Qt vs Java. Évalué à 2.
sous Linux & *BSD au moins, je ne dev pas sous d'autres plateformes on trouve notament kdevelop , assorti de tout le bazard pour les besoins précis (assistant pour l'aide/la doc, designer pour la gui, linguist pour l'internationalisation ...), ou XCode sous mac.
[^] # Re: Protocole CARP
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 6.0. Évalué à 7.
Oui exact.
Mais tu peut avoir deux (ou plus) IP flottantes gérées de la sorte par CARP et faire ainsi de la répartition de charge en proffitant de la puissance des deux (ou plus) machines: chaque machine utilise une des IP, on peut répartir le traffic par rr dns ou autre (et lorsque l'une des machines est en panne, l'autre récupère son traffic).
Bref, dans l'esprit de simplicité et minimalisme BSD, CARP a été conçu pour ne gérer que le failover/redondance, mais tout de même pour ne pas empécher la répartition de charge.
Dans la boite à outils complémentaires il y a aussi pfsync, qui permet de synchroniser les tables d'états et rulesets des firewalls entre les diverses machines et sasyncd pour synchroniser les SA IPsec (je ne crois pas que ce denier soit déjà porté d'OpenBSD 3.8 à FeeBSD 6). Le tout permettant de faire, par ex lorsque couplé à CARP, des firewalls et passerelles VPN redondants avec reprise de traffic automatique et sans interuption.
# portabilité
Posté par herodiade . En réponse au journal .Net vs Qt vs Java. Évalué à 4.
À ma connaisance mono (donc C#) n'est pas encore porté sur la plupart des systèmes *BSD (et en particulier sur les architecture non i386) ; Idem pour java (surtout si tu a besoin d'un jdk1.5, qui par ex n'est pas porté sur Mac OS X, mais gcj n'est pas encore très portable non plus). Par ailleur la large audience que tu semble vouloir toucher sera certainement heureuse de n'avoir pas à installer des interpréteurs pour faire tourner l'appli, surtout les non informaticiens.
La légereté (économie de mémoire) est aussi un bon argument en faveur de qt par rapport à java/mono.
Dans tout les cas (heu, en fait pour java et qt au moins) il y a des bindings opengl à disposition et ont toutes les widgets nécéssaires pour faire des "interfaces bien léchées", donc semblent remplir les (trop peu détaillées) contraintes techniques que tu indique.
# améliorations des performances
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 6.0. Évalué à 10.
Il semblerait que l'énorme travail effectué sur l'écriture et l'intégration du nouveau scheduler, l'elimination de giant lock etc. mis en place avec la branche 5 commence à peine à porter ses fruits avec la branche 6 qui vient d'arriver.
C'était un travail de longue haleine, mais c'est agréable de constater que les choix faits des années plus tôt étaient réalistes et pertinents !
Un autre changement sympa: le proto carp est maintenant supporté.
[^] # Re: pilotes ipw2x00
Posté par herodiade . En réponse à la dépêche Sortie du noyau 2.6.14. É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 herodiade . En réponse à la dépêche Sortie du noyau 2.6.14. É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 . En réponse à la dépêche Sortie du noyau 2.6.14. É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 herodiade . En réponse à la dépêche Sortie du noyau 2.6.14. É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 herodiade . En réponse à la dépêche Sortie du noyau 2.6.14. É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 herodiade . En réponse à la dépêche Sortie du noyau 2.6.14. É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 ...