Renommés pour leur quête inlassable de la sécurité et pour leur intransigeance envers la liberté et la propreté du code, les développeurs de ce système d'exploitation dérivé d'Unix nous proposent plusieurs évolutions fort intéressantes.
Les récents problèmes de financements du projet semblent également avoir conduit à un effort encore plus soutenu de communication et de promotion à destination du monde extérieur. On peut ainsi lire sur le net plusieurs articles et interviews intéressants qui permettent de se faire une idée plus juste des atouts particuliers de ce système.
NdM : Merci également à Landry Breuil et Louis Nyffenegger pour leur proposition d'article. Cette version met l'accent sur la lutte contre le blob (c'est d'ailleurs le thème de la chanson rituelle qui accompagne chaque sortie). Un blob c'est un pilote (ou une portion de pilote) qui n'est disponible que sous forme binaire. La différence avec un firmware binaire est que ce dernier tourne directement sur le périphérique (une souris USB par exemple) alors qu'un blob fonctionne sur le processeur principal de l'ordinateur, en espace noyau. Les blobs entraînent donc des graves problèmes de portabilité sur les différentes architectures, de correction des bugs ou de sécurité générale du système et c'est pourquoi ils sont bannis d'OpenBSD.
Sur le site KernelTrap on peut lire une interview de Jonathan Gray and Damien Bergamini sur leur travail d'écriture d'une version libre du driver des cartes ethernet Nvidia. Damien (qui est français) explique notamment que, dans la lutte contre le blob, OpenBSD est un peu esseulé :
Traduction libre : "Nous ne voulons pas de ces blobs dans notre système parce que nous ne pouvons pas les maintenir nous mêmes. Aujourd'hui les blobs surgissent partout (le dernier qui me vient à l'esprit est le démon Linux binaire pour la carte Intel PRO/Wireless 3945ABG). Malheureusement cela ne va pas s'arrêter car plusieurs systèmes, réputés open-source, ont laissé tomber et décidé d'accepter ces blobs" (c'est moi qui souligne).
L'interview fleuve que le site ONLamp a réalisé à l'occasion de la sortie de la version 3.9 évoque également cette bataille cruciale contre les drivers binaires :
Traduction libre : "Certaines personnes on fait ce qui est de plus en plus commun chez FreeBSD, ils ont inclus un driver qui n'est en fait qu'un code "glue" qui entoure un blob binaire. Ils ont même eu une licence spécifique à FreeBSD pour le distribuer. C'est un scénario terrifiant que nous n'avons jamais envisagé de suivre dans OpenBSD".
Du coté des nouveautés techniques de la 3.9 on peut signaler l'interface unifiée de gestion des capteurs (température, ventilateurs, courant...etc) qui simplifie beaucoup l'obtention d'informations sur l'état des machines. Également le port vers les Mac G5, l'amélioration (par le français Marc Espie) des outils pkg_add et pkg_delete, l'audit complet du source pour traquer les usages fautifs de la macro queue(3), l'amélioration profonde du démon hostapd qui permet la communication entre les points d'accès wifi, l'introduction de l'outil sdiff de comparaison visuelle de deux fichiers afin de faciliter la gestion des configurations en cas d'upgrade du logiciel, le démon apmd pour faire varier la vitesse du processeur en fonction de la charge et beaucoup, beaucoup d'autres choses.
Dans les versions futures (qui sont évoquées à la fin de cet article) les développeurs vont travailler sur le support de l'ACPI (pour les portables) et des cartes RAID (pour les serveurs). La version multiprocesseur de l'OS va également faire l'objet d'efforts particuliers.
Pour ses qualités techniques propres comme pour son combat opiniâtre pour la liberté du code, le projet OpenBSD mérite donc votre attention et votre soutien. Vous pouvez acheter le CD de la version 3.9, épater votre copine de geek en portant un T-shirt de grande classe ou bien plus directement faire un don.
Aller plus loin
- L'annonce de la sortie (5 clics)
- Les nouveautés de la version 3.9 (3 clics)
- L'interview anti-blob sur KernelTrap.org (3 clics)
- L'interview géante sur ONLamp.com (3 clics)
- Introduction à OpenBSD 3.9 (4 clics)
# Les blobs c'est l'amoco cadiz !
Posté par Raoul Volfoni (site web personnel) . Évalué à 10.
http://www.openbsd.org/lyrics.html
C'est vraiment dommage que ce projet soit si seul à lutter contre la propriétarisation des drivers. Mais on en revient inlassablement à cette lancinante question: "vaut-il mieux céder une part de sa liberté en échange de fonctionnalités accrues, ou rester 100% libre quitte à baver d'envie devant ce que permettent les drivers proprios?"
Certains ont des réponses absolues et je les envie...
[^] # Re: Les blobs c'est l'amoco cadiz !
Posté par agmk . Évalué à 6.
>propriétarisation des drivers.
Juste une remarque, concernant l'exemple du blob ipw3945 : le driver *est* libre, la partie binaire est le démon userland assurant le respect des standards légaux en matière de télécoms http://bughost.org/ipw3945/daemon/README.ipw3945d Intel assure qu'ils y a sont obligés, et il me semble que ça a provoqué un troll sur la LKML il y a assez peu de temps.
[^] # Re: Les blobs c'est l'amoco cadiz !
Posté par reno . Évalué à 5.
Comme personne n'en sait rien (cela peut même dépendre du pays), et que c'est un prétexte facile pour les entreprises, c'est un troll qui n'est pas près de s'éteindre.
[^] # Re: Les blobs c'est l'amoco cadiz !
Posté par Jerome Herman . Évalué à 10.
Ce qui ets encore plus fort, c'est que si j'ai envie de me servir du channel 13 pour faire de l'émission hors batiment (ce qui en France est interdit) Il suffit de dire au binaire que l'on habite au canada ou à singapour.
Donc on appréciera le haut niveau de protection et de forcage des normes offert par les blobs en question.
[^] # Re: Les blobs c'est l'amoco cadiz !
Posté par reno . Évalué à 3.
# Linux
Posté par M . Évalué à 10.
N'est-ce pas plutôt les utilisateurs qui ont laissés tombés ?
Dans le cas de Linux, aucun blob n'est supporté par les développeur de kernel.org, au contraire si certaines parties sont détectées comme servant à charger un blob, elles sont ejecté (c'est ce qui à été fait dans le cas du driver pwc).
De même sous Linux, certains blob sont RE (reverse engineering) comme par exemple le driver ethernet de nvidia (qui au passage à servi de specification pour écrire le driver openbsd) ou encore le driver wifi broadcom, pour pouvoir être intégré dans la branche principale.
Certains développeurs en sont même à mettre du export_gpl partout.
Par contre certaines distributions sous la pression des utilisateurs se mettent à fournir des drivers proprio au lieu d'encourager leur clients à choisir des solutions supportant/compatible avec le libre ou de convaincre les constructeurs de libérer leur spécifications/drivers.
[^] # Re: Linux
Posté par patrick_g (site web personnel) . Évalué à 10.
Il n'empêche que si les utilisateurs étaient un peu plus consistants sur le chapitré de la liberté du code les distros ne se battraient pas pour intégrer des blobs. C'est bien parcequ'il existe une demande de la base que certains "trahissent" ainsi la cause. Et ça ne va certainement pas s'arranger quand xgl/compiz va débarquer et que tous les gens vont vouloir des drivers 3d qui tuent pour en profiter.
[^] # Re: Linux
Posté par ragoutoutou . Évalué à 6.
C'est toujours le problème: ou tu donnes aux utilisateurs ce qu'ils veulent ou alors ils vont voir ailleurs... Si linux n'avait pas les drivers proprio nvidia et ATI, je connais quelques personnes qui retourneraient illico sous Windows.
De toutes façons, le grand danger pour le libre, ce n'est pas tant le proprio que les lois anti-logiciel libre comme les DMCA/EUCD/DADVSI, les brevets sur le logiciel, et la complaisance des pouvoirs publics envers les gros joueurs monopolistes.
[^] # Re: Linux
Posté par M . Évalué à 3.
Dans ce cas il faut savoir ce qu'est/sera Linux :
- un système libre
- un système gratuit
- un système performant (qui doit utiliser la moindre fonctionnalité du matériel qui sont présentes seulement dans les driver proprio/doc sous NDA)
- un système qui doit concurencer windows (et avoir le plus d'utilisateur, de support matériel, d'effet funky, ... [1] )
- ...
[1]
A ce propos un post sur la Linux Kenel Mailling List donnait un aperçu de ce qui pouvait se passer si les blobs prennait le dessus (j'ai plus le lien :( )
[^] # Re: Linux
Posté par ragoutoutou . Évalué à 6.
Le gros frein à l'ouverture de certains pilotes par les constructeurs, c'est les lois comme le DADVSI, le DMCA, ...
Par exemple, ATI se retranche derrière le DMCA pour expliquer qu'ils ne peuvent fournir le code source des pilotes sous peine de donner des informations permettant de désactiver le macrovision sur leurs cartes.
Bien sûr, il y a sans doutes une part d'hypocrisie de la part d'ATI, mais ce problème de licence des technologies dvd assortit de surarmement juridique pour punir les atteintes à l'intégrité des mesures de protection comme le macrovision fait que le problème est tout de même plus complexe qu'un simple problème de sensibilisation d'un constructeur.
[^] # Re: Linux
Posté par Jerome Herman . Évalué à 8.
Le vrai problème d'ATI (le coté macrovision étant annecdotique) est un problème de fonctionnalités sur lesquelles ils n'ont pas l'ensemble des droits. A la vitesse à laquelle vont les technos 3D aujourd'hui, même un gros poisson comme ATI ne peut pas se permettre d'avori uen équipe R&D assez importante pour trouver des méthodes pour implémenter toutes les fonctionnalités demandées à une carte graphique de nos jours. Pour combler les lacunes ils font appel à des sociétés extérieures (ils ne peuvent pas tout racheter non plus). Ces sociétés extérieures, ne vendent pas du produit mais du papier, elles n'ont donc non seulement aucun interet à ce que les specs de elur focntions soient révélées, mais elles ont même clairement interet à ce que ca reste le plus secret possible (parceque défendre en tribunal que tel implémentation d'un "shader register combiner" est en fait une copie de leur implémentation à eux c'est pas gagné).
Si on ajoute à celà qu'avec les specs complète d'une carte il tout à fait possible de s'arranger pour qu'un jeu brille sur une carte et soit très lent sur une autre (on ira même jsuqu'à dire que ca a déjà été fait plusieurs fois), on comprend vu la fascination qu'ont les power-gamer pour les benchs alac que les fabriquants de puces n'aient pas vraiment envie de fournir toutes leurs specs.
[^] # Re: Linux
Posté par BAud (site web personnel) . Évalué à 4.
je pense qu'il s'agit de ce thread (provenant de mes notes, regarder les suivants/précédents aussi) :
http://marc.theaimsgroup.com/?l=linux-kernel&m=113378006(...) an horror story :-( starring binary modules
* http://marc.theaimsgroup.com/?t=113378020600002&r=1&(...) the whole thread
* http://marc.theaimsgroup.com/?l=linux-kernel&m=113383205(...) answer showing the need to educate buyers, make them choose hardware with open source drivers
* http://marc.theaimsgroup.com/?l=linux-kernel&m=113383205(...) EXPORT_SYMBOL_GPL as a technical measure to identify derivatives of the linux kernel
* http://marc.theaimsgroup.com/?l=linux-kernel&m=113386088(...) "designed for Free Software" Label
* http://marc.theaimsgroup.com/?l=linux-kernel&m=113388088(...) call the support center and sales people, requiring open drivers
* http://marc.theaimsgroup.com/?l=linux-kernel&m=113389410(...) opengraphics
* http://marc.theaimsgroup.com/?l=linux-kernel&m=113389936(...) Alan Cox' position
[^] # Re: Linux
Posté par reno . Évalué à 3.
Bof, dans le cas des cartes 3D haute performances, il n'y a pas le choix, juste de ne pas en acheter, ce qui est un *gros* inconvénient pour les utilisateurs!
Et les utilisateurs de Linux étant quand même très peu nombreux, il n'est pas évident qu'ils aient suffisamment de poids pour faire plier les fabriquants de matériels..
[^] # Re: Linux
Posté par patrick_g (site web personnel) . Évalué à 10.
Mais personne ne demande qu'ils plient et baissent leur culotte !
Si leurs drivers binaires sont si géniaux et si pleins de propriété intellectuelle fabuleusement avancée tant mieux pour eux ! Nous on veut juste qu'ils fournissent la documentation de leurs cartes et la communauté se chargera, comme une grande, d'écrire des drivers libres à partir de ces docs.
Il n'y a strictement aucun argument intelligent pour appuyer leur position restrictive. Leurs concurrents connaissent déja le layout de leurs cartes et donc publier des docs ne leur coutera strictement rien. En plus le cycle de dev est tel que publier la doc d'une carte quand elle sort ne peux donner aucun avantage à un concurrent car le dev de la carte n+1 est déja terminé et celui de la n+2 est bien avancé. Le premier qui fera le pas de la publication des docs aura toute la communauté libriste derrière lui...et elle est assez nombreuse et très bruyante.
En résumé : le premier d'entre nvidia ou ati qui bouge sur ce sujet gagne une pub énorme à travers tous l'internet, un argument marketing supplémentaire, des drivers libres développés gratuitement, des ventes en plus...c'est tout bénef !
[^] # Re: Linux
Posté par kowalsky . Évalué à 0.
Mouais, j'aime pas trop cette philosophie.
Deja la communauté, il faut le rappeler, n'existe pas.
Certains projet vont des des sens opposés, certain ne pensent même
qu'a eux et veulent faire tourner leur logiciel sur l'OS du mal.
Il y a diverse communauté, mais pas une communauté de communauté.
Bref, qui va l'ecrire ce driver libre...?
C'est un peu la même mentalité que les windowsien qui disent:
Pas grave, les pirates trouveront une parade...
Les pirates crackeront le Vista le lendemain, etc etc...
Donc il FAUT faire plier les fabricants.
Linux et BSD ont deja fait plier d'autres fabriquant, pourquoi pas ceux la...!
[^] # Re: Linux
Posté par patrick_g (site web personnel) . Évalué à 5.
Les mêmes que ceux qui passent actuellement des nuits blanches et des trésors d'ingéniosité à écrire un driver pour les ati r300 en ingéniérie inverse...ou pour les cartes ethernet nvidia...etc etc
Si des gens sont capables de se lancer dans ces projets utra-complexes alors tu imagines bien que si les docs étaient disponibles il y aurait d'autant plus de volontaires.
[^] # Re: Linux
Posté par kowalsky . Évalué à 2.
C'est n'est pas parce que c'est fait actuellement que ça dois continuer.
[^] # Re: Linux
Posté par lasher . Évalué à 8.
Voyons voir ...
Driver Solaris, driver Linux, driver {DragonFly,Free,Net,Open}BSD, driver QNX, driver ...
Franchement, il serait plus simple de laisser le dév desdits drivers aux gens qui ont le plus l'habitude de bosser sur les systèmes précités... Sans parler du fait que certains aiment développer des drivers (si si), ou tout un tas d'autres trucs. :-)
[^] # Re: Linux
Posté par patrick_g (site web personnel) . Évalué à 5.
Solaris sur Sparc, NetBSD sur ARM, Linus sur PPC, OpenBSD sur mips...etc etc
La seule méthode réaliste pour un fabricant c'est de publier la doc.
[^] # Re: Linux
Posté par erik_lallemand . Évalué à 3.
Petite question d'un ignorant en matière de drivers... Ca demande quelle quantité de ressources de développer (on laisse de côté l'encadrement, la coordination, etc.) un driver de qualité correcte pour 1 système? 2 mois-hommes? plus? moins?
[^] # Re: Linux
Posté par lasher . Évalué à 5.
Par contre, si pour une "bête" carte réseau ethernet (sans fonctions de crypto intégrée en dur ou autres) la rédaction d'un pilote est rapide , autant pour une carte vidéo qui comporte énormément de circuits différents et spécialisés, ça risque de prendre plus de temps - notemment à cause du temps pris par des tests sérieux. Combien, je ne sais pas. :-)
[^] # Re: Linux
Posté par reno . Évalué à 6.
Oui bien sûr mais:
-je pense qu'un driver de carte 3D est plus complexe qu'un driver ethernet..
-les cartes 3D évoluent très vite.
-je me souviens que même quand les specs des cartes ATI étaient libre, le driver n'était pas de bonne qualité: J. Carmarck avait contribué au driver, pas parce que cela l'intérressait mais parce qu'il était en mauvais état pour faire tourner un de ses jeux..
Et c'était *avant* que les drivers intègrent des compilateurs de shadeurs!
Certes on peut penser que la contribution de J. Carmack fait partie du processus 'normal' de développement de driver libre, mais cela montre bien qu'un driver libre peut rester de "mauvaise qualité" pendant très longtemps: il y a peu d'application 3D sous Linux et ceux qui les développent ne sont pas forcément prèts a corriger les bugs des drivers..
De plus il y a le probleme de l'optimisation pour la 3D qui est très différent d'un driver Ethernet: où mettre la barre entre précision et performance?
Pour un jeux, c'est tout à fait justifié de baisser la précision si les FPS augmentent, pour une appli de CAO cela peut être différent..
Ceci dit, la défense de NVidia de ne pas fournir les specs car la communauté OpenSource ne serait pas capable de faire un driver de qualité est bien sûr absurde: certes l'histoire montrent que coté performances les driver proprio sont meilleur, mais
1) cela peut changer si l'interet pour la 3D sur Linux augmentait
2) coté fiabilité en général c'est le contraire (le driver opensources sont meilleurs) donc cela reste très intérressant
3) les non x86 en profitent, argument moins intérressant maintenant:Apple étant passé au x86..
[^] # Re: Linux
Posté par Antoine . Évalué à 2.
Pour un jeux, c'est tout à fait justifié de baisser la précision si les FPS augmentent, pour une appli de CAO cela peut être différent..
C'est à l'userspace de choisir, le driver n'a qu'à fournir l'API nécessaire pour choisir le compromis voulu.
[^] # Re: Linux
Posté par Xavier Teyssier (site web personnel) . Évalué à 7.
Par exemple le fait que les constructeurs de cartes utilisent des techniques/algo/agencement de composant/etc. qu'ils ont obtenus chez des partenaires, avec dans le contrat d'utilisation, l'obligation de ne pas les dévoiler ?
Auquel cas, avec la meillleure volonté du monde, le fabricant de cartes ne pourra rien publier tant qu'il n'a pas l'accord de ses partenaires...
# des efforts "dipomatiques" ont-il été faits pour la libération des spéc?
Posté par padawan . Évalué à 3.
Certains comme RMS ou Theo DeRaad ont des discours assez virulent envers tout ce qui est propriétaire (RMS ayant récemment dit que les catholiques - lui est athé - devraient considérer les logiciels propriétaires comme diaboliques ... je suis pro-libre mais de là à penser ça !!!).
Bien que les drivers n'aient (amha) aucun rapport avec les logiciels (on a quand même le droit de faire tout ce qui est moral et/ou légal avec un objet palpable qu'on a acheté, non ?) et que les spécifications devraient être totalement libre, je pense qu'il faut de temps en temps modérer un peu les discours, essayer de discuter calmement et faire le possible pour convaincre objectivement nos interlocuteurs. Il ne faut pas oublier que les fabricants ont presque toujours fait du propriétaire et qu'ils sont sous la pression de leur concurrents, il faut les rassurer, leur faire comprendre qu'il n'y a réellement aucun risque à publier leurs spécifications ou alors que le risque est acceptable étant donné la possibilité d'avoir de nouveaux clients, de jouir de plus de publicité et d'avoir de nouveaux développeurs pour gratis qui les aideront dans leur quête du pilote le plus parfait et performant. Il faut leur montrer que la publication des spécification n'a pas lésé certains de leurs concurrents qui ont franchi le pas.
Car finalement, un discours dur entraine au mieux un renfermement défensif au pire un entêtement qui risque de faire disparaître à tout jamais l'éventualité d'un publication des spécifications matérielles.
Je pense aussi qu'une seule main ne peut pas applaudir, ne serait-il pas temps que les differents acteurs du libre fasse la paix, oublient leur différends, se rappellent de ce qui les unie et se réunissent autour d'une fondation ou d'une alliance pour mettre au point un programme commun pour la liberté logicielle pour faire entendre leur voix et monter leur nombre et leur force pour être considérés comme un interlocuteur digne de respect ?
dans chaque parti il y a des courants de pensée mais la philosophie motrice reste la même.
Est-ce que quelqu'un a des informations sur des efforts qui ont été faits dans ce sens svp ?
merci
________
zisis note e troll !
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par neologix . Évalué à 6.
Pour moi, l'issue est le soutien de différents acteurs majeurs (IBM, Oracle, Sun), gouvernements, et administrations. De ce point de vue là, les choses bougent, s'accélèrent. L'apparition de partenariat avec des constructeurs (HP, Dell) est relativement significative des progrès accomplis ces dernières années. Par exemple, il y a quelques temps, très peu de personnes avaient entendu parler de Linux, de l'Open Source, etc. Aujourd'hui, de telles personnes se font rares.
En résumé, lorsque nous aurons atteint une "masse critique", les choses bougeront. Pour négocier, il faut "avoir des billes"...
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Antoine . Évalué à 2.
Quoi de neuf alors ? ;)
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par herodiade . Évalué à 10.
TdR (sur ce point, à la différence de RMS) n'a rien contre le propriétaire. Si ce n'est qu'il le considère généralement comme une condition de mauvaise qualité logicielle, et que lui ne veut pas faire du propriétaire. D'où sa préférence pour la licence BSD, ou mieux ISC/MIT (s'il faut qu'il y ai des softs proprios, autant qu'ils ne pourissent pas nos réseaux et ré-utilisent du bon code, tiré d'OpenBSD par exemple).
Il est moins idéologue que RMS, sa position est plus généralement celle d'un développeur puriste de la qualité du code source.
Concernant ta remarque sur la diplomatie, on vois que tu n'a pas suivi les mailings-lists d'OpenBSD. TdR explique régulièrement les efforts qu'il fait pour obtenir des spécifications, et celà commence évidement par contacter poliment le constructeur, puis lui faire savoir qu'il a un marché et des clients à conquerir (ou ne pas laisser filer), puis, parfois, demander aux utilisateurs de logiciels libres de faire savoir eux-mêmes au constructeur qu'ils sont des clients potentiels, représentent un gros marché, et sont sensibles à (et avertis de) la politique du constructeur.
Et finalement, parfois, si tout le reste à échoué, en déséspoir de cause, TdR peut lancer un large appel public aux utilisateurs de logiciels libres, dans l'espoir que la solidarité aidera, et que le constructeur cherchera finalement à éviter une trop mauvaise publicité, et décide de travailler dans son intéret (c'est à dire, in fine, celui de ses clients !).
Voilà. Plutôt que dire aux autres (RMS, TdR ...) ce qu'ils devraient faire, pourquoi ne pas simplement répondre à leur appel à l'aide, et simplement envoyer un petit email à Intel, nVidia, ATI, Connexant, Adaptec etc. ?
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par padawan . Évalué à 1.
tu as bien lu ma question ? je ne savais pas ce qui avait été fait c'est pour cela que j'ai demandé si des efforts ont bien été faits.
Je suis qui pour dire aux autres ce qui doivent faire ? je ne suis même pas foutu d'écrire une ligne en C...
blame me not sir !
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Jerome Herman . Évalué à 3.
C'est presque celà, mais pas du tout.
Il ne faut pas oublier que les fabricants ont presque toujours fait du propriétaire
Pas du tout en fait, les matériels (jusqu'en 94-95) étaient fournis avec l'ensemble des specs et souvent le schéma matériel et le schéma logique de la machine. Les 286 IBM, les premières sparc et les premières station DEC étaient même fournie avec la structure des pros en bonus. La mode du propiétaire a été instaurée tout d'abord par adaptec qui a commencé à blinder ses piotes et ses specs SCSI dans tous les sens aux alentours de 95. Derrières les autres boites ont suivi (malheureusement). On a eu droit tout d'abord à uen explosions de dongles et de cables bizaroïdes dans tous les sens et pusi on s'est lentement acheminé vers le proprio tel qu'on le connait maintenant.
leur faire comprendre qu'il n'y a réellement aucun risque à publier leurs spécifications ou alors que le risque est acceptable étant donné la possibilité d'avoir de nouveaux clients
Si seulement, on ne compte malheureusement pas les personnes qui veulent absolument mettre le dernier drivers cracké comme un goret par un hacker de l'autre bout du globe et qui permet de gagner 2% de perfs sur certaines applications. Bon des fois le dit drivers fait partir le matos en fumée, lequel matos se retrouve alors en SAV et va savoir si c'est vraiment un défaut ou si le mec a fait n'importe quoi avec. Bien sur sur le matos "haut de gamme" pour els serverus de grande entreprises le risque est plus réduit que l'ingénieur système en place s'amuse à toucher les paramètres pour voir "ce que ca fait". Mais bon sur le haut de gamme il y a souvent des accords croisés, des partenariats et des NDA dans tous les sens. Donc pas de specs publiques non plus.
Cependant, je n'ai pas l'impression que des efforts diplomatiques ont été fait pour la libération des spécifications des différents matériels, ou du moins ça n'a pas été médiatisé sur les médias du libre.
je me permet de placer ici deux citatiosn de Theo de Raddt :
Trad : Les donnations de matériels ne viennent pas des fournisseurs qui utilisent OpenSSH sur des morceaux de leurs produits. Elles viennent de particuliers. Les fournisseurs de matériel qui utilisent OpenSSH sur tous leurs produits nous ont donné un total de un ordinateur portable depuis que nous avons développés OpenSSH il y a 5 ans. Et il a fallu demander pendant un an. C'était IBM
Trad : Alors le mec de HP vient vers moi (a la conférence de Melbourne) et il dit, " si vous dites des choses aussi méchantes que çà aux fournisseurs, vous n'êtes pas prêt d'obtenir quoi que ce soit". J'ai dit "Non, en huit ans sans rien dire, on a rien obtenu, et je vais commencer à dire des choses méchantes dans l'espoir que certains de ces fournisseurs commeceront à me donner de l'argent pour que je la boucle."
En bref la méthode diplomatique a été essayée. Elle a échoué.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par imalip . Évalué à 2.
La question vaut aussi pour les autres constructeurs (IBM, Sparc), qui financent ou donnent du materiel a d'autres projets, mais pas a celui-la.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par lasher . Évalué à 2.
Sans doute parce que Linux a une visibilité bien plus grande qu'OpenBSD, que la base de développeurs pour le système est, elle aussi, bien plus grande, etc.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Jerome Herman . Évalué à 3.
Au final ils ne veulent pour rien au monde perdre la main sur leur projet et ils ne font pas dans le compromis. Hors ca c'est pas très interressant pour les fabriquants.
L'intransigence de Theo est ce qui donne sa force à OpenBSD, masi c'ets aussi ce qui le coupe des sponsors. Autant on est prêt à investir dans un projet en création à conditin d'avoir son mot à dire, autant il est plsu difficile d'investir dans un projet qu'on ne peut absolument pas influencer. Au final pour des groupes comme HP ou IBM donner de l'argent à OpenBSD reviendrait soit à payer un produit (OpenSSH) qui est un produit déjà fini, déjà maintenu et déjà disponible, soit à faire du mécénat sur les futurs produits d'OpenBSD. Mais ca n'est pas vraiment un investissement.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par padawan . Évalué à 0.
justement, il a rien dit pendant des années et quand il a parlé il a dit des choses méchantes et il les a dit tout seul. comment veut-tu que les concernés réagissent ? il font la sourde oreille ou ils agissent méchamment.
En ce qui concerne les drivers crackés et la SAV, franchement s'ils conçoivent du matos mal foutu qui grille à la première fausse instruction c'est un peu de leur faute (je met un CD ultra-techno dans ma chaine, si elle grille c'est la faute au fabricant)
et puis s'il publiaient les specs les drivers ne seraient pas crackés ils seraient alternatifs et susceptibles d'être plus compatible avec le matériel. et puis avec le peer review ils (les fabricants) pourraient même certifier des drivers opensource pour un système donné (openbsd, une distribution linux, le kernel vanilla, etc) parce que des drivers crackés ont toujours existé et existeront toujours DAVDSI/EUCD/DMCA I&II ou pas.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par Jerome Herman . Évalué à 4.
Façon de parler bien sur. Il a rien dit de méchant. Il faut voir que Theo était auteur de pilotes professionnel avant même de rejoindre NetBSD. Donc parler avec les différentes salles techniques des fabriquants il connait un peu.
En ce qui concerne les drivers crackés et la SAV, franchement s'ils conçoivent du matos mal foutu qui grille à la première fausse instruction c'est un peu de leur faute (je met un CD ultra-techno dans ma chaine, si elle grille c'est la faute au fabricant)
Oui mais les fabriquants pour éviter de dépenser trop de frics dans 50 000 chaine sde montage ils ont une seule chaine et dérrière ils testent. ca tient 200Mhz => top rpoduit. Ca tient 180Mhz => moyen produit. Ca tient 150Mhz => bof rpoduit. Ensuite la différence c'est un ou deux petits bits dans le firmware. Des fois aussi ils se content d'éteindre des fonctionnalités dans la puce grace un quelques bits dans le firmware et un gros morceau dans le driver, des trucs auquel l'utilisateur a pas droit parceque c'ets pas uen carte top produit bien sur, mais aussi des trucs expérimentaux qu'on a quand même laissé dans le tape out mais dont on saity qu'ils marchent pas bien. Alors hop désactivés logiciellement.
Dérrière le driver alternatif il te propose bien sur de mettre la vitesse maximale et d'activer pleins de fonctions expérimentales. Et dans certains cas (souvent chez les mecs qui commencent à bidouiller pour voir) frouf la carte.
[^] # Re: des efforts "dipomatiques" ont-il été faits pour la libération des s
Posté par herodiade . Évalué à 8.
Ce dernier y explique très clairement ces problématiques, et sa démarche face aux constructeurs :
http://kerneltrap.org/node/6550
# Et l'EFI?
Posté par paco69 . Évalué à 7.
Croyez vous que l'EFI (Extensible Firmware Interface) peut arranger tous les problèmes de drivers? ou du moins une grande partie des drivers?
"You need to stop using the crap shipped with Ubuntu."
[^] # Re: Et l'EFI?
Posté par M . Évalué à 5.
En gros ça change rien : que ton blob soit sous la forme d'un fichier binaire, ou alors d'un bytecode à télécharger de ton matos, ça reste du code proprio que tu maîtrises pas qui tourne sur le host cpu.
# Rebondissement
Posté par Bertrand Jacquin (site web personnel) . Évalué à 4.
Aujourd'hui, quel constructeur permet d'utiliser une carte vidéo sans pilotes propio ? Ou du moins quels sont les cartes bien supportées ? Avec un minimum de 3d.
J'ai recemment acheté une carte vidéo ATI x800 en PCI Express pour l'utiliser sur un AMD64. Et c'est la croix et la bannière pour la faire fonctionner.
Les drivers de Xorg ne me permettent pas l'utiliser avec une résolution supérieur a 640x480 (C'est pas franchement terrible). Avec les pilotes proprio, je ne peux que l'utiliser avec Xorg 6.8.2 (pas avec le X modulaire) et marche mal avec le kernel >= 2.6.15.
Voila, ce que j'attend c'est une carte qui marche mais aujourd'hui a part du Nvidia ou ATI, le paysage est pas tellement diversifié. Et google non plus remarqué.
Je suis pour l'utilisation de pilotes libres sans blobs mais est-ce que c'est possible ? Quel carte fonctionne bien avec des pilotes libre ?
[^] # Re: Rebondissement
Posté par padawan . Évalué à 2.
Matrox (drivers pour X je ne sais pas mais ça a l'air de marcher pour le projet DirectFB car Matrox publie les spécifications de certaines cartes), et jadis - vant le rachat par ATI cette année - les Xgi.
[^] # Re: Rebondissement
Posté par Nicolas Bernard (site web personnel) . Évalué à 4.
[^] # Re: Rebondissement
Posté par neologix . Évalué à 4.
Le r300 n'est pas encore au point, mais son prédécesseur est plutôt pas mal.
[^] # Re: Rebondissement
Posté par patrick_g (site web personnel) . Évalué à 7.
Certes je n'ai pas la puissance d'une des dernières ati ou nvidia mais :
1) je n'ai pas sacrifié mes principes et je n'ai pas encouragé avec mes euros ces salopiots d'ati/nvidia.
2) je n'ai pas à me tracasser pour aller récupérer des drivers sur des sites du constructeur et pour essayer de les faire marcher. Mon driver "just work" et, comme le source est dispo, je sais qu'il ne fait rien de louche dans mon dos.
3) ma carte graphique est suffisante pour planet-pingouin-racer et sera suffisante une fois que xgl/compiz seront dispo.
[^] # Re: Rebondissement
Posté par Bertrand Jacquin (site web personnel) . Évalué à 5.
[^] # Re: Rebondissement
Posté par Aurélien BEGEL . Évalué à 2.
[^] # Re: Rebondissement
Posté par Meku (site web personnel) . Évalué à 4.
glxgears n'est certainement pas un bon benchmark, mais sur ce point ça reste meilleur que le score de ma GeForce2 MX avec drivers proprios : je m'attendais à beaucoup moins bien !
Et c'est vrai que c'est sympa d'avoir l'accélération 3D out-of-the-box et Open Source après l'installation de sa distro préférée :-)
# Autres nouveautés
Posté par herodiade . Évalué à 10.
- support ipv6 dans ppp (enfin !!!)
- trunk (interfaces agregees) supporte maintenant le failover et roulent bien avec carp et pfsync.
- support des cartes ethernet 10Gbps LS/SR et CX4 intel (ixgb(4), et peut etre
des gigabits Sun).
- refactoring complet et nombreuses ameliorations de lint et xlint (puis correction de nombreux petits bugs potentiel sur l'ensemble du systeme, grace à ce nouveau lint).
- ré-audit des sources à la recherche d' "int overflows" (et adoption de mesures préventives contre les trucs vicieux, comme le vilain malloc(x*y)).
- ports: update de gettext en 0.14.5 (il n'etait plus updaté depuis des années !)
- les sont libs compilees par defaut avec -g, les binaires linkes avec -X
- correction de l'implementation de W^X d'après les commentaires de Julien Tinnes, suite à son article dans le magazine misc: http://marc.theaimsgroup.com/?l=openbsd-cvs&m=1137105999(...)
- log (user) dans pf.conf: permet de logguer l'uid/gid du process de la socket (visibles par ex sur tcpdump -i pflog0).
[^] # Re: Autres nouveautés
Posté par djano . Évalué à 2.
Peux tu en dire un peu plus s'il te plait? Ca m'interesse.
J'ai cherche un peu mais je n'ai pas trouve exactement ce que tu sembles dire.
[^] # Re: Autres nouveautés
Posté par herodiade . Évalué à 4.
Celà a certainement un rapport avec le refactoring de lint(1), qui sait maintenant repérer ce type d'erreur sans trop de fausses alertes, et qui a révélé un paquet d'erreur (là encore, l'aide de lint était souvent indiquée dans les logs cvs), et révéillé l'attention des développeurs à la fragilité du code sur ce point, entrainant un réaudit plus fin/manuel.
Pour le "vilain malloc(x*y)", je fait référence à un article publié le mois dernier par un dev d'OpenBSD, "Multiplication Considered Harmful" ( http://undeadly.org/cgi?action=article&sid=2006033007191(...) ).
En gros:
void mafunc(int arg);
int x, y;
[...]
mafunc( x * y ) ; /* baboum, x*y ne tient peut-être pas dans un entier ! */
qui fait particulièrement mal lorsque mafunc() est en fait malloc(). C'est pourtant un truc qu'on trouve courrament dans du code, lorsqu'on fait malloc( n * sizeof(obj) ) pour allouer "n" objet "obj".
[^] # Re: Autres nouveautés
Posté par djano . Évalué à 1.
Merci de ta reponse!
[^] # Re: Autres nouveautés
Posté par chl (site web personnel) . Évalué à 3.
D'où l'interet de la fonction calloc qui verifie si le resultat de la multiplication est valide.
[^] # Re: Autres nouveautés
Posté par herodiade . Évalué à 3.
1- La problèmatique présentée est plus générale (malloc() était un exemple): il faut faire attention aux int overflows, même lorsqu'on ne fait pas l'assignation soi même explicitement. En d'autre termes, être précautioneux lorsqu'une fonction prend un entier en argument et qu'on lui passe une multiplication (ou une adition) d'entiers. Et être attentif à ce problème lorsqu'on réaudite du code.
2- Avec malloc(), ce problème fait très mal, donc on utilise calloc(). Par contre il n'y a pas d'équivalent pour realloc(), il faut alors prendre des précautions "à la main".
Pour info, la faille de sécu qui avait touché OpenSSH (qui est maintenu par les gars d'OpenBSD, comme chacun sait) en 2002, était justement dûe a un débordement d'entier. Preuve que ça peut faire très mal, et raison de leur réaudit.
# Ayé
Posté par gnumdk (site web personnel) . Évalué à 2.
J'ai juste un petit probleme avec pfstat qui refuse de s'installer, on dirait que les packages sont pas encore vraiment prets... Une idée?
# pkg_add pfstat
Can't install gd-2.0.33p2: lib not found fontconfig.3.0
Even by looking in the dependency tree:
jpeg-6bp3, png-1.2.8, libiconv-1.9.2p3
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
Can't install gd-2.0.33p2: lib not found freetype.13.1
Can't install pfstat-1.7p1: can't resolve gd-2.0.33p2
Et effectivement, pas de fontconfig.3.0 sur les serveurs, et des versions de paquets différents...
[^] # Re: Ayé
Posté par Antoine Jacoutot (site web personnel) . Évalué à 1.
# Où sont les blobs ?
Posté par cbon linux . Évalué à 0.
j'ai installé Debian, y a des blobs dessus ? Ca me génerait. (on voit là l'avantage de OpenBSD que je connais mal et qui a une licence chelou non gpl).
Quels sont ces blobs existants aujourd'hui ?
Solutions aux blobs par niveau de gravité :
1* N'est-il pas possible pour les hackers (ceux qui touchent grave à l'informatique) de coder des drivers gpl pour remplacer ces blobs ?
2* Et sinon, n'est-il pas possible de demander à la boite qui fait ce hardware blobien de sortir des drivers gpl et de les inclure dans el kernelo del linuxo olé ?
3* Et encore sinon, ba il faudrait que les gens achètent que du "bon hardware qui a des drivers gpl et toc" ? (moi j'achète mes légumes bio).
Merci
[^] # Re: Où sont les blobs ?
Posté par cbon linux . Évalué à 2.
D'abord un article excellent qui dit pourquoi les blobs, c'est pas joli joli : http://lwn.net/Articles/159313/
Je résume :
- Linux deviendrait dépendant des drivers proprios,
- les drivers proprios sont buggés et rendrait le kernel instable,
- impossible que les développeurs linux puissent aider les utilisateurs lors des bugs de ces drivers proprios,
- les drivers proprios ne marchent pas sur tous les hardware que Linux connait,
- il suffit d'un blob dans une distribution ou le noyau Linux pour les rendre non-GPL.
Il est donc obligatoire que Linux remplace ces blobs par du code GPL.
OpenBSD est alors un système supérieur à Linux car sans blobs (sans parler de la sécurité et de la propreté de son code, no comment).
Par contre la licence de BSD est mauvaise : elle permet à une boite privée d'utiliser du code BSD (et même GPL) dans ses logiciels fermés.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.