vendredi 05 février
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Pilotes binaires dans Linux: quel est le problème ?

Posté par Thomas Petazzoni (page perso, ). Modéré le 08 décembre 2005.
0
Aujourd'hui, le nombre de périphériques nécessitant des pilotes binaires dans le noyau Linux s'accroît. Du côté des cartes graphiques, NVidia a toujours livré des pilotes binaires pour Linux. ATI, qui à l'origine fournissait des pilotes libres a rejoint NVidia et livre maintenant des pilotes binaires. De nombreux chipsets Wifi ne disposent pas non plus de pilotes libres, et les utilisateurs doivent passer par ndiswrapper, une couche de compatibilité permettant d'utiliser sous Linux des pilotes prévus pour Windows.

Ces pilotes binaires posent un certain nombre de problèmes, qui ont poussé Arjan van de Ven, développeur du noyau Linux, à publier une petite fiction intitulée « Linux dans un monde binaire, une hypothétique débâcle ». Cette petite fiction, dont une traduction rapide et non-officielle est proposée dans le corps de l'article, pourrait bien devenir réalité si les pilotes binaires venaient à se généraliser. Le traducteur a ajouté des notes de bas de page à l'histoire afin de faciliter sa compréhension par des non-spécialistes.

Pour résumer, voici quelques-uns des problèmes posés par les pilotes non-libres:
  • Il est impossible de mettre à jour son noyau si le constructeur n'a pas sorti de nouvelle version de son pilote. Si le constructeur décide que le matériel ne vaut plus le coup d'être supporté, alors il n'y a tout simplement plus de pilote ;
  • Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau (voir ce document de Greg Kroah-Hartman) ;
  • Le fait d'utiliser des pilotes binaires implique d'avoir du code qui s'exécute en mode privilégié et qu'on ne peut pas auditer ou étudier. Il est alors impossible de savoir si ce code n'effectue rien de malveillant (l'histoire du rootkit Sony n'est pas si lointaine). Les bugs qu'il comporte peuvent entraîner des corruptions de données ou des plantages qui affecteront la totalité de la machine, et pas simplement un programme individuel. C'est d'ailleurs la raison pour laquelle les développeurs du noyau refusent aujourd'hui de corriger des « oops » signalés par un utilisateur lorsque des modules binaires sont chargés ;
  • L'utilisation de pilotes binaires, ou de pilotes Windows au travers de ndiswrapper réduit la pression sur les constructeurs pour qu'ils mettent à disposition des pilotes libres ou les spécifications de leur matériel, et réduit la pression sur les développeurs de Logiciels Libres pour qu'ils développement des pilotes compatibles et libres.
En cette époque de fin d'année et d'achats pour Noël, choisissez donc bien votre matériel !

> Lire la suite (200 commentaires, moyenne: 3).   [dépêche : 14531 caractères]

Linux dans un monde binaire

Que se passerait-il si demain les développeurs du noyau Linux acceptaient que les modules binaires sont une bonne chose et qu'ils sont essentiels au progrès de Linux ?

Une hypothétique débâcle, par Arjan van de Ven

L'hypothèse principale sur laquelle est basé ce scénario ne va évidemment pas se produire, mais toutes les affirmations qui suivent sont basées sur des éléments tangibles.

Le 6 décembre 2005, les développeurs du noyau décident en masse que les modules binaires sont légaux [1] et qu'ils sont souhaitables pour le progrès de Linux. Au départ, le processus de développement du noyau Linux ne change pas vraiment, à part le fait que de nouveaux symboles sont exportés, et que EXPORT_SYMBOL_GPL [2] est supprimé.

Trois semaines plus tard, des distributions comme Red Hat Enterprise Linux et SuSE SLES commencent à inclure de nombreux modules binaires dans leurs CD d'installation. Debian s'y refuse et reste fidèle à sa cause, ainsi que les autres distributions ouvertes comme Fedora Core ou openSuSE.

Les distributions professionnelles n'incluent pas seulement les modules NVidia et ATI, mais incluent également les modules fakeraid et les différents pilotes wifi, winmodem, windsl et TCP-offloading. À l'inverse de NVidia et ATI, la plupart des constructeurs livrant des pilotes binaires ne proposent pas de couche d'abstraction [3] dont le code source est disponible: ils proposent seulement la version binaire finale.

Plusieurs constructeurs de matériel qui avaient jusqu'à présent été coopératifs avec la communauté du Logiciel Libre voient leurs concurrents livrer uniquement des pilotes binaires. Chez eux, la pression monte pour que la « propriété intellectuelle » soit sauvegardée. Certaines fonctionnalités de leurs matériels ne sont pas exploitées par les pilotes parce que leurs départements juridiques estiment que le risque de divulgation de leur « propriété intellectuelle » est beaucoup trop important. Par conséquent, ils considèrent que les pilotes binaires de leurs concurrents ont un avantage concurrentiel, ou au moins que leurs propres pilotes pourraient y gagner en étant fermés, parce qu'ils pourraient alors utiliser ces quelques fonctionnalités supplémentaires afin de dominer la compétition. [4] Le 1er février 2006, environ la moitié des constructeurs de matériel ont recentré leur travail sur les pilotes pour Linux autour de la création de valeur ajoutée dans des pilotes binaires qu'ils distribueront en plus des pilotes libres qui existent déjà. Certains constructeurs ont même stoppé le support des pilotes libres parce qu'ils n'ont pas assez de ressources pour maintenir deux versions en parallèle.

