Articles précédents : Articles
- [18] Création de la fondation MapServer
- [33] Support des chipsets bcm-43xx
- [62] Dépêche numéro 20 000
- [137] Pétition EUCD.info « Non au projet de loi DADVSI ! »
- [22] Firefox et DADVSI dans Le Monde
- [47] Les Européens de l'année sont...
- [52] Les nouvelles puces Wifi Prism54 maintenant supportées sous Linux et FreeBSD
- [68] Migrations vers l'open source: pourquoi se taire ?
- [35] TomTom, fabricant de GPS, contribue au libre
- [11] Nouvelle version de Tuxpaint: 0.9.15
Liens connexes
- Linux dans un monde binaire, une hypothéthique débâcle (741 hits)
- Stable API: Non-sense (445 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Pilotes binaires dans Linux: quel est le problème ?
Posté par Thomas Petazzoni (page perso, ). Modéré le 08 décembre 2005.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.
Linux dans un monde binaire, une hypothéthique débâcle (741 hits)
Stable API: Non-sense (445 hits)
> Lire la suite (200 commentaires, moyenne: 3). [dépêche : 14531 caractères]
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.
C'est parti ..
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.
-
[^]Re: C'est parti ..
Posté par huz () le 08/12/2005 à 07:45. (lien). Évalué à 7.<troll inside>
Le but de Linux c'est d'avoir un système d'exploitation libre, pas gratuit.
Non - ça s'est le but du GNU
</troll inside>-
[+] [^]Re: C'est parti ..
Posté par izulium (page perso, ) le 08/12/2005 à 09:44. (lien). Évalué à -6.<troll is out>
Pourquoi tu ne dis pas "Gnu\Linux" ?
Je ne vois que des distributions Gnu\Linux ... De plus, GNU est un projet regroupant d'autres projets. Je pense que "Linux" ne devrait pas s'appeler "Linux" mais "Gnu".
Je souhaite rajouter que Linux est publie sous la license GNU "GPL" et qu'il a donc pour but de fournir un kernel libre, modifiable ...
</troll is out>
IzuliuM ;)-
[^]Re: C'est parti ..
Posté par Sebastien Binet () le 08/12/2005 à 10:03. (lien). Évalué à 10.Halala...
Un si joli troll, concocté, mitonné avec amour...
Et paf, c'est le drame: un back-slash à la place d'un simple slash, et ça fout tout par terre. (sans parler des majuscules ;) )
Pour futures references: GNU/Linux :)
-
[^]Re: deja pris
Posté par GTof (Jabber id, ) le 08/12/2005 à 13:37. (lien). Évalué à 5.
"Linux" ne devrait pas s'appeler "Linux" mais "Gnu".
1 - Le système "Gnu" existe déjà et utilise le Hurd
2 - Linux à débuté indépendemment du projet GNU et n'est pas un projet GNU.-
[+] [^]Re: deja pris
Posté par kolter (page perso, ) le 08/12/2005 à 14:43. (lien). Évalué à -2."indépendemment" ???
le jeune Linus utilisais gcc et minix pour développer son petit noyau monolithique. et GCC c'est GNU !
M.-
[^]Re: deja pris
Posté par Krunch (Jabber id, page perso, ) le 08/12/2005 à 18:35. (lien). Évalué à 9.J'utilise GCC pour compiler mes programmes C, ça en fait pas des programmes GNU. Linux est indépendant de GCC dans le sens où n'importe quel compilateur C est censé pouvoir compiler Linux.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: deja pris
-
[^]Re: deja pris
Posté par Brice Arnould ( un_brice ) (page perso, ) le 09/12/2005 à 21:20. (lien). Évalué à 7.Linux est indépendant de GCC dans le sens où n'importe quel compilateur C est censé pouvoir compiler Linux.
Non, uniquement gcc. C'est écrit noir sur blanc dans le README à la racine des sources.
Et à d'autres endroits qu'il ne liront pas les rapports de bugs fait avec d'autres compilateurs.
Alors bon, en pratique ça marche avec d'autres, mais c'est pas plus un objectif que le support des pilotes binaires.--
Respect à RMS.-
[^]Re: deja pris
Posté par boris (page perso, ) le 11/12/2005 à 02:31. (lien). Évalué à 1.Je ne sais pas si "ça marche avec d'autres", il y a beaucoup de "trucs" spécifiques à GCC dans le code du noyau.
-
[^]Re: deja pris
Posté par Krunch (Jabber id, page perso, ) le 11/12/2005 à 10:12. (lien). Évalué à 2.Apparement c'est au moins compatible avec TCC.
https://linuxfr.org/2004/10/27/17522.html--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
-
[^]Re: deja pris
-
-
[^]Re: deja pris
Posté par Brice Arnould ( un_brice ) (page perso, ) le 09/12/2005 à 21:15. (lien). Évalué à 4.Linux à débuté indépendemment du projet GNU et n'est pas un projet GNU.
Je ne pense pas que Linus aurait inventé la GPL. Il était déjà pas bien chaud pour ouvrir son code à la base... (cf sa bio)
C'est un fan de la FSF qui lui a ouvert les yeux.
De plus les développeurs Linux ont mis dans leurs prérequis GCC>2.95.3 et GNU Make>3.79.1.
Sur d'autres compilateurs/make les rapports de bugs sont ignorés.
C'est quand même une reconnaissance officielle.--
Respect à RMS.-
[^]Re: deja pris
Posté par gnap gnap (page perso, ) le 16/12/2005 à 09:58. (lien). Évalué à 2.Linus n'aurait pas inventé la GPL.
Ceci dit, s'il a choisi la GPL, c'est pour faire un logiciel gratuit mais un logiciel libre. On ne peut pas prétendre qu'il ait voulu faire un logiciel gratuit puisque nulle part dans sa licence il n'est dit que linux est gratuit.
-
-
-
-
[^]Re: C'est parti ..
Posté par littletux (page perso, ) le 08/12/2005 à 19:40. (lien). Évalué à 5.Ce troll là il, je ne peux pas résister:
Tu vas pas nous faire chier, c'est un des buts de GNU/Linux ;)
C'est plus clair comme ça ?
-
-
[^]Re: C'est parti ..
Posté par Laurent Godard () le 08/12/2005 à 09:03. (lien). Évalué à 1... ne vont pas faire l'effort de les porter sur d'autres architectures si ça ne génère pas de ventes significatives.
En liberant les specs, ils pourraient avoir des ventes supplementaires
Peut etre pas significatives mais un sou est un sou, non ?
Ils auraient alors acces pour presque rien à un marché qu'il nauraient pas eu autrement. Et le boulot serait fait par la communauté
Ce n'est pas envisageable de liberer pour une architecture/os donné (ils peuvent se garder le win32 si ils veulent) ? Celà restreint la liberté mais serait un pas dans la bonne direction
laurent-
[^]Re: C'est parti ..
Posté par Julien CARTIGNY (page perso, ) le 08/12/2005 à 10:56. (lien). Évalué à 5.Problème: les entreprises ne veulent ni libérer les specs, ni faire une version source de leur(s) driver(s) pour des raisons de propriétés intelectuelles:
- soit le source possède une nouvelle technologie que les entreprises ne voudraient pas diffuser à leur(s) concurent(s) [peu probable: les nouvelles technologies des constructeurs sont plutôt présentes au niveau hardware]
- soit le source utilise des technologies brevetés par d'autres sociétés [plus probable: l'industirel préfere obscurcir que laisser en clair une preuve flagrante de l'utilisation d'un brevet]
Finalement, on en revient toujours aux brevets.--
"Nobody expects the spanish inquisition"-
[^]Re: C'est parti ..
Posté par -=[ Benoit Plessis ]=- (page perso, ) le 08/12/2005 à 12:32. (lien). Évalué à 5.- soit le source possède une nouvelle technologie que les entreprises ne voudraient pas diffuser à leur(s) concurent(s) [peu probable: les nouvelles technologies des constructeurs sont plutôt présentes au niveau hardware]
Au contraire c'est la l'erreur commune a bcp de gens, une majoritée de puces 'dédiés' ne le sont pas vraiment cela a commencé avec les winmodem & co => la puce ne fait pas tout le boulot (notamment les puces audio et video) c'est le driver qui en gere une tres grosse part.
Et la ca coince parce que la lutte entre ATI & Nvidia par exemple ce joue énormement sur les drivers et leurs perfs.
Alors les rendres open-sources ....--
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libr-
[^]Re: C'est parti ..
Posté par Will Hunting () le 08/12/2005 à 22:17. (lien). Évalué à 3.Et la ca coince parce que la lutte entre ATI & Nvidia par exemple ce joue énormement sur les drivers et leurs perfs.
Surtout les drivers "optimisés" pour les benchmarks comme le 3DMarks & Co. 20 Mo (ou +) pour un driver de carte vidéo, ça semble un minimum désormais (sous Windows en tout cas, c'est moins sous Linux). Quand à savoir ce qu'il y a dans ces drivers...-
[^]Re: C'est parti ..
Posté par Rin Jin (page perso, ) le 09/12/2005 à 08:00. (lien). Évalué à 4.Pour beaucoup de driver, mais ça installe en sus une tonne de logiciels "indispensables pour profiter des fonctions évoluées de votre carte machin2000" c'est à dire, dans le cas d'une carte son, un logiciel de réglage du son lourd, peu réactif et plein d'options inutiles.
--
"On obtient plus de chose en étant poli et armé qu'en étant juste poli" Al Capone
-
-
[^]Re: C'est parti ..
Posté par Julien () le 09/12/2005 à 22:30. (lien). Évalué à 5.Dans le cas de ce genre de pilotes (ceux où "c'est le driver qui en gere une tres grosse part [du boulot]") si la couche d'adaptation (glue) est bien faite, je suis près à faire des concessions dans mes revendications libristes.
Prenons le cas du driver nvidia. Essayons de ne plus penser en terme d'opposition matériel/logiciel. Il y a donc une couche supérieure, connectée au noyau, qui est libre et tout ce qui est plus bas niveau est propriétaire (logiciel et matériel). J'ai même cru comprendre que cette couche bas niveau était à peu près la même sous linux ou windows.
Il n'existe presque aucun matériel libre, et personne ne crie au scandale. En quoi cette couche de logiciel est-elle intrinsèquement différente ?
Ce que nous demandons, ce sont les spécifications du matériel. Et si c'est l'interface de cette couche logicielle qu'on nous fournit, comment doit on réagir ?
Le véritable problème réside dans le deuxième type de pilotes. Ceux qui sont distribués sous formes de binaires adaptés à une seule distribution. Ceux là devraient être évités à tout prix. Mais les utilisateurs de ces pilotes sont bien souvent des entreprises qui ont choisi linux uniquement par pragmatisme, pas du tout par amour du libre.
Les distributions pour lesquelles ces pilotes sont écris on en plus un avantage par rapport aux concurrents. Ça ne va pas les pousser à crier au scandale. Et même, ces distributions emploient bon nombre de développeurs noyau qui vont, eux aussi, avoir un jugement biaisé.
Tout ça ne fait pas de nvidia le bon samaritain du libre, mais sachons établir des priorités dans notre recherche de liberté.-
[^]Re: C'est parti ..
Posté par wahnby () le 10/12/2005 à 13:19. (lien). Évalué à 3.Alors peut etre que je me trompe mais la fameuse couche glue de nvidia dans le noyeau linux est opensource (forcément sinon ça peut pas marché avec tout les noyeau) mais pas du tout libre!
Ensuite le problème d'avoir une couche pas libre ou que ce soit c'est qu'on ne peut pas faire evoluer le système. exemple si on décide d'utiliser plutot directfb que x.org a partir de demain il faudras atendre que nvidia fasse des pilotes une nouvelle couche glue et tout.
En tout cas moi mon avis c'est de ne pas faire de concession, il faut rester libre meme si ça doit ralentir la propagation de linux. je prefaire que linux soit moins utilisé mais propre plutot que répandu mais tainted dans tous les sens. Ne passont pas du coté obscur pour plus de pouvoir.-
[+] [^]Re: C'est parti ..
Posté par Julien () le 12/12/2005 à 01:41. (lien). Évalué à -1.Alors peut etre que je me trompe mais la fameuse couche glue de nvidia dans le noyeau linux est opensource (forcément sinon ça peut pas marché avec tout les noyeau) mais pas du tout libre!
je pensais que cette couche avait été modifiée pour fonctionner avec les noyaux 2.6 par exemple quand ils n'étaient pas supportés par nvidia.
Je ne suis pas du tout sur de moi, passons sur ce "détail".
Ensuite le problème d'avoir une couche pas libre ou que ce soit c'est qu'on ne peut pas faire evoluer le système. exemple si on décide d'utiliser plutot directfb que x.org a partir de demain il faudras atendre que nvidia fasse des pilotes une nouvelle couche glue et tout.
Biens sur, mais continuons dans mon analogie en considérant cette surcouche logicielle comme une extension du matériel. Si j'achète un modem, je ne peux pas l'utiliser comme répondeur téléphonique. Je me limite par rapport à un winmodem, mais personne ne vient se plaindre, au contraire. On se simplifie la vie avec des primitives plus haut niveau, mais on diminue les possibilités, c'est certain.
En tout cas moi mon avis c'est de ne pas faire de concession, il faut rester libre meme si ça doit ralentir la propagation de linux. je prefaire que linux soit moins utilisé mais propre plutot que répandu mais tainted dans tous les sens. Ne passont pas du coté obscur pour plus de pouvoir.
Quelles belles paroles, je pense qu'à peu près tout le monde ici est d'accord avec toi.
Cependant, quand il s'agit de mettre ces paroles en application, les choses se corsent.
Il existe des systèmes qui ont toujours été plus rigoureux sur l'application du libre que linux. Je pense notament à GNU. Es-tu pour autant un utilisateur du Hurd ?
Meme parmis les distributions linux, certaines sont plus rigoureuses, par exemple debian, mais celle-ci perd des utilisateurs au profit d'autres, telle qu'ubuntu.
Quel est le problème ? Tout simplement, plus de rigueur signifie moins de performances, moins de performances, moins d'utilisateurs, moins d'utilisateurs, moins de contributeurs, moins de contributeurs, moins de performances ... C'est un cercle vicieux.-
[^]Re: C'est parti ..
Posté par wahnby () le 12/12/2005 à 16:50. (lien). Évalué à 3.
Biens sur, mais continuons dans mon analogie en considérant cette surcouche logicielle comme une extension du matériel. Si j'achète un modem, je ne peux pas l'utiliser comme répondeur téléphonique. Je me limite par rapport à un winmodem, mais personne ne vient se plaindre, au contraire. On se simplifie la vie avec des primitives plus haut niveau, mais on diminue les possibilités, c'est certain.
je comprend pas vraiment ou tu veut en venir mais en fait tout est question de frontière a mon avis. Les pilotes c'est notre coté, le firmware c'est le leur, si on a des drivers proprio la frontière recule on nous mange notre téritoire on perd . si on a des firmwares libres la frontière avance on gagne ! alors avec le materiel libre la c'est carrement victoire totale. maintenant la limite avec les pilotes chez nous c'est a mon avis la solution minimum, peut etre bientot avec l'arrivé des nouvelles cartes XGI on aura des cartes graphique bien avec des pilotes libres qui peut savoir.
ensuite les winmodem peuvent marché sous nux si y'a les spec qui sont distribué.
Quelles belles paroles, je pense qu'à peu près tout le monde ici est d'accord avec toi.
Cependant, quand il s'agit de mettre ces paroles en application, les choses se corsent.
Il existe des systèmes qui ont toujours été plus rigoureux sur l'application du libre que linux. Je pense notament à GNU. Es-tu pour autant un utilisateur du Hurd ?
Meme parmis les distributions linux, certaines sont plus rigoureuses, par exemple debian, mais celle-ci perd des utilisateurs au profit d'autres, telle qu'ubuntu.
Quel est le problème ? Tout simplement, plus de rigueur signifie moins de performances, moins de performances, moins d'utilisateurs, moins d'utilisateurs, moins de contributeurs, moins de contributeurs, moins de performances ... C'est un cercle vicieux.
alors je crois pas que ubuntu utilise du logiciel proprio mais peut etre je me trompe et ensuite son succé est a mon avis plutot du au fait que c'est simple a installer, 2 3 menus puis boom un bureau gnome tout pret...
enuite la rigueur c'est pas une question de système, je crois pas avoir de logiciels proprio sur le mien, en tout cas j'ai ni drivers proprio ni flash kipuképalibre et je suis pas sur qu'on puisse en dire autant de tout le monde même ici (je m'envois pas de roses hein, c'est ma philosophie c'est tout).
Le problème avec les concession c'est qu'on fini sous windows genre : "ouai j'adore linux le libre tout ça mais je suis sous windows parce que y'a le jeu machinchose qui marche que avec ie sous window"
-
-
-
[^]Le risque n'est pas le même
Posté par Arthur Accroc () le 10/12/2005 à 13:27. (lien). Évalué à 6.En quoi cette couche de logiciel est-elle intrinsèquement différente ?
Elle ne fonctionne pas sur le périphérique, comme un firmware, mais sur le processeur central, en mode noyau.
Ça lui ouvre nettement plus de possibilités pour planter le système ou contenir du code malicieux sans qu'on le sache...
Même en espérant que nVidia n'est pas un autre Sony, comme tout fabriquant de carte 3D, ils programment leurs drivers pour la performance (pour impressionner plus que le concurrent), en dépit de toute autre considération. Confronté à ce problème Microsoft a mis en place il y a plusieurs années un programme de certification des drivers pour obliger les fabriquants de matériel à faire des drivers potables qui ne plantent pas (plus ;-) ) Windows; sous Linux, ils peuvent à nouveau "se lâcher" et je suis convaincu qu'ils le font.
Exemple : j'ai installé une fois (!) un driver nVidia propriétaire (pas sur ma machine et encore moins sur un serveur, et c'était ça, le driver VESA, ou la mise-à-jour d'XFree, voire de la distrib), ça marchait super bien... jusqu'à ce que l'APM ou l'ACPI se déclenche. Là, freeze complet du système. Efficace.
Avoir une architecture à micronoyau où les pilotes tourneraient en mode non privilégié limiterait déjà beaucoup le risque, en échange d'une certaine perte de performances.
Andrew Tannenbaum considère que le jeu en vaut la chandelle (c'est le genre de trucs qu'il reproche à l'architecture du noyau de Linux), et je serais assez d'accord avec lui si un jour on ne peut éviter d'utiliser ces saletés de drivers binaires.
Cela dit, les considérations sont différentes suivant qu'on utilise sa machine uniquement comme une console de jeux en plus cher, pour stocker ses informations bancaires, ou comme serveur pour le boulot. Mais comprend qu'il y en a qui ont besoin d'un Linux fiable.--
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.-
[^]Re: Le risque n'est pas le même
Posté par wahnby () le 11/12/2005 à 11:50. (lien). Évalué à 1.En tout cas chez ati je peut t'affirmé qu'ils ne se lachent pas sur les drivers pour obtenir une meilleur performance!
-
[^]Re: Le risque n'est pas le même
-
[^]ATI...
Posté par Arthur Accroc () le 13/12/2005 à 00:40. (lien). Évalué à 2.En tout cas chez ati je peut t'affirmé qu'ils ne se lachent pas sur les drivers pour obtenir une meilleur performance!
Ah ?
Je ne suis pas allé assez loin avec les pilotes ATI pour en avoir une idée.
Mon expérience avec ATI se limite à l'essai d'une Mandriva qui m'a installé le pilote ATI propriétaire sans me demander mon avis (alors que j'ai une Radeon 9200 justement parce que c'est l'une des dernières ATI supportées par le pilote libre).
Résultat, dès le premier chargement de X, affichage pourri et gelé (j'admet, j'ai une carte pas ATI à base de chipset ATI, mais il n'est pas dit que le pilote ne supporte que les ATI pur sucre !).
Ensuite, j'ai redémarré en runlevel 3 le temps nettoyer le système du pilote propriétaire et, magie, plus de problème...--
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
-
-
[^]Re: Le risque n'est pas le même
Posté par Julien () le 12/12/2005 à 01:51. (lien). Évalué à 0.Ça lui ouvre nettement plus de possibilités pour planter le système ou contenir du code malicieux sans qu'on le sache...
J'ai du mal à comprendre qu'on puisse faire planter le système plus facilement avec du code qu'avec du matériel.
Une carte mal développée peut endommager ma carte mère, elle peut ne pas tout à fait effectuer ce que lui demande le système, elle peut corrompre la mémoire ...
Je pense par contre que le code est souvent écris plus "à la vas vite" et c'est certainement la raison qui fait qu'on a plus confiance en le matériel.
Mais comprend qu'il y en a qui ont besoin d'un Linux fiable.
Là n'est pas le problème. Je reprend mon argument précédent. Si le logiciel est écrit avec les pieds, ton linux n'est pas fiable, mais si le matériel a une erreur de conception, ton serveur risque encore plus ...
Certes, l'une des raisons qui pousse pas mal de monde à refuser d'utiliser les pilotes propriétaires est leur réputation d'instabilité.
Je pense que c'est se tromper de bataille. Le vrai problème est de garder une alternative libre.
Si la fiabilité est la préoccupation numéro un, il existe des unices propriétaires qui font très bien leur travail.-
[^]Re: Le risque n'est pas le même
Posté par Arthur Accroc () le 13/12/2005 à 00:32. (lien). Évalué à 5.Je pense par contre que le code est souvent écris plus "à la vas vite" et c'est certainement la raison qui fait qu'on a plus confiance en le matériel.
Certainement, en tout cas dans le cas des fabriquants de périphériques.
On peut facilement trouver un matériel qu'on considère comme étant d'une certaine qualité. Pour un pilote propriétaire, il faut bien prendre celui fourni par le constructeur, et si l'on se pose avant la question de choisir un matériel fourni avec un pilote propriétaire de qualité, là, on ne trouve pas grand chose...
Peut-être aussi est-ce qu'on se dit qu'un problème matériel se manifeste généralement assez vite et que si cela a fonctionné correctement pendant un certain temps, c'est que ça doit être bon.
À part cela, on peut aussi, notamment sur un serveur, utiliser du RAID si l'on n'a pas confiance dans les disques, utiliser de la mémoire ECC... Du côté des pilotes, je n'en vois pas trop qui comprennent un système pour rattrapper leur éventuelle défaillance.
Si la fiabilité est la préoccupation numéro un, il existe des unices propriétaires qui font très bien leur travail.
Si l'on ne considère que la fiabilité technique, en effet. En particulier, sur les Unix propriétaires, les pilotes ne sont généralement pas écrit par le fabriquant des périphériques, mais par le vendeur du système. Du coup, il y a moins de pilotes, peut-être moins performants, mais plus fiables.
Cependant, si l'on considère dans la fiabilité l'assurance de ne pas avoir de backdoor dans le système, on n'est pas très avancé avec un Unix entièrement propriétaire...
D'ailleurs, la différence importante, entre le matériel et le logiciel, se situe justement dans ce domaine. Si l'on se pose les questions, pour être caricatural, "Est-ce que ma carte réseau ne laisserait pas des fois la NSA accéder à ma machine comme elle veut ?" et "Est-ce que le pilote propriétaire de ma carte réseau ne laisserait pas des fois la NSA accéder à ma machine comme elle veut ?", il est plus difficile pour le firmware qui tourne sur le chip intégré à la carte d'aller prendre le contrôle du noyau que pour le pilote qui est déjà exécuté sur le CPU en mode privilégié...--
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.-
[+] [^]Re: Le risque n'est pas le même
Posté par Julien () le 13/12/2005 à 14:45. (lien). Évalué à -1.il est plus difficile pour le firmware qui tourne sur le chip intégré à la carte d'aller prendre le contrôle du noyau que pour le pilote qui est déjà exécuté sur le CPU en mode privilégié...
J'avais entendu parler d'ordinateurs portables auxquels on avait greffé une simple petite mémoire entre le clavier et le reste.
Dans ces conditions, meme avec le système logiciel le plus libre du monde, il est relativement simple pour le SAV de récupérer tes mots de passe et données sensibles.
Attention, une fois de plus, je ne fais pas l'apologie du propriétaire ("de toute façon, on peut récupérer mes mots de passe meme sous linux, autant repasser sous windows")
Je ne fais que dire : concentrons nous sur le plus urgent, les pilotes propriétaires qui reposent sur une ABI fixe. Le reste viendra après.
-
-
-
-
-
-
[^]Re: C'est parti ..
Posté par littletux (page perso, ) le 08/12/2005 à 20:01. (lien). Évalué à 3.
- soit le source utilise des technologies brevetés par d'autres sociétés [plus probable: l'industirel préfere obscurcir que laisser en clair une preuve flagrante de l'utilisation d'un brevet]
Finalement, on en revient toujours aux brevets.
Cette "peur des représailles" n'existait pas du temps où Microsoft s'est créée, on peut difficilement dire le contraire !
Aujourd'hui, alors que les logiciels libres libres gagnent toujours et encore en part de marché sur les serveurs et plus récemment les clients, les constructeurs ne veulent pas pas fournir de pilotes libres ?!?
Mauvais fournisseur, changer de fournisseur !
Et surtout, l'informer personnellement (quelques mails peuvent suffire) de pourquoi il PUE !
Et pour finir, putain de brevets logiciels de m****...
Eh ben non j'ai pas encore fini (dommage, hein ?), n'oubliez pas de signer la pétition d'eucd.info contre le projet de loi DADVSI : http://eucd.info/petitions/index.php?petition=2 .
A peluche !
-
-
-
[^]Re: C'est parti ..
Posté par zaxxon () le 08/12/2005 à 09:23. (lien). Évalué à 1.d'accord de plus je ne vois pas en quoi donner des specifications de materiel peut gener un constructeur ( a croire que les concurrents ne savent pas faire du reverse ingenering ) a moins que les construteurs se livrent a quelques magouilles peut avouables ( on gomfle un peut les perfs avec un petit overclocking !!! ).
perso j'en ai marre des pilotes prives qui ne marchent pas ( exemples ati ) j'ai l'impression d'etre revenu en 95 quand linux etait tout jeune et que les cartes n'etaient pas encore bien supportees.
cela rappelle la jeunesse mais qu'est que c'est gonflant !
ps : j'ai toujours pas d'acceleration avec les pilotes ati (merci ati de pondre plus vite des cartes et pas de drivers qui tiennent la route!!!)-
[^]Re: C'est parti ..
Posté par Toufou (page perso, ) le 08/12/2005 à 12:48. (lien). Évalué à 3.de plus je ne vois pas en quoi donner des specifications de materiel peut gener un constructeur
d'apres le boss d'HP France, en ce qui concerne le WIFI c'est pour des histoires de certification : http://linuxfr.org/2005/08/31/19501.html . Moi ça me laisse réveur une argumentation pareille.-
[+] [^]Re: C'est parti ..
Posté par Nicolas () le 08/12/2005 à 14:29. (lien). Évalué à -4.ouhais et des problemes d'acces de disque dur sous windows et linux (le disque bougeait physiquement et se decrochait des slots) c'est formatage et reinstallation de windows pour HP alros le niveau technique des gars de chez HP ca laisse reveur...
-
-
-
[+] [^]Re: C'est parti ..
Posté par wahnby () le 09/12/2005 à 10:38. (lien). Évalué à -5.A mon avis il faudrai interdire les pilotes non libres puisque a priori c'est lié du code gpl avec du non gpl et a ma connaissance (mais peut etre il y a des details qu je ne connais pas) c'est interdit! ensuite on pourait faire un nouveau système pour l'affichage ou les pilotes graphique sont entièrement dans le noyau (a leur place quoi) comme ça on se débarasse des drivers proprio ati (pourri) et nvidia et en plus on se débarasse du serveur X (usine a gaz), double avantage donc.
-
[^]Re: C'est parti ..
-
OpenBSD
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
-
[^]Re: OpenBSD
Posté par Jean Parpaillon (Jabber id, page perso, ) le 08/12/2005 à 10:30. (lien). Évalué à 10.Il me semble que c'est la seule démarche utile. Linux "souffre" d'être utilisé en majorité sur plateforme i386 et c'est peut-être pour ça que beaucoup d'utilisateurs ne voit pas le problème de logiciels closed-source pour Linux, que ça soit pour les drivers ou, par exemple, flash, acrobat reader, etc...
Mais ceux qui ont essayé Linux sur machine Apple ont déjà plus de difficulté. Et les innombrables portages des *BSD ne peuvent effectivement pas se satisfaire d'une telle situation.-
[^]Re: OpenBSD
Posté par gnumdk (page perso, ) le 08/12/2005 à 11:54. (lien). Évalué à 1.Ben, y'a aussi le fait que les gens utilisent ce qu'il faut pour faire fonctionner leur machine.
Sur mon portable et sur mon pc chez moi, j'ai les drivers Nvidia, pourquoi? Parce que il offre quand meme pas mal de chose au niveau accélération 2D par rapport au driver nv.
Y'a un an, j'ai acheté une carte ATI Radeon 7500(bien supporté par le driver dri) histoire de me débarrasser de ma carte nvidia, résultat, ca ne fonctionne pas sur mon écran, j'ai un affichage flou(police qui bave) et bien sur, c'est pas un probleme de conf, ca ne le fait qu'avec mon Ecran :(
Résultat, bah j'ai tjs les driver nvidia sur ma machine :(
-
-
[^]Re: OpenBSD
Posté par Julien CARTIGNY (page perso, ) le 08/12/2005 à 11:00. (lien). Évalué à 3.Le problème, c'est l'alternative: dans le monde de la 3D par exemple, à part Nvidia et Ati il n'y a pas grand chose (d'où l'existence d'ailleurs d'un projet de carte graphique libre). Il faudrait vraiment que les parts de marchés s'érodent sérieusement avant qu'une entreprise réagisse.
Le meilleur vecteur d'attaque pour une réelle ouverture n'est _pas_ le monde du desktop et de l'utilisateur lambda malheureusement. Les gens veulent que ça marche et une grande partie de la population linuxienne n'est pas sensibilisé à cette question ("faut que ça marche, c'est tout"). C'est du côté serveur, avec des controleurs raids ou des cartes réseaux que ça changera.--
"Nobody expects the spanish inquisition"-
[^]Re: OpenBSD
Posté par Miair Patreau () le 08/12/2005 à 13:43. (lien). Évalué à 2.Ben, justement.
Ça "marche [beaucoup mieux], c'est tout" avec des drivers libres que proprios qu'il faut aller télécharger, exécuter le prog fourni, faire gaffe à sa gestion des biblios openGL si on compte changer de carte graphique plus tard...
Maintenant que je suis un peu plus vieux, un peu moins con et un peu plus tolérant, l'un de mes principaux griefs quand je dois installer windows chez quelqu'un, c'est qu'il n'y a pas d'équivalent de Synaptic. Incroyable le temps qu'on perd dans ces stupidités laborieuses de fichiers "setup.exe"
-
Oui, mais que faire ?
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).
Berlin 1936, Moscou 1980, Pékin 2008.
Jeux Olympiques, sponsor officiel de la dictature.
Mexico 1968, Pékin 2008.
Jeux Olympiques, sponsor officiel de la répression.
-
[^]Re: Oui, mais que faire ?
Posté par Thomas Petazzoni (page perso, ) le 08/12/2005 à 07:42. (lien). Évalué à 10.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" ?
C'est déjà le cas. Quand tu charges un module non-libre, un warning est affiché te disant que ton noyau est « tainted ».-
[^]Re: Oui, mais que faire ?
Posté par creak (page perso, ) le 08/12/2005 à 10:12. (lien). Évalué à 5.Je crois bien qu'il pensait à un truc un peu plus voyant. Genre dans la liste des matériels dans GNOME ou KDE, qu'il y ait une petite marque rouge "pilote non libre, risque de faille de sécurité".
Sans dire que ce n'est pas "certifié Linux", ce qui serait trop difficile à mettre en place... OpenSource ne signifie pas forcément que c'est sécurisé, pas pour tous les programmes en tous cas. J'aime bien la notion de "pilote non libre, risque de faille de sécurité", ça montrerait très simplement les risques qu'encourt un utilisateur lorsqu'il installe un pilote binaire, ensuite c'est à ses risques et périls.-
[^]Re: Oui, mais que faire ?
Posté par _flo_ () le 08/12/2005 à 23:04. (lien). Évalué à 4.
OpenSource ne signifie pas forcément que c'est sécurisé, pas pour tous les programmes en tous cas. J'aime bien la notion de "pilote non libre, risque de faille de sécurité", ça montrerait très simplement les risques qu'encourt un utilisateur lorsqu'il installe un pilote binaire, ensuite c'est à ses risques et périls.
Euh... Donc en gros, tu dis que ce n'est pas parce que c'est open source qu'il n'y a pas de faille, mais qu'en face des pilotes closed source on devrait marquer : "risque de faille" en rouge qui clignote? Et pas en face des pilotes open source alors qu'ils ne sont pas exempts de failles, tu le dis toi même?
Donc en somme ça reviendrait à se servir de la peur engendrée chez les utilisateurs "novices" par le signe "faille de sécurité" pour qu'ils fassent le choix que tu aimerais qu'ils fassent.
J'imagine que quand Microsoft ou autre se sert de ce genre de méthodes, tu es le premier à applaudir...
PS: je précise que sur le fond je suis contre une stabilisation de l'ABI et une généralisation des modules binaires, je réagis juste sur la méthode que tu suggères.-
[^]Re: Oui, mais que faire ?
Posté par Mickaël L () le 09/12/2005 à 09:15. (lien). Évalué à 4.Oui, sauf quand il y a un raisonnement cohérent derrière.
Quand une faille de sécurité est annoncée dans le noyau linux, en général, (j'insiste sur le en général), c'est corrigé plutôt vite.
Quand nvidia ou ati sort un nouveau pilote tous les 4 mois, tu es content. Et en plus pas un mot sur les failles corrigées.
-
[^]Re: Oui, mais que faire ?
Posté par Olivier (page perso, ) le 09/12/2005 à 10:04. (lien). Évalué à 3.J'imagine que quand Microsoft ou autre se sert de ce genre de méthodes, tu es le premier à applaudir...
Microsoft fait déjà quelque chose de similaire. Lorsque tu installes un driver qui n'est pas "certifié Microsoft", tu as une belle boîte de dialogue (avec un icone de "warning" jaune) qui te dit que tu risques des problèmes d'instabilité, du fait que ces drivers n'a pas été testé par les laboratoires MS.
-
-
-
-
[^]Re: Oui, mais que faire ?
Posté par creak (page perso, ) le 08/12/2005 à 10:22. (lien). Évalué à 9.
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é).
Ce n'est pas une parole en l'air, qui serait partant pour mettre en place un Wiki pour lister pilotes et matériels comptible Linux.
Principe simple, une page par matériel et une page par pilote... Ensuite des pages de conseils et de sommaire pour rassembler le tout.
On listerait ainsi les avantages et les inconvénients de chacun des composant. On pourrait aussi proposer des confs de PC pour tous type d'utilisateur: Joueur, Serveur, Bureau...
J'ai un hébergement, si des gens sont motivés, je veux bien mettre ça en place avec eux!-
[^]Re: Oui, mais que faire ?
Posté par baud123 (Jabber id, page perso, ) le 08/12/2005 à 12:02. (lien). Évalué à 7.comme http://dev.librehwdb.tuxfamily.org ? ;-) si tu es compétent en php / postgresql ou mysql, je te propose de pousser plus loin avec une base de données plutôt.
Sachant que le wiki dont tu parles existe déjà avec
http://www.linuxquestions.org/hcl/index.php
et http://wiki.linuxquestions.org/wiki/Hardware_TOC-
[^]Re: Oui, mais que faire ?
Posté par creak (page perso, ) le 08/12/2005 à 13:45. (lien). Évalué à 3.je te propose de pousser plus loin avec une base de données plutôt
Je comprend pas le sens de ta phrase... Un wiki c'est déjà de la base de données :-|
Pour les autres Wiki... Ils sont pas ce qu'il y a de plus simple à utiliser...-
[^]Re: Oui, mais que faire ?
Posté par baud123 (Jabber id, page perso, ) le 08/12/2005 à 14:30. (lien). Évalué à 4.ok, précision : base de données *relationnelle*
permettant d'avoir des champs identifiés plutôt qu'un format flou "à la wiki" permettant difficilement de faire des requêtes SQL...-
[^]Re: Oui, mais que faire ?
Posté par wahnby () le 08/12/2005 à 21:08. (lien). Évalué à 2.Alors la je suis 100% d'accord puisque chaque fois que je veut acheter du materiel ça me prend moulte temp pour savoir si oui ou non il est compatible. Mais il faudrai, a mon avis, un site international et il faudrai réussire a le faire connaitre. En fait il faudrais qu'il ai l'air "officiel" . Je suis sur qu'il y a plein de projet comme ça qui existe mais qui sont totalement inconu.
-
[^]Re: Oui, mais que faire ?
Posté par Will Hunting () le 08/12/2005 à 22:32. (lien). Évalué à 2.Comme http://www.compatiblelinux.org/ (à ne pas confondre avec http://www.linuxcompatible.org/ !) ?
-
[^]Re: Oui, mais que faire ?
Posté par wahnby () le 08/12/2005 à 22:58. (lien). Évalué à 3.Oui c'est ça l'idée mais il manque juste que le site soit officiel et qu'il y ai plus d'informations aussi. je voudrais aussi savoir si les drivers sont binaires ou source, spec dispo ou reverse engineering et aussi si ça fonctionne c'est pas oui ou non c'est souvent bof. Ma radeon 9550 par exemple elle fonctione oui mais avec les drivers libres, pas de 3D et avec les proprio, deja c'est contre ma philosophie et en plus ils sont merdiques avec des perfs lamentables. Mais sinon ce site est une bonne initiative.
-
-
-
-
-
-
[^]Re: Oui, mais que faire ?
Posté par lilliput (page perso, ) le 08/12/2005 à 17:01. (lien). Évalué à 3.si tu regardes sur le site web knoppix-fr.org tu verras une section hardware.
Fut une époque j'avais essayer de mettre cette base de donnée en commun avec le forum anglais.
Le truc serait de normaliser des fichiers XML, creer un serveur central soap et des api qui vont bien, genre php et tous...
Plus l'outil sera facile a ajouter dans un site web plus l'outil sera interressant.
(le XML permet nottament de gerer la langue et de nombreuse autre possibilité)
Si plus de détails contact mois par mail, c'est vraiment un projet qui m'interesse.
-
[^]Re: Oui, mais que faire ?
Posté par David (page perso, ) le 09/12/2005 à 13:10. (lien). Évalué à 2.Le site http://www.linuxprinting.org a déjà mis en place une base de données concernant les imprimantes.
De plus, une page pour diriger les acheteurs vers du matériel compatible me semble une bonne idée.
Voir http://www.linuxprinting.org/suggested.html.
A+-
[+] [^]Re: Oui, mais que faire ?
Posté par tuks () le 09/12/2005 à 14:39. (lien). Évalué à -1.NON NON ET NON
ce n'est pas la bonne methode
l'uttilisateur lambda qui pose sa config...
bonne methode
-telecharger le kernel
-le decompresser
-aller DANS LES SOURCES...
-et magiquement y'as le nom des cartes du comerce...GENIAL
autres drivers:
prendre les docs ou sources du project et faire pareil...
comme madwifi ou tout ce qui est userspace ou "module built against the kernel"
je propose d'ouviri un NOUVEAU site en faisant appel a tuxfamily par exemple
car le succes des projets sont aussi enormement dus au bon management
prenez react-os par exemple...
les projets precedents ont echoues car ils n'uttilisaient pas la bonne methode et parlementaient trop
moi aussi j'ai eu l'idee de construire une database questionable pour:
-acheter(materiel compatible avec le meilleur driver)
-installer(choisir prosm54 au lieu de ndiswrapper)
-etc...
mais il faut faire qqch face a cette derive...
sinon a quoi bon sert d'avoir linux(par rapport a bsd) si c'est pour avoir tout ces drivers binaires sans avoir d'autres choix...
mais linux a d'enormes avantages:
-bien plus compatible comme pour des projects comme wine
-le mode de developement est du style "contributions"(un utilisateur lambda contribue ou modifie les sources d'un programme et post sa modification au project...)
donc:
-tuxfamily
-fresmeat
-sourceforge(sait pas s'ils ont sucombes aux derives qu'on leur pretait dans le temps...)-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 09/12/2005 à 14:54. (lien). Évalué à 1.ou pourait on parler de la construction d'un tel site qui propose:
-une base de donnee linux/unix
et acessoirement:
-une base de donee distrib afin de promouvoir les drivers libres comme "compatible knoppix et open-source" pour l'acheteur debutant en linux
-des configs linux(beaucoup de personnes ont achetes des ordis linux dans les operations de grand magazins avec des ordis linux a 300 euros...)
-promouvoir les drivers libre non connus/non operationels comme le driver airport extreme en developement en donnant l'etat du devellopement et les HAL libres pour madwifi ou les drivers pour ati radeon(les nouvelles)
le nom du site pourait etre LHCL
linux hardware compatibility list
ca ressemble un peu a l'affaire rootkit de sony...beaucoup de personnes asimilent cela a un virus...alors que ca va jusqu'a espioner TOUT dont email etc...
le probleme des drivers proprietaires est que cela divise les efforts de devellopement car beaucoup se satisfont des drivers binaires...
cela peut a terme tuer linux
a quoi sert de faire tourner linux s'il n'y as pas de support hardware...
il faudrait donc aussi creer une section pour les constructeurs en donnant des arguments(wiki) pour les relases de specifiactions et faire un listing de ceux qui donnent ces specifications et ceux qui refusent de les donner(bah ouais faut bien recompenser ce qui les donnent...)-
[^]Re: Oui, mais que faire ?
Posté par baud123 (Jabber id, page perso, ) le 09/12/2005 à 16:10. (lien). Évalué à 2.comme http://dev.librehwdb.tuxfamily.org en fait :-) (je te recommande de lire aussi les autres commentaires de cette dépêche).
Tu peux t'inscrire sur la ML de librehwdb (en anglais préférentiellement, peu active actuellement) et le wiki peut-être complété soit en anglais, soit en français, tiki-wiki gérant facilement les traductions.
ça te permettra de passer du "il faudrait" à "voilà, ça c'est fait", pas mal de tes arguments demandant à être développés en plus d'une ligne (et argumentés par des faits).-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 09/12/2005 à 19:43. (lien). Évalué à 1.j'aimerai poser une question
sans doute certains sont deja aller fouiller dans les sources pour savoir si un materiel est compatible
est ce que cela est a faire manuelement?
ou semi-manuelement/semi-automatise?
ou totalement automatise en script?
exemple: les drivers pour les clee usb wifi
xconfig
USB ZD1201 based Wireless device support (USB_ZD1201)
type: tristate
prompt: USB ZD1201 based Wireless device support
dep: USB && NET && NET_RADIO
select: FW_LOADER
dep: USB && NET && NET_RADIO
defined at drivers/usb/net/Kconfig:304
Say Y if you want to use wireless LAN adapters based on the ZyDAS
ZD1201 chip.
This driver makes the adapter appear as a normal Ethernet interface,
typically on wlan0.
The zd1201 device requires external firmware to be loaded.
This can be found at http://linux-lc100020.sourceforge.net/
To compile this driver as a module, choose M here: the
module will be called zd1201.
isi on voit:
defined at drivers/usb/net/Kconfig:304
et:
USB_ZD1201 #nom du module
avec le simlink:
/usr/src/linux/drivers/usb/net/
ls
->zd1201,h
->zd1201.c
dans le zd1201.c:
static struct usb_device_id zd1201_table[] = {
{USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
{USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
{USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb adapter */
{USB_DEVICE(0x0db0, 0x6823)}, /* MSI UB11B usb adapter */
{USB_DEVICE(0x1044, 0x8005)}, /* GIGABYTE GN-WLBZ201 usb adapter */
{}
};-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 09/12/2005 à 19:57. (lien). Évalué à 1.dans d'autres cas piix(ich ide chipset)
case PCI_DEVICE_ID_INTEL_82801EB_1:
mode = 3;
break;
/* UDMA 100 capable */
case PCI_DEVICE_ID_INTEL_82801BA_8:
case PCI_DEVICE_ID_INTEL_82801BA_9:
case PCI_DEVICE_ID_INTEL_82801CA_10:
case PCI_DEVICE_ID_INTEL_82801CA_11:
case PCI_DEVICE_ID_INTEL_82801E_11:
case PCI_DEVICE_ID_INTEL_82801DB_1:
case PCI_DEVICE_ID_INTEL_82801DB_10:
case PCI_DEVICE_ID_INTEL_82801DB_11:
case PCI_DEVICE_ID_INTEL_82801EB_11:
case PCI_DEVICE_ID_INTEL_ESB_2:
case PCI_DEVICE_ID_INTEL_ICH6_19:
case PCI_DEVICE_ID_INTEL_ICH7_21:
case PCI_DEVICE_ID_INTEL_ESB2_18:
mode = 3;
break;
/* UDMA 66 capable */
case PCI_DEVICE_ID_INTEL_82801AA_1:
case PCI_DEVICE_ID_INTEL_82372FB_1:
mode = 2;
break;
/* UDMA 33 capable */
case PCI_DEVICE_ID_INTEL_82371AB:
case PCI_DEVICE_ID_INTEL_82443MX_1:
case PCI_DEVICE_ID_INTEL_82451NX:
case PCI_DEVICE_ID_INTEL_82801AB_1:
return 1;
/* Non UDMA capable (MWDMA2) */
case PCI_DEVICE_ID_INTEL_82371SB_1:
case PCI_DEVICE_ID_INTEL_82371FB_1:
case PCI_DEVICE_ID_INTEL_82371FB_0:
case PCI_DEVICE_ID_INTEL_82371MX:
default:
return 0;
}
/*
* If we are UDMA66 capable fall back to UDMA33
* if the drive cannot see an 80pin cable.
*/
if (!eighty_ninty_three(drive))
mode = min(mode, (u8)1);
return mode;
}
et
case PCI_DEVICE_ID_INTEL_82801AA_1: /* ICH */
case PCI_DEVICE_ID_INTEL_82801AB_1: /* ICH0 */
case PCI_DEVICE_ID_INTEL_82801BA_8: /* ICH2 */
case PCI_DEVICE_ID_INTEL_82801BA_9: /* ICH2 */
peut etre qu'il faudrait des lignes standard pour le kernel
un simple script construirait une database
consultable par les downloaders des sources du kernel-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 09/12/2005 à 20:55. (lien). Évalué à 2.et c'est parti
http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Proje(...)-
[^]Re: Oui, mais que faire ?
Posté par baud123 (Jabber id, page perso, ) le 09/12/2005 à 21:54. (lien). Évalué à 2.hum j'ai l'impression que tu as loupé un épisode ;-)
la pci et usb database existent déjà mais ne font l'objet que d'un rapprochement entre
vendor_id1, product_id1, éventuellement vendor_id2, product_id2 voire révision
et
le pilote qui gère le chipset ainsi identifié
pour prendre un exemple que je connais : http://faq.eagle-usb.org/wakka.php?wiki=ModemSupport
Ton idée de fouiller dans le code pour trouver les produits n'est pas si mauvaise, mais ça risque d'être incomplet (côté produits) vu que les développeurs de pilote ont du mal à identifier les produits intégrant le chipset géré par le pilote (vu que c'est le constructeur qui sait ce qu'il choisit et omet souvent de changer.
D'autre part, 2 projets existent déjà sur le sujet (que la future base pourrait utiliser) :
http://www.pcidatabase.com/ pour les pilotes pci
et http://www.qbik.ch/usb/devices/index.php pour les pilotes usb
et cela correspond aux codes qui apparaissent dans
/usr/share/ldetect-lst/usbtable.d/90default.lst
/usr/share/ldetect-lst/pcitable.d/90default.lst (il y a aussi dmitable.d/90default.lst ScannerDB.gz MonitorsDB pcmciatable.d/90default.lst ...)
(sur une mandriva, après sur d'autres distribs cela peut être fait de manière similaire...). C'est aussi comme ça que lspci / lsusb peuvent afficher des infos complémentaires.
Bon en tout cas, c'est bien tu me donnes l'idée de structurer un peu le wiki... je crois qu'il va falloir ajouter une FAQ ;-)
notamment, indiquer qu'étudier l'existant avec http://wiki.eagle-usb.org/wakka.php?wiki=HwDbExistingResourc(...) (qu'il faudrait un peu structurer) est important.
après, pour l'instant je n'ai pas très bien compris ton histoire d'api, mais n'hésite pas à préciser (euh, flash tu peux oublier... ou alors à titre d'api non libre).-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 10/12/2005 à 17:35. (lien). Évalué à 2.faudrait que je m'explique
un lsusb donne ca:
0b95:1720 ASIX Electronics Corp
et c'est pas le produit c'est la puce...
bonjour monsieur je voudrait acheter une carte asix ab95:1720
euh...
mais si je dis:
"DLink DUB-E100 USB Ethernet"
Netgear FA-120 USB Ethernet
Hawking UF200 USB Etherne
ca le vendeur connais
meme que si tu lui donne une liste de toutes les cartes suportees bah il peut en trouver une...ou meme plusieurs
ensuite le lspci tu le fait si t'as deja le produit,cela implique que qqn doit l'avoir fait et donc que ce qqn as achete une carte...dont il n'etais pas sur du tout qu'elle etais suporte par linux...on tourne en rond
mais qqn qui cherche une carte reseau usb2.0 va chercher dans les sources,construire une liste et uploade cette liste sur le site
en plus s'il as une perte de donee il peut retrouver facilement cette liste ou dire c'est moi qui ait fait ca-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 10/12/2005 à 17:42. (lien). Évalué à 0.en gros les hcl venant des sources c'est la base...pas garanti a 100% mais necessaire pour que des gens achetent...
apres les contrib du type lspci=telle carte c'est la serise sur le gateau qui ne peut etre possible que si la base existe deja et que les personnes ont achetes en fonction de cette base
pour obtenir le genre de renseignements suivants:
dans la revision 3 du firmware ils ont change aussi le chip...bah ca vient APRES et pas avant
neanmoin integrer les databases existantes est aussi une obligation
ca permet a des personnes de ne pas faire cette erreur d'acheter qqch qui a change de puces-
[^]Re: Oui, mais que faire ?
Posté par baud123 (Jabber id, page perso, ) le 10/12/2005 à 18:07. (lien). Évalué à 3.j'ai toujours pas bien compris ton approche.
Les infos disponibles via lspci, lsusb, ne donnent effectivement que le chipset (ça permettra d'avoir des stats semi-automatiques...).
Bien sûr que l'objet de http://wiki.eagle-usb.org/wakka.php?wiki=HardwareDb et de http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Doc+D(...)
est de faire le lien entre le produit vendu et le pilote
D'ailleurs pour les notes attribuées :
- la note de fonctionnment est plutôt portée par le produit
- la note de liberté est plutôt issue des infos sur le pilote (pilote libre, firmware libre, ...)
Pour un même produit (description du vendeur disons...) il peut y avoir des chipsets différents, même si ça ne devrait pas exister. Derrière le pilote va a priori être différent (Starmodem a réussi à faire ça avec pilotes eci et eagle-usb déjà... Dlink DSL aussi pour les modems adsl usb, yen a qui n'ont peur de rien...). Faudra trouver un moyen de montrer ce genre de choses à l'utilisateurs (en partant à partir des descriptions de produits ça viendra de soi-même... et dans les commentaires).
-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 10/12/2005 à 18:08. (lien). Évalué à 0.il faut aussi qqn qui conaisse bien le kernel et le hardware
par exemple un newbee ne sait pas(la preuve:moi)que pccard et pci est la meme chose et s'etone qu'un pilote pci fonctionne pour une carte pc-card-
[^]Re: Oui, mais que faire ?
Posté par tuks () le 11/12/2005 à 17:39. (lien). Évalué à 0.ma demarche est simple
construire cette database SANS poseder le hardware en question
-cela demanderait beaucoup trop de monde si on devait posseder le hardware(donc connaitre la marque et le model) et faire un lspci
-c'est un cercle vicieu car si personne ne posede une carte,personne n'ira l'acheter car personne ne saura si elle a une chance d'etre compatible
donc il faut:
1)construire la database a partir des sources:
-rapide
-facile
-enorme database
2)que par dessus des utilisateur fassent des lspci pour verifier cela(version des cartes avec des chipset differents...)-
[^]Re: Oui, mais que faire ?
Posté par baud123 (Jabber id, page perso, ) le 11/12/2005 à 19:40. (lien). Évalué à 2.1) oui, c'est bien l'approche prise, relis https://linuxfr.org/comments/658445.html#658445 (là où je te parle de pcitable et usbtable, l'équivalent doit exister pour gentoo).
En revanche, regarder dans le noyau peut donner d'autres choses (mais non automatisable facilement), ça vaut le coup de faire une passe.
pour ton 2, tu peux regarder ce schéma : http://librehwdb.tuxfamily.org/dev/project_organization_reso(...) (le source dia est dispo)
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Oui, mais que faire ?
Posté par David (page perso, ) le 09/12/2005 à 17:16. (lien). Évalué à 4.Désolé mais quand j'avais à choisir une imprimante photo pour chez moi, ça m'a bien servi. Surtout à ne pas choisir une Canon qui pourtant me plaisait plus.
Obliger quelqu'un à télécharger un kernel linux pour lire le code et voir si le matériel qu'il convoite est supporté, je trouve ca délirant.
Une base de donnée permet autant de vérifier la compatibilité de son matos que de suggérer du matos compatible si on veut investir.
J'ai plein d'ami et collègue qui pense passer à linux, c'est pas pour les dégouter au dernier moment en les faisant lire les sources du kernel.
Perso, je n'achette que du matos qui est supporté (+/-) avec driver GPL. Et je ne lit pas les sources pour ça.
A+-
[^]Re: Oui, mais que faire ?
-
-
-
-
Oui, mais....
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 ?
-
[^]Re: Oui, mais....


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.