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.
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.
Aller plus loin
- Linux dans un monde binaire, une hypothéthique débâcle (2 clics)
- Stable API: Non-sense (2 clics)
# C'est parti ..
Posté par Xavier Bestel (site web personnel) . Évalué à 10.
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 . Évalué à 7.
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 . Évalué à -6.
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 . Évalué à 10.
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 . Évalué à 5.
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 (site web personnel, Mastodon) . Évalué à -2.
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 (site web personnel) . Évalué à 9.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: deja pris
Posté par durandal . Évalué à 4.
[^] # Re: deja pris
Posté par un_brice (site web personnel) . Évalué à 7.
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.
[^] # Re: deja pris
Posté par boris . Évalué à 1.
[^] # Re: deja pris
Posté par Krunch (site web personnel) . Évalué à 2.
https://linuxfr.org/2004/10/27/17522.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: deja pris
Posté par modr123 . Évalué à -1.
[^] # Re: deja pris
Posté par spotty . Évalué à 1.
Argument idiot et je le démontre par l'absurde: les *BSD ne sont pas gnu et pourtant emploient GCC
[^] # Re: deja pris
Posté par un_brice (site web personnel) . Évalué à 4.
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.
[^] # Re: deja pris
Posté par Anonyme . Évalué à 2.
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 . Évalué à 5.
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 . Évalué à 1.
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 (site web personnel) . É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]
- 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.
[^] # Re: C'est parti ..
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 5.
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 ....
[^] # Re: C'est parti ..
Posté par WH (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 4.
[^] # Re: C'est parti ..
Posté par Julien . Évalué à 5.
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 . Évalué à 3.
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 . Évalué à -1.
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".
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.
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 . Évalué à 3.
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é.
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 . Évalué à 6.
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.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Le risque n'est pas le même
Posté par wahnby . Évalué à 1.
[^] # Re: Le risque n'est pas le même
Posté par Corto . Évalué à 0.
Ce n'est pas que je mette en doute ta parole mais si tu pouvais nous donner d'autres infos.
[^] # ATI...
Posté par Arthur Accroc . Évalué à 2.
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...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Le risque n'est pas le même
Posté par Julien . Évalué à 0.
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.
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 . Évalué à 5.
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 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é...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Le risque n'est pas le même
Posté par Julien . Évalué à -1.
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 . É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 . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est parti ..
Posté par wahnby . Évalué à -5.
[^] # Re: C'est parti ..
Posté par JoeBar . Évalué à 3.
# OpenBSD
Posté par Nicolas Bernard (site web personnel) . Évalué à 10.
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 (site web personnel) . Évalué à 10.
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.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: OpenBSD
Posté par gnumdk (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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.
[^] # Re: OpenBSD
Posté par Miair Patreau . Évalué à 2.
Ç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 ?
Posté par Arthur Accroc . Évalué à 10.
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).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Oui, mais que faire ?
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
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 (site web personnel) . Évalué à 5.
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_ . Évalué à 4.
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 mickabouille . Évalué à 4.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 9.
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 BAud (site web personnel) . Évalué à 7.
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 (site web personnel) . Évalué à 3.
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 BAud (site web personnel) . Évalué à 4.
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 . Évalué à 2.
[^] # Re: Oui, mais que faire ?
Posté par WH (site web personnel) . Évalué à 2.
[^] # Re: Oui, mais que faire ?
Posté par wahnby . Évalué à 3.
[^] # Re: Oui, mais que faire ?
Posté par ~ lilliput (site web personnel) . Évalué à 3.
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.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Oui, mais que faire ?
Posté par David (site web personnel) . Évalué à 2.
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 GNUtoo . Évalué à -1.
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 GNUtoo . Évalué à 1.
-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 BAud (site web personnel) . Évalué à 2.
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 GNUtoo . Évalué à 1.
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 GNUtoo . Évalué à 1.
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 GNUtoo . Évalué à 2.
http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Proje(...)
[^] # Re: Oui, mais que faire ?
Posté par BAud (site web personnel) . Évalué à 2.
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 GNUtoo . Évalué à 2.
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 GNUtoo . Évalué à 0.
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 BAud (site web personnel) . Évalué à 3.
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 GNUtoo . Évalué à 0.
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 GNUtoo . Évalué à 0.
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 BAud (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 4.
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 ?
Posté par GNUtoo . Évalué à 0.
y'as juste a trouver l'ocurence du nom commercial dans les sources
# Oui, mais....
Posté par Anonyme . Évalué à 9.
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....
Posté par Colin Leroy (site web personnel) . Évalué à 8.
[^] # Re: Oui, mais....
Posté par Miair Patreau . Évalué à 7.
[^] # Re: Oui, mais....
Posté par kursus_hc . Évalué à 0.
[^] # Re: Oui, mais....
Posté par Anonyme . Évalué à 5.
C'est bien joli de critiquer, mais bon...
Et si je dis à un de mes potes, "passe sous Linux, mais tu n'aura plus de support wifi sur ton portable parce que les binaires caymâl", il va crever de rire, et rester sous fenetre (c).
Attention, je ne dis pas que les binaire caybien et tout ça, je suis 100% pour du full libre/open-source et compagnie, mais si vous avez une alternative pour les cartes graphiques (va reverse enginerer les pilotes ATi, c'est nettement plus hardcore qu'une bête carte réseau ou un pilote IDE)...
[^] # Re: Oui, mais....
Posté par un_brice (site web personnel) . Évalué à 5.
L'idée est que si les pilotes proprios étaient impossibles, les pilotes seraient libres, comme c'était le cas il n'y a pas si longtemps.
Et pourtant, y'a des bourrins qui y arrivent ! Ça doit être possible.
http://r300.sourceforge.net/ supporte déjà ppracer et quake3 (proprio...).
[^] # Re: Oui, mais....
Posté par Jiel (site web personnel) . Évalué à 8.
Je comprends ce que tu veux dire, mais est-ce que ce sera vraiment une victoire si tes potes passent sous GNU/Linux mais utilisent plein de logiciels propriétaires?
[^] # Re: Oui, mais....
Posté par Jacquot Raphael . Évalué à 8.
viens nous aider (ou nous cracher dans les mains) et inscrit toi sur la mailing liste qui va bien...
http://lists.duskglow.com/mailman/listinfo/open-graphics
[^] # Re: Oui, mais....
Posté par Claude Le Gall (site web personnel) . Évalué à 5.
Il n'est peut-être pas nécessaire d'avoir toutes les fonctionnalités de la carte, mais au moins les fonctionnalités OpenGL les plus basiques pour afficher un joli petit tuxcracer.
A quel niveau est-ce que cela "coince" ? Est-ce un problème de disponibilité d'un gentil développeur volontaire pour s'y coller ? Est-ce nVidia qui empêche le développement de drivers libres ?
C'est vraiment dommage qu'il n'est pas possible d'avoir une solution OpenGL totalement libre. Je me serais bien passé de nVidia si je connaissais une carte OpenGL alternative (et relativement récente tout de même).
Dans le domaine du wifi on peut toujours diriger ses achats vers des cartes à base de chipset prism pour ne pas avoir recours à Ndiswrapper, mais dans le domaine des cartes graphique je ne connais pas d'alternative.
Ou alors... on ne doit pas faire de 3D sous GNU/Linux ?
[^] # Re: Oui, mais....
Posté par Jerome Herman . Évalué à 8.
Pour faire court : si.
Aussi absurde que celà paraisse, il est impossible de faire sur une carte graphique moderne les choses simples sans faire appel aux fonctions compliquées. Bien sur c'est le pilote qui s'en charge et celà reste totalement transparent pour le developpeur, mais une banale application de texture sur un polygone en rendu "plat" sera décomposé en moult appel à des vertex et pixel shaders sur une X800 ou une 6800.
La raison en est très simple : Sachant que
a) qui peut le plus peut le moins et
b) moins on a de transistors dans une puce plus elle est rentable
on arrive à la conclusion simple, : il faut recylcer les transistors des fonctions évoluées pour traiter les fonctions simples.
Dans 99,9% des cas c'est le pilote qui se charge du découpage. Donc pour faire un bête rendu à plat d'une texture sur un polygone de façon un peu optimisée, il faut les specs complète des shaders.
Dans le même ordre d'idée, de nos jours l'ensemble du T&L (transform and lighting) est assuré entièrement par des wrappers vers les shaders.
Bien sur il existe sur les fonctions vraiment basiques des cablages fait en hardware qui permettent au pilote de ne pas faire TOUT le boulot de décomposition. Mais déjà elle s'appliquent rarement à tous les cas de figures et ensuite ce sont des fonctions très basiques (une fois de plus le nombre de transitors joue).
Donc pour faire un pilote digne de ce nom pour jouer, il faut une bonne partie des specs des shaders.
[^] # Re: Oui, mais....
Posté par ZeroHeure . Évalué à 2.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Oui, mais....
Posté par Anonyme . Évalué à 1.
Sinon, les coup du pilote R300 libre, je l'attendais... Mais quand je vois:
Bah c'est marrant, mais ça ne me donne pas vraiment envie de tester.
Enfin, moi, des drivers basiques, ça ne me sert à rien, j'ai acheté une 9800pro pour pouvoir exploiter à fond les derniers raffinements technologiques en OpenGL (je veux développer du jeux vidéo plus tard, et avec support Linux natif s'il-vous-plait), donc si c'est pour afficher trois textures, deux lumières et un effet de brouillard, merci mais non.
Pour la mailing-liste, je m'inscris :)
# hum is free drivers
Posté par Bayet Thierry . Évalué à 10.
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.
[^] # Re: hum is free drivers
Posté par BAud (site web personnel) . Évalué à 5.
http://wiki.eagle-usb.org/wakka.php?wiki=HwDbExistingResourc(...)
Pour l'obsolescence, c'est effectivement aussi aux développeurs de pilote de faire des mises à jour, voire aux utilisateurs quand ça marche pour eux. Mais en cherchant bien, ces sites sont tout de même relativement à jour.
Si tu trouves qu'il te manque des infos, n'hésite pas à les lister, ya un début ici : http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Doc+D(...) (après la base reste à développer...)
[^] # Re: hum is free drivers
Posté par Guillaume Vauvert (site web personnel) . Évalué à 1.
http://www.linuxprinting.org/
Pour le reste, il y a un Linux Hardware Compatibility HOWTO :
http://www.traduc.org/docs/HOWTO/lecture/Hardware-HOWTO.html
D'abord, il faut que ce soit mis à jour souvent.
Ensuite, difficile de juger la qualité d'un pilote : selon quels critères ? ça dépend du point de vue. Sans parler de l'objectivité, étant donné les intérêts en jeu.
[^] # Re: hum is free drivers
Posté par Frédéric COIFFIER . Évalué à 3.
Il n'existe actuellement aucune base de données regroupant tous les types de matériels fonctionnant avec Linux ! Le projet de baud123 permettrait d'avoir une base de données que l'on pourrait personnellement enrichir ! Comme je le disais dans un autre commentaires, on pourrait en plus des caractéristiques du drivers donner notre appréciation avec commentaires + notes !
Si toutes les personnes de LinuxFR passaient sur un site comme celui-ci pour recencer leur matériel, on arriverait rapidement à quelque chose de vraiment intéressant. Ensuite, à chaque nouveau matériel testé, il faudrait le mettre à jour : "le PC de ma soeur Carrefour ne boote pas avec Knoppix : Matériel X et Y non supporté".
Maintenant, il faudrait des bras pour lui filer un coup de main !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hum is free drivers
Posté par BAud (site web personnel) . Évalué à 2.
concernant ubuntu j'avais trouvé en plus un wiki : https://wiki.ubuntu.com//HardwareSupport
quel est le lien entre les deux ?
Y-aurait-il une autre interface de consultation des données remontées par le programme hwdb-client ? (permettant par exemple de faire des statistiques ?)
J'ai vu qu'il y a un GUI : http://www.ubuntu.com/include/ubuntu-5.10-hwdb.jpg demandant de confirmer le résultats de certains tests...
Mandriva avait mis en place le même genre de choses (un peu moins utilisé que sur Ubuntu, car pas lancé à chaque nouvelle install' mais plutôt par ceux qui connaissent).
aussi avec un wiki : http://club.mandriva.com/xwiki/bin/KB/HardwareIndex
sans lien avec http://qa.mandriva.com/test_hw_stat.cgi (la page de stats liées à hwdb, rame un peu...)
La documentation inclue ce projet dans celui des fiches de tests http://qa.mandriva.com/twiki/bin/view/Main/TestZilla (un peu plus large que la seule base de données de matériel).
Il y a le pendant utilisateur http://wwwnew.mandriva.com/en/hardware pour rechercher du matériel dit "compatible" voire certifié.
Bon j'ai pris 2 distributions (j'allais dire "au hasard"), je pense qu'il y a des projets équivalents sur pas mal d'autres distributions...
si vous avez des infos pour la vôtre... n'hésitez pas à le signaler !
Tiens au passage, cela m'aura permis de tomber sur http://lists.osdl.org/pipermail/desktop_architects/2005-Dece(...) qui fait un point sur " l'état de l'art " des pilotes pour matériel et des problèmes rencontrés (globalement).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: hum is free drivers
Posté par moramarth . Évalué à 0.
https://wiki.ubuntu.com/HardwareSupport
C'est vrai que cela concerne la distribution Ubuntu, et que peut-être, d'autre distributions ont du matériel supporté en moins, et d'autre encore, supporté en plus.
Mais les différences ne doivent pas être fondamentale, et cela reste parfaitement valable pour 53 % des utilisateurs de Linux pour Bureau selon OSDL...
http://66.102.9.104/custom?q=cache:hjGTJkHlblUJ:www.osdl.org(...)
et en pdf http://www.osdl.org/dtl/DTL_Survey_Report_Nov2005.pdf
# créons un label "linux-compatible" !
Posté par flynn . Évalué à 5.
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.
[^] # Re: créons un label "linux-compatible" !
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 4.
WeeChat, the extensible chat client
[^] # Re: créons un label "linux-compatible" !
Posté par Thomas Petazzoni (site web personnel) . Évalué à 5.
[^] # Re: créons un label "linux-compatible" !
Posté par Croconux . Évalué à 5.
Quid de la visibilité ? Il y a déjà un bon paquet de boites qui surfent sur cette vague. La plus connue est LinuxCertified qui moyennant (grosses) finances se propose de déclarer un matériel donné "certifié Linux"... sauf qu'ils ne testent pas la motitié de ce que supporte le matériel. Pour les cartes mères, ils zappent souvent le son et ne touchent pas un mot de l'acpi. Que testent-ils alors ? Le fait que ça boot, que les DD sont détectés, bref ce qui marche de toutes façon out of the box sur n'importe quelle carte même la plus pourrie.
A côté de ça, il y a aussi des magasins qui vendent des machines "compatibles Linux", en particulier des portables (genre EmperorLinux) mais quand je vois les config ça me fait doucement rigoler. Oser vendre un portable soit disant compatible Linux avec une puge graphique ATI c'est limite foutage de gueule. Encore avec du Nvidia ça passerait mais il est bien dit dans la doc des drivers proprio ATI que les puces mobiles ne sont pas supportées ! Il recommendent d'aller voir chez les grecs^M^M^M^Mle fabricant du portable. Sans parler des supers équipements inclus comme le tuner TV dont il est dit dans une note microscopique en bas de page qu'il n'a pas été testé. Ca sert à quoi de vendre une machine avec 2500EUR d'équipement non testé ? Autant proposer une machine à 700EUR mais avec que des composants qui marchent (puce graphique intégrée Intel, etc). Au final pour un prix délirant on a droit à une machine dont la compatibilité est équivalente (plutot pire) que celle d'une machine prise au hasard dans un magasin. Je suis près à payer plus cher pour être sûr de n'avoir pas de problème mais payer plus cher (x2 à x3) pour de la merde il ne faut pas abuser.
[^] # Re: créons un label "linux-compatible" !
Posté par Guillaume Vauvert (site web personnel) . Évalué à 1.
[^] # Re: créons un label "linux-compatible" !
Posté par Guillaume Vauvert (site web personnel) . Évalué à -1.
Ce que je veux dire, c'est que ce n'est pas parce que tu as les spécifications que tu as un pilote. Tu as juste la possibilité d'écrire un pilote : compatible me semble alors être un peu trop fort.
Ce n'est pas forcément facile d'écrire un pilote de bonne qualité, notamment pour du matériel peu utilisé (car peu de développeurs intéressés).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: créons un label "linux-compatible" !
Posté par Fred Albrecht . Évalué à 1.
Bon en règle générale (comme avec beaucoup de choses) moyennant quelques bricolages pas très compliqués, ça marchait quand même avec les pilotes du noyau mais bon, ça fait pas très sérieux.
Le fait est que si les fabricants disaient d'une manière générale avec quoi ils sont compatibles (notament les imprimantes pour l'exemple typique donné plus haut), ça simplifierait la vie de tout le monde. Heureusement qu'il y a linuxprinting.org (et l'équivalent pour les bidules USB).
# Une question, comme ça...
Posté par calandoa . Évalué à 1.
[^] # Re: Une question, comme ça...
Posté par un_brice (site web personnel) . Évalué à 4.
# Avocat du diable
Posté par Anthony Jaguenaud . Évalué à 7.
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).
[^] # Re: Avocat du diable
Posté par Calim' Héros (site web personnel) . Évalué à 5.
- une partie des specs (comme ca driver libre mais ne tirant pas pleinement partie du hardwrae)
- un drivers binaire + glue a la nvidia/ati pour avoir qque chose de performant et pas trop lié au noyau
- passé le délais d'amortissemnt du chip/de la techno les spec completes
L'idéal étant encore d'avoir les spec completes directement et des drivers libre.
[^] # Re: Avocat du diable
Posté par dilbert . Évalué à 1.
Un an de délai, ce n'est pas mal, sachant que si la concurrence désassemble, elle aura largement eu le temps d'en apprendre suffisement d'ici là.
[^] # Re: Avocat du diable
Posté par Croconux . Évalué à 10.
L'architecture de ta puce on s'en contrefout. Ce dont on a besoin ce sont les interfaces : Qu'est ce que je dois envoyer comme commande à ton matériel pour lui faire exécuter une tache donnée. Tu immagine si un fabricant de microonde refusait de te donner le mode d'emploi sous prétexte que tu pourrait comprendre comment marche son four ? Moi son four je m'en fout. Je veut savoir où est le bouton marche et où on règle la puissance et le temps de cuisson, bref l'interface. Pourquoi l'informatique s'affranchirait-elle de fournir des interfaces claires ? La raison le plus fréquent est que le matériel informatique ne fait souvent pas ce qu'il dit faire. Une partie du boulot est fait par le processeur ou mal fait pour gagner du temps (cartes graphiques). Forcément si on voit qu'il n'y a pas de bouton pour régler la puissance sur un microonde on comprends que le vendeur s'est foutu de notre gueule en disant que la puissance était réglable.
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).
Amen. Je serais preneur d'une carte graphique pas trop récente mais supportée via des drivers libres. Je n'ai pas besoin d'une GF 7800GTX par contre une GF4 avec des pilotes libres ça m'irait tout à fait. Sauf que ça n'arrivera probablement pas par peur des brevet. Dans ce domaine il y a beaucoup de brevets à la cons déposés dans tous les sens et personne ne sait trop quand il a une idée tout bête si ça n'a pas déjà été déposé par quelqu'un. Il y a quelques temps John Carmack avait dans une interview expliqué quelques principes de base connus depuis des lustres utilisés dans le moteur de Doom3. Illico attaque de Creative : "On l'a breveté" (à quoi ça leur sert ?). Ca s'est réglé à condition que JC mettent en avant leur techno sonore EAX. Après ça je comprends la réaction des gens. Pour vivre heureux vivont cachés.
[^] # Re: Avocat du diable
Posté par SuperDindon . Évalué à 4.
Si l'ouverture des sources des drivers laissent voir l'architecture du matos c'est que le matos est mal conçu. Le rôle des drivers c'est rien d'autre que de donner des ordres à travers un protocole, un protocole qui devrait être standardisé pour tout le matos d'un même type ( et si besoin des extensions pour les fonctionnalités exotiques ). Ensuite si les constructeurs ont besoin d'une partie logicielle upgradable fermée alors qu'ils utilisent des firmwares closed-source là pas de problème, tout ce qu'on veut, c'est des specs ouvertes ! Faire le parallèle avec les DRMs, tu le paies ton matos mais c'est pas toi qui décide ce que tu en fais
( Et Creative c'est des méchants )
[^] # Re: Avocat du diable
Posté par atlexx . Évalué à 2.
si on suit ta direction (protocole standardisé), on à plus besoin de driver. l'os implémente le standard et ton matos contient un driver entre le matos et le standard dans son firmware. mais la tu vas avoir un tas de gens qui, à raison, vont demander pourquoi les sources du firmware sont fermés.
[^] # Re: Avocat du diable
Posté par SuperDindon . Évalué à 1.
mais que les constructeurs pensent leurs produits de façon à pouvoir fournir les specs ( comme HP fait pour ses imprimantes )
[^] # Re: Avocat du diable
Posté par ldng . Évalué à 1.
[^] # Re: Avocat du diable
Posté par Anthony Jaguenaud . Évalué à 3.
Je suis bien d'accord, mais comprends que la première version de la puce à un petit bug très con, qu'on a contourné dans le driver... Ca passera plus facilement inaperçu comme ça.
Seules les premières séries sont impactées, quand on sortira le driver open source, se sera avec des die correct. On pourra alors annoncer qu'on a eu une mauvaise série, et qu'on peut patché le driver comme ça pour que ça marche.
Sinon, je suis bien d'accord, que d'un point de vue informatique, on devrait uniquement parler de flux d'information, finalement, les blocs de code qui traite l'info, on devrait s'en foutre royalement, hélas, ce n'est pas le cas. :-(
[^] # Re: Avocat du diable
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Je souscris totalement à cette analyse. Je propose d'ailleurs un modèle de spécification des interfaces : http://pjarillon.free.fr/redac/interface.html
C'est une démarche complémentaire à celle qui demande des formats ouverts car elle permet de formaliser et de généraliser l'exigence.
Une autre requête est d'exiger que l'interface logique et l'interface physique coïncident. Cela éviterait de jouer à la cascade de dominos lorsqu'on veut en changer un.
[^] # Re: Avocat du diable
Posté par nazcafan . Évalué à 1.
1°) Production _et_maintenance_ d'un driver binaire (pourquoi pas close-source) pendant une période de temps fixée à l'avance selon l'aspect critique du matériel.
2°) Publication des sources ou des spécifications nécessaires à l'écriture d'un pilote open-source. Avec un label "linux-goldmember" pour ceux qui s'engagent à libèrer à la fois les sources et les spécifications. (on pourrait rêver et proposer un label "penguin loves me" pour les constructeurs qui fondent et supportent eux-mêmes un projet de maintenance de leurs pilotes sous manchots).
Maintenant, la publication des sources ne signifierait pas forcément l'existence d'un pilote pour la version actuelle du noyau, mais ce serait à la communauté de se bouger pour qu'il existe. Corrigez-moi si je dis une connerie, mais si on sort un driver pour XP, le driver restera compatible au fil des maj de winXP, non ? Donc /a priori/ c'est à la communauté de manchots d'assumer le fait d'avoir des kernels évolutifs et de maintenir les pilotes, non ?
[^] # Re: Avocat du diable
Posté par Calim' Héros (site web personnel) . Évalué à 3.
[^] # Re: Avocat du diable
Posté par pasBill pasGates . Évalué à 1.
Les 99% restants eux par contre continuaient a fonctionner sans probleme.
[^] # Re: Avocat du diable
Posté par Sigurr . Évalué à 2.
D'ailleur je remarque que pour cette raison, XP64 n'est même pas vendu en grande surface.
Vous auriez au moins pu faire un mode "compatible x32" !
[^] # Re: Avocat du diable
Posté par Guillaume Vauvert (site web personnel) . Évalué à 1.
Le terme "éduquer" me fait un peu peur; je dirais plutôt informer. Pour qu"ils puissent choisir en toute connaissance de cause. Mais le sujet n'est pas facile.
[^] # Re: Avocat du diable
Posté par norbs . Évalué à 2.
De cette façon tu résoud la majorité des problèmes soulevés :
- changement de version du noyau : on peut espérer que tu pourras livrer de nlles versions de ton driver bianire pendant un an
- à partir de la libération des sources, le noyau n'est plus "tainted"
Tu y gagnes à tous les coups : réputation dans le monde linux, récupération des idées des developpeurs noyaux qui modifient tes sources pour tes prochains produits... Si tu n'as pas les ressources pour maintenir ton driver dans le futur, tu peux te reposer sur la communauté...
# Binaire c'est mal(TM)
Posté par hervé Couvelard . Évalué à 10.
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 ?
[^] # Re: Binaire c'est mal(TM)
Posté par Calim' Héros (site web personnel) . Évalué à 4.
Ba justement : Nvidia, Ati et les fabriquand de puce wifi... et comme sur un serveur t'as pas trop besoin de tout ca, ils s'en foutent.
[^] # Re: Binaire c'est mal(TM)
Posté par hervé Couvelard . Évalué à 4.
*je rappelle que des gens ACHETENT des machines pour les mettres sous linux, ce n'est pas que du recyclage.
DONC il y a un MARCHE, qui devient de plus en plus important et nous tuons cette force (un marché qui augmente) en autorisant des constructeurs à livrer des pilotes binaires.
Si au moment de l'achat on regardait si la machine est compatible pour ce que l'on veut en faire, on achete, sinon NON, on en choisit une autre, la donne serait vite vue.
Sur ma machine j'ai un winmodem, et bien j'ai acheté un olitec externe.
Je vais mettre sur le marché, en début d'année prochaine une machine linux (on travaille dessus en ce moment), elle a été CHOISIE pour marcher avec linux SANS pilotes binaires DU TOUT, ok ce n'est pas une console de JEUX (3D pas accelérée), mais il y a assez de jeux 'classique' pour une utilisation 'classique', sinon, je conseille l'achat d'une console de jeux.
Tout n'est que CHOIX.
[^] # Re: Binaire c'est mal(TM)
Posté par Anonyme . Évalué à 1.
Mais combien recyclent leur machines ? J'ai de bonnes raisons de penser qu'ils sont majoritaires.
Je vais mettre sur le marché, en début d'année prochaine une machine linux (on travaille dessus en ce moment)
Très bonne initiative ! Je pense que la connexion WiFi est un des plus gros problèmes de prise en charge, témoin NDISWrapper. Qu'en penses-tu ?
Sinon, je conseille l'achat d'une console de jeux.
Là... C'est une histoire d'argent et de contexte (recyclage ou non).
Tout n'est que CHOIX.
Et concessions (avec son porte feuille et son matériel déjà acquis, par exemple).
[^] # Re: Binaire c'est mal(TM)
Posté par gc (site web personnel) . Évalué à 4.
Mais combien recyclent leur machines ? J'ai de bonnes raisons de penser qu'ils sont majoritaires.
Et quelles sont ces raisons ?
[^] # Re: Binaire c'est mal(TM)
Posté par Anonyme . Évalué à 2.
Par exemple, le fait que beaucoup ont d'abord utilisé ou acheté leur ordinateur personnel avec un autre système d'exploitation, du même nom que les ouvertures légèrement surélevées pratiquées dans les murs d'une pièce d'habitation ?
[^] # Re: Binaire c'est mal(TM)
Posté par Anonyme . Évalué à 1.
Si oui, tant pis, oubliez ça.
Si non, je maintiens : je suis presque sûr que la plupart des PC sous Linux étaient sous Persiennes avant.
[^] # Re: Binaire c'est mal(TM)
Posté par Calim' Héros (site web personnel) . Évalué à 2.
[^] # Re: Binaire c'est mal(TM)
Posté par Anonyme . Évalué à 2.
-->[]
[^] # Re: Binaire c'est mal(TM)
Posté par Calim' Héros (site web personnel) . Évalué à 4.
Je vais prendre un cas que je connais bien, le mien :
- Je paye un ordinateur suffisament chere pour esperer ne pas avoir a me payer une console pour jouer
- J'aime linux et le libre pour le partage du savoir qui va avec et plein d'autres choses que j'ai decouvert en l'utilisant (maitrise de la machine, respect des licences, prise en compte des differences des autres, respect des autres...)
Et je n'ai pas envie de repasser a Windows ni a un autre OS propriétaire. Cependant j'aime bien jouer et aux MMORPG de preference. Et la c'est le drame, parce que j'aime quand meme que ca soit un minimum jolie, j'aime bien la 3D aussi et j'aime bien qu'il y ai un peut de monde sur le serveur.
Idéalement pour moi ca serait DAoC sur Linux mais alors la pour esperer le faire marcher j'ai pas bcp de choix :
- 3D => driver proprio
- Windows Only => wine / cedega et que ca soit libre ou non on est dans le même cas de figure que le wrapper a wifi.
Alors je fait comment? J'en suis donc venu a prendre une machine avec des puces supportées par le kernel (et donc libre) sauf pour la video ou j'ai des pilotes graphiques proprio.
Pour les jeux, je prend des jeux natif linux mais proprios sauf pour le mmorpg ou je tente avec wine / cedega (et la je me retrouve avec WoW ou CoH). Dans tout les cas je suis bien concient des limite du systeme :
- un changement de mon systeme un peut trop brutal et zou, plus de jeux
- un changement trop brutal de wine / cedega et zou plus de jeux
- un add-on trop fou et zou plus de jeux
- un patch trop violent et zou plus de jeux
Bref c'est galere. Et autant je sais que ces solution intermediares augmentent les migrations vers notre systeme préféré autant je sais que c'est dangeureux pour son avenir. Et ca devient de moins en moins facil de choisir.
[^] # Re: Binaire c'est mal(TM)
Posté par brunus (site web personnel) . Évalué à -2.
Arrète de jouer...code...fabrique des modèles et des textures...planche sur un système de jeu, un background...en gros, participe à un projet de MMORPG libre ou lance s'en un.
Le moteur de Saga of Ryzom (NEL) est libre justement...autant en profiter...tu aurais peut être parler de ce jeu dailleur...
Arrange toi pour que ce projet fonctionne sur des machines qui n'utilisent pas de pilotes proprios.
Faudrait voir ce qu'en pense l'équipe de NEKEME prod...ou celle de Soya :
http://home.gna.org/oomadness/en/soya/index.html
[^] # Re: Binaire c'est mal(TM)
Posté par Calim' Héros (site web personnel) . Évalué à 2.
2 - Qu'est ce qui te dit que j'ai des competences d'analyste programeur.
3 - Le moteur de SoR (NEL) c'est pas le client et moi c'est un client que je veux sous linux.
4 - NEL doit déja tourner sur des machines qui ne nécessitent pas de drivers proprio vue qu'il tourne sur des serveurs
[^] # Re: Binaire c'est mal(TM)
Posté par dilbert . Évalué à 1.
[^] # Re: Binaire c'est mal(TM)
Posté par hervé Couvelard . Évalué à 4.
Remarque supplémentaire, mes réponses ne sont JAMAIS des réponses à un cas particulier, mais une extrapolation de chaque cas à un 'cas' générique. Je suis content que TOI calim tu arrives à faire tourner TA machine comme tu peux (avec du proprio) mais je ne veux pas que LINUX accepte cela.(je sais c'est assez schizophrène)
La remarque générale : Comment je fais avec ma machine alors que j'ai pas de drivers blabla.... -> tu ne fais pas, c'est aussi simple que cela.
Tu as fais le choix d'acheter une machine plus chère, tu ne l'aurais pas achetée si tu n'avais pas pu faire tourner un driver proprio dessus -> le constructeur ne l'aurais pas vendu, il aurait perdu une part de marché, alors que dans le cas présent, il est convaincu d'avoir fait le bon choix : cela ne lui a rien couté et lui a rapporté, c'est TOI l'acheteur qui te fais chier et tu LE confortes dans son choix.
Une analogie à 2 balles, avec le prix de l'essence, c'est dégeulasse, je peux pas mettre de gazole dans mon moteur essence. : c'est pareil ou alors c'est dégeulasse on peut pas mettre de fuel domestique dans mon moteur diesel, pourtant ca marche (tm!)
Pour le cas du recyclage : En grande majorité, les ordinateurs que l'on recycle sont des machines plus anciennes qui ont plus de chance d'avoir des pilotes libres, même incomplets. Si ce n'est pas un portable, il est toujours possible de trouver une carte graphique supportée avec un driver libre (en général ce sont des cartes pas trop chères).
Pour le cas du MM_CHOSE : je ne sais pas. Il faudrait connaitre le nombre de MM_JOUEURS sous linux pour voir si cela fait une masse critique, et ne pas jouer sous linux TANT qu'il n'y a pas de solutions acceptables proposées (le coup du bac à sable en USER_LAND pour un module proprio/driver est une solution acceptable à mon sens). Dans le doute, ben on ne fait pas sous linux, désolé.
Pour ma machine : il n'y aura pas de wifi c'est tout.(c'est un choix) ceux qui veulent une machine avec wifi, il y en a plein à porté d'un simple clic.
[^] # Re: Binaire c'est mal(TM)
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Sinon je crois qu'on veux TOUS un LINUX LIBRE mais qu'on aimerais TOUS avoir des truc qui marches (différents selon les gouts). Le problème est bien de determiner :
- ce dont on est pres a ce passer
- les consequences de ce que l'on fait (ba oui si on repasse a win pour avoir le(s) truc(s) "indispensable(s)", ca fait des utilisateurs linux de moins, donc ca devient moins interressant pour les industries, par contre si on trouve des solution intermediares ca peut pourrir la situation encore plus)
Et c'est bien la que se trouvais ma question : Comment trouver le juste milieux?
[^] # Re: Binaire c'est mal(TM)
Posté par Pierre6020 . Évalué à 2.
C'est bien 24 heures de temps de jeu, ce qui est un très bon compromis pour tester un jeu de ce type en prenant son temps.
[^] # Re: Binaire c'est mal(TM)
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Merci du renseignement.
[^] # Re: Binaire c'est mal(TM)
Posté par Larry Cow . Évalué à 2.
Il y a bien d'autres raisons de refuser le "tout binaire", et cet article nous en donne assez comme ça. Pas la peine de ressortir des raisons douteuses en plus.
Pour revenir au fond du problème, la solution "optimale" pour tolérer les drivers binaires serait de leur donner un statut particulier. Ne plus les intégrer dans le noyau, mais les faire dialoguer avec un module (libre, celui-là), d'interface stable et contrôlant autant que faire se peut que les drivers "fermés" ne fassent pas d'âneries.
[^] # Re: Binaire c'est mal(TM)
Posté par Sigurr . Évalué à 1.
[^] # Re: Binaire c'est mal(TM)
Posté par serge_kara . Évalué à 4.
et juste apres :
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.
Ca me parait "tainter" la philosophie linux les "on veut pas de vous".
Faut assumer ses choix aussi, on accepte tout le monde ou on accepte pas tout le monde.
'fin j'dis ca, j'dis rien, hein, c'est pas comme si c'etait un appel au troll ce sujet.
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.
Quand on pense qu'il suffit que les gens ne l'achetent pas pour que ca se vende pas!!
Et inversemment, si les cartes nvidia n'avait pas eu de pilote du tout, linux serait cantonne uniquement au serveur et aux barbus au jour d'aujourd'hui.
La poule et l'oeuf, ceux qui aiment l'objet pour ce qu'il est et ceux qui aiment l'objet pour ce qu'il fait, le ying et le yang, la dualite du monde, tout ca.
[^] # Re: Binaire c'est mal(TM)
Posté par hervé Couvelard . Évalué à 10.
La philosophie de linux (la plus haute marche, la pureté absolue) c'est QUE du libre. Je serais dev du noyau je me casserais pas le C. pour que les pilotes binaires continue à fonctionner, il ne faut pas inverser le charue et les boeufs : le plus important dans linux, ce n'est pas le nombre d'utilisateur, ce n'est pas le nombre d'architecture qui fonctionne, ce n'est pas le nombre de machine supportée, ce n'est pas le nombre de distribution, c'est le LIBERTE comme dans free speech.
C'est ce qui a fait et fait le succes de linux. Il ne faut pas résister à l'appel des sirènes de toujours plus de monde qu'on fait venir en acceptant des compromis.
C'est la même chose qu'une secrétaire qui accepte de se faire peloter pour une augmentation ou un meilleur poste : une main au cul c'est pas la mort quoi [ un driver binaire, c'est pas la mort et on va attirer la cible des joueurs qui veulent la dernière carte nvidia pour coder ses jeux 3D qui demanderont la dernière carte 3D au driver binaire], pourtant c'est scier la branche qui a fait pousser les feuilles de linux sur l'arbre gnu.
Les grosses boites ne peuvent pas acheter linux, mais elles peuvent le corrompre facilement. Chaque driver proprio enlève chaque jour à l'UTILISATEUR un peu de sa liberté (pas possible de choisir sa distribution car les binaires ne peuvent pas tourner sur toutes, pas possible de monter en noyau si le binaire n'a pas été compilé comme il faut - version de gcc, version de glibc, unresolved symbol) Celui qui fait tourner un binaire sur son linux, il sacrifie sa liberté.
Maintenant, je ne dis pas qu'il faut JETER les individus (les personnes qui veulent utiliser linux avec des drivers fournis par les fabricants), mais il faut clairement interdire les hacks et hook sur le kernel [ j'accepterais les binaires si ils tournaient en user_space sans avoir besoin d'être root pour l'installer] pour que les fabricants qui ne jouent pas le jeux aient du matériel qui tourne mal sur linux. pour que leur image de marque soit tachée par des implémentations merdiques, pour que les joueurs achetent d'autres matériels ou geulent parce que leur matériel ne marche pas. En ce moment, ils vendent des cartes MAL supportée et s'en foutent car ceux de linux font des compromis sur leur philosophie. <= C'est là le danger, c'est une lente corruption.
C'est, à mon avis assez grave. Certes, il faut faire une croix sur son petit confort perso (ne pas pouvoir faire ou ne pas faire certaines choses). Je developpe aussi du web, depuis 1 ans, je ne fais plus d'anim flash, j'explique à mes clients pourquoi (pas libre, pas d'outils libre, pas de player libre), et par quoi/comment on peut le remplacer. Si c'est un site qui a clairement besoin de flash (il y en a, suivant la typologie de clientèle, suivant le secteur de l'entreprise). Je ne fais pas,et je ne 'prend pas ce client', je peux te dire que cela en fait réfléchir plus d'un, un prestataire qui refuse un client pour cette raison. Je fais autre choses, autrement.
Pour ceux qui disent que j'ai de la chance de me le permettre, je dis NON, j'assume les conséquences de mon choix (des revenus moindres).
Maintenant, je puis concevoir que certains ne peuvent/veulent pas assumer, je ne les blame pas. Il y a d'autres OS sur terre que linux, il y a vindauze, macos, *bsd, freedos, unix, et plein que je connais pas, je suis persuadé que tout le monde peut trouver son bonheur.
Des personnes veulent jouer avec leur ordinateur tant mieux, elles ont raison de le vouloir, MAIS ce n'est pas possible en environnement linux et bien elles peuvent rester sur windows, une Xbox coutera 300 euros, on est loin des machines à 2000 euros ou des cartes graphiques à 700 euros (pour avoir la plus grosse). Il n'y a pas de mal à être sous vindauze, ce n'est pas le mal absolu.
le mal absolu c'est des binaires sous linux.
[^] # Re: Binaire c'est mal(TM)
Posté par moramarth . Évalué à -1.
Et pas comme dans «free beer» ( http://linuxfr.org/2005/07/21/19331.html ) :P
Pour ceux qui ne suivent pas, Richard Mathew Stallman, fondateur du GNU, avait enlevé, une fois, l'ambiguïté du mot anglais «free» en faisant la comparaison entre une bière gratuite «free beer» et un discour libre «free speech»...
[^] # Re: Binaire c'est mal(TM)
Posté par Anonyme . Évalué à 2.
Mmh, pourtant ça en avait bien l'air. Mais ne t'inquiète pas, peu de personnes ont sans doute obéi à l'ordre que tu ne voulais pas faire passer :)
Mais il faut clairement interdire les hacks et hook sur le kernel.
Vu que le source est justement libre, je ne vois pas comment tu peux appliquer cette interdiction. Je simplifie, trop peut-être, mais je vois bien une simple mise en commentaire du code vérificateur. Vu certaines distributions contiennent un noyau non officiel, je ne vois pas en quoi désactiver la protection poserait problèmes aux gérants desdites distributions.
En plus, ça n'exterminera pas Ndiswrapper contre lequel tu pestes également. Ma connexion Wi-Fi est donc sauve pour le moment. :)
A moins que tu ne pensais à une nouvelle licence ?
[^] # Re: Binaire c'est mal(TM)
Posté par oops (site web personnel) . Évalué à 2.
>linux serait cantonne uniquement au serveur et aux barbus au jour >d'aujourd'hui.
Que représente dans le nombre de nombre postes dont l'utilisateur utilise réellement l'accélération 3d dans le monde :
- Commençont par enlever 99% des postes d'entreprise ( ce qui doit représenter plus de la moitié des postes total ... et je suis gentil...)
- Enlevons toutes les personnes qui ne jouent pas ( et il y en a beaucoup )
- Enlevons toutes les personnes qui jouent... uniquement sur console...
Bon au final cela représente combien de postes ?
10 % ? 20% ?
Négligeable ....
[^] # Re: Binaire c'est mal(TM)
Posté par pasBill pasGates . Évalué à -5.
T'as raison, c'est theoriquement possible.
Donc vraiment, tu devrais arreter d'utiliser un PC car si ca se trouve, le BIOS de ton PC est configure pour detecter la presence de Linux sur le disque dur et ralentir le CPU automatiquement, mieux vaut etre prudent, mets toi au boulier.
Les conneries qu'on peut lire des fois, c'est affligeant.
[^] # Re: Binaire c'est mal(TM)
Posté par hervé Couvelard . Évalué à 1.
Pour ta gouverne personnelle quel était l'objectif de tcpa/palladium ? ne pas faire tourner des applications non estampillées MS (non c'est pas Ma Salope) en mode SECURE, ce qui est exactement la même chose d'une manière différente, c'est lorsque l'on avait parlé de cela que j'ai découvert, en cherchant une alternative, VIA.
Pour ta gouverne personnelle quelle était l'objectif du tatouage du proc visible depuis l'OS ?
Ce qui est affligeant, c' est surtout (soit ta naiveté - je puis comprendre que tu défendes l'entreprise pour laquelle tu travailles) soit ta mauvaise foi.
Par exemple, pourquoi on ne veut pas de trust computing ? parce que ceux qui le décident accordent un avantage à leurs AMIS, imagine un gros ATTENTION VOUS ALLEZ EXECUTER UNE APPLICATION NON SURE SUR VOTRE MACHINE OK ANNULE, sur le pc de Mr tout le monde Mr michu il va fermer sans réfléchir si c'est écrit en ROUGE.
Savoir qu'il n'est pas possible de connecter un windows sur internet pour telecharger sa mise à jour car il meurt avant d'avoir terminé, je puis te dire que c'est affligeant : voir des bricoleurs de logiciels vendre ca comme un OS et supporter les conneries de ceux qui arrive à le défendre l'est encore plus.
Tu veux en entendre une autre de connerie affigeante ? explique moi exactement ce qui se passe sur la Xbox 360 connectée sur internet lorsque tu joues à splinter cell ?
Tu pourrais demander à ton chef une explication, il y en a plein qui serait content de comprendre pourquoi on tient une liste de ce à quoi ils jouent et pourquoi certains fichiers disparaissent de leur console.
Mon avis, c'est ton post qui est d'une connerie affligeant, étant donné le passif de micro_soft.
[^] # Re: Binaire c'est mal(TM)
Posté par pasBill pasGates . Évalué à -3.
Pour ta gouverne personnelle, ne parle pas d'une techno si tu ne sais pas a quoi elle sert et comment elle fonctionne: tcpa/palladium
Pour ta gouverne personnelle quelle était l'objectif du tatouage du proc visible depuis l'OS ?
Je sais pas, dis moi donc, ralentir Linux ? Donner ton nom a la CIA ? ... ? Parce que ce cher numero, je ne le vois pas dans mes e-mails, IE ne l'envoie nulle part quand je surf sur le web, ...
Ce qui est affligeant, c' est surtout (soit ta naiveté - je puis comprendre que tu défendes l'entreprise pour laquelle tu travailles) soit ta mauvaise foi.
Ce qui est affligeant c'est les theories du complot a la mord moi le noeud pour justifier une paranoia aigue
Savoir qu'il n'est pas possible de connecter un windows sur internet pour telecharger sa mise à jour car il meurt avant d'avoir terminé, je puis te dire que c'est affligeant : voir des bricoleurs de logiciels vendre ca comme un OS et supporter les conneries de ceux qui arrive à le défendre l'est encore plus.
Ah voila, maintenant on part dans une tout autre voie qui n'a rien a voir avec le probleme du debut, t'as juste envie de te defouler sur ton cher MS hein mon petit ? Tu te sens mieux maintenant ?
Tu veux en entendre une autre de connerie affigeante ? explique moi exactement ce qui se passe sur la Xbox 360 connectée sur internet lorsque tu joues à splinter cell ?
Tu pourrais demander à ton chef une explication, il y en a plein qui serait content de comprendre pourquoi on tient une liste de ce à quoi ils jouent et pourquoi certains fichiers disparaissent de leur console.
Dis moi d'abord quel est le probleme, on verra ensuite.
Je sens que je vais bien rire.
[^] # Re: Binaire c'est mal(TM)
Posté par Sigurr . Évalué à 4.
Alors moins haut la basse !
[^] # Re: Binaire c'est mal(TM)
Posté par pasBill pasGates . Évalué à 4.
Je te proposes de lire ca : http://www.proudlyserving.com/archives/2005/08/dos_aint_done(...)
[^] # Re: Binaire c'est mal(TM)
Posté par wismerhill . Évalué à -2.
J'utilise les driver NVidia sur ma machine pour avoir de l'accélération 3D et la sortie TV, j'en ai rien à faire de windows et tu peux aller te faire foutre!
(1h30, du someil de retard et pas envie de prendre ton intolérance avec philosophie)
# appeler le support de votre vendeur
Posté par BAud (site web personnel) . Évalué à 3.
# 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 (site web personnel) . Évalué à 2.
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.
[^] # Re: Pilotes Cartes Graphiques
Posté par glyj . Évalué à 2.
http://linuxfr.org/2005/10/06/19686.html
Je pense qu'il faudra se ruer sur ce genre de carte et devant le succès PHENOMENAL de la carte certaines sociétés se lanceront sur le créneau avant les autres....et c'en sera fini des cartes propriétaires ;-)
[^] # Re: Pilotes Cartes Graphiques
Posté par Frédéric COIFFIER . Évalué à 3.
[^] # Re: Pilotes Cartes Graphiques
Posté par Ontologia (site web personnel) . Évalué à 4.
ce qui peut constituer un marché de niche acceptable.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pilotes Cartes Graphiques
Posté par reno . Évalué à 1.
Certains ne sont interressés que par la 2D, d'autres veulent la 3D full performance donc utiliseront une carte driver proprio, d'autres ont acheté une 9200 car à l'époque c'était libre et ils ne seront interressé par une autre carte que si soit le prix est inférieur, soit les performances sont supérieur, soit le rapport performance/prix est supérieure, d'autre réutiliseront la carte graphique de leur PC tout-fait, etc..
[^] # Re: Pilotes Cartes Graphiques
Posté par skeespin (site web personnel) . Évalué à 1.
On voit bien que ce n'est pas ATI ou Nvidia le plus grands vendeurs de GPU mais Intel. Je pense qu'il y a de la place
pour des GPU "libres" surtout s'ils pouvaient être integrer
aux CM.
[^] # Re: Pilotes Cartes Graphiques
Posté par Croconux . Évalué à 6.
XGI avait annoncé il y a à peu près un an des drivers libres sauf qu'ils ne couvraient que la 2D et étaient en fait un simple rip des drivers inclus de base dans X.org en ajoutant la détection de leurs nouvelles cartes. Il ont récemment décidé de refaire une tentative pour le début de l'année prochaine (cf. http://www.phoronix.com/scan.php?page=article&item=323&a(...) ).
A voir mais bon je n'y crois pas trop. Pour VIA, ils m'ont l'air très rapides pour faire des annonces du genre "on supporte à fond Linux" mais pas très actifs au niveau code. Si les puces VIA sont supportées, c'est plutot grace au travail de bénévoles. Enfin pour S3, je ne sais pas. Il me semblait que XGI appartenait à S3. Me trompe-je ?
# Vivement que le 26 aout arrive !
Posté par totof2000 . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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é.
[^] # Re: Un problème stratégique
Posté par Calim' Héros (site web personnel) . Évalué à 5.
# Probleme de population...?
Posté par kowalsky . Évalué à 4.
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...
# Driver Nvidia 8874 et Quake IV
Posté par sylware . Évalué à 4.
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 (site web personnel) . Évalué à 8.
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...
# Activisme ?
Posté par Olivier Guerrier . Évalué à 2.
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.
[^] # Re: Activisme ?
Posté par GutsBlack . Évalué à 2.
[^] # Re: Activisme ?
Posté par Anonyme . Évalué à 5.
Par contre, devant le siège français d'ATi, ça devient nettement plus utile.
[^] # Re: Activisme ?
Posté par Corto . Évalué à -2.
Quoi... ils veulent que j'utilise des trucs (drivers) libre qui ne sont pas du constructeur parce que c'est pas libre, et en plus ca marche moins bien???
La mojorité des gens qui ont leur XP chez eux, ils ont toujours eu des binaires...
# ...
Posté par M . É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-(...)
[^] # Re: ...
Posté par mickabouille . Évalué à 4.
# Pilotes ndiswrapper
Posté par Jésus Christ . Évalué à 1.
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.
[^] # driver != firmware
Posté par Krunch (site web personnel) . Évalué à 5.
Ceci dit si on pouvait avoir le driver, le firmware et le matériel libres ça serait extra mais le driver libre avec le firmware redistribuable pour le moment ça me convient.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Pilotes ndiswrapper
Posté par Alban Crequy (site web personnel) . Évalué à 3.
Le pilote permet de charger un firmware autant libre que proprio, non?
Tout comme GNU/Linux permet de lancer des applications autant libres que proprio.
En fait, quel est l'inconvénient des firmware proprio? Le code du firmware ne s'éxécute pas sur votre processeur. Avez-vous tous un BIOS libre?
[^] # Re: Pilotes ndiswrapper
Posté par BAud (site web personnel) . Évalué à 4.
En plus pour un firmware usb sur le fast 800 ce serait pas mal d'éviter d'avoir à débrancher le modem quand il est parti en vrille => là avoir le source ça permettrait d'ajouter une fonction "réinit de force" sans avoir à décharger le pilote du modem + le pilote usb (qui fait perdre clavier et souris à certains...).
donc bon, moins grande priorité sur les firmwares, déjà qu'ils soient redistribuables (au minimum, ce qui est loin d'être le cas, ce qui est débile pour le firmware d'un modem vu que tu dois te connecter pour le récupérer ou l'avoir au préalable). M'enfin des firmwares libres, ça ferait pas grand mal à grand monde... voire je préfèrerais franchement.
Sans être parano mais un peu fuddesque, qui dit que le firmware n'envoie pas ton IP/mac address à un serveur central ? en libre, beaucoup plus de monde peut le constater et rassurer.
[^] # Re: Pilotes ndiswrapper
Posté par Krunch (site web personnel) . Évalué à 3.
http://www.fsf.org/campaigns/free-bios.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Du matériel libre?
Posté par godzom . Évalué à 4.
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)
[^] # Re: Du matériel libre?
Posté par Krunch (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Du matériel libre?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Du matériel libre?
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: Du matériel libre?
Posté par BAud (site web personnel) . Évalué à 3.
Dommage la certification open-hardware n'a plus l'air très active depuis 2002 d'après http://www.open-hardware.org/Status.html
# esfedq
Posté par TImaniac (site web personnel) . Évalué à -1.
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.
[^] # Re: esfedq
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: esfedq
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: esfedq
Posté par Zenitram (site web personnel) . Évalué à 6.
Le probleme est le pilote, pas Linux : si le pilote est libre, le pilote est adapté dans les 10 secondes a la nouvelle interface, et profite du gain apporté.
La force du libre est juste ceci : pas de contrainte au niveau binaire. Win2000 il y a 5 ans pose le probleme que si on a une meilleure idée pour l'interface, boom pas possible. MS ne se prive pas de casser les interface (entre Win3.x et Win9X, entre Win9X et Win2000...) ton argument est un argument contre toi : MS casse bien les interfaces (certes moins souvent, mais c'est deja trop), et une tonne de pilotes meurent car non adaptables...
Un interface binaire est certes utile si on veut du closed-source, si on ne veut pas du close-source dans les pilotes, geler une interface n'est absolument pas utile.
Donc tu n'es pas coherant : soit tu es pour les drivers closed-source interdits et donc tu n'a aucun argument pour la stabilité des interfaces, soit tu es pour les drivers closed-source acceptables et la une interface gelée est necessaire. Etre entre les deux est bizarre... Pourquoi avoir besoin d'interface stable si tu es contre les drivers closed-source?
[^] # Re: esfedq
Posté par TImaniac (site web personnel) . Évalué à 3.
Au contraire : que des enmerdes au niveau binaires. C'est pour moi un des gros problèmes du libre justement. Sous prétexte qu'on a les sources on se fou royalement de la compatibilité binaire. Ca pose de nombreux problèmes de maintenance, de support, d'incompatibilités, et d'une manière générale ca empêche Linux de vraiment percer.
ton argument est un argument contre toi : MS casse bien les interfaces (certes moins souvent, mais c'est deja trop), et une tonne de pilotes meurent car non adaptables...
L'argument ne se retourne pas du tout, j'ai clairement dit qu'il fallait parfois changer les interfaces lors de grosses évolutions, et pour moi les passages de win3 à win9x à win2000 sont autant de grosses évolutions qui justifient des incompatibilités. Mais une interface reste stable pendant un certain temps. Sous Linux c'est l'orgie permanente dans le noyau.
et une tonne de pilotes meurent car non adaptables...
Ca c'est parcque c'est des pilotes binaires fermés et proprio. Je l'ai dis clairement, je suis contre les pilotes binaires fermés.
Un interface binaire est certes utile si on veut du closed-source, si on ne veut pas du close-source dans les pilotes, geler une interface n'est absolument pas utile.
Moi je crois surtout qu'une interface en perpétuelle évolution est un signe de bordel constant, de risques potentiels d'incompatibilités, de temps perdu en maintenance de centaines de drivers, et surtout une excuse pour ne pas "se faire chier" à bien concevoir ces interfaces justement.
La compatibilité binaire n'est pas du tout contradictoire avec le libre, je crois que Linux a besoin d'une compatibilité binaire, pas spécialement pour aider les softs proprio fermés, mais pour Linux lui même. Pour sa maintenance. Pour sa diffusion. Pour sa distribution.
Pourquoi avoir besoin d'interface stable si tu es contre les drivers closed-source?
Pour pleins de choses :
- forcer les développeurs à "réfléchir" avant de coder l'interface : bref à pondre un truc conçu pour être évolutif, et non pondre un bousin en se disant "cpa grave on pètera tout plus tard"
- faciliter la distribution (qui a dit incompatibilités entre distributions ?)
- arrêter de perdre du temps à maintenir la même chose pour 1000 versions.
J'ai eu l'occasion d'utiliser GStreamer en tant que développeur, rien de plus pénible que de voir des interfaces modifiées à chaque mise-à-jour. Je perdais un temps fou à suivre les "évolutions".
Seulement j'étais tolérant car je savais que ce n'était pas une interface "stable", GStreamer n'étant pas en version 1.0. Je suis heureux de voir qu'à l'approche de la 1.0 le tout se stabilise.
[^] # Re: esfedq
Posté par Colin Leroy (site web personnel) . Évalué à 4.
Gaël Duval, sors de ce corps! ;-)
La compatibilité binaire on s'en fout, effectivement, parce qu'on a les sources. Ça ne gêne que les éditeurs propriétaires.
Plus sérieusement et pour en revenir au sujet initial. Figer les APIs d'un truc en évolution constante comme le noyau Linux, c'est s'obliger à trouver des workarounds à chaque fois que l'API existante ne suffit plus - ce qui arrive toujours quel que soit le soin que tu apportes à la définition de ton API, s'obliger à des hacks crades pour pouvoir les nouveaux trucs que tu veux faire sans trop casser les anciens, et tu finis par en être réduit, comme Microsoft, à maintenir trois APIs USB différentes pendant plusieurs années (je ne retrouve pas le lien, non).
D'après ta signature tu développes en Mono, qui comme Java supporte les fonctions à multiples prototypes comme
void doStuff(Object victim);
void doStuff(Object victim, boolean do_it_all);
Ceci a tendance à fortement (très fortement) réduire le besoin de changer une API, car tu peux l'étendre sans avoir à réparer tous les utilisateurs de ladite API.
En C, tu n'as pas ça.
[^] # Re: esfedq
Posté par CrEv (site web personnel) . Évalué à 1.
Et pourquoi pas passer le noyau en java ou C# alors ?
...
non ?
...
toujours pas ?
bon tan pis, je retourne à mon perl :-D
[^] # Re: esfedq
Posté par Zenitram (site web personnel) . Évalué à 0.
(J'avoue n'avoir toujours pas compris les adeptes du C sur le C++... sans vouloir forcement troller :) )
[^] # Re: esfedq
Posté par Miair Patreau . Évalué à 9.
Noyauterie : On ne doit pas utiliser de langage qui cherche à gérer la mémoire, ou quoi que ce soit dépassant l'assembleur amélioré, lui-même pour coder du noyau monolithique, c'est mal. Méthode de preuve :
- essayer,
- pleurer,
- retenir la leçon.
Exceptions : elles sont le grand n'importe quoi en C++ et nécessitent une véritable usine à gaz dans les bibliothèques de base pour fonctionner (presque),
Sinon, dans le cas général où l'abstraction est souhaitable et non pas bannie, je préfère le C++ au C.
[^] # Re: esfedq
Posté par TImaniac (site web personnel) . Évalué à 4.
Je ne suis pas un éditeur propriétaire, et ca m'enmerde. Je t'ai donné un exemple concrêt. Maintenant un autre exemple, amuses-toi pour le fun à reprendre un programme sur le net qui est vieux de y'a 3 ans sous Linux. Bien sûr tu es madame Michu et tu ne connais rien à gcc & co. Tu fais quoi ?
Ceci a tendance à fortement (très fortement) réduire le besoin de changer une API, car tu peux l'étendre sans avoir à réparer tous les utilisateurs de ladite API.
Ah bah voilà qui est mieux et qui rejoint ce que je dis :)
En gros l'API n'est pas changé, il est juste étendu. L'interface initiale est inchangée et fonctionne toujours.
comme Microsoft, à maintenir trois APIs USB différentes pendant plusieurs années (je ne retrouve pas le lien, non).
Ben au moins ils assument les changements, et doivent désormais réfléchir à 2 fois avant de pondre une interface. Je préfères largement avoir ouvertement plusieurs versions d'une interface, et maintenir ces interfaces pendant un certain temps, plutôt que d'avoir une seule interface qui bouge tout le temps, les développeurs démerdez-vous pour suivre.
On doit pas avoir la même vision du service rendu aux développeurs.
[^] # Re: esfedq
Posté par Krunch (site web personnel) . Évalué à 3.
Au fait pour cette histoire de foo(x) compatible avec foo(x, y), c'est aussi possible en C après tout (foo(...)). Quelqu'un y a déjà pensé ? (bien que je doute que ça soit suffisant pour garder une interface compatible dans beaucoup de cas)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: esfedq
Posté par TImaniac (site web personnel) . Évalué à -1.
Cela reste une perte de temps, et surtout cela suppose que le noyau maintien tous les drivers/modules. Tu me diras c'est peut être pour ca qu'on a un bousin monolithique.
Pour les modules qui ne sont pas dans le noyau vanille et qui doivent donc être modifiés par leur mainteneur ben c'est soit que leur qualité est insuffisante soit...qu'ils ne sont pas libres.
Ou tout simplement qu'ils ne sont pas intégrés au processus de devel du noyau.
Evidemment quand les modifs sont en "interne" au noyau, les APIs stables ne sont pas forcement "utiles", mais il faut faire le raisonnement inverse : cette instabilité des APIs "ferme" le noyau, dans cette dépêche cette fermeture se fait au dépend des pilotes binaires non libre, mais d'une manière générale cela reste une fermeture tout court, aussi bien aux pilotes libres maintenus par des tierces personnes.
Même en supposant qu'un constructeur décide de faire des pilotes "libres", il est normal qu'il souhaite en être le mainteneur principal, mais le modèle de devel du noyau (modèle fermé par changement incéssant des interfaces) l'obligerait à laisser son contrôle à d'autres développeurs.
En fait le noyau est l'anti-thèse des standards. Il ne respecte rien, même en interne. C'est comme si OOo 1.1.3 était incompatible avec OOo 1.1.2 incompatible avec 00o 1.1.1, etc.
Les interfaces c'est comme les standards, il n'a jamais été écris qu'ils ne pouvaient pas évoluer, ce n'est pas pour autant qu'ils ne doivent pas exister et être stable, par soucis d'interopérabilité et d'ouverture.
Et je suis convaincu que cette mauvaise foi concernant les pilotes binaires n'est qu'une façon de cacher des lacunes flagrantes d'architecture et d'organisation au coeur du noyau.
Voilà tout ca pour dire que le noyau lui même contribue au final à son manque de succès auprès des fabriquants matériels.
[^] # Re: esfedq
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: esfedq
Posté par TImaniac (site web personnel) . Évalué à 0.
Je parle pas de la compatibilité binaire des exécutables, ca reste du x86 avec du posix, on parle de la compatibilité des modules/pilotes qui s'interfacent directement avec le noyau.
J'ai voulu comparer une interface et un standard (celui de OOo) et j'ai justement voulu montrer que cette interface n'était pas "interne", mais bien une interface "publique" avec laquelle devrait pouvoir s'interfacer tous les pilotes, qu'ils sont libres ou non, maintenus par l'équipe du noyau ou une équipe tierce.
Et je reproche au final à cette interface de pilotes d'être maintenue comme une interface interne alors qu'elle devrait s'ouvrir et se stabiliser.
[^] # Re: esfedq
Posté par HappyPeng . Évalué à 8.
Le prétexte est le suivant : puisque c'est libre, vous n'avez qu'à adapter votre driver puisque vous pouvez le faire. Simplement c'est abuser des ressources dont nous disposons : les développeurs n'ont pas que ça à faire, déjà souvent de développer le logiciel ; alors que là on leur demande en plus de cesser toute innovation pour faire du simple portage à chaque fois qu'une version mineure du noyau sort. Quel gaspillage ! Et aussi, quel enfer pour l'utilisateur ...
Partout on ne parle que de formats standards, d'API standards, d'interfaces définies, versionnées et stables. Le kernel ne fait _aucune_ exception. GNOME par exemple ne changerait pas ses interfaces tous les quatre matins en disant "les développeurs peuvent adapter leurs applications".
C'est tout simplement absurde.
Quand à l'argument de la rapidité de développement, certes. C'est de la rapidité de développement sans phase de conception et de réflexion préalable, on écrit du code spaghetti, on avance par patch mineur sur patch mineur : ça n'est pas non plus un bon prétexte. Des interfaces bien conçues doivent pouvoir durer plus de deux semaines. (POSIX dure bien des années.)
# attention danger...linux pourait disparaitre
Posté par GNUtoo . Évalué à 1.
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?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.