Premier mars. Toutes les nouvelles gammes de serveurs des plus grands constructeurs embarquent la nouvelle génération de matériel réseau et de stockage. Ce matériel est livré avec des pilotes binaires pour les deux dernières versions des distributions RHEL et SLES, et ces pilotes sont déjà intégrés dans les mises à jour de février de ces distributions. L'un des constructeurs livre son pilote sous la forme d'un binaire et d'une couche d'abstraction, les autres n'y attachent pas d'importance et livrent uniquement des pilotes binaires pour ces deux distributions. Deux des constructeurs de cartes réseau publient une mise à jour de leur pilote libre avec un support réduit des nouvelles cartes. Les autres constructeurs ne le font pas. Le matériel grand public n'est pas vraiment affecté: la plupart des chipsets des produits grand public sont basés sur le standard AHCI pour le stockage SATA, et conservent les fonctionnalités existantes dans les chipsets réseau.

Premier avril. Deux des constructeurs de chipsets ont mis à jour leurs puces pour inclure une nouvelle fonctionnalité audio intéressante qui permet une lecture améliorée des DVD, mais malheureusement, cela les oblige à dévier de l'interface audio "standard" i810. L'un des constructeurs publie un pilote binaire pour quelques distributions, les autres ne considèrent pas Linux intéressant pour le desktop et ne jugent pas utile de faire un pilote pour Linux pour le moment.

Premier mai. Tous les serveurs que l'on peut acheter demandent au moins un, mais souvent deux ou trois modules binaires pour fonctionner. Bien que certains de ces pilotes soient disponibles sous la forme d'un « blob binaire » et d'une couche d'abstraction, plusieurs sont seulement disponibles pour RHEL3, RHEL4 et SLES 9 et parfois pour la nouvelle distribution SLES10. Les utilisateurs de Linux sur ces serveurs n'ont d'autre choix que ces quatre noyaux, sans le moindre espoir de pouvoir exécuter un noyau « vanilla » [5] provenant de kernel.org. La communauté d'Ubuntu est sérieusement agacée, et essaie, avec un succès mitigé, d'inclure des pilotes libre sa distribution. Grâce au demi-succès de ce lobbying, environ 50% de ces serveurs pourront fonctionner avec le noyau Ubuntu.

Premier juin. Une énorme « flamewar&nsbp;», la quatrième sur ce sujet depuis janvier, a lieu sur la liste de diffusion du noyau Linux. Les utilisateurs et quelques développeurs demandent à ce que les développeurs du noyau officiel (kernel.org) adoptent l'ABI module [6] existante dans la distribution RHEL ou la distribution SLES. Après investigation, il apparaît que cela n'est pas possible, et le fil de discussion s'oriente vers un débat entre la définition d'une nouvelle ABI, ou le gel de l'ABI actuelle. De nombreux développeurs du noyau ont le sentiment que l'ABI existante ne convient pas pour devenir une ABI stable, et qu'une nouvelle ABI et API, conçue de manière à pouvoir rester stable plus facilement est la bonne solution. D'autres disent que cela prendra trop de temps et que cela ne servira à rien pendant les deux prochaines années, tant que RHEL et SLES n'auront pas adopté cette ABI. Ils demandent au moins un gel immédiat de l'ABI du noyau « vanilla » de façon à ce que la prochaine RHEL5 l'utilise et livre des pilotes écrits pour cette ABI. Les utilisateurs utilisent généralement la RHEL ou la SLES pour les serveurs de productions, ou des clones comme CentOS qui disposent d'une compatibilité binaire au niveau du noyau.

Premier juillet. Il devient de plus en plus difficile de faire fonctionner Linux sans modules binaires sur la plupart des nouveaux PCs grand public. Alors qu'un an plus tôt, les gens devaient pour cette raison abandonner l'accélération 3D, maintenant même la 2D ne fonctionne plus sans pilotes binaires, pas plus que le réseau (aussi bien filaire que sans fil) ou le son. Pour la moitié des machines, il n'y a pas de support Linux, tandis que 20% des machines utilisent des systèmes de traduction comme NdisWrapper pour faire fonctionner les pilotes son et réseau conçus pour Windows sous Linux. Le projet Debian, qui ne peut maintenant plus fonctionner sur la plupart des machines, perd une énorme quantité d'utilisateurs qui migrent vers Ubuntu, ou des hybrides Ubuntu-Debian. La liste Debian-legal et d'autres listes du projet sont monopolisées par ce sujet, déclenchant de vifs débats. La plupart des constructeurs qui livraient encore des pilotes libres plus à moins à jour ont tout simplement arrêté de le faire.

Quartorze juillet. Linus Torvalds déclare que l'ABI du noyau est maintenant stable, mais crée en même temps la branche 2.7 du noyau, et annonce que le noyau 2.8 aura une ABI différente. En pratique, seules les personnes qui ont encore accès à leurs vieilles machines peuvent désormais aider au développement du noyau 2.7, puisqu'aucun pilote fourni par les constructeurs, même ceux qui ont encore une couche d'abstraction ne peuvent suivre l'arbre de développement du noyau dans lequel les changements sont "trop rapides" pour être suivi par les constructeurs.

