Tu as toujours l'OIN qui protège Mono. Je vois pas ce qu'il te faut de plus.
Super, et lorsque MS se fait menaçant, il ne te reste plus qu'a réassigner tes copyrights à SuSE. Ça donne vachement envie de coder avec mono !
Ah, on peut dire qu'ils ont bien arrangé leur prise de contrôle SuSE, d'abord faire croire à tout le monde qu'ils ne courent aucun risque parce que eux ne courent aucun risque, et lancer Miguel de Icaza dans de lourdes manoeuvres de marketing et de lobbying pour l'intégrer dans GNOME.
Le jour ou un élément fondamental de GNOME dépendra de mono, GNOME appartiendra, virtuellement, à SuSE.
Comme OpenSSH, le serveur de routage BGP OpenBGPD est maintenu par OpenBSD et releasé ponctuellement sous la forme "portable" (emballé pour être plus pratique à compiler sur d'autres systèmes). : http://www.openbgpd.org/
Certains développeurs d'OpenBSD travaillent en effet activement au développement de toute une batterie de serveurs de routage : on a déjà, au menu, un serveur BGP (celui dont je parle), un serveur OSPF (OpenOSPFD), un serveur dvmrp/IGMP (dvmrpd), et tout récemment un serveur RIP (ripd, qui devrai remplacer avantageusement le vieux routed).
Quant à l'annonce de la release d'OpenBSD, dommage qu'elle passe sous silence les énormes progrès d'ipsecctl(8), un outil à la configuration super simple et ergonomique qui paramètre la pile IPsec du noyau et le serveur de clef ISAKMPD (lequel a une conf à la syntaxe plus tortueuse, mais qu'on a plus besoin d'écrire soi-même, grâce à ipsecctl).
J'ai la flemme de rechercher les liens sur les mails de l'époque (mais tu trouvera un apperçu sur http://opencvs.org/ ), mais en gros : parce qu'ils ont besoin de cvs (et rcs) pour leurs dépôts, et qu'ils se sont aperçus que le code était très moche et pas forcément facile à maintenir et sécuriser.
Ce qui se devine facilement :
s2t0c$ find /usr/src/gnu/usr.bin/cvs/ -type f -name '*.c' | xargs wc -l | tail -1
102145 total
( plus 11 000 lignes de headers, 24 000 lignes de shell script etc.).
À cette époque (et même depuis lors), GNU CVS a mangé quelques râteaux, en matière de sécu.
OpenBGPD 4.0 qui pour ceux qui ne connaissent pas est un protocole de routage utilisé dans de gros réseaux.
Bon pour clarifier : OpenBGPD est un serveur BGP, et BGP est un protocole de routage. Les devs d'OpenBSD maintiennent une version dite « portable », qui marche aussi sur les autres unices.
Ils ont aussi un OpenOSFPD et un dvmrpd mais je ne sait pas si l'équipe d'OpenBSD à déjà sorit la version "portable" (et un ripd est en bonne voie pour 4.1).
Sinon, voilà quelques nouveautés intéressantes que j'ai relevé en lisant les logs des commits de ces 6 derniers mois (c'est à dire depuis 3.9):
- pf: "urpf sanity checks", un antispoofing simple et efficace : vérifie si le paquet est reçu sur l'interface par laquelle passe la route vers l'IP source indiquée dans le paquet. Utile si routage symétrique.
- possibilité d'utiliser des listes dans des listes dans pf (eg. pass from { a, b, { c, d } e f })
- pf: support des lites "tagged {}"
- passage à python 2.4 par défaut (dans les ports)
- OpenRCS remplace désormais gnu rcs dans base.tgz
- add the net80211 hostap options "nwflag hidenwid" for hidden SSID mode and "nwflag nobridge" to prevent inter-station communications.
- dvmrpd (pour le routage. serveur dvmrp, igmp, ...)
- ipsecctl: support des protos encapsules
- ipsecctl: support d'ike en mode transport
- ipsecctl: add support for "local" to ike rules. Allows to specify the local IP to be used on a multi-homed machine
- ipsecctl: support des macros à la pf (yo !)
- ipsecctl: appelle par rc/rc.conf (donc meilleur intégration)
- ipsecctl: on peut spécifier le type de flow (require, bypass, use ...)
- ipsecctl: résout les nom d'hôtes
- ipsecctl: monitor mode (suivre les négociations de SA en temps réel)
- ipsecctl: support ipv6
- ipsecctl: support des nom de groupes d'interfaces, comme pf. Par ex. : ike esp from egress to 10.1.2.0/24 peer mygate.home.net
- ipsecctl: support des listes, façon pf. eg: ike from em0 to { 192.168.7.0/24, 192.168.9.0/24 } peer 1.2.3.4
- ipsecctl: Support flows with port modifiers for proto tcp/udp, e.g. flow proto udp from 1.2.3.4 port ntp to 5.6.7.8
- ipsecctl: possib de ne pas préciser le "peer", la règle fonctionne alors en catch-all (matche pour tout peer qui se présente)
- ipsecctl: on peut préciser les lifetimes de phase 1 et 2. par ex: ike from 1.1.1.1 to 2.2.2.2 main life 3600 quick life 1200
- ipsecctl: possibilité de désactiver la pfs (groupe "none")
- isakmpd: permettre la sélection de clef RSA selon l'ID isakmp
- améliorations de m4 (plus d'extensions gnu, tant pis pour posix)
- support multiples tables de routages
- support de l'algo de crypto michael mic (en vu du support tkip/wpa !)
- encore plein d'améliorations dans lint
- correction de pleins de bugs trouves par coverty et lint
- ld.so prebind (un prelink securisé, avec randomisation)
- port java de sun plus facile à installer (via kaffe)
- gcc 4.1 dans les ports, et même gcc-4.2.20060715
- OpenOffice.org est enfin porté (2.0.3) !
- ameliorations de la gestion des DAT (chargeurs multiples, barcodes ...)
- support gravure cds et dvds dans cdio(1)
- support des horloges hardwares udcf dans ntpd
- port sur l'architecture AViiON (mvme88k)
- port UltraSparc III
- port armish (vers plein de boards arm, xscale cpu etc)
- refactoring du code du driver ami(4), qui devient notamment monitorable via le framework des sensors
- acpitz: minimal thermal zone driver. Monitors thermal zone temperature, shuts down the system if the 'critical temperature' is reached.
- driver onewire(4) - Dallas 1-wire bus (et aussi gpiow(4) etc.)
- driver wpi(4) - blob-free driver for Intel PRO/Wireless 3945ABG
- driver rum(4) - chipsets wifi Ralink RT2561, RT2561S et RT2661
- driver zyd(4) - Zydas ZD1211, chipset wifi
- driver mfi(4) - cartes LSI MegaRAID SAS
- driver azalia(4) - periph audio intel
- driver udcf(4) - Gude ADS Expert mouseCLOCK DCF77/HBG time signal recv
- driver nmea(4) - time delta sensors
- driver bnx(4) - cartes reseau broadcom NetXtreme II Gigabit
- driver acx(4) - pour les cartes wifi avec chipset Texas Instrument
- driver msk(4) - Marvell Yukon-2 based Gigabit Ethernet adapters
- driver uark(4) - Arkmicro Technologies ARK3116 USB UART serial adaptater
- driver ucycom(4) - USB support for Cypress microcontroller serial adapters
- driver arc(4) - Areca Technology Corporation RAID Controller
- driver pgt(4) - PrismGT chipset (FullMAC for now)
- drivers pour divers nouveaux sensors i2c
- ajout de warnings dans gcc : "-Wstack-larger-than-N", to report functions which are too greedy in stack variables (sera utilisé par défaut pour compiler le kernel)
Oui certes, mais on peut aussi choisir une nVidia et utiliser le driver libre "nv" non accéléré en attendant que le support de la 3D soit plus complet : visiblement, le projet Nouveau est tout prêt du but ! :
http://www.freesoftwaremagazine.com/node/1797 dit :
The nouveau project is now working on implementing a memory manager for NVIDIA
cards which would make both their revamped nv driver (added EXA support) and
their new 3D driver (DRI, DRM, GLX and GLSL being worked on) almost working on
the whole NVIDIA cards range (from NV04 to G70).
J'aurai donc tendance à dire : il faut d'abord encourager ceux qui jouent le jeu (en l'occurrence Intel) en achetant leur matériel. Mais lorsque ce n'est pas possible (par ex. dans le cas d'Intel, je n'ai pas trouvé de carte « standalone », en AGP ou PCI-E), on peut choisir une ATI ou nVidia qui de façon égale, ne jouent pas le jeu, et utiliser leur driver libre avec ou sans accélération en attendant qu'il progresse (ça va très vite). Bien entendu, les drivers proprios sont à proscrire (non éthiques, instables, mal maintenus, mal intégrés dans les distros et chiants lors des upgrades de la distro ou même du noyau, ...).
En complément, je disait plus haut qu'il est difficile de trouver une carte ATI supportée par le driver libre et suffisamment récente pour être fournie en PCI-E (ce qui peut être une contrainte lourde). Un autre détail, j'ai lu que AIGXL ne fonctionne pas correctement, pour le moment, avec une distro en 64 bits (source : http://fedoraproject.org/wiki/RenderingProject/aiglx , à confirmer) !!
Donc faire le choix d'une nVidia ou d'une ATI récente pas encore bien accélérée et d'attendre un petit peu n'est pas forcément sot, non ?
J'ai quelques questions supplémentaires sur cette carte (enfin, ce chipset) :
- Est-ce que le driver libre est stable ? ça plante parfois ?
- Est-ce que le pilote libre fournit une accélération 3D suffisante pour les petits jeux libres (type tuxracer par ex.) ou pas d'accélération du tout ?
- Est-il possible d'utiliser la sortie TV avec des outils/pilotes libres uniquement ?
- Tu dit que tu l'a choisie dans l'espoir d'avoir AIGLX un jour. As-tu l'impression que les pilotes libres sont encore loin du compte ou qu'ils avancent vite, sur ce point ?
- Le pilote est-il inclus dans les versions récentes (par ex. 7.1) de x.org ou distribué séparément ? nécessite-t-il un module noyau tiers ?
- Le pilote est-il inclus en standard dans les distributions récentes (etch, edgy, fc6, par ex.) ou faut-il l'installer en ajoutant des dépôts externes ?
Merci d'avance !
P.S. : au sujet du journal, il y a un critère supplémentaire qui complique encore le choix, c'est le fait que les carte mères récentes supportent de moins en moins l'AGP mais que les pilotes libres semblent supporter des cartes graphiques anciennes plus souvent disponibles en AGP qu'en PCI-X. Voir des cartes carrément abandonnées : impossible de trouver une 9100 (rv200) sur le site de rue-montgallet. :(
Pour la lutte contre l'anglocentrisme, je te recommande de signaler ton avis (c'est ce que je vient de faire en commentaire sur l'une des propals) : ils n'ont pas l'air de s'en rendre compte en fait. Les annonces de J. Walles ont été diffusées sur des sites et mailing-lists anglophones essentiellement. Il faut leur rappeler sans arret.
Concernant les livres scolaires, il est précisé qu'il faut libérer du contenu existant (donc pas payer des gens pour écrire du neuf).
Mais il y a une proposition qui me semble super intéressante à ce sujet : racheter des livres scolaires out-of-print, c'est-à-dire au tirage épuisé (mais pas trop vieux si possible). L'idée c'est que de tels livres seront surement très bon marché, ce qui permetrai d'en acheter plusieur par matière/langue : par exemple un manuel de géographie français, un quebecois, un suisse, un belge etc. : ainsi on pourrai les « merger » pour limiter le biais culturel (ce qui est plus dûr avec un seul livre neuf).
La mise à jour des livres épuisés (par exemple datant du dernier changement dans le programme scolaire de la matière) ne devrait pas être trop dur pour nous, surtout si on a des livres correspondants aux programmes scolaires de plusieurs pays différents pour une langue donnée.
L'autre bon coté des livres scolaires c'est qu'au delà de wikibooks, on devrait pouvoir s'en servir pour étayer aussi les articles de wikipédia. Comme dit dans la proposition que je cite : ça permettrai d'être sûr que wikipédia ai une couverture décente de tout les sujets encyclopédiques et scolaires de base (car pour le moment on a des articles de qualité sur des sujets hyper pointus, et des articles misérables sur des sujet essentiels).
Oui mais l'annonce est très claire sur ce point : l'offre propose spécifiquement d'acheter et libérer du contenu déjà existant et copyrighté mais propriétaire !
Elle précise aussi que le but est de libérer des choses qu'il serait impossible ou extrèmement dur d'obtenir ou de faire nous même (donc pas, par exemple, l'écriture d'articles sur des sujets où les sources sont dispos).
Jimbo Walles a donc fait remarquer que les propositions de ce type (très fréquentes) sont irrecevables pour cette offre précise :
- faire du lobbying (ce n'est pas acheter des données existantes)
- payer des devs (idem)
- subventionner un/des projet(s) libres (idem)
Dans les propals que j'ai lu, j'ai tilté sur une qui rappelle aux autres qu'il ne faut pas oublier les non-anglophones si possible. Car on voit essentiellement des propositions avec des implicites du type « the world is America ». Par exemple les propositions de scanner la « library of congress » ou celle du MIT, de libérer des archives d'un « newspaper » (explicite ou sous-entendu : un journal américain, en langue anglaise et avec un regard américain sur le monde). Idem pour les propals du genre : libérer des archives vidéos (l'exemple qui leur vient tout de suite en tête, c'est la BBC).
Du coup il me semble qu'il serait plus profitable pour le « reste du monde » qu'ils libèrent des fichiers moins culturellements/linguistiquements marqués.
En particulier des photos (par exemple des archives de Reuters, AP, AFP etc.), car c'est maintenant impossible de produire nous même des photos de personnes décédées ou d'évenements passés (et que wikipédia manque singulièrement d'images, et c'est très dommageable pour les articles sur les personnages du 20em siècle, sur le cinéma, la musique, etc. : wikipédia est alors sous-évaluée par rapport a des sites ou autre encyclopédies, libres, etc. au contenu textuel moins riches mais qui ne sont pas très regardants sur la liberté des images). Les cartographies sont aussi un bon exemple (mais le problème c'est leur durée de vie / vitesse de péremption de la justesse de leur contenu).
Pour préciser un point par rapport à la dépêche : le filtrage des réponses (ce que le serveur web retourne) n'est possible qu'avec Apache 2.x (pas Apache 1.3.x), malheureusement (à cause d'une limitation des fonctionalités d'Apache 1.3, pas d'une décision arbitaire des devs de mod_security).
Et même avec Apache 2.x, certaines de ces directives sur le filtrage des réponses / flux sortants n'est possible que sous condition (par exemple le filtrage sur OUTPUT - le contenu complet de la réponse - n'est possible que si l'output buffering n'est pas activé).
mod_security est vraiment un bijou ; il est très efficace pour protéger les services web (ou simplement pour alerter en cas de comportements déviants), et sa syntaxe, vraiment agréable et souple, permet de faire beaucoup de choses.
J'en profite pour signaler un bon compagnon pour mod_security, à savoir mod_evasive (http://www.zdziarski.com/projects/mod_evasive/ ). Ce module permet de restreindre le nombre d'accès par seconde (globale/pour tous, et pour une IP/client donné) sur un objet apache (un repertoire, un cgi, un script php, ...). C'est une protection utile pour se prémunir des attaques par dictionnaire (en protégeant les pages d'authentification, par exemple) ou les DoS involontaires (en restreignant le nombre d'accès sur les scripts dont l'execution est lourde et lente).
Dans un autre registre, mais aussi très utile pour protéger les serveurs webs utilisant PHP, on peut citer le patch Hardened-PHP (http://www.hardened-php.net/ ).
Une précision, Chad Loder (« Manager of Engineering » de Rapid7 ) est un développeur OpenBSD, d'où la formulation très militante de cet advisory.
OpenBSD fait justement parti de ceux qui réclament les specs de tout matériel, sans NDA, depuis longtemps. J'espère que les devs Debian pas contents (de la dépêche d'à coté) saisiront l'occasion pour leur filer un coup de main.
LGPL, MIT et BSD imposent elles aussi leurs restrictions.
Restrictions minimes, au moins pour les deux dernières : du moins elles n'empêchent pas un logiciel qui veut réutiliser un bout de code, ou se linker sur une lib en mit/lgpl/bsd d'utiliser la licence de son choix, y compris la GPL.
autant mettre son logiciel dans le domaine public et fournir les sources.
Oui, « public domain » serait idéal.
Mais dans certains pays (dont la France, je crois) ça n'est pas un statut juridique suffisant pour fonctionner comme une licence.
Et ça ne permet pas de dire : « je ne suis pas responsable de ce que vous faites avec ce que je vous donne » (ce qui est autre chose qu'une restriction).
L'esprit de la double licence c'est de ne pas faire de "cadeau" gratuit au proprio alors qu'on peut leur tirer du lait.
Tout en emmerdant ceux qui ne pensent pas 100% comme toi mais veulent faire du libre.
Par exemple la licence (libre) CDDL, très typée GPL dans le sens où elle est contaminante, estime qu'il faut en plus abandonner l'exploitation de ses brevets logiciels si on veut ré-utiliser le logiciels (ce que prévoit la GPLv3 à priori). Mais cela constitue une restriction supplémentaire par rapport à la GPL (v1 et v2), et rend donc ces deux licences incompatibles.
La GPL ne tolère pas l'imposition de restrictions supplémentaires (fut-ce pour forcer des libertés : restrictions contre les DRM, etc.). Mais on ne peut pas réduire les restrictions imposées sur du code GPL (contamination, copyright, etc.). Par conséquent, la GPL impose un vision très précise du libre, et se refuse toute compatibilité avec les visions/besoins légèrement divergent (en plus ou en moins restrictif). Je trouve ça un peu sectaire.
Si en plus on me dit (enfin, Pierre Tramo le dit) qu'ils font ça par rapport au logiciel propriétaire, je pense : mince, quel dommage, se laisser dicter sa conduite, et imposer des contraintes aux autres utilisateurs du libres à cause du propriétaire !
Vive la compatibilité élargie, vive le respect des autres approches du libre (jugées aussi libres par la FSF et l'OSI), vive les LGPL, BSD et MIT !
C'est aussi l'idée toute simple : « vous pouvez faire du libre, et vous n'étes pas obligé de le faire comme nous ».
Il faut cesser de croire que les personnes utilisant les licences MIT, BSD ou même LGPL le font spécialement « pour permettre au proprio » de les utiliser. Dans bien des cas, ils utilisent ces licences avant tout parce qu'ils veulent laisser aux autres - y compris aux inconditionels de la GPL - le plus de choix possible dans leur façon d'être libre.
C'est le choix de la compatibilité avec les autres licences libres (à contrario du « tous comme nous » de la GPL).
Celà dit, ça va être dur de supplanter OpenSSH. Non seulement sur le plan fonctionnel, mais surtout en ce qui concerne la confiance des utilisateurs et des distros qui l'intègrent.
En effet, en suivant le cvs, on remarque vite qu'OpenSSH est régulièrement audité par des spécialistes renommés. Je me rappele avoir vu passer quelques corrections de bugs identifiées par Solaar designer ou Ulrich Drepper, par ex. Ou, pour s'en tenir à ces derniers mois, des corrections venant d'audits par l'outil d'analyse statique « coverty » de standford, par l'outil « Saturne » et par la Google Security Team.
Mais le gros de ce travail de (ré)audit permanent et d'amélioration continue de la sécurité tient à l'intégration d'OpenSSH dans un projet beaucoup plus large, OpenBSD. De là, de nombreux developpeurs d'OpenBSD participent régulièrement au ré-audit d'OpenSSH, avec en particulier des recherches ou améliorations « à thèmes » : séparation des privilèges (c'était il y a un moment déjà, mais plus récement: ), utilisation systématique de fonctions d'allocations renforcées ad hoc pour prévenir divers types de débordements, recherche systématique des int overflow, ré-audit systématique de la gestion des signaux, ré-audit systématique des paths d'erreurs, ...
Autrement dit, à mon sens, le succès d'OpenSSH vient aussi du fait que sa sécurité n'est pas seulement améliorée par ses développeurs (au sens strict), pas si nombreux, mais par une équipe beaucoup plus large de développeurs experts en sécurité, l'équipe d'OpenBSD (même les développeurs du noyau ou de la libc d'Open participent régulièrement à l'amélioration de la sécurité d'OpenSSH).
Je ne crois pas que ce soit une bonne idée de reprendre Theo sur ce point, de surenchérir, de mettre Debian et OpenBSD en opposition.
D'une part, parce qu'il s'agit d'une invitation à réagir destinée à la collectivité au sens large, que cela concerne les utilisateurs de GNU/Linux autant que ceux d'OpenBSD, et que les utilisateurs de Debian se sentent probablement tout autant concernés, et sont plutôt les bienvenus pour se faire entendre auprès d'Intel. D'ailleurs, si bizarre que cela puisse paraître, si Debian accepte (provisoirement) ces firmwares illégaux, c'est justement parce qu'elle veut être plus radicale encore qu'OpenBSD, en refusant carrément les firmwares librement distribuables mais non libres & opensources (ce qui est une tache énorme, donc débattue et régulièrement repoussée, c'est pourquoi, pour le moment, rien n'est fait et on a donc paradoxalement quelques firmwares "illégaux" qui traînent encore).
Second point, il y a une incompréhension endémique entre ces deux mondes de développeurs. L'objectif des deux communautés est le même (pouvoir fonctionner sur le matériel actuel en gardant un système le plus libre possible), les stratégies et enjeux diffèrent légèrement.
Sur ce point de divergence, il faut rappeler que que « développeur » ne signifie pas la même chose dans « développeur Debian » et « développeur OpenBSD ». Le développeur Debian travaille plutôt à l'intégration, au packaging, à la correction/remontée de bugs et à la redistribution & upgrade de logiciels tier, le plus souvent développés par d'autres (ce qui les rend plus sensibles aux questions de procédure et redistributions, compatibilité de licences, d'où l'objectif du "tout, même les firmwares, libre et avec les sources" pour le moment bloquant mais plus radical que "tout libre, mais les firmwares peuvent être seulement redistribuables"). Tandis que la fonction principale d'un développeur OpenBSD est d'écrire du code, ce qui le rend plus sensible aux questions de documentation du matériel, aux NDA - qu'ils refusent radicalement - mais moins sensibles au besoin d'avoir les sources pour les firmwares : ils n'auraient pas le temps ni les outils ni les compétences pour modifier le code des firmwares, fussent-ils libres (et ils ont besoin de réagir tout de suite, quitte à être moins exigeants / plus pragmatique, contrairement à Debian qui peut se permettre d'attendre de trouver un consensus sur des exigences plus "idéaliste", car les firmwares sont déja là dans Linux et avec eux le support du matériel dans un kernel développé par d'autres).
De plus, comme dit plus haut, « The firmware problem is a Linux [kernel] problem, not a Debian problem » (car c'est en amont les devs. kernel qui incluent souvent ces firmwares dans le kernel vanilla, tandis que sous OpenBSD, les développeurs noyau sont les mêmes personnes que ceux qui font l'OS => problématique différente).
Signalons aussi que les dictionnaires orthographiques d'OpenOffice sont réutilisés par les logiciels Thunderbird et Vim (depuis la version 7.0, qui inclus un correcteur d'orthographe, cf. :help spell et :help spelllang).
Ces dictionnaires seront aussi utilisés par Firefox 2.0 (sortie prochaine), qui (sauf contre ordre) inclura un correcteur d'orthographe pour les formulaires basé sur les dicos d'OOo. Pour le plus grand bien de Wikipédia, de linuxfr et des multiples blogs à mon avis ;)
Un petit point à signaler à ce sujet. Les dictionnaires français d'OOo sont dérivés d'autres dictionnaires qui étaient sous licence GPL, ce qui explique la licence inhabituelle pour un projet issu d'OOo.
Ça explique aussi pourquoi on est obligé de télécharger et installer ces dictionnaires séparément du logiciel (aussi bien pour OOo que pour Thunderbird, et probablement idem pour Firefox 2) : ces logiciels sont publiés sous des licences plus souple, et ne veulent pas être « contaminés » par l'inclusion d'un dictionnaire français en GPL. Pour une fois, je regrette un peu le choix de la licence GPL (plutôt que LGPL, BSD ou MIT), car l'effet escompté de la GPL par rapport aux autres licences citées (la contamination / l'encouragement à passer le reste sous GPL) n'a pas été atteint dans ce cas, et parce que cette opération d'installation n'est pas forcément triviale, ni même, parfois, connue par les débutants.
À l'heure où les spammeurs cherchent à faire monter leur score, justement sur google, en bombardant les commentaires des blogs, des wikis etc., cet outil, s'il est efficace, pourrai sonner le glas des mauvais CAPTCHA.
Éspérons qu'il y ai des progrès sur les implems libres de CAPTCHA, parce que Sam Hocevar a déjà frappé fort : http://sam.zoy.org/pwntcha/
Avant de tirer des conclusions hâtives donc, il est utile de se renseigner
Plaît-il ?
Avant de donner des leçons de morales, faudrait peut-être voir à ne pas prendre tes interlocteurs pour des sous informés débiles. Merci.
D'une part j'ai bien entendu lu les threads sur les mailings-lists à ce sujet, dont les deux liens que tu cite, d'autre part j'ai aussi lu (et ça tu ne les cites pas dans ta selection de messages) des messages expliquant que l'absence de sources pour ces fichiers ne poserait pas de vrais problèmes légaux:
1) parce qu'on peut éventuellement filer des sources assembleur si qqun insiste à coup de procès (en décompilant le fw binaire)
2) parce que toutes les distros qui ont des juristes pour étudier ces questions ont jugé que ce ça ne pose pas de gros problème
3) parce que si on va par là, il y a un paquet d'autres fichiers, inclus dans des softs libres, dont debian ne peut pas filer les sources : scripts './configure' dont le config.in est perdu, images diverses, certaines fonts, ... . Tant qu'à enculer les mouches au lieu de se battre aux cotés de ceux qui écrirvent les drivers pour régler les vrais problèmes de liberté (obtenir les specs du matos sans NDA, par ex.), allez-y jusqu'au bout.
Quoiqu'il en soit, mon commentaire ne visait pas à critiquer le fait que Debian ne soit pas parvenu à retirer ces fw jusqu'à présent, au contraire (car oui, je sait que c'est dur, long, etc. et je l'ai dit plus haut), mais à critiquer ceux qui jettent des GR inaplicables (parce que justement, c'est dur) sur ce sujet, et qui ne font pas (ou ne peuvent pas finir) le boulot de toutes façons (parce que oui, c'est dur).
C'est très bien de faire la morale et de lancer les GR, maintenant, si ceux qui savent si bien monter sur leurs grands cheveaux quant à la question de la liberté des fw s'étaient sortis les doigts du cul pour virer ces fw, adapter l'installeur, etc. ils n'en seraient peut-être pas là. En l'occurence, ça ressemble fort à un : « nous on aime seulement donner des leçons et troller sur les ML, alors on va vous forcer, vous les developpeurs kernels, à faire le boulot que vous ne jugez pas prioritaire/utile ou que vous n'avez pas envi de faire ».
[^] # Re: Seth Nickell avait raison !
Posté par herodiade . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 7.
Super, et lorsque MS se fait menaçant, il ne te reste plus qu'a réassigner tes copyrights à SuSE. Ça donne vachement envie de coder avec mono !
Ah, on peut dire qu'ils ont bien arrangé leur prise de contrôle SuSE, d'abord faire croire à tout le monde qu'ils ne courent aucun risque parce que eux ne courent aucun risque, et lancer Miguel de Icaza dans de lourdes manoeuvres de marketing et de lobbying pour l'intégrer dans GNOME.
Le jour ou un élément fondamental de GNOME dépendra de mono, GNOME appartiendra, virtuellement, à SuSE.
P.S. : À part ça, l'avis de Bruce Perens : http://technocrat.net/d/2006/11/2/9945
# Et aussi, sortie de OpenBGPD 4.0
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 4.0. Évalué à 5.
Et bien ce bougre d'OpenBGPD est sorti le même jour, avec tout un tas de nouvelles fonctionnalités qui sont indiquées ici :
http://undeadly.org/cgi?action=article&sid=2006110115435(...) .
Certains développeurs d'OpenBSD travaillent en effet activement au développement de toute une batterie de serveurs de routage : on a déjà, au menu, un serveur BGP (celui dont je parle), un serveur OSPF (OpenOSPFD), un serveur dvmrp/IGMP (dvmrpd), et tout récemment un serveur RIP (ripd, qui devrai remplacer avantageusement le vieux routed).
Quant à l'annonce de la release d'OpenBSD, dommage qu'elle passe sous silence les énormes progrès d'ipsecctl(8), un outil à la configuration super simple et ergonomique qui paramètre la pile IPsec du noyau et le serveur de clef ISAKMPD (lequel a une conf à la syntaxe plus tortueuse, mais qu'on a plus besoin d'écrire soi-même, grâce à ipsecctl).
[^] # Re: GNU RCS -> OpenRCS: pourquoi ?
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 4.0. Évalué à 3.
Ce qui se devine facilement :
s2t0c$ find /usr/src/gnu/usr.bin/cvs/ -type f -name '*.c' | xargs wc -l | tail -1
102145 total
( plus 11 000 lignes de headers, 24 000 lignes de shell script etc.).
À cette époque (et même depuis lors), GNU CVS a mangé quelques râteaux, en matière de sécu.
# Nouveautés !
Posté par herodiade . En réponse au journal OpenBSD 4.0 is out !. Évalué à 6.
Bon pour clarifier : OpenBGPD est un serveur BGP, et BGP est un protocole de routage. Les devs d'OpenBSD maintiennent une version dite « portable », qui marche aussi sur les autres unices.
Ils ont aussi un OpenOSFPD et un dvmrpd mais je ne sait pas si l'équipe d'OpenBSD à déjà sorit la version "portable" (et un ripd est en bonne voie pour 4.1).
Sinon, voilà quelques nouveautés intéressantes que j'ai relevé en lisant les logs des commits de ces 6 derniers mois (c'est à dire depuis 3.9):
- pf: "urpf sanity checks", un antispoofing simple et efficace : vérifie si le paquet est reçu sur l'interface par laquelle passe la route vers l'IP source indiquée dans le paquet. Utile si routage symétrique.
- possibilité d'utiliser des listes dans des listes dans pf (eg. pass from { a, b, { c, d } e f })
- pf: support des lites "tagged {}"
- passage à python 2.4 par défaut (dans les ports)
- OpenRCS remplace désormais gnu rcs dans base.tgz
- add the net80211 hostap options "nwflag hidenwid" for hidden SSID mode and "nwflag nobridge" to prevent inter-station communications.
- dvmrpd (pour le routage. serveur dvmrp, igmp, ...)
- ipsecctl: support des protos encapsules
- ipsecctl: support d'ike en mode transport
- ipsecctl: add support for "local" to ike rules. Allows to specify the local IP to be used on a multi-homed machine
- ipsecctl: support des macros à la pf (yo !)
- ipsecctl: appelle par rc/rc.conf (donc meilleur intégration)
- ipsecctl: on peut spécifier le type de flow (require, bypass, use ...)
- ipsecctl: résout les nom d'hôtes
- ipsecctl: monitor mode (suivre les négociations de SA en temps réel)
- ipsecctl: support ipv6
- ipsecctl: support des nom de groupes d'interfaces, comme pf. Par ex. : ike esp from egress to 10.1.2.0/24 peer mygate.home.net
- ipsecctl: support des listes, façon pf. eg: ike from em0 to { 192.168.7.0/24, 192.168.9.0/24 } peer 1.2.3.4
- ipsecctl: Support flows with port modifiers for proto tcp/udp, e.g. flow proto udp from 1.2.3.4 port ntp to 5.6.7.8
- ipsecctl: possib de ne pas préciser le "peer", la règle fonctionne alors en catch-all (matche pour tout peer qui se présente)
- ipsecctl: on peut préciser les lifetimes de phase 1 et 2. par ex: ike from 1.1.1.1 to 2.2.2.2 main life 3600 quick life 1200
- ipsecctl: possibilité de désactiver la pfs (groupe "none")
- isakmpd: permettre la sélection de clef RSA selon l'ID isakmp
- améliorations de m4 (plus d'extensions gnu, tant pis pour posix)
- support multiples tables de routages
- support de l'algo de crypto michael mic (en vu du support tkip/wpa !)
- encore plein d'améliorations dans lint
- correction de pleins de bugs trouves par coverty et lint
- ld.so prebind (un prelink securisé, avec randomisation)
- port java de sun plus facile à installer (via kaffe)
- gcc 4.1 dans les ports, et même gcc-4.2.20060715
- OpenOffice.org est enfin porté (2.0.3) !
- ameliorations de la gestion des DAT (chargeurs multiples, barcodes ...)
- support gravure cds et dvds dans cdio(1)
- support des horloges hardwares udcf dans ntpd
- port sur l'architecture AViiON (mvme88k)
- port UltraSparc III
- port armish (vers plein de boards arm, xscale cpu etc)
- refactoring du code du driver ami(4), qui devient notamment monitorable via le framework des sensors
- acpitz: minimal thermal zone driver. Monitors thermal zone temperature, shuts down the system if the 'critical temperature' is reached.
- driver onewire(4) - Dallas 1-wire bus (et aussi gpiow(4) etc.)
- driver wpi(4) - blob-free driver for Intel PRO/Wireless 3945ABG
- driver rum(4) - chipsets wifi Ralink RT2561, RT2561S et RT2661
- driver zyd(4) - Zydas ZD1211, chipset wifi
- driver mfi(4) - cartes LSI MegaRAID SAS
- driver azalia(4) - periph audio intel
- driver udcf(4) - Gude ADS Expert mouseCLOCK DCF77/HBG time signal recv
- driver nmea(4) - time delta sensors
- driver bnx(4) - cartes reseau broadcom NetXtreme II Gigabit
- driver acx(4) - pour les cartes wifi avec chipset Texas Instrument
- driver msk(4) - Marvell Yukon-2 based Gigabit Ethernet adapters
- driver uark(4) - Arkmicro Technologies ARK3116 USB UART serial adaptater
- driver ucycom(4) - USB support for Cypress microcontroller serial adapters
- driver arc(4) - Areca Technology Corporation RAID Controller
- driver pgt(4) - PrismGT chipset (FullMAC for now)
- drivers pour divers nouveaux sensors i2c
- ajout de warnings dans gcc : "-Wstack-larger-than-N", to report functions which are too greedy in stack variables (sera utilisé par défaut pour compiler le kernel)
[^] # Re: NVIDIA
Posté par herodiade . En réponse au journal Et pour noel c'est quelle carte graphique qu'on s'achète ???. Évalué à 2.
http://www.freesoftwaremagazine.com/node/1797 dit :
The nouveau project is now working on implementing a memory manager for NVIDIA
cards which would make both their revamped nv driver (added EXA support) and
their new 3D driver (DRI, DRM, GLX and GLSL being worked on) almost working on
the whole NVIDIA cards range (from NV04 to G70).
J'aurai donc tendance à dire : il faut d'abord encourager ceux qui jouent le jeu (en l'occurrence Intel) en achetant leur matériel. Mais lorsque ce n'est pas possible (par ex. dans le cas d'Intel, je n'ai pas trouvé de carte « standalone », en AGP ou PCI-E), on peut choisir une ATI ou nVidia qui de façon égale, ne jouent pas le jeu, et utiliser leur driver libre avec ou sans accélération en attendant qu'il progresse (ça va très vite). Bien entendu, les drivers proprios sont à proscrire (non éthiques, instables, mal maintenus, mal intégrés dans les distros et chiants lors des upgrades de la distro ou même du noyau, ...).
En complément, je disait plus haut qu'il est difficile de trouver une carte ATI supportée par le driver libre et suffisamment récente pour être fournie en PCI-E (ce qui peut être une contrainte lourde). Un autre détail, j'ai lu que AIGXL ne fonctionne pas correctement, pour le moment, avec une distro en 64 bits (source : http://fedoraproject.org/wiki/RenderingProject/aiglx , à confirmer) !!
Donc faire le choix d'une nVidia ou d'une ATI récente pas encore bien accélérée et d'attendre un petit peu n'est pas forcément sot, non ?
[^] # Re: Ati 9250?
Posté par herodiade . En réponse au journal Et pour noel c'est quelle carte graphique qu'on s'achète ???. Évalué à 2.
J'ai quelques questions supplémentaires sur cette carte (enfin, ce chipset) :
- Est-ce que le driver libre est stable ? ça plante parfois ?
- Est-ce que le pilote libre fournit une accélération 3D suffisante pour les petits jeux libres (type tuxracer par ex.) ou pas d'accélération du tout ?
- Est-il possible d'utiliser la sortie TV avec des outils/pilotes libres uniquement ?
- Tu dit que tu l'a choisie dans l'espoir d'avoir AIGLX un jour. As-tu l'impression que les pilotes libres sont encore loin du compte ou qu'ils avancent vite, sur ce point ?
- Le pilote est-il inclus dans les versions récentes (par ex. 7.1) de x.org ou distribué séparément ? nécessite-t-il un module noyau tiers ?
- Le pilote est-il inclus en standard dans les distributions récentes (etch, edgy, fc6, par ex.) ou faut-il l'installer en ajoutant des dépôts externes ?
Merci d'avance !
P.S. : au sujet du journal, il y a un critère supplémentaire qui complique encore le choix, c'est le fait que les carte mères récentes supportent de moins en moins l'AGP mais que les pilotes libres semblent supporter des cartes graphiques anciennes plus souvent disponibles en AGP qu'en PCI-X. Voir des cartes carrément abandonnées : impossible de trouver une 9100 (rv200) sur le site de rue-montgallet. :(
[^] # Re: Des manuels scolaires du monde entier.
Posté par herodiade . En réponse au journal Que libéreriez-vous si vous aviez 100 millions de dollars ?. Évalué à 6.
Concernant les livres scolaires, il est précisé qu'il faut libérer du contenu existant (donc pas payer des gens pour écrire du neuf).
Mais il y a une proposition qui me semble super intéressante à ce sujet : racheter des livres scolaires out-of-print, c'est-à-dire au tirage épuisé (mais pas trop vieux si possible). L'idée c'est que de tels livres seront surement très bon marché, ce qui permetrai d'en acheter plusieur par matière/langue : par exemple un manuel de géographie français, un quebecois, un suisse, un belge etc. : ainsi on pourrai les « merger » pour limiter le biais culturel (ce qui est plus dûr avec un seul livre neuf).
La mise à jour des livres épuisés (par exemple datant du dernier changement dans le programme scolaire de la matière) ne devrait pas être trop dur pour nous, surtout si on a des livres correspondants aux programmes scolaires de plusieurs pays différents pour une langue donnée.
L'autre bon coté des livres scolaires c'est qu'au delà de wikibooks, on devrait pouvoir s'en servir pour étayer aussi les articles de wikipédia. Comme dit dans la proposition que je cite : ça permettrai d'être sûr que wikipédia ai une couverture décente de tout les sujets encyclopédiques et scolaires de base (car pour le moment on a des articles de qualité sur des sujets hyper pointus, et des articles misérables sur des sujet essentiels).
[^] # Re: Des codeurs
Posté par herodiade . En réponse au journal Que libéreriez-vous si vous aviez 100 millions de dollars ?. Évalué à 7.
Elle précise aussi que le but est de libérer des choses qu'il serait impossible ou extrèmement dur d'obtenir ou de faire nous même (donc pas, par exemple, l'écriture d'articles sur des sujets où les sources sont dispos).
Jimbo Walles a donc fait remarquer que les propositions de ce type (très fréquentes) sont irrecevables pour cette offre précise :
- faire du lobbying (ce n'est pas acheter des données existantes)
- payer des devs (idem)
- subventionner un/des projet(s) libres (idem)
Dans les propals que j'ai lu, j'ai tilté sur une qui rappelle aux autres qu'il ne faut pas oublier les non-anglophones si possible. Car on voit essentiellement des propositions avec des implicites du type « the world is America ». Par exemple les propositions de scanner la « library of congress » ou celle du MIT, de libérer des archives d'un « newspaper » (explicite ou sous-entendu : un journal américain, en langue anglaise et avec un regard américain sur le monde). Idem pour les propals du genre : libérer des archives vidéos (l'exemple qui leur vient tout de suite en tête, c'est la BBC).
Du coup il me semble qu'il serait plus profitable pour le « reste du monde » qu'ils libèrent des fichiers moins culturellements/linguistiquements marqués.
En particulier des photos (par exemple des archives de Reuters, AP, AFP etc.), car c'est maintenant impossible de produire nous même des photos de personnes décédées ou d'évenements passés (et que wikipédia manque singulièrement d'images, et c'est très dommageable pour les articles sur les personnages du 20em siècle, sur le cinéma, la musique, etc. : wikipédia est alors sous-évaluée par rapport a des sites ou autre encyclopédies, libres, etc. au contenu textuel moins riches mais qui ne sont pas très regardants sur la liberté des images). Les cartographies sont aussi un bon exemple (mais le problème c'est leur durée de vie / vitesse de péremption de la justesse de leur contenu).
# Précision
Posté par herodiade . En réponse à la dépêche ModSecurity 2.0.1 est disponible. Évalué à 5.
Et même avec Apache 2.x, certaines de ces directives sur le filtrage des réponses / flux sortants n'est possible que sous condition (par exemple le filtrage sur OUTPUT - le contenu complet de la réponse - n'est possible que si l'output buffering n'est pas activé).
# Son compagnon
Posté par herodiade . En réponse à la dépêche ModSecurity 2.0.1 est disponible. Évalué à 10.
J'en profite pour signaler un bon compagnon pour mod_security, à savoir mod_evasive (http://www.zdziarski.com/projects/mod_evasive/ ). Ce module permet de restreindre le nombre d'accès par seconde (globale/pour tous, et pour une IP/client donné) sur un objet apache (un repertoire, un cgi, un script php, ...). C'est une protection utile pour se prémunir des attaques par dictionnaire (en protégeant les pages d'authentification, par exemple) ou les DoS involontaires (en restreignant le nombre d'accès sur les scripts dont l'execution est lourde et lente).
Dans un autre registre, mais aussi très utile pour protéger les serveurs webs utilisant PHP, on peut citer le patch Hardened-PHP (http://www.hardened-php.net/ ).
# Précision
Posté par herodiade . En réponse à la dépêche Faille de sécurité dans le pilote propriétaire Nvidia. Évalué à 10.
OpenBSD fait justement parti de ceux qui réclament les specs de tout matériel, sans NDA, depuis longtemps. J'espère que les devs Debian pas contents (de la dépêche d'à coté) saisiront l'occasion pour leur filer un coup de main.
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 4.
Restrictions minimes, au moins pour les deux dernières : du moins elles n'empêchent pas un logiciel qui veut réutiliser un bout de code, ou se linker sur une lib en mit/lgpl/bsd d'utiliser la licence de son choix, y compris la GPL.
autant mettre son logiciel dans le domaine public et fournir les sources.
Oui, « public domain » serait idéal.
Mais dans certains pays (dont la France, je crois) ça n'est pas un statut juridique suffisant pour fonctionner comme une licence.
Et ça ne permet pas de dire : « je ne suis pas responsable de ce que vous faites avec ce que je vous donne » (ce qui est autre chose qu'une restriction).
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 3.
Tout en emmerdant ceux qui ne pensent pas 100% comme toi mais veulent faire du libre.
Par exemple la licence (libre) CDDL, très typée GPL dans le sens où elle est contaminante, estime qu'il faut en plus abandonner l'exploitation de ses brevets logiciels si on veut ré-utiliser le logiciels (ce que prévoit la GPLv3 à priori). Mais cela constitue une restriction supplémentaire par rapport à la GPL (v1 et v2), et rend donc ces deux licences incompatibles.
La GPL ne tolère pas l'imposition de restrictions supplémentaires (fut-ce pour forcer des libertés : restrictions contre les DRM, etc.). Mais on ne peut pas réduire les restrictions imposées sur du code GPL (contamination, copyright, etc.). Par conséquent, la GPL impose un vision très précise du libre, et se refuse toute compatibilité avec les visions/besoins légèrement divergent (en plus ou en moins restrictif). Je trouve ça un peu sectaire.
Si en plus on me dit (enfin, Pierre Tramo le dit) qu'ils font ça par rapport au logiciel propriétaire, je pense : mince, quel dommage, se laisser dicter sa conduite, et imposer des contraintes aux autres utilisateurs du libres à cause du propriétaire !
Vive la compatibilité élargie, vive le respect des autres approches du libre (jugées aussi libres par la FSF et l'OSI), vive les LGPL, BSD et MIT !
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 5.
Il faut cesser de croire que les personnes utilisant les licences MIT, BSD ou même LGPL le font spécialement « pour permettre au proprio » de les utiliser. Dans bien des cas, ils utilisent ces licences avant tout parce qu'ils veulent laisser aux autres - y compris aux inconditionels de la GPL - le plus de choix possible dans leur façon d'être libre.
C'est le choix de la compatibilité avec les autres licences libres (à contrario du « tous comme nous » de la GPL).
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 3.
Le fait, par exemple, de maintenir ces paquets via le bugtracker de Debian est aussi une forme de support pour ces paquets.
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 6.
http://fr.wikipedia.org/wiki/Image:Shamil_Basayev_and_Aslan_(...)
[^] # Re: "Apporter le calme" ?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 6.
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 3.
lynx -dump http://www.debian.org/vote/2006/vote_005_tally.txt |grep "^V: 1"
C'est vrai que la proportion de français est assez impressionante dans cette liste !
À quoi c'est dû ? une kabbale dissidente ?
[^] # Re: Hein?
Posté par herodiade . En réponse à la dépêche Les développeurs Debian choisissent le pragmatisme et souhaitent bonne chance à Dunc Tank. Évalué à 7.
[^] # Re: historique de OpenSSH
Posté par herodiade . En réponse à la dépêche OpenSSH version 4.4 fait dans la finesse. Évalué à 10.
Celà dit, ça va être dur de supplanter OpenSSH. Non seulement sur le plan fonctionnel, mais surtout en ce qui concerne la confiance des utilisateurs et des distros qui l'intègrent.
En effet, en suivant le cvs, on remarque vite qu'OpenSSH est régulièrement audité par des spécialistes renommés. Je me rappele avoir vu passer quelques corrections de bugs identifiées par Solaar designer ou Ulrich Drepper, par ex. Ou, pour s'en tenir à ces derniers mois, des corrections venant d'audits par l'outil d'analyse statique « coverty » de standford, par l'outil « Saturne » et par la Google Security Team.
Mais le gros de ce travail de (ré)audit permanent et d'amélioration continue de la sécurité tient à l'intégration d'OpenSSH dans un projet beaucoup plus large, OpenBSD. De là, de nombreux developpeurs d'OpenBSD participent régulièrement au ré-audit d'OpenSSH, avec en particulier des recherches ou améliorations « à thèmes » : séparation des privilèges (c'était il y a un moment déjà, mais plus récement: ), utilisation systématique de fonctions d'allocations renforcées ad hoc pour prévenir divers types de débordements, recherche systématique des int overflow, ré-audit systématique de la gestion des signaux, ré-audit systématique des paths d'erreurs, ...
Autrement dit, à mon sens, le succès d'OpenSSH vient aussi du fait que sa sécurité n'est pas seulement améliorée par ses développeurs (au sens strict), pas si nombreux, mais par une équipe beaucoup plus large de développeurs experts en sécurité, l'équipe d'OpenBSD (même les développeurs du noyau ou de la libc d'Open participent régulièrement à l'amélioration de la sécurité d'OpenSSH).
[^] # Debian, OpenBSD: objectifs convergents & petites diffs. conjecturelles
Posté par herodiade . En réponse à la dépêche Intel seulement open pour le business. Évalué à 8.
D'une part, parce qu'il s'agit d'une invitation à réagir destinée à la collectivité au sens large, que cela concerne les utilisateurs de GNU/Linux autant que ceux d'OpenBSD, et que les utilisateurs de Debian se sentent probablement tout autant concernés, et sont plutôt les bienvenus pour se faire entendre auprès d'Intel. D'ailleurs, si bizarre que cela puisse paraître, si Debian accepte (provisoirement) ces firmwares illégaux, c'est justement parce qu'elle veut être plus radicale encore qu'OpenBSD, en refusant carrément les firmwares librement distribuables mais non libres & opensources (ce qui est une tache énorme, donc débattue et régulièrement repoussée, c'est pourquoi, pour le moment, rien n'est fait et on a donc paradoxalement quelques firmwares "illégaux" qui traînent encore).
Second point, il y a une incompréhension endémique entre ces deux mondes de développeurs. L'objectif des deux communautés est le même (pouvoir fonctionner sur le matériel actuel en gardant un système le plus libre possible), les stratégies et enjeux diffèrent légèrement.
Sur ce point de divergence, il faut rappeler que que « développeur » ne signifie pas la même chose dans « développeur Debian » et « développeur OpenBSD ». Le développeur Debian travaille plutôt à l'intégration, au packaging, à la correction/remontée de bugs et à la redistribution & upgrade de logiciels tier, le plus souvent développés par d'autres (ce qui les rend plus sensibles aux questions de procédure et redistributions, compatibilité de licences, d'où l'objectif du "tout, même les firmwares, libre et avec les sources" pour le moment bloquant mais plus radical que "tout libre, mais les firmwares peuvent être seulement redistribuables"). Tandis que la fonction principale d'un développeur OpenBSD est d'écrire du code, ce qui le rend plus sensible aux questions de documentation du matériel, aux NDA - qu'ils refusent radicalement - mais moins sensibles au besoin d'avoir les sources pour les firmwares : ils n'auraient pas le temps ni les outils ni les compétences pour modifier le code des firmwares, fussent-ils libres (et ils ont besoin de réagir tout de suite, quitte à être moins exigeants / plus pragmatique, contrairement à Debian qui peut se permettre d'attendre de trouver un consensus sur des exigences plus "idéaliste", car les firmwares sont déja là dans Linux et avec eux le support du matériel dans un kernel développé par d'autres).
De plus, comme dit plus haut, « The firmware problem is a Linux [kernel] problem, not a Debian problem » (car c'est en amont les devs. kernel qui incluent souvent ces firmwares dans le kernel vanilla, tandis que sous OpenBSD, les développeurs noyau sont les mêmes personnes que ceux qui font l'OS => problématique différente).
# Réutilisation des correcteurs d'OOo dans Vim, Firefox et Thunderbird
Posté par herodiade . En réponse à la dépêche OpenOffice.org prend désormais en compte la nouvelle orthographe française. Évalué à 10.
Ces dictionnaires seront aussi utilisés par Firefox 2.0 (sortie prochaine), qui (sauf contre ordre) inclura un correcteur d'orthographe pour les formulaires basé sur les dicos d'OOo. Pour le plus grand bien de Wikipédia, de linuxfr et des multiples blogs à mon avis ;)
Un petit point à signaler à ce sujet. Les dictionnaires français d'OOo sont dérivés d'autres dictionnaires qui étaient sous licence GPL, ce qui explique la licence inhabituelle pour un projet issu d'OOo.
Ça explique aussi pourquoi on est obligé de télécharger et installer ces dictionnaires séparément du logiciel (aussi bien pour OOo que pour Thunderbird, et probablement idem pour Firefox 2) : ces logiciels sont publiés sous des licences plus souple, et ne veulent pas être « contaminés » par l'inclusion d'un dictionnaire français en GPL. Pour une fois, je regrette un peu le choix de la licence GPL (plutôt que LGPL, BSD ou MIT), car l'effet escompté de la GPL par rapport aux autres licences citées (la contamination / l'encouragement à passer le reste sous GPL) n'a pas été atteint dans ce cas, et parce que cette opération d'installation n'est pas forcément triviale, ni même, parfois, connue par les débutants.
# rencensement du hardware pro libre et des fabriquants coopératifs
Posté par herodiade . En réponse au journal Achat libre ?. Évalué à 2.
# pour de meilleurs CAPTCHA
Posté par herodiade . En réponse au journal Google et logiciel OCR Open Source. Évalué à 5.
Éspérons qu'il y ai des progrès sur les implems libres de CAPTCHA, parce que Sam Hocevar a déjà frappé fort : http://sam.zoy.org/pwntcha/
En tout cas, un bon OCR pourrai booster Wikisource (http://wikisource.org/wiki/Main_Page ), c'est une très bonne nouvelle !
[^] # Re: Interrogations ???
Posté par herodiade . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 4.
Plaît-il ?
Avant de donner des leçons de morales, faudrait peut-être voir à ne pas prendre tes interlocteurs pour des sous informés débiles. Merci.
D'une part j'ai bien entendu lu les threads sur les mailings-lists à ce sujet, dont les deux liens que tu cite, d'autre part j'ai aussi lu (et ça tu ne les cites pas dans ta selection de messages) des messages expliquant que l'absence de sources pour ces fichiers ne poserait pas de vrais problèmes légaux:
1) parce qu'on peut éventuellement filer des sources assembleur si qqun insiste à coup de procès (en décompilant le fw binaire)
2) parce que toutes les distros qui ont des juristes pour étudier ces questions ont jugé que ce ça ne pose pas de gros problème
3) parce que si on va par là, il y a un paquet d'autres fichiers, inclus dans des softs libres, dont debian ne peut pas filer les sources : scripts './configure' dont le config.in est perdu, images diverses, certaines fonts, ... . Tant qu'à enculer les mouches au lieu de se battre aux cotés de ceux qui écrirvent les drivers pour régler les vrais problèmes de liberté (obtenir les specs du matos sans NDA, par ex.), allez-y jusqu'au bout.
Quoiqu'il en soit, mon commentaire ne visait pas à critiquer le fait que Debian ne soit pas parvenu à retirer ces fw jusqu'à présent, au contraire (car oui, je sait que c'est dur, long, etc. et je l'ai dit plus haut), mais à critiquer ceux qui jettent des GR inaplicables (parce que justement, c'est dur) sur ce sujet, et qui ne font pas (ou ne peuvent pas finir) le boulot de toutes façons (parce que oui, c'est dur).
C'est très bien de faire la morale et de lancer les GR, maintenant, si ceux qui savent si bien monter sur leurs grands cheveaux quant à la question de la liberté des fw s'étaient sortis les doigts du cul pour virer ces fw, adapter l'installeur, etc. ils n'en seraient peut-être pas là. En l'occurence, ça ressemble fort à un : « nous on aime seulement donner des leçons et troller sur les ML, alors on va vous forcer, vous les developpeurs kernels, à faire le boulot que vous ne jugez pas prioritaire/utile ou que vous n'avez pas envi de faire ».