Vingt-et-un août. Une faille de sécurité sérieuse est découverte dans les noyaux de la série 2.6. Cette faille de sécurité s'avère être liée à un problème de conception d'une API importante du "sysfs" [7]. Corriger cette faille nécessiterait de casser l'ABI des modules, et donc en pratique tous les modules binaires disponibles, alors que la non-correction de cette faille laisserait ouvert un trou de sécurité dont l'exploitation permet de passer "root". Un correctif est rapidement publié sous la forme d'une option de configuration, mais les utilisateurs ayant besoin de pilotes binaires n'ont pas d'autre choix que de laisser leurs systèmes vulnérables [8]. Les trolls sur la liste de diffusion du noyau recommencent et Linus est accusé d'avoir commis une erreur en gelant l'ABI existante plutôt qu'en créant une nouvelle ABI destinée à être gelée. Le développement du 2.7 est quasiment à l'arrêt et un patch est proposé afin de disposer dans le 2.7 d'une ABI similaire à celle du 2.6, patch nécessitant de retirer de nombreuses améliorations importantes du sous-système de gestion de mémoire virtuelle ainsi que les patchs de gestion du temps réel d'Ingo [9].

Vingt-six août. Un exploit prêt à l'emploi pour le trou de sécurité arrive sur BugTraq et est identifié comme étant utilisé par différents rootkits. Un exploit PHP l'utilise pour passer de l'utilisateur httpd à root. Les utilisateurs mettent la pression sur les distributeurs de modules pour qu'ils mettent à jour ceux-ci avec la nouvelle ABI, et plusieurs d'entre eux le font dans les trois semaines qui suivent. Les autres, principalement les constructeurs fabriquant du matériel grand public, disent que la matériel en question n'est plus construit et qu'ils ne sont pas prêts à dépenser du temps ou de l'argent pour produire des pilotes compatibles avec la nouvelle ABI.

Maintenant, ce scénario peut vous sembler improbable. Et fort heureusement la principale hypothèse (l'évènement du 6 décembre) est effectivement très peu probable.

Malheureusement, plusieurs des autres faits ne sont pas si improbables. En fait, certains de ces faits sont même très probables, comme en témoignent les trolls sur la liste de diffusion du noyau concernant la rupture de l'API et l'ABI des modules, ou l'effet « ndiswrapper » sur les constructeurs qui disent maintenant « nous supportons Linux, parce que ndiswrapper permet d'utiliser notre pilote Windows ». J'espère que cela n'aura pas lieu. Une partie de cet espoir est un espoir silencieux, mais je crois que les avantages de la liberté sont suffisamment importants pour surmonter les forces contraires.

Notes du traducteur, pour faciliter la compréhension de l'histoire à des non-spécialistes

[1] Aujourd'hui, les modules binaires sont plus ou moins tolérés. Il n'y a pas réellement de position officielle à ce sujet, et les débats sont souvent vifs sur la liste de développement du noyau. Tout le débat repose sur l'interprétation de la notion de « travail dérivé », tel que défini par la licence GPL.

[2] Dans le noyau Linux, pour que des modules externes puissent appeler des fonctions du coeur du noyau, il faut que ces fonctions soient « exportées ». Pour cela, les développeurs du noyau peuvent utiliser les instruction EXPORT_SYMBOL() ou EXPORT_SYMBOL_GPL(). EXPORT_SYMBOL() rend la fonction utilisable dans les modules libres et propriétaires, tandis que, en principe, EXPORT_SYMBOL_GPL() rend la fonction utilisable uniquement dans les modules sous licence GPL. Cette différence n'a pas de valeur juridique, mais elle est une indication du fait que les développeurs considèrent que l'utilisation de telle ou telle fonction du noyau constitue un travail dérivé de celui-ci.

[3] NVidia livre ses pilotes binaires sous une forme un peu particulière. Ils sont constitués d'une partie binaire, le coeur du pilote, et d'une partie dont les sources sont disponibles, qui sert de couche d'abstraction entre le noyau et la partie binaire. En anglais, la couche d'abstraction est souvent appelée « glue layer ». Ce fonctionnement permet de recompiler son noyau et la glue, tout en conservant la même partie binaire. Sans ce mécanisme, il faudrait à chaque fois qu'un nouveau noyau sort où que l'on recompile son noyau, que NVidia sorte une nouvelle version de ses pilotes.

[4] À ce sujet, ATI livrait auparavant des pilotes libres et les spécifications de leur matériel. Depuis que NVidia met à disposition des pilotes binaires, ATI fait de même.

[5] Le noyau dit « vanilla » est le noyau officiel disponible sur kernel.org. Il est dit « vanilla » par opposition aux noyaux fournis par les distributions (Fedora, Debian, Ubuntu, Mandriva, etc.) qui incluent des patches qui les font dériver de la version officielle.

[6] ABI désigne l'« Application Binary Interface », c'est-à-dire l'interface binaire entre deux sous-systèmes. Un changement d'ABI a lieu lorsque des structures de données changent, ou lorsque des prototypes de fonction changent. Un changement d'ABI nécessite une recompilation, ce qui pose problème aux constructeurs souhaitant livrer des modules propriétaires. Ils font donc pression pour disposer d'une ABI stable pour programmer des modules noyau. Pourtant, c'est une aberration technique, voir ce document de Greg Kroah-Hartman.

[7] « sysfs » est un des sous-systèmes du noyau Linux 2.6 permettant à des applications d'interagir avec les pilotes de périphériques en mode noyau.

[8] En effet, la correction de la faille de sécurité entraînant un changement d'ABI, il n'est plus possible d'utiliser les pilotes binaires: il faut attendre que le constructeur publie une nouvelle version de son pilote. Aujourd'hui, les utilisateurs de routeurs personnels Linksys WRT54 ne peuvent pas migrer leur petite machine vers le noyau 2.6: ils sont bloqués, car le pilote Wifi Broadcom 43xx n'est disponible qu'en module binaire pour le noyau 2.4. Heureusement deux équipes de fous très compétentes se sont lancées dans la rétro-ingénierie du pilote binaire avec des résultats intéressants, mais est-ce véritablement une solution viable ?

[9] En référence à Ingo Molnar qui travaille sur des patches pour le noyau Linux améliorant la latence de celui-ci, le rendant plus adapté à des applications audio très sensibles aux temps de réponse.

Un grand merci à Gaël Utard et Colin Leroy pour la relecture et les corrections.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

C'est parti ..

Posté par Xavier Bestel (Jabber id, page perso, ) le 08/12/2005 à 06:59. (lien). Évalué à 10.

Je vois d'ici les commentaires du genre "ben moi je trouve que les drivers nvidia sont au top, bien mieux que les drivers libres" ou "les développeurs du kernel sont des dictateurs, les utilisateurs ont le droit de faire ce qu'ils veulent" ou encore "une ABI stable pour les drivers ça serait quand même beaucoup plus pratique".
La situation est pourtant simple: en autorisant les drivers binaires on se retrouve comme sous Windows à la merci du bon vouloir du constructeur, qui s'arrête là où les clients de payent plus.
Pourquoi n'y a-t'il plus de Windows sous processeur Alpha ?
Pourquoi Win64 ne démarre-t'il pas ?
Parceque tous les drivers sont sous Windows IA32 et que les constructeurs ne vont pas faire l'effort de les porter sur d'autres architectures si ça ne génère pas de ventes significatives.

Le but de Linux c'est d'avoir un système d'exploitation libre, pas gratuit.

OpenBSD

Posté par Nicolas Bernard (page perso, ) le 08/12/2005 à 07:08. (lien). Évalué à 10.

Notons en passant que pour toutes ces raisons avec en plus un "le système doit être libre pour tous les usages", l'équipe d'OpenBSD refuse farouchement toute inclusion de pilote binaire dans leur système.

Dans cette même politique, ils mènent régulièrement des campagnes de lobbying auprès des constructeurs pour qu'ils fassent des pilotes libres ou publient les spécifications permettant d'en faire. En cas de refus, soit le driver closed source est déassemblé pour en refaire un open source (ex: cartes wifi avec chipset atheros) soit, si le matériel n'est pas prioritaire vis-à-vis des objectifs d'OpenBSD, il est déclaré non supporté et il est suggéré de ne pas l'acheter.

Linuxfr a déjà relayé certaines des campagnes pour la publications des spécifications:
http://linuxfr.org/2005/03/19/18549.html

Oui, mais que faire ?

Posté par Arthur Accroc () le 08/12/2005 à 07:31. (lien). Évalué à 10.

Voilà un article utile !

J'ai souvent fait des remarques de ce genre... et je me suis souvent fait moinser dessus. Il faut dire que je les ai faites en commentaire sur des annonces de nouveaux pilotes binaires ATI/nVidia et que ça gâchait peut-être la fête du nouveau pilote (buggé) de la mort pour la dernière carte 3D qui coûte le prix d'une console complète.

Maintenant, quelles sont les possibilités pour se sortir de cette situation ?

Si les développeurs du noyau refusaient totalement les pilotes binaires à partir de demain, ça pourrait limiter plus la diffusion de Linux que celles des matériels coupables...
Peut-être pourraient-ils déjà afficher au démarrage un message du genre "Attention, en raison de la présence d'un pilote propriétaire fermé (closed source) pour tel matériel dans votre noyau, l'intégrité de votre système ne peut être garantie" ?
Il faudrait peut-être utiliser le terme "non-certifié". Si ça pouvait déjà garantir que les constructeurs ne vendent pas comme "certifiées Linux" des machines contenant du matériel ne fonctionnant qu'avec des pilotes propriétaires, ce serait déjà un premier pas.

Une page sur kernel.org ou directement dans la doc du noyau avec la liste des matériel supportés par le kernel officiel pourrait fournir une véritable référence pour le choix de matériel (ce qui existe actuellement manque un peu de visibilité). En demandant aux constructeurs qui fournissent leurs spécs de fournir une table de conversion entre le type technique de leur matériel (vu par les pilotes) et les dénominations commerciales de ses variantes compatibles, ça pourrait être faisable.

En attendant, au niveau de LinuxFr, pourquoi ne pas déjà arrêter de passer les annonces de pilotes propriétaires, en tout cas en première page ?

Et le "nerf de la guerre", c'est qu'au niveau de chaque utilisateur, il est important d'acheter préférentiellement du matériel dont les spécifications sont disponibles plutôt que du matériel supporté uniquement par des pilotes binaires.
Nous votons avec notre argent : si nous achetons sans réticence du matériel supporté uniquement par des pilotes binaires, uniquement sur les plateformes les plus classiques et sans garantie que le support continuera une fois que le modèle ne sera plus produit, c'est un signe clair pour les constructeurs qu'ils n'ont pas à faire d'effort pour faire mieux. C'est comme cela qu'ATI a interprété le succès de nVidia y compris sur Linux...
Et les petits ruisseaux formant les grandes rivières, il faut prendre conscience que vous êtes responsable du futur (ça ne vaut pas que pour Linux, d'ailleurs).

--
« L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)

Oui, mais....

Posté par Martyanoff Nicolas (Jabber id, page perso, ) le 08/12/2005 à 08:04. (lien). Évalué à 9.

Le problème, c'est qu'en ce qui concerne l'accélération 3D, on a pas réellement le choix.
Si je veux faire de la prog OpenGL avancée (shaders...), il me faut l'accélération 3D sur une carte récente.
Il n'existe pas de pilotes libres efficaces pour une Radeon 9800pro (en fait pour toute carte postérieure à la Radeon 9200 chez ATI), donc je n'ai pas le choix, même si cela m'énerve pas mal.

Et le "je n'ai pas le choix", cela arrive aussi pour ceux qui ont un portable, et qui ont un chipset wi-fi non supporté par des drivers libres.

Bref, a quand des cartes graphiques modernes, performantes, avec un support OpenGL 2.0 complet, ET des pilotes libres ?

hum is free drivers

Posté par Bayet Thierry () le 08/12/2005 à 08:14. (lien). Évalué à 10.

Tiens ca me fait penser à un truc. J'en avais déjà parlé il me semble, mais c'est bien le moment d'en remettre une couche.

Un site (je suis tout doucement en train d'y penser) où l'on pourrais savoir très facilement si un drivers est libre ou pas. Non seulement ca donnerais du poid à la communauté, mais de plus, on ne serais pas obligé de faire des recherche démesurées pour savoir si un matériel est à acheter ou pas.

Je suis déjà tombé sur des sites similaires, mais je ne me souviens pas de l'adresse. Je pense même qu'ils étaient obsolètes.

Par contre si quelqu'un en connait un a jour, je ne vais pas réinventer le fil à couper le beurre.

--
snspy

créons un label "linux-compatible" !

Posté par flynn (page perso, ) le 08/12/2005 à 08:45. (lien). Évalué à 5.

Pourquoi ne pas créer un label "linux-compatible" ?

Ce label pourrait être apposé sur les matériels uniquement si les spécifications complètes de l'équipement sont publiques.

Pas de label => je n'achète pas.

J.

Une question, comme ça...

Posté par calandoa () le 08/12/2005 à 09:01. (lien). Évalué à 1.

Ces drivers binaires, ils s'exécutent sur le PC ou sur un processeur embarqué sur la carte graphique/wifi/réseau/etc... ? Les deux? Dans quelle proportion?

Avocat du diable

Posté par JAGUENAUD Anthony () le 08/12/2005 à 09:03. (lien). Évalué à 7.

Je vais me faire l'avocat du diable, mais je pense qu'il faut aussi regarder les choses avec un autre point de vue.

Je suis une grosse société qui fabrique du matériel informatique, j'ai fait une carte SCSI, Wifi, ... vraiment génial, je sais qu'en l'exploitant à fond, je serais bien meilleurs que la concurrence.
Mon problème, c'est qu'une partie de mes clients sont sous linux, et que si je livre des drivers complétement libre, l'architecture de la puce sera plus facile à comprendre et au lieu de 1 an d'avance, je n'aurais que six mois. Que faire, des drivers bridés, pour que ça marche bien, mais pas à fond, mais que ça n'aide pas les concurrents, et je réserve les drivers binaire pour les serveurs windows ?
Je fais des super pilotes libre, mais je dois amortir mon cout en R&D de plusieurs million d'¤ en 6 mois au lieu de 12 ?


Je ne sais pas si c'est ultra réaliste, mais je pense que pour promouvoir Linux et les logiciels libres, il faut éduquer les gens, pas leur imposer le libre.
Cette société, décrite pourrait faire un compromis, un driver close pendant un an, puis libérer les sources du driver (de toute façon, il aura était désassemblé par ses concurrents).

--
Je donne mon sang, et vous, que faites-vous pour sauver des vies ?
http://www.dondusang.net/

Binaire c'est mal(TM)

Posté par hervé Couvelard (Jabber id, page perso, ) le 08/12/2005 à 09:21. (lien). Évalué à 10.

Bonjour,

Comme la plus part des libristes (ce qui n'est pas forcement la totalité des utilisateurs linux), je considère que le binaire c'est mal. Par nature.

Qui peut dire ce que le pilote nvidia fait sur sa machine ?
Personne à part nvidia.
Qui peut affirmer que demain nvidia ne refusera pas afficher un film dvd qui n'est pas "tatoué graphiquement" ? Personne.

je comprends la position du developpeur de jeux 3D (plus haut), mais c'est l'histoire du serpent qui se mort la queue : si il a besoin de pilote binaire pour developper son jeu, il OBLIGE les utilisateurs à utiliser un pilote binaire pour utiliser son jeu : c'est un suppot de satan (nan je rigole, mais vous avez compris le truc).

Mon portable à une carte nvidia truc_chose_je sais pas quoi. Il y a longtemps j'ai utilisé le driver nvidia binaire et j'ai réfléchi : cela va à l'encontre de ce pour quoi j'ai choisi linux et je suis revenu à mon pilote nv. Oui effectivement au niveau accelération graphique pour les jeux, c'est pas une console de jeux (mais j'ai ma machine surtout pour travailler).

Ceux qui utilisent linux, et il y en a de plus en plus, ne devrait pas utiliser de pilote binaire sous peine de tainted, non seulement son noyau, mais la philosophie de linux.

Que ceux qui veulent que tout marche comme sous windows, avec des pilotes windows (ndiswrapper) avec des drivers closed_sources (ati, nvidia) qu'ils RESTENT sous windows, nous n'en voulons pas, mais on les aime bien quand même, il n'y a pas que cela dans la vie.

La preuve: l'utilisation des binaires nvidia a 'sorti' ATI de la route vers le libre. Si pratiquement aucune machine nvidia était sous linux, ceux qui n'ont pas le choix utilisant nv, nvidia sortirait aujourd'hui des pilotes libres plus ou moins fonctionnels.

Le choix d'un système d'exploitation est un choix réfléchi et qui porte à conséquence, il faut accepter les conséquences de ses actes. on ne peut avoir le beurre et l'argent du beurre (encore moins le cul de la crémière). Je trouve que les dev du noyau (et encore plus les distributions) devrait refuser les pilotes binaires.

Quel constructeur refuserait de sortir un pilote libre pour un serveur ? Il se fermerait près de la moitié du marché des serveurs.

Demain qui peut affirmer que mikrosauft, untel, ashpe, ou d'autres n'enfermeront pas dans leur driver closed un procédé pour 'ralentir' la machine si elle ne tourne pas sous vindoz, pour 'montrer' que vindoz c'est mieux.

Le binaire ne passera pas par moi. et vous ?

appeler le support de votre vendeur

Posté par baud123 (Jabber id, page perso, ) le 08/12/2005 à 10:12. (lien). Évalué à 3.

J'avais commencé à suivre le thread complet (quand il n'y avait "que" 128 messages) :
# 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

l'étape suivante est, en cas de problème identifié potentiellement sur votre PC (Oops ou moins pire, ou fonctionnalité intéressante identifiée...), d'envoyer une demande à l'équipe support de votre matériel (vous l'avez payé, non ? c'est pour que ça marche, que ça soit interopérable, toussa).
Cela permet aux constructeurs d'évaluer la demande d'une part et d'autre part de constater les remontées intéressantes suggérées par notre communauté du libre (les ouin ça marche pas seraient bien sûr à proscrire... mais vu que tout le monde a lu http://www.gnurou.org/documents/smart-questions-fr.html ça devrait aller ).

Pilotes Cartes Graphiques

Posté par skeespin (page perso, ) le 08/12/2005 à 10:51. (lien). Évalué à 2.

Et oui il n'existe pas que 2 constructeurs de cartes graphiques...
Les 3 sociètés VIA, S3, XGI avaient plus au moins parler d'ouvrir leurs pilotes. quand est il ?

Je pense que les perfs 3d de leurs cartes ne sont pas énormes mais elles seraient suffisantes pour ameliorer le rendu du serveur X.

Faire pression sur ces "petites" societes permet en meme temps de mettre la pression sur ATI et Nvidia.

Vivement que le 26 aout arrive !

Posté par totof2000 () le 08/12/2005 à 11:15. (lien). Évalué à 1.

1/ Il n'a pas besoin de la première étape pour ça

2/ Ca pourrait aider à faire prendre conscience du problème.

3/ Quoique je me pose des questions, on risque de dire " C'est Linux qui marche pas, on retourne sous Windows", mais sans penser que sous windows c pareil (voir même pire).

Un problème stratégique

Posté par Guillaume Vauvert (page perso, ) le 08/12/2005 à 11:50. (lien). Évalué à 2.

Je pense que ceux qui fournissent du matériel auront toujours de "bonnes" raisons de protéger leurs pilotes : cacher le fonctionnement de leur matériel, cacher comment les fonctionalités logicielles sont réellement réalisées, vendre les mises à jour des pilotes (on y viendra peut-être). Peu importe.
Le problème est que le monde du libre aura du mal à fonctionner avec ça. Ce qui peut sembler secondaire à certains pour la carte graphique (alors que ça ne l'est pas pour tous), devient crucial pour tous pour des éléments centraux : chipset, contrôleur disque ...
Je pense qu'il s'agit donc essentiellement d'un problème stratégique. Comment encourager|inciter|forcer les fournisseurs de matériel à permettre l'utilisation de pilotes libres, en fournissant au moins les spécifications nécessaires ?
- on peut à la BSD tout refuser, et faire du lobying. La difficulté est de survivre en attendant que ça paye.
- on peut accepter les pilotes fermés pour que la masse des utilisateurs augmentent jusqu'à former une masse suffisament pesante pour que les "proprios" cèdent, ce qui devrait se produire brutalement par domaine (si ATI juge que c'est rentable et cède, probable que NVidia suive). Le risque est notamment celui présenté dans l'article.
Je pense qu'il faut réfléchir en terme de stratégie à long terme, pas forcément en étant absolument dogmatique ou pragmatique.
Ce qui est certain, c'est que cela modifie les modèles économiques viables : il n'y a plus d'avance technologique qui serait visible par analyse du code du pilote. Il y a d'autres avantages (participation au développement, débogage), mais il faut faire un choix. Le changement est toujours risqué.

Probleme de population...?

Posté par kowalsky () le 08/12/2005 à 13:19. (lien). Évalué à 4.

Le probleme qui est soulevé, est un probleme du à la popularité de linux,
d'une autre informatique possible à celle mis en place par SUN, IBM et
microsoft en autre.

Le libre, pas au sens gratuit, cherche à avoir une informatique de concurence,
pas propietaire, avec des specification claire, OASIS, XML, POSIX, et
tout ce qui suis en terme d'API et de toolkit.

Sur une technologie donnée, tout le monde devrait avoir les même chances.

Mais c'est un peu le contraire de ce que souhaite l'industrie, qui veut poser
un verrou technologique, partout ou c'est possible, et presser le citron
eternellement, puisque le verrou technologique et commercial empeche
toute concurence de faire le moindre geste.

Il y a quelque année, quand le cercle d'acteur et de contributeur etait
restreint, on achetait ce qui fonctionnait. On faisait attention.

Maintenant, les utilisateurs ont changés, ils veulent du power graphique
3D de la mort, des drivers wifi pour des chipsets integré et autre trucs
impensable il y a quelque temps.

Le choc inevitable du libre et du proprietaire est la.

Fini le temps ou linux et bsd n'existaient pas pour l'industrie.

Maintenant, les politiques de verrous vont aussi tenter de s'installer dans
le monde du libre. Une niche economique potentiellement gigantesque
voit le jour. Et si l'on n'y prend pas garre, un retour au source, sans jeu de
mots, sera inevitable.

J'entend par la, qu'il va y avoir un monde libre, avec la même communauté
qu'avant "l'affaire binaires", et une autre, adepte des share-ware et du
je m'en foutisme... et tout ce qui s'en suis, piratage, spyware, malware
etc...

Est-ce un bien ou un mal apres tout...

--
You got the money, I got the soul.

Driver Nvidia 8874 et Quake IV

Posté par sylware () le 08/12/2005 à 13:20. (lien). Évalué à 4.

Déjà que les drivers nvidia ne s'incrivent pas correctement dans le modèle du support des GPUs dans le noyau (Direct Redering Manager)... cela commence à devenir sérieusement agassant. C'est eux et rien d'autre!
J'ai acheté Quake IV pour GNU/Linux et il faut avoué que leur driver, performant c'est vrai, n'est pas digne de beaucoup de stabilité. Chaque version du driver à ses situations où il freeze le jeu.
Bref... ct pour donner de l'eau au moulin des drivers libres.

Suite...

Posté par Calim' Héros (Jabber id, page perso, ) le 08/12/2005 à 16:39. (lien). Évalué à 8.

octobre 2006, dégouté par le fait que presque personne n'ai vers la nouvelle ABI les developpeur du libre laisse tomber le developpement des drivers.

fevrier 2007, Les multinationnales de la culture et les mouvement securitaires anti-terroristes ont enfin gagné leur combat contre la diffusion numérique de contenu sensible (c'est pas le même selon ou l'on se place sauf pour le cas de se groupe techno-punk qui chante la recette de fabrication d'un EMP) et des solutions dérivées de TCPA/Palladium sont validées.

vingt-six juin 2007, tout les drivers reseau/audio/video sont dans la chaine TCPA/Palladium et l'ordinateur sais ce qu'il vous faut. Plus la peine d'essayer de passer au travers, plus rien ne marche sans... bienvenu dans la matrice...

--
Un petit coup de main, votez pour moi

Activisme ?

Posté par Olivier Guerrier () le 08/12/2005 à 16:41. (lien). Évalué à 2.

Je pense qu'on obtiendra rien en restant polis et gentils. Une solution serait peut-être de se retrouver à quelques centaines devant un grand magasin spécialisé, avec tracts et banderolles, pour informer le public et médiatiser un peu la chose. Avec un message pas uniquement centré sur le support du logiciel libre, mais aussi sur la pérennité des drivers en environnement propriétaire. Peut-être qu'en brûlant quelques $@#%* de cartes wifi devant les caméras...

J'ai les nerfs parce que je suis en plein dedans... J'ai été livré par le père noël avec un peu d'avance, qui m'a gentillement amené un AP et une carte pcmcia wifi. Seul problème, la carte était une linksys (c'est un cadeau, j'ai pas choisi) qui évidemment ne marche pas sous Linux (sauf à utiliser ndiswrapper). Je m'en vais donc échanger ça pour un autre modèle. Je trouve dans les rayons une netgear WG511, je fais bien attention que çe soit une V2 (sur la boite). Arrivé à la maison, pan dans ma gueule, c'est une "made in china" à base de chipset Marvell non supporté :(( résultat, je vais y reretourner lundi, en espérant trouver une carte qui puisse fonctionner en natif. D'ailleurs si vous en connaissez une dans le catalogue de la fnac, je suis preneur.

...

Posté par Matthieu C () le 08/12/2005 à 18:16. (lien). Évalué à 1.


[8] En effet, la correction de la faille de sécurité entraînant un changement d'ABI, il n'est plus possible d'utiliser les pilotes binaires: il faut attendre que le constructeur publie une nouvelle version de son pilote. Aujourd'hui, les utilisateurs de routeurs personnels Linksys WRT54 ne peuvent pas migrer leur petite machine vers le noyau 2.6: ils sont bloqués, car le pilote Wifi Broadcom 43xx n'est disponible qu'en module binaire pour le noyau 2.4. Heureusement deux équipes de fous très compétentes se sont lancées dans la rétro-ingénierie du pilote binaire avec des résultats intéressants, mais est-ce véritablement une solution viable ?
C'est absolument faux.

Les nouveaux version Linux livré par broadcom tourne sur du linux 2.6.
Si tu regarde par exemple les source de l'alicebox [1], tu veras que c'est un beau 2.6.8 ...

Secondo, il n'y a pas que le driver wifi qui est binnaire, mais aussi certains truc pour l'ethernet, voir l'adsl...

[1] ftp://ftp.gpl-devices.org/pub/vendors/Hitachi/AH4021/AH4021-(...)

Pilotes ndiswrapper

Posté par Jésus Christ (page perso, ) le 08/12/2005 à 20:06. (lien). Évalué à 1.

C'est pour une fois un super article ;)

J'espère que ca fera comprendre à pas mal de gens qui utilisent des drivers proprios et qui souhaitent leur intégration dans le noyau linux qu'il est grand temps d'arrêter de déconner.

J'ai été assez embêté que dernièrement les pilotes ipw2200 soit inclus dans le noyau. Bien qu'ils soient libres, ils contribuent à un relachement sur la politique d'inclusion d'un pilote dans l'arbre officiel du noyau, du fait de la possibilité de charger un firmware proprio.

Il faut absolument que l'installation de drivers propriétaire soit marginalisée en particulier pour les matériels grand public. Il faut au maximum promouvoir un projet libre visant à créer un pilote libre pour un matériel qui n'en dispose pas ou dispose d'un driver propriétaire. C'est par exemple ce que fait Xorg lorsque que l'on sait que la prochaine version permettera l'utilisation de pilotes libre (avec 3d) pour certains cartes ATI jusque là uniquement disponibles avec le driver propriétaire.

Soyons clair, les pilotes proprios soit, mais pas dans les projets libres. Et puisque pour la plupart d'entre nous, nous sommes sensibles à la promotions des logiciels libres, restons intègres et vigilants, en veillant par exemple à acheter du matériel qui fonctionne avec des drivers libres.

Du matériel libre?

Posté par godzom () le 09/12/2005 à 11:42. (lien). Évalué à 4.

Il existe des projets de matériel libres, cela semble utopique, mais certains y croient.
Je tiens à signaler tout particulièrement, le projet OpenGraphics (http://www.opengraphics.com), ceux d'entre vous qui ont lu le GLMF d'avril savent de quoi je parle.
Je pense que ce genre d'initiatives pourraient (en cas de succès) aider les contructeurs à réfléchir.

specs de la carte graphique :OpenGraphics (http://www.opengraphics.gitk.com/open_graphics_spec.pdf)

[+] esfedq

Posté par TImaniac (Jabber id, page perso, ) le 09/12/2005 à 11:45. (lien). Évalué à -1.

Il est impossible de mettre à jour son noyau si le constructeur n'a pas sorti de nouvelle version de son pilote.
Qu'il y est des incompatibilités entre versions majeures oui, qu'il y est une impossibilité d'upgrader au noyau 2.6.14 depuis 1.6.12, c'est une abberation, une mauvaise architecture du noyau Linux, ou en tout cas de très mauvais choix d'évolution.
Sous Windows, on peut utiliser aujourd'hui des pilotes prévus pour marcher sous win2000 il y a 5 ans.
Bref le problème c'est Linux, pas le pilote.

Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau
Là encore je ne suis pas du tout d'accord.
Au lieu de changer d'interface toutes les semaines, qui est une une perte de temps continuelle pour les mainteneurs de pilotes, il faudrait mieux justement bien les concevoir et les figer. C'est le rôle même d'une interface : être pérenne dans le temps. Evolution nécessaire ? Changer d'interface. Et si possible garder la compatibilité avec l'ancienne.

Sinon je suis pas pour les pilotes binaires, mais pour d'autres raisons : c'est pas des logiciels libres tout simplement.

attention danger...linux pourait disparaitre

Posté par tuks () le 29/12/2005 à 20:03. (lien). Évalué à 1.

http://en.wikipedia.org/wiki/SCO-Linux_controversies
on voit bien jusqu'ou va microsoft:
-car il vont jusqu'a faire cela
-car ils ont depenses enormement d'argent

bon...sachant que ca a pas marche et que linux pose un enorme probleme a microsoft...que fait microsoft?...il donne une image plus "open-source" a windows
cela se voit par plusieurs facteurs:
-integration de SFU(service) dans les prochains windows et deja integre dans le sp2 de windows server 2003
-channel 9 http://channel9.msdn.com/ est une comunautee autour de microsoft avec les devellopeurs et les uttilisateurs dont le logiciel wiki a ete mis en open-source http://en.wikipedia.org/wiki/Channel9#Wiki

disons que windows devient uttilisable avec les anti-virus,anti-spyware et les firewall contenus par default dans windows...
le probleme se pose alors pour un uttilisateur:choisirt entre:
-windows:un unix closed source
-linux un unix closed source(a cause de tout ces drivers closed source...)
windows etant bien compatible avec le hardware et as le subsystem win32...vers quoi les uttilisateurs se tourneront ils?

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.5939s (dont 0.0751 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !