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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aller plus loin

  • # C'est parti ..

    Posté par  (site web personnel) . Évalué à 10.

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

    Le but de Linux c'est d'avoir un système d'exploitation libre, pas gratuit.
    • [^] # Re: C'est parti ..

      Posté par  . Évalué à 7.

      <troll inside>
      Le but de Linux c'est d'avoir un système d'exploitation libre, pas gratuit.
      Non - ça s'est le but du GNU
      </troll inside>
      • [^] # Re: C'est parti ..

        Posté par  . Évalué à -6.

        <troll is out>
        Pourquoi tu ne dis pas "Gnu\Linux" ?

        Je ne vois que des distributions Gnu\Linux ... De plus, GNU est un projet regroupant d'autres projets. Je pense que "Linux" ne devrait pas s'appeler "Linux" mais "Gnu".

        Je souhaite rajouter que Linux est publie sous la license GNU "GPL" et qu'il a donc pour but de fournir un kernel libre, modifiable ...
        </troll is out>

        IzuliuM ;)
        • [^] # Re: C'est parti ..

          Posté par  . Évalué à 10.

          Halala...
          Un si joli troll, concocté, mitonné avec amour...
          Et paf, c'est le drame: un back-slash à la place d'un simple slash, et ça fout tout par terre. (sans parler des majuscules ;) )

          Pour futures references: GNU/Linux :)
        • [^] # Re: deja pris

          Posté par  . Évalué à 5.


          "Linux" ne devrait pas s'appeler "Linux" mais "Gnu".


          1 - Le système "Gnu" existe déjà et utilise le Hurd
          2 - Linux à débuté indépendemment du projet GNU et n'est pas un projet GNU.
          • [^] # Re: deja pris

            Posté par  (site web personnel, Mastodon) . Évalué à -2.

            "indépendemment" ???

            le jeune Linus utilisais gcc et minix pour développer son petit noyau monolithique. et GCC c'est GNU !

            M.
            • [^] # Re: deja pris

              Posté par  (site web personnel) . Évalué à 9.

              J'utilise GCC pour compiler mes programmes C, ça en fait pas des programmes GNU. Linux est indépendant de GCC dans le sens où n'importe quel compilateur C est censé pouvoir compiler Linux.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: deja pris

                Posté par  . Évalué à 4.

                N'importe quel compilateur C supportant certaines extensions de GCC.
              • [^] # Re: deja pris

                Posté par  (site web personnel) . Évalué à 7.

                Linux est indépendant de GCC dans le sens où n'importe quel compilateur C est censé pouvoir compiler Linux.
                Non, uniquement gcc. C'est écrit noir sur blanc dans le README à la racine des sources.
                Et à d'autres endroits qu'il ne liront pas les rapports de bugs fait avec d'autres compilateurs.

                Alors bon, en pratique ça marche avec d'autres, mais c'est pas plus un objectif que le support des pilotes binaires.
                • [^] # Re: deja pris

                  Posté par  . Évalué à 1.

                  Je ne sais pas si "ça marche avec d'autres", il y a beaucoup de "trucs" spécifiques à GCC dans le code du noyau.
                • [^] # Re: deja pris

                  Posté par  . Évalué à -1.

                  non , je viens de telecharger le noyau 1.0 et ce n'est pas marqué , car la on parle du début du devellopment du noyaux
            • [^] # Re: deja pris

              Posté par  . Évalué à 1.

              le jeune Linus utilisais gcc et minix pour développer son petit noyau monolithique. et GCC c'est GNU !


              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  (site web personnel) . Évalué à 4.

            Linux à débuté indépendemment du projet GNU et n'est pas un projet GNU.
            Je ne pense pas que Linus aurait inventé la GPL. Il était déjà pas bien chaud pour ouvrir son code à la base... (cf sa bio)
            C'est un fan de la FSF qui lui a ouvert les yeux.

            De plus les développeurs Linux ont mis dans leurs prérequis GCC>2.95.3 et GNU Make>3.79.1.
            Sur d'autres compilateurs/make les rapports de bugs sont ignorés.
            C'est quand même une reconnaissance officielle.
            • [^] # Re: deja pris

              Posté par  . Évalué à 2.

              Linus n'aurait pas inventé la GPL.

              Ceci dit, s'il a choisi la GPL, c'est pour faire un logiciel gratuit mais un logiciel libre. On ne peut pas prétendre qu'il ait voulu faire un logiciel gratuit puisque nulle part dans sa licence il n'est dit que linux est gratuit.
      • [^] # Re: C'est parti ..

        Posté par  . Évalué à 5.

        Ce troll là il, je ne peux pas résister:
        Tu vas pas nous faire chier, c'est un des buts de GNU/Linux ;)
        C'est plus clair comme ça ?
    • [^] # Re: C'est parti ..

      Posté par  . Évalué à 1.

      .. ne vont pas faire l'effort de les porter sur d'autres architectures si ça ne génère pas de ventes significatives.


      En liberant les specs, ils pourraient avoir des ventes supplementaires
      Peut etre pas significatives mais un sou est un sou, non ?
      Ils auraient alors acces pour presque rien à un marché qu'il nauraient pas eu autrement. Et le boulot serait fait par la communauté

      Ce n'est pas envisageable de liberer pour une architecture/os donné (ils peuvent se garder le win32 si ils veulent) ? Celà restreint la liberté mais serait un pas dans la bonne direction

      laurent
      • [^] # Re: C'est parti ..

        Posté par  (site web personnel) . Évalué à 5.

        Problème: les entreprises ne veulent ni libérer les specs, ni faire une version source de leur(s) driver(s) pour des raisons de propriétés intelectuelles:
        - soit le source possède une nouvelle technologie que les entreprises ne voudraient pas diffuser à leur(s) concurent(s) [peu probable: les nouvelles technologies des constructeurs sont plutôt présentes au niveau hardware]
        - soit le source utilise des technologies brevetés par d'autres sociétés [plus probable: l'industirel préfere obscurcir que laisser en clair une preuve flagrante de l'utilisation d'un brevet]

        Finalement, on en revient toujours aux brevets.
        • [^] # Re: C'est parti ..

          Posté par  (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]

          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  (site web personnel) . Évalué à 3.

            Et la ca coince parce que la lutte entre ATI & Nvidia par exemple ce joue énormement sur les drivers et leurs perfs.
            Surtout les drivers "optimisés" pour les benchmarks comme le 3DMarks & Co. 20 Mo (ou +) pour un driver de carte vidéo, ça semble un minimum désormais (sous Windows en tout cas, c'est moins sous Linux). Quand à savoir ce qu'il y a dans ces drivers...
            • [^] # Re: C'est parti ..

              Posté par  (site web personnel) . Évalué à 4.

              Pour beaucoup de driver, mais ça installe en sus une tonne de logiciels "indispensables pour profiter des fonctions évoluées de votre carte machin2000" c'est à dire, dans le cas d'une carte son, un logiciel de réglage du son lourd, peu réactif et plein d'options inutiles.
          • [^] # Re: C'est parti ..

            Posté par  . Évalué à 5.

            Dans le cas de ce genre de pilotes (ceux où "c'est le driver qui en gere une tres grosse part [du boulot]") si la couche d'adaptation (glue) est bien faite, je suis près à faire des concessions dans mes revendications libristes.

            Prenons le cas du driver nvidia. Essayons de ne plus penser en terme d'opposition matériel/logiciel. Il y a donc une couche supérieure, connectée au noyau, qui est libre et tout ce qui est plus bas niveau est propriétaire (logiciel et matériel). J'ai même cru comprendre que cette couche bas niveau était à peu près la même sous linux ou windows.
            Il n'existe presque aucun matériel libre, et personne ne crie au scandale. En quoi cette couche de logiciel est-elle intrinsèquement différente ?
            Ce que nous demandons, ce sont les spécifications du matériel. Et si c'est l'interface de cette couche logicielle qu'on nous fournit, comment doit on réagir ?

            Le véritable problème réside dans le deuxième type de pilotes. Ceux qui sont distribués sous formes de binaires adaptés à une seule distribution. Ceux là devraient être évités à tout prix. Mais les utilisateurs de ces pilotes sont bien souvent des entreprises qui ont choisi linux uniquement par pragmatisme, pas du tout par amour du libre.
            Les distributions pour lesquelles ces pilotes sont écris on en plus un avantage par rapport aux concurrents. Ça ne va pas les pousser à crier au scandale. Et même, ces distributions emploient bon nombre de développeurs noyau qui vont, eux aussi, avoir un jugement biaisé.

            Tout ça ne fait pas de nvidia le bon samaritain du libre, mais sachons établir des priorités dans notre recherche de liberté.
            • [^] # Re: C'est parti ..

              Posté par  . Évalué à 3.

              Alors peut etre que je me trompe mais la fameuse couche glue de nvidia dans le noyeau linux est opensource (forcément sinon ça peut pas marché avec tout les noyeau) mais pas du tout libre!

              Ensuite le problème d'avoir une couche pas libre ou que ce soit c'est qu'on ne peut pas faire evoluer le système. exemple si on décide d'utiliser plutot directfb que x.org a partir de demain il faudras atendre que nvidia fasse des pilotes une nouvelle couche glue et tout.

              En tout cas moi mon avis c'est de ne pas faire de concession, il faut rester libre meme si ça doit ralentir la propagation de linux. je prefaire que linux soit moins utilisé mais propre plutot que répandu mais tainted dans tous les sens. Ne passont pas du coté obscur pour plus de pouvoir.
              • [^] # Re: C'est parti ..

                Posté par  . Évalué à -1.

                Alors peut etre que je me trompe mais la fameuse couche glue de nvidia dans le noyeau linux est opensource (forcément sinon ça peut pas marché avec tout les noyeau) mais pas du tout libre!

                je pensais que cette couche avait été modifiée pour fonctionner avec les noyaux 2.6 par exemple quand ils n'étaient pas supportés par nvidia.
                Je ne suis pas du tout sur de moi, passons sur ce "détail".

                Ensuite le problème d'avoir une couche pas libre ou que ce soit c'est qu'on ne peut pas faire evoluer le système. exemple si on décide d'utiliser plutot directfb que x.org a partir de demain il faudras atendre que nvidia fasse des pilotes une nouvelle couche glue et tout.

                Biens sur, mais continuons dans mon analogie en considérant cette surcouche logicielle comme une extension du matériel. Si j'achète un modem, je ne peux pas l'utiliser comme répondeur téléphonique. Je me limite par rapport à un winmodem, mais personne ne vient se plaindre, au contraire. On se simplifie la vie avec des primitives plus haut niveau, mais on diminue les possibilités, c'est certain.

                En tout cas moi mon avis c'est de ne pas faire de concession, il faut rester libre meme si ça doit ralentir la propagation de linux. je prefaire que linux soit moins utilisé mais propre plutot que répandu mais tainted dans tous les sens. Ne passont pas du coté obscur pour plus de pouvoir.

                Quelles belles paroles, je pense qu'à peu près tout le monde ici est d'accord avec toi.
                Cependant, quand il s'agit de mettre ces paroles en application, les choses se corsent.
                Il existe des systèmes qui ont toujours été plus rigoureux sur l'application du libre que linux. Je pense notament à GNU. Es-tu pour autant un utilisateur du Hurd ?
                Meme parmis les distributions linux, certaines sont plus rigoureuses, par exemple debian, mais celle-ci perd des utilisateurs au profit d'autres, telle qu'ubuntu.
                Quel est le problème ? Tout simplement, plus de rigueur signifie moins de performances, moins de performances, moins d'utilisateurs, moins d'utilisateurs, moins de contributeurs, moins de contributeurs, moins de performances ... C'est un cercle vicieux.
                • [^] # Re: C'est parti ..

                  Posté par  . Évalué à 3.


                  Biens sur, mais continuons dans mon analogie en considérant cette surcouche logicielle comme une extension du matériel. Si j'achète un modem, je ne peux pas l'utiliser comme répondeur téléphonique. Je me limite par rapport à un winmodem, mais personne ne vient se plaindre, au contraire. On se simplifie la vie avec des primitives plus haut niveau, mais on diminue les possibilités, c'est certain.


                  je comprend pas vraiment ou tu veut en venir mais en fait tout est question de frontière a mon avis. Les pilotes c'est notre coté, le firmware c'est le leur, si on a des drivers proprio la frontière recule on nous mange notre téritoire on perd . si on a des firmwares libres la frontière avance on gagne ! alors avec le materiel libre la c'est carrement victoire totale. maintenant la limite avec les pilotes chez nous c'est a mon avis la solution minimum, peut etre bientot avec l'arrivé des nouvelles cartes XGI on aura des cartes graphique bien avec des pilotes libres qui peut savoir.

                  ensuite les winmodem peuvent marché sous nux si y'a les spec qui sont distribué.


                  Quelles belles paroles, je pense qu'à peu près tout le monde ici est d'accord avec toi.
                  Cependant, quand il s'agit de mettre ces paroles en application, les choses se corsent.
                  Il existe des systèmes qui ont toujours été plus rigoureux sur l'application du libre que linux. Je pense notament à GNU. Es-tu pour autant un utilisateur du Hurd ?
                  Meme parmis les distributions linux, certaines sont plus rigoureuses, par exemple debian, mais celle-ci perd des utilisateurs au profit d'autres, telle qu'ubuntu.
                  Quel est le problème ? Tout simplement, plus de rigueur signifie moins de performances, moins de performances, moins d'utilisateurs, moins d'utilisateurs, moins de contributeurs, moins de contributeurs, moins de performances ... C'est un cercle vicieux.


                  alors je crois pas que ubuntu utilise du logiciel proprio mais peut etre je me trompe et ensuite son succé est a mon avis plutot du au fait que c'est simple a installer, 2 3 menus puis boom un bureau gnome tout pret...

                  enuite la rigueur c'est pas une question de système, je crois pas avoir de logiciels proprio sur le mien, en tout cas j'ai ni drivers proprio ni flash kipuképalibre et je suis pas sur qu'on puisse en dire autant de tout le monde même ici (je m'envois pas de roses hein, c'est ma philosophie c'est tout).

                  Le problème avec les concession c'est qu'on fini sous windows genre : "ouai j'adore linux le libre tout ça mais je suis sous windows parce que y'a le jeu machinchose qui marche que avec ie sous window"
            • [^] # Le risque n'est pas le même

              Posté par  . Évalué à 6.

              En quoi cette couche de logiciel est-elle intrinsèquement différente ?

              Elle ne fonctionne pas sur le périphérique, comme un firmware, mais sur le processeur central, en mode noyau.

              Ça lui ouvre nettement plus de possibilités pour planter le système ou contenir du code malicieux sans qu'on le sache...

              Même en espérant que nVidia n'est pas un autre Sony, comme tout fabriquant de carte 3D, ils programment leurs drivers pour la performance (pour impressionner plus que le concurrent), en dépit de toute autre considération. Confronté à ce problème Microsoft a mis en place il y a plusieurs années un programme de certification des drivers pour obliger les fabriquants de matériel à faire des drivers potables qui ne plantent pas (plus ;-) ) Windows; sous Linux, ils peuvent à nouveau "se lâcher" et je suis convaincu qu'ils le font.
              Exemple : j'ai installé une fois (!) un driver nVidia propriétaire (pas sur ma machine et encore moins sur un serveur, et c'était ça, le driver VESA, ou la mise-à-jour d'XFree, voire de la distrib), ça marchait super bien... jusqu'à ce que l'APM ou l'ACPI se déclenche. Là, freeze complet du système. Efficace.

              Avoir une architecture à micronoyau où les pilotes tourneraient en mode non privilégié limiterait déjà beaucoup le risque, en échange d'une certaine perte de performances.
              Andrew Tannenbaum considère que le jeu en vaut la chandelle (c'est le genre de trucs qu'il reproche à l'architecture du noyau de Linux), et je serais assez d'accord avec lui si un jour on ne peut éviter d'utiliser ces saletés de drivers binaires.
              Cela dit, les considérations sont différentes suivant qu'on utilise sa machine uniquement comme une console de jeux en plus cher, pour stocker ses informations bancaires, ou comme serveur pour le boulot. Mais comprend qu'il y en a qui ont besoin d'un Linux fiable.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

              • [^] # Re: Le risque n'est pas le même

                Posté par  . Évalué à 1.

                En tout cas chez ati je peut t'affirmé qu'ils ne se lachent pas sur les drivers pour obtenir une meilleur performance!
                • [^] # Re: Le risque n'est pas le même

                  Posté par  . Évalué à 0.

                  Il faudrait que tu argumente un peu plus... pour qu'on puissent juger...
                  Ce n'est pas que je mette en doute ta parole mais si tu pouvais nous donner d'autres infos.
                • [^] # ATI...

                  Posté par  . Évalué à 2.

                  En tout cas chez ati je peut t'affirmé qu'ils ne se lachent pas sur les drivers pour obtenir une meilleur performance!

                  Ah ?
                  Je ne suis pas allé assez loin avec les pilotes ATI pour en avoir une idée.
                  Mon expérience avec ATI se limite à l'essai d'une Mandriva qui m'a installé le pilote ATI propriétaire sans me demander mon avis (alors que j'ai une Radeon 9200 justement parce que c'est l'une des dernières ATI supportées par le pilote libre).
                  Résultat, dès le premier chargement de X, affichage pourri et gelé (j'admet, j'ai une carte pas ATI à base de chipset ATI, mais il n'est pas dit que le pilote ne supporte que les ATI pur sucre !).
                  Ensuite, j'ai redémarré en runlevel 3 le temps nettoyer le système du pilote propriétaire et, magie, plus de problème...

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

              • [^] # Re: Le risque n'est pas le même

                Posté par  . Évalué à 0.

                Ça lui ouvre nettement plus de possibilités pour planter le système ou contenir du code malicieux sans qu'on le sache...

                J'ai du mal à comprendre qu'on puisse faire planter le système plus facilement avec du code qu'avec du matériel.
                Une carte mal développée peut endommager ma carte mère, elle peut ne pas tout à fait effectuer ce que lui demande le système, elle peut corrompre la mémoire ...
                Je pense par contre que le code est souvent écris plus "à la vas vite" et c'est certainement la raison qui fait qu'on a plus confiance en le matériel.

                Mais comprend qu'il y en a qui ont besoin d'un Linux fiable.

                Là n'est pas le problème. Je reprend mon argument précédent. Si le logiciel est écrit avec les pieds, ton linux n'est pas fiable, mais si le matériel a une erreur de conception, ton serveur risque encore plus ...

                Certes, l'une des raisons qui pousse pas mal de monde à refuser d'utiliser les pilotes propriétaires est leur réputation d'instabilité.
                Je pense que c'est se tromper de bataille. Le vrai problème est de garder une alternative libre.
                Si la fiabilité est la préoccupation numéro un, il existe des unices propriétaires qui font très bien leur travail.
                • [^] # Re: Le risque n'est pas le même

                  Posté par  . Évalué à 5.

                  Je pense par contre que le code est souvent écris plus "à la vas vite" et c'est certainement la raison qui fait qu'on a plus confiance en le matériel.

                  Certainement, en tout cas dans le cas des fabriquants de périphériques.
                  On peut facilement trouver un matériel qu'on considère comme étant d'une certaine qualité. Pour un pilote propriétaire, il faut bien prendre celui fourni par le constructeur, et si l'on se pose avant la question de choisir un matériel fourni avec un pilote propriétaire de qualité, là, on ne trouve pas grand chose...
                  Peut-être aussi est-ce qu'on se dit qu'un problème matériel se manifeste généralement assez vite et que si cela a fonctionné correctement pendant un certain temps, c'est que ça doit être bon.
                  À part cela, on peut aussi, notamment sur un serveur, utiliser du RAID si l'on n'a pas confiance dans les disques, utiliser de la mémoire ECC... Du côté des pilotes, je n'en vois pas trop qui comprennent un système pour rattrapper leur éventuelle défaillance.

                  Si la fiabilité est la préoccupation numéro un, il existe des unices propriétaires qui font très bien leur travail.

                  Si l'on ne considère que la fiabilité technique, en effet. En particulier, sur les Unix propriétaires, les pilotes ne sont généralement pas écrit par le fabriquant des périphériques, mais par le vendeur du système. Du coup, il y a moins de pilotes, peut-être moins performants, mais plus fiables.
                  Cependant, si l'on considère dans la fiabilité l'assurance de ne pas avoir de backdoor dans le système, on n'est pas très avancé avec un Unix entièrement propriétaire...

                  D'ailleurs, la différence importante, entre le matériel et le logiciel, se situe justement dans ce domaine. Si l'on se pose les questions, pour être caricatural, "Est-ce que ma carte réseau ne laisserait pas des fois la NSA accéder à ma machine comme elle veut ?" et "Est-ce que le pilote propriétaire de ma carte réseau ne laisserait pas des fois la NSA accéder à ma machine comme elle veut ?", il est plus difficile pour le firmware qui tourne sur le chip intégré à la carte d'aller prendre le contrôle du noyau que pour le pilote qui est déjà exécuté sur le CPU en mode privilégié...

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                  • [^] # Re: Le risque n'est pas le même

                    Posté par  . Évalué à -1.

                    il est plus difficile pour le firmware qui tourne sur le chip intégré à la carte d'aller prendre le contrôle du noyau que pour le pilote qui est déjà exécuté sur le CPU en mode privilégié...

                    J'avais entendu parler d'ordinateurs portables auxquels on avait greffé une simple petite mémoire entre le clavier et le reste.
                    Dans ces conditions, meme avec le système logiciel le plus libre du monde, il est relativement simple pour le SAV de récupérer tes mots de passe et données sensibles.

                    Attention, une fois de plus, je ne fais pas l'apologie du propriétaire ("de toute façon, on peut récupérer mes mots de passe meme sous linux, autant repasser sous windows")
                    Je ne fais que dire : concentrons nous sur le plus urgent, les pilotes propriétaires qui reposent sur une ABI fixe. Le reste viendra après.
        • [^] # Re: C'est parti ..

          Posté par  . É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  . Évalué à 1.

      d'accord de plus je ne vois pas en quoi donner des specifications de materiel peut gener un constructeur ( a croire que les concurrents ne savent pas faire du reverse ingenering ) a moins que les construteurs se livrent a quelques magouilles peut avouables ( on gomfle un peut les perfs avec un petit overclocking !!! ).

      perso j'en ai marre des pilotes prives qui ne marchent pas ( exemples ati ) j'ai l'impression d'etre revenu en 95 quand linux etait tout jeune et que les cartes n'etaient pas encore bien supportees.

      cela rappelle la jeunesse mais qu'est que c'est gonflant !
      ps : j'ai toujours pas d'acceleration avec les pilotes ati (merci ati de pondre plus vite des cartes et pas de drivers qui tiennent la route!!!)
    • [^] # Re: C'est parti ..

      Posté par  . Évalué à -5.

      A mon avis il faudrai interdire les pilotes non libres puisque a priori c'est lié du code gpl avec du non gpl et a ma connaissance (mais peut etre il y a des details qu je ne connais pas) c'est interdit! ensuite on pourait faire un nouveau système pour l'affichage ou les pilotes graphique sont entièrement dans le noyau (a leur place quoi) comme ça on se débarasse des drivers proprio ati (pourri) et nvidia et en plus on se débarasse du serveur X (usine a gaz), double avantage donc.
      • [^] # Re: C'est parti ..

        Posté par  . Évalué à 3.

        Youhouhou, grande idée ! Tu devrais tout de suite écrire à la lkml pour leur dire :)
  • # OpenBSD

    Posté par  (site web personnel) . Évalué à 10.

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

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

    Linuxfr a déjà relayé certaines des campagnes pour la publications des spécifications:
    http://linuxfr.org/2005/03/19/18549.html
    • [^] # Re: OpenBSD

      Posté par  (site web personnel) . Évalué à 10.

      Il me semble que c'est la seule démarche utile. Linux "souffre" d'être utilisé en majorité sur plateforme i386 et c'est peut-être pour ça que beaucoup d'utilisateurs ne voit pas le problème de logiciels closed-source pour Linux, que ça soit pour les drivers ou, par exemple, flash, acrobat reader, etc...
      Mais ceux qui ont essayé Linux sur machine Apple ont déjà plus de difficulté. Et les innombrables portages des *BSD ne peuvent effectivement pas se satisfaire d'une telle situation.

      "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

      • [^] # Re: OpenBSD

        Posté par  (site web personnel) . Évalué à 1.

        Ben, y'a aussi le fait que les gens utilisent ce qu'il faut pour faire fonctionner leur machine.

        Sur mon portable et sur mon pc chez moi, j'ai les drivers Nvidia, pourquoi? Parce que il offre quand meme pas mal de chose au niveau accélération 2D par rapport au driver nv.

        Y'a un an, j'ai acheté une carte ATI Radeon 7500(bien supporté par le driver dri) histoire de me débarrasser de ma carte nvidia, résultat, ca ne fonctionne pas sur mon écran, j'ai un affichage flou(police qui bave) et bien sur, c'est pas un probleme de conf, ca ne le fait qu'avec mon Ecran :(

        Résultat, bah j'ai tjs les driver nvidia sur ma machine :(
    • [^] # Re: OpenBSD

      Posté par  (site web personnel) . Évalué à 3.

      Le problème, c'est l'alternative: dans le monde de la 3D par exemple, à part Nvidia et Ati il n'y a pas grand chose (d'où l'existence d'ailleurs d'un projet de carte graphique libre). Il faudrait vraiment que les parts de marchés s'érodent sérieusement avant qu'une entreprise réagisse.

      Le meilleur vecteur d'attaque pour une réelle ouverture n'est _pas_ le monde du desktop et de l'utilisateur lambda malheureusement. Les gens veulent que ça marche et une grande partie de la population linuxienne n'est pas sensibilisé à cette question ("faut que ça marche, c'est tout"). C'est du côté serveur, avec des controleurs raids ou des cartes réseaux que ça changera.
      • [^] # Re: OpenBSD

        Posté par  . Évalué à 2.

        Ben, justement.

        Ça "marche [beaucoup mieux], c'est tout" avec des drivers libres que proprios qu'il faut aller télécharger, exécuter le prog fourni, faire gaffe à sa gestion des biblios openGL si on compte changer de carte graphique plus tard...

        Maintenant que je suis un peu plus vieux, un peu moins con et un peu plus tolérant, l'un de mes principaux griefs quand je dois installer windows chez quelqu'un, c'est qu'il n'y a pas d'équivalent de Synaptic. Incroyable le temps qu'on perd dans ces stupidités laborieuses de fichiers "setup.exe"
  • # Oui, mais que faire ?

    Posté par  . Évalué à 10.

    Voilà un article utile !

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

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

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

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

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

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

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Oui, mais que faire ?

      Posté par  (site web personnel) . Évalué à 10.

      Peut-être pourraient-ils déjà afficher au démarrage un message du genre "Attention, en raison de la présence d'un pilote propriétaire fermé (closed source) pour tel matériel dans votre noyau, l'intégrité de votre système ne peut être garantie" ?

      C'est déjà le cas. Quand tu charges un module non-libre, un warning est affiché te disant que ton noyau est « tainted ».
      • [^] # Re: Oui, mais que faire ?

        Posté par  (site web personnel) . Évalué à 5.

        Je crois bien qu'il pensait à un truc un peu plus voyant. Genre dans la liste des matériels dans GNOME ou KDE, qu'il y ait une petite marque rouge "pilote non libre, risque de faille de sécurité".

        Sans dire que ce n'est pas "certifié Linux", ce qui serait trop difficile à mettre en place... OpenSource ne signifie pas forcément que c'est sécurisé, pas pour tous les programmes en tous cas. J'aime bien la notion de "pilote non libre, risque de faille de sécurité", ça montrerait très simplement les risques qu'encourt un utilisateur lorsqu'il installe un pilote binaire, ensuite c'est à ses risques et périls.
        • [^] # Re: Oui, mais que faire ?

          Posté par  . Évalué à 4.


          OpenSource ne signifie pas forcément que c'est sécurisé, pas pour tous les programmes en tous cas. J'aime bien la notion de "pilote non libre, risque de faille de sécurité", ça montrerait très simplement les risques qu'encourt un utilisateur lorsqu'il installe un pilote binaire, ensuite c'est à ses risques et périls.



          Euh... Donc en gros, tu dis que ce n'est pas parce que c'est open source qu'il n'y a pas de faille, mais qu'en face des pilotes closed source on devrait marquer : "risque de faille" en rouge qui clignote? Et pas en face des pilotes open source alors qu'ils ne sont pas exempts de failles, tu le dis toi même?

          Donc en somme ça reviendrait à se servir de la peur engendrée chez les utilisateurs "novices" par le signe "faille de sécurité" pour qu'ils fassent le choix que tu aimerais qu'ils fassent.

          J'imagine que quand Microsoft ou autre se sert de ce genre de méthodes, tu es le premier à applaudir...

          PS: je précise que sur le fond je suis contre une stabilisation de l'ABI et une généralisation des modules binaires, je réagis juste sur la méthode que tu suggères.
          • [^] # Re: Oui, mais que faire ?

            Posté par  . Évalué à 4.

            Oui, sauf quand il y a un raisonnement cohérent derrière.
            Quand une faille de sécurité est annoncée dans le noyau linux, en général, (j'insiste sur le en général), c'est corrigé plutôt vite.

            Quand nvidia ou ati sort un nouveau pilote tous les 4 mois, tu es content. Et en plus pas un mot sur les failles corrigées.
          • [^] # Re: Oui, mais que faire ?

            Posté par  (site web personnel) . Évalué à 3.

            J'imagine que quand Microsoft ou autre se sert de ce genre de méthodes, tu es le premier à applaudir...

            Microsoft fait déjà quelque chose de similaire. Lorsque tu installes un driver qui n'est pas "certifié Microsoft", tu as une belle boîte de dialogue (avec un icone de "warning" jaune) qui te dit que tu risques des problèmes d'instabilité, du fait que ces drivers n'a pas été testé par les laboratoires MS.
    • [^] # Re: Oui, mais que faire ?

      Posté par  (site web personnel) . Évalué à 9.


      Une page sur kernel.org ou directement dans la doc du noyau avec la liste des matériel supportés par le kernel officiel pourrait fournir une véritable référence pour le choix de matériel (ce qui existe actuellement manque un peu de visibilité).

      Ce n'est pas une parole en l'air, qui serait partant pour mettre en place un Wiki pour lister pilotes et matériels comptible Linux.
      Principe simple, une page par matériel et une page par pilote... Ensuite des pages de conseils et de sommaire pour rassembler le tout.

      On listerait ainsi les avantages et les inconvénients de chacun des composant. On pourrait aussi proposer des confs de PC pour tous type d'utilisateur: Joueur, Serveur, Bureau...

      J'ai un hébergement, si des gens sont motivés, je veux bien mettre ça en place avec eux!
      • [^] # Re: Oui, mais que faire ?

        Posté par  (site web personnel) . Évalué à 7.

        comme http://dev.librehwdb.tuxfamily.org ? ;-) si tu es compétent en php / postgresql ou mysql, je te propose de pousser plus loin avec une base de données plutôt.

        Sachant que le wiki dont tu parles existe déjà avec
        http://www.linuxquestions.org/hcl/index.php
        et http://wiki.linuxquestions.org/wiki/Hardware_TOC
        • [^] # Re: Oui, mais que faire ?

          Posté par  (site web personnel) . Évalué à 3.

          je te propose de pousser plus loin avec une base de données plutôt

          Je comprend pas le sens de ta phrase... Un wiki c'est déjà de la base de données :-|

          Pour les autres Wiki... Ils sont pas ce qu'il y a de plus simple à utiliser...
          • [^] # Re: Oui, mais que faire ?

            Posté par  (site web personnel) . Évalué à 4.

            ok, précision : base de données *relationnelle*
            permettant d'avoir des champs identifiés plutôt qu'un format flou "à la wiki" permettant difficilement de faire des requêtes SQL...
            • [^] # Re: Oui, mais que faire ?

              Posté par  . Évalué à 2.

              Alors la je suis 100% d'accord puisque chaque fois que je veut acheter du materiel ça me prend moulte temp pour savoir si oui ou non il est compatible. Mais il faudrai, a mon avis, un site international et il faudrai réussire a le faire connaitre. En fait il faudrais qu'il ai l'air "officiel" . Je suis sur qu'il y a plein de projet comme ça qui existe mais qui sont totalement inconu.
              • [^] # Re: Oui, mais que faire ?

                Posté par  (site web personnel) . Évalué à 2.

                • [^] # Re: Oui, mais que faire ?

                  Posté par  . Évalué à 3.

                  Oui c'est ça l'idée mais il manque juste que le site soit officiel et qu'il y ai plus d'informations aussi. je voudrais aussi savoir si les drivers sont binaires ou source, spec dispo ou reverse engineering et aussi si ça fonctionne c'est pas oui ou non c'est souvent bof. Ma radeon 9550 par exemple elle fonctione oui mais avec les drivers libres, pas de 3D et avec les proprio, deja c'est contre ma philosophie et en plus ils sont merdiques avec des perfs lamentables. Mais sinon ce site est une bonne initiative.
      • [^] # Re: Oui, mais que faire ?

        Posté par  (site web personnel) . Évalué à 3.

        si tu regardes sur le site web knoppix-fr.org tu verras une section hardware.
        Fut une époque j'avais essayer de mettre cette base de donnée en commun avec le forum anglais.
        Le truc serait de normaliser des fichiers XML, creer un serveur central soap et des api qui vont bien, genre php et tous...

        Plus l'outil sera facile a ajouter dans un site web plus l'outil sera interressant.

        (le XML permet nottament de gerer la langue et de nombreuse autre possibilité)

        Si plus de détails contact mois par mail, c'est vraiment un projet qui m'interesse.

        http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

      • [^] # Re: Oui, mais que faire ?

        Posté par  (site web personnel) . Évalué à 2.

        Le site http://www.linuxprinting.org a déjà mis en place une base de données concernant les imprimantes.

        De plus, une page pour diriger les acheteurs vers du matériel compatible me semble une bonne idée.

        Voir http://www.linuxprinting.org/suggested.html.

        A+
        • [^] # Re: Oui, mais que faire ?

          Posté par  . Évalué à -1.

          NON NON ET NON
          ce n'est pas la bonne methode
          l'uttilisateur lambda qui pose sa config...

          bonne methode
          -telecharger le kernel
          -le decompresser
          -aller DANS LES SOURCES...
          -et magiquement y'as le nom des cartes du comerce...GENIAL

          autres drivers:
          prendre les docs ou sources du project et faire pareil...
          comme madwifi ou tout ce qui est userspace ou "module built against the kernel"

          je propose d'ouviri un NOUVEAU site en faisant appel a tuxfamily par exemple

          car le succes des projets sont aussi enormement dus au bon management

          prenez react-os par exemple...
          les projets precedents ont echoues car ils n'uttilisaient pas la bonne methode et parlementaient trop

          moi aussi j'ai eu l'idee de construire une database questionable pour:
          -acheter(materiel compatible avec le meilleur driver)
          -installer(choisir prosm54 au lieu de ndiswrapper)
          -etc...

          mais il faut faire qqch face a cette derive...
          sinon a quoi bon sert d'avoir linux(par rapport a bsd) si c'est pour avoir tout ces drivers binaires sans avoir d'autres choix...
          mais linux a d'enormes avantages:
          -bien plus compatible comme pour des projects comme wine
          -le mode de developement est du style "contributions"(un utilisateur lambda contribue ou modifie les sources d'un programme et post sa modification au project...)

          donc:
          -tuxfamily
          -fresmeat
          -sourceforge(sait pas s'ils ont sucombes aux derives qu'on leur pretait dans le temps...)
          • [^] # Re: Oui, mais que faire ?

            Posté par  . Évalué à 1.

            ou pourait on parler de la construction d'un tel site qui propose:
            -une base de donnee linux/unix
            et acessoirement:
            -une base de donee distrib afin de promouvoir les drivers libres comme "compatible knoppix et open-source" pour l'acheteur debutant en linux
            -des configs linux(beaucoup de personnes ont achetes des ordis linux dans les operations de grand magazins avec des ordis linux a 300 euros...)
            -promouvoir les drivers libre non connus/non operationels comme le driver airport extreme en developement en donnant l'etat du devellopement et les HAL libres pour madwifi ou les drivers pour ati radeon(les nouvelles)
            le nom du site pourait etre LHCL
            linux hardware compatibility list

            ca ressemble un peu a l'affaire rootkit de sony...beaucoup de personnes asimilent cela a un virus...alors que ca va jusqu'a espioner TOUT dont email etc...

            le probleme des drivers proprietaires est que cela divise les efforts de devellopement car beaucoup se satisfont des drivers binaires...
            cela peut a terme tuer linux
            a quoi sert de faire tourner linux s'il n'y as pas de support hardware...

            il faudrait donc aussi creer une section pour les constructeurs en donnant des arguments(wiki) pour les relases de specifiactions et faire un listing de ceux qui donnent ces specifications et ceux qui refusent de les donner(bah ouais faut bien recompenser ce qui les donnent...)
            • [^] # Re: Oui, mais que faire ?

              Posté par  (site web personnel) . Évalué à 2.

              comme http://dev.librehwdb.tuxfamily.org en fait :-) (je te recommande de lire aussi les autres commentaires de cette dépêche).

              Tu peux t'inscrire sur la ML de librehwdb (en anglais préférentiellement, peu active actuellement) et le wiki peut-être complété soit en anglais, soit en français, tiki-wiki gérant facilement les traductions.
              ça te permettra de passer du "il faudrait" à "voilà, ça c'est fait", pas mal de tes arguments demandant à être développés en plus d'une ligne (et argumentés par des faits).
              • [^] # Re: Oui, mais que faire ?

                Posté par  . Évalué à 1.

                j'aimerai poser une question
                sans doute certains sont deja aller fouiller dans les sources pour savoir si un materiel est compatible
                est ce que cela est a faire manuelement?
                ou semi-manuelement/semi-automatise?
                ou totalement automatise en script?

                exemple: les drivers pour les clee usb wifi

                xconfig
                USB ZD1201 based Wireless device support (USB_ZD1201)

                type: tristate
                prompt: USB ZD1201 based Wireless device support
                dep: USB && NET && NET_RADIO
                select: FW_LOADER
                dep: USB && NET && NET_RADIO

                defined at drivers/usb/net/Kconfig:304

                Say Y if you want to use wireless LAN adapters based on the ZyDAS
                ZD1201 chip.

                This driver makes the adapter appear as a normal Ethernet interface,
                typically on wlan0.

                The zd1201 device requires external firmware to be loaded.
                This can be found at http://linux-lc100020.sourceforge.net/

                To compile this driver as a module, choose M here: the
                module will be called zd1201.

                isi on voit:
                defined at drivers/usb/net/Kconfig:304
                et:
                USB_ZD1201 #nom du module
                avec le simlink:
                /usr/src/linux/drivers/usb/net/
                ls
                ->zd1201,h
                ->zd1201.c

                dans le zd1201.c:
                static struct usb_device_id zd1201_table[] = {
                {USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
                {USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
                {USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb adapter */
                {USB_DEVICE(0x0db0, 0x6823)}, /* MSI UB11B usb adapter */
                {USB_DEVICE(0x1044, 0x8005)}, /* GIGABYTE GN-WLBZ201 usb adapter */
                {}
                };
                • [^] # Re: Oui, mais que faire ?

                  Posté par  . Évalué à 1.

                  dans d'autres cas piix(ich ide chipset)
                  case PCI_DEVICE_ID_INTEL_82801EB_1:
                  mode = 3;
                  break;
                  /* UDMA 100 capable */
                  case PCI_DEVICE_ID_INTEL_82801BA_8:
                  case PCI_DEVICE_ID_INTEL_82801BA_9:
                  case PCI_DEVICE_ID_INTEL_82801CA_10:
                  case PCI_DEVICE_ID_INTEL_82801CA_11:
                  case PCI_DEVICE_ID_INTEL_82801E_11:
                  case PCI_DEVICE_ID_INTEL_82801DB_1:
                  case PCI_DEVICE_ID_INTEL_82801DB_10:
                  case PCI_DEVICE_ID_INTEL_82801DB_11:
                  case PCI_DEVICE_ID_INTEL_82801EB_11:
                  case PCI_DEVICE_ID_INTEL_ESB_2:
                  case PCI_DEVICE_ID_INTEL_ICH6_19:
                  case PCI_DEVICE_ID_INTEL_ICH7_21:
                  case PCI_DEVICE_ID_INTEL_ESB2_18:
                  mode = 3;
                  break;
                  /* UDMA 66 capable */
                  case PCI_DEVICE_ID_INTEL_82801AA_1:
                  case PCI_DEVICE_ID_INTEL_82372FB_1:
                  mode = 2;
                  break;
                  /* UDMA 33 capable */
                  case PCI_DEVICE_ID_INTEL_82371AB:
                  case PCI_DEVICE_ID_INTEL_82443MX_1:
                  case PCI_DEVICE_ID_INTEL_82451NX:
                  case PCI_DEVICE_ID_INTEL_82801AB_1:
                  return 1;
                  /* Non UDMA capable (MWDMA2) */
                  case PCI_DEVICE_ID_INTEL_82371SB_1:
                  case PCI_DEVICE_ID_INTEL_82371FB_1:
                  case PCI_DEVICE_ID_INTEL_82371FB_0:
                  case PCI_DEVICE_ID_INTEL_82371MX:
                  default:
                  return 0;
                  }

                  /*
                  * If we are UDMA66 capable fall back to UDMA33
                  * if the drive cannot see an 80pin cable.
                  */
                  if (!eighty_ninty_three(drive))
                  mode = min(mode, (u8)1);
                  return mode;
                  }
                  et
                  case PCI_DEVICE_ID_INTEL_82801AA_1: /* ICH */
                  case PCI_DEVICE_ID_INTEL_82801AB_1: /* ICH0 */
                  case PCI_DEVICE_ID_INTEL_82801BA_8: /* ICH2 */
                  case PCI_DEVICE_ID_INTEL_82801BA_9: /* ICH2 */

                  peut etre qu'il faudrait des lignes standard pour le kernel

                  un simple script construirait une database
                  consultable par les downloaders des sources du kernel
                  • [^] # Re: Oui, mais que faire ?

                    Posté par  . Évalué à 2.

                    • [^] # Re: Oui, mais que faire ?

                      Posté par  (site web personnel) . Évalué à 2.

                      hum j'ai l'impression que tu as loupé un épisode ;-)

                      la pci et usb database existent déjà mais ne font l'objet que d'un rapprochement entre
                      vendor_id1, product_id1, éventuellement vendor_id2, product_id2 voire révision
                      et
                      le pilote qui gère le chipset ainsi identifié
                      pour prendre un exemple que je connais : http://faq.eagle-usb.org/wakka.php?wiki=ModemSupport

                      Ton idée de fouiller dans le code pour trouver les produits n'est pas si mauvaise, mais ça risque d'être incomplet (côté produits) vu que les développeurs de pilote ont du mal à identifier les produits intégrant le chipset géré par le pilote (vu que c'est le constructeur qui sait ce qu'il choisit et omet souvent de changer.
                      D'autre part, 2 projets existent déjà sur le sujet (que la future base pourrait utiliser) :
                      http://www.pcidatabase.com/ pour les pilotes pci
                      et http://www.qbik.ch/usb/devices/index.php pour les pilotes usb
                      et cela correspond aux codes qui apparaissent dans
                      /usr/share/ldetect-lst/usbtable.d/90default.lst
                      /usr/share/ldetect-lst/pcitable.d/90default.lst (il y a aussi dmitable.d/90default.lst ScannerDB.gz MonitorsDB pcmciatable.d/90default.lst ...)
                      (sur une mandriva, après sur d'autres distribs cela peut être fait de manière similaire...). C'est aussi comme ça que lspci / lsusb peuvent afficher des infos complémentaires.

                      Bon en tout cas, c'est bien tu me donnes l'idée de structurer un peu le wiki... je crois qu'il va falloir ajouter une FAQ ;-)
                      notamment, indiquer qu'étudier l'existant avec http://wiki.eagle-usb.org/wakka.php?wiki=HwDbExistingResourc(...) (qu'il faudrait un peu structurer) est important.

                      après, pour l'instant je n'ai pas très bien compris ton histoire d'api, mais n'hésite pas à préciser (euh, flash tu peux oublier... ou alors à titre d'api non libre).
                      • [^] # Re: Oui, mais que faire ?

                        Posté par  . Évalué à 2.

                        faudrait que je m'explique
                        un lsusb donne ca:
                        0b95:1720 ASIX Electronics Corp
                        et c'est pas le produit c'est la puce...
                        bonjour monsieur je voudrait acheter une carte asix ab95:1720
                        euh...
                        mais si je dis:
                        "DLink DUB-E100 USB Ethernet"
                        Netgear FA-120 USB Ethernet
                        Hawking UF200 USB Etherne
                        ca le vendeur connais
                        meme que si tu lui donne une liste de toutes les cartes suportees bah il peut en trouver une...ou meme plusieurs
                        ensuite le lspci tu le fait si t'as deja le produit,cela implique que qqn doit l'avoir fait et donc que ce qqn as achete une carte...dont il n'etais pas sur du tout qu'elle etais suporte par linux...on tourne en rond
                        mais qqn qui cherche une carte reseau usb2.0 va chercher dans les sources,construire une liste et uploade cette liste sur le site
                        en plus s'il as une perte de donee il peut retrouver facilement cette liste ou dire c'est moi qui ait fait ca
                        • [^] # Re: Oui, mais que faire ?

                          Posté par  . Évalué à 0.

                          en gros les hcl venant des sources c'est la base...pas garanti a 100% mais necessaire pour que des gens achetent...
                          apres les contrib du type lspci=telle carte c'est la serise sur le gateau qui ne peut etre possible que si la base existe deja et que les personnes ont achetes en fonction de cette base
                          pour obtenir le genre de renseignements suivants:
                          dans la revision 3 du firmware ils ont change aussi le chip...bah ca vient APRES et pas avant
                          neanmoin integrer les databases existantes est aussi une obligation
                          ca permet a des personnes de ne pas faire cette erreur d'acheter qqch qui a change de puces
                          • [^] # Re: Oui, mais que faire ?

                            Posté par  (site web personnel) . Évalué à 3.

                            j'ai toujours pas bien compris ton approche.
                            Les infos disponibles via lspci, lsusb, ne donnent effectivement que le chipset (ça permettra d'avoir des stats semi-automatiques...).
                            Bien sûr que l'objet de http://wiki.eagle-usb.org/wakka.php?wiki=HardwareDb et de http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Doc+D(...)
                            est de faire le lien entre le produit vendu et le pilote
                            D'ailleurs pour les notes attribuées :
                            - la note de fonctionnment est plutôt portée par le produit
                            - la note de liberté est plutôt issue des infos sur le pilote (pilote libre, firmware libre, ...)
                            Pour un même produit (description du vendeur disons...) il peut y avoir des chipsets différents, même si ça ne devrait pas exister. Derrière le pilote va a priori être différent (Starmodem a réussi à faire ça avec pilotes eci et eagle-usb déjà... Dlink DSL aussi pour les modems adsl usb, yen a qui n'ont peur de rien...). Faudra trouver un moyen de montrer ce genre de choses à l'utilisateurs (en partant à partir des descriptions de produits ça viendra de soi-même... et dans les commentaires).
                          • [^] # Re: Oui, mais que faire ?

                            Posté par  . Évalué à 0.

                            il faut aussi qqn qui conaisse bien le kernel et le hardware
                            par exemple un newbee ne sait pas(la preuve:moi)que pccard et pci est la meme chose et s'etone qu'un pilote pci fonctionne pour une carte pc-card
                            • [^] # Re: Oui, mais que faire ?

                              Posté par  . Évalué à 0.

                              ma demarche est simple
                              construire cette database SANS poseder le hardware en question
                              -cela demanderait beaucoup trop de monde si on devait posseder le hardware(donc connaitre la marque et le model) et faire un lspci
                              -c'est un cercle vicieu car si personne ne posede une carte,personne n'ira l'acheter car personne ne saura si elle a une chance d'etre compatible

                              donc il faut:
                              1)construire la database a partir des sources:
                              -rapide
                              -facile
                              -enorme database

                              2)que par dessus des utilisateur fassent des lspci pour verifier cela(version des cartes avec des chipset differents...)
          • [^] # Re: Oui, mais que faire ?

            Posté par  (site web personnel) . Évalué à 4.

            Désolé mais quand j'avais à choisir une imprimante photo pour chez moi, ça m'a bien servi. Surtout à ne pas choisir une Canon qui pourtant me plaisait plus.

            Obliger quelqu'un à télécharger un kernel linux pour lire le code et voir si le matériel qu'il convoite est supporté, je trouve ca délirant.

            Une base de donnée permet autant de vérifier la compatibilité de son matos que de suggérer du matos compatible si on veut investir.

            J'ai plein d'ami et collègue qui pense passer à linux, c'est pas pour les dégouter au dernier moment en les faisant lire les sources du kernel.

            Perso, je n'achette que du matos qui est supporté (+/-) avec driver GPL. Et je ne lit pas les sources pour ça.

            A+
            • [^] # Re: Oui, mais que faire ?

              Posté par  . Évalué à 0.

              y'as rien a comprendre en lisant les sources
              y'as juste a trouver l'ocurence du nom commercial dans les sources
  • # Oui, mais....

    Posté par  . Évalué à 9.

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

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

    Bref, a quand des cartes graphiques modernes, performantes, avec un support OpenGL 2.0 complet, ET des pilotes libres ?
    • [^] # Re: Oui, mais....

      Posté par  (site web personnel) . Évalué à 8.

      Le problème avec la solution "je n'ai pas le choix", c'est que tu commences par te dire ça pour ta carte graphique, maintenant pour ton driver wifi, puis ensuite... ?
      • [^] # Re: Oui, mais....

        Posté par  . Évalué à 7.

        Possible, mais après tout ça ne change rien quand on n'a pas le choix... C'est un peu le c½ur du problème, d'ailleurs.
      • [^] # Re: Oui, mais....

        Posté par  . Évalué à 5.

        Si les codeurs n'utilisaient pas ces drivers non libres pour cartes graphiques, il n'y aurait aucun jeu vidéo 3D sous Linux...
        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  (site web personnel) . Évalué à 5.

          Si les codeurs n'utilisaient pas ces drivers non libres pour cartes graphiques, il n'y aurait aucun jeu vidéo 3D sous Linux...
          C'est bien joli de critiquer, mais bon...

          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.

          va reverse enginerer les pilotes ATi, c'est nettement plus hardcore qu'une bête carte réseau ou un pilote IDE
          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  (site web personnel) . Évalué à 8.

          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).

          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  . Évalué à 8.

      mais si t'as le choix...
      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  (site web personnel) . Évalué à 5.

      Toutes les spécifications de ces cartes nVidia et ATI modernes ne sont pas fournies, mais n'est-il vraiment pas possible de développer des drivers libres basiques gérant l'OpenGL ?
      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  . Évalué à 8.

        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.

        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  (site web personnel) . Évalué à 2.

      Mais si tu as le choix. Rappelle-toi il y a quelques annees (entre 95-99) c'etait bien pire.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Oui, mais....

        Posté par  . Évalué à 1.

        Dans ces années là, je n'avait pas Linux, et je crois que j'avais même pas d'ordinateur tout cours, donc je ne dirais rien.

        Sinon, les coup du pilote R300 libre, je l'attendais... Mais quand je vois:

        The source code on this website may damage your hardware.

        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  . Évalué à 10.

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

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

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

    Par contre si quelqu'un en connait un a jour, je ne vais pas réinventer le fil à couper le beurre.
  • # créons un label "linux-compatible" !

    Posté par  . Évalué à 5.

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

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

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

    J.
    • [^] # Re: créons un label "linux-compatible" !

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      "linux compatible" ferait plutôt penser à une compatibilité du matériel point (avec un driver binaire donc). Avoir un pilote libre va plus loin qu'une simple compatibilité avec Linux. Mais je suis d'accord sur l'idée d'un tel label.

      WeeChat, the extensible chat client

    • [^] # Re: créons un label "linux-compatible" !

      Posté par  (site web personnel) . Évalué à 5.

      Il en est effectivement question dans le fil de discussion, voir http://marc.theaimsgroup.com/?l=linux-kernel&m=113398104(...)
    • [^] # Re: créons un label "linux-compatible" !

      Posté par  . Évalué à 5.

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

      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  (site web personnel) . Évalué à 1.

      Qu'est-ce que ça veut dire "compatible" ? Il existe un pilote ? Mais qui exploite bien tout le produit, avec quelle qualité ? Quand tu vois les différences entres les différents pilotes sous Microsoft Windows, compatible, ça veut pas dire grand chose.
      • [^] # Re: créons un label "linux-compatible" !

        Posté par  (site web personnel) . Évalué à -1.

        Le moinsage précédent me suggère que je n'ai pas été assez clair.
        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  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: créons un label "linux-compatible" !

      Posté par  . Évalué à 1.

      À chaque fois que j'ai vu ça sur une boîte (ou presque) j'ai en fait trouvé sur un coin du CD d'installation des pilotes (sous forme de sources) pour RH 6.

      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  . Évalué à 1.

    Ces drivers binaires, ils s'exécutent sur le PC ou sur un processeur embarqué sur la carte graphique/wifi/réseau/etc... ? Les deux? Dans quelle proportion?
    • [^] # Re: Une question, comme ça...

      Posté par  (site web personnel) . Évalué à 4.

      Ces drivers binaires, ils s'exécutent sur le PC ou sur un processeur embarqué sur la carte graphique/wifi/réseau/etc... ? Les deux? Dans quelle proportion?
      Les parties considérés comme "à problèmes" s'executent dans le noyau. Les autres (firmwares) relèvent plus des détails de réalisation du hardware.
  • # Avocat du diable

    Posté par  . Évalué à 7.

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

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


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

      Posté par  (site web personnel) . Évalué à 5.

      Ca pourrait etre un intermediare passable a condition qu'ils jouent vraiment le jeux.

      - 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  . Évalué à 1.

      Si tu as la certitude que la concurrence a désassemblé le code du driver, alors la société qui ouvrirait son code ne serait pas lésée. Elle gagnerait un petit marché, pour un faible coût.

      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  . Évalué à 10.

      si je livre des drivers complétement libre, l'architecture de la puce sera plus facile à comprendre

      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  . Évalué à 4.

        Exactement

        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  . Évalué à 2.

          ben non ... le role du driver c'est bien de faire le lien entre ton materiel et l'os qui lui est standardisé ... si tu considère que tu fais une couche d'abstraction entre le matos et ton driver, ça fait un goulot d'étranglement en plus... si tu commences a empiler les couches logicielles avant même d'avoir rajouté l'OS, en terme de perfs tu commence mal!.
          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  . Évalué à 1.

            bah mince ça invalide tout mon post plus haut :)

            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  . Évalué à 1.

              D'autant plus que ce que tu propose s'appelle une ABI ...
      • [^] # Re: Avocat du diable

        Posté par  . Évalué à 3.

        L'architecture de ta puce on s'en contrefout. Ce dont on a besoin ce sont les interfaces

        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  (site web personnel) . Évalué à 5.

        L'architecture de ta puce on s'en contrefout. Ce dont on a besoin ce sont les interfaces

        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  . Évalué à 1.

        En tout cas, on peut proposer quelque chose comme ça pour créer un label "linux compatible". Le label serait obtenu sous la forme d'un contrat :

        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  (site web personnel) . Évalué à 3.

          Oui, ca restera compatible avec XP... y'a qu'a voir les problemes qu'il y a eu avec la sortie du SP2.
          • [^] # Re: Avocat du diable

            Posté par  . Évalué à 1.

            C'est clair, les problemes etaient vraiment enormes, au vu des bug reports qu'on a recu je dirais qu'il y a _au moins_ 1% des drivers qui ont eu des problemes, principalement du au fait qu'ils faisient des trucs qu'ils ne sont pas sense faire.

            Les 99% restants eux par contre continuaient a fonctionner sans probleme.
            • [^] # Re: Avocat du diable

              Posté par  . Évalué à 2.

              Oui, mais pour XP64, tes drivers ils puent.

              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  (site web personnel) . Évalué à 1.

      Pour moi, tu as raison : le libre modifie les modèles économiques viables.
      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  . Évalué à 2.

      Tu fournis une version binaire et au bout d'un an tu fournis les sources du driver.

      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  . Évalué à 10.

    Bonjour,

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

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

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

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

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

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

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

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

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

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

    Le binaire ne passera pas par moi. et vous ?
    • [^] # Re: Binaire c'est mal(TM)

      Posté par  (site web personnel) . Évalué à 4.

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

      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  . Évalué à 4.

        Voila tu as compris exactement NOTRE arme : le nombre de plus en plus important de machines sous linux.

        *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  . Évalué à 1.

          Je rappelle que des gens ACHETENT des machines pour les mettres sous linux, ce n'est pas que du recyclage.
          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  (site web personnel) . Évalué à 4.

            >Je rappelle que des gens ACHETENT des machines pour les mettres sous linux, ce n'est pas que du recyclage.
            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  . Évalué à 2.

              Et quelles sont ces raisons ?

              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  . Évalué à 1.

                Apparemment, j'avais mal compris le terme recyclage. J'ai cru qu'il s'agissait d'un changement d'OS. Ce n'était pas ça ?

                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  (site web personnel) . Évalué à 2.

                Un un OS qui s'appelle porte?
                • [^] # Re: Binaire c'est mal(TM)

                  Posté par  . Évalué à 2.

                  Non, une Porte aux Factures d'où sortent des Fenêtres Micromolles. Mais en y allant, on tombe effectivement sur un os.

                  -->[]
        • [^] # Re: Binaire c'est mal(TM)

          Posté par  (site web personnel) . Évalué à 4.

          J'vais etre mechant 30 sec : Comment tu fait du MMORPG sur une console?

          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  (site web personnel) . Évalué à -2.

            Et les MMORPG libres ?

            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  (site web personnel) . Évalué à 2.

              1 - J'ai pas envie de programmer, j'ai envie de jouer.
              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  . Évalué à 1.

              Laisse-le faire ce qu'il veut avec sa machine. C'est pas un des fondements de linux, ça ?
          • [^] # Re: Binaire c'est mal(TM)

            Posté par  . Évalué à 4.

            Je réponds aux questionnements précédents (et pas seulement à Calim' -> oui je sais c'est vraiment trop injuste).

            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  (site web personnel) . Évalué à 2.

              Pour le MMO y'a A tales in the desert qui doit avoir un client linux (mais l'offre d'essait n'est que de 24h ce que je trouve un peu court a moins que ce soit 24h de tps de jeux). Mais je compte bien le tester un jour et retester PlaneShift qui tout deux sont dispo sous linux. Si deja ca incite les compagnies videoludiques a faire du linux on peut esperer que ca fasse du mieux avec les driver video...

              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  . Évalué à 2.

                Pour le MMO y'a A tales in the desert qui doit avoir un client linux (mais l'offre d'essait n'est que de 24h ce que je trouve un peu court a moins que ce soit 24h de tps de jeux).

                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  (site web personnel) . Évalué à 2.

                  Effectivement c'est pas mal du tout comme compromis (surtout quand je suis pas en vacance sinon les 24h de jeux je suis capable de les faire en 2 jours voir moins)

                  Merci du renseignement.
    • [^] # Re: Binaire c'est mal(TM)

      Posté par  . Évalué à 2.

      Faut quand même arréter avec ce mythe que "quand le code-source est dispo, on peut pas (ou moins) cacher de merde dedans". Pour que cela soit vrai, il faut que l'outil qui transforme ce source en binaire n'ait pas de merde cachée dedans. Ce qu'on peut vérifier en lisant les sources du-dit compilateur, certes, mais comme il faut bien commencer avec un binaire...

      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  . Évalué à 1.

        Et on pourrait aussi partir de l'autre ponit de vu : Linux refuserait purement et simplement de fonctionner avec des produits sans pilotes libres. La, ca secourait pas mal les constructeurs !
    • [^] # Re: Binaire c'est mal(TM)

      Posté par  . Évalué à 4.

      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.

      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  . Évalué à 10.

        Ben j'ai une carte nvidia et j'utilise le pilote nv.

        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  . Évalué à -1.

          «c'est le LIBERTE comme dans free speech»

          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  . Évalué à 2.

          Maintenant, je ne dis pas qu'il faut JETER [les personnes qui veulent utiliser linux avec des drivers fournis par les fabricants].

          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  (site web personnel) . Évalué à 2.

        >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.

        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  . Évalué à -5.

      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.

      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  . Évalué à 1.

        Tu veux que je te cites TES posts ou il y a une mauvaise foi manifeste.

        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  . Évalué à -3.

          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, 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  . Évalué à 4.

        Je te signal que lors des (nombreux) procés contre Microsoft, Ashton Tate a prouvé que MS-DOS (tu connais ? Vague rapport avec ton Microsoft, je crois) avait une fonction qui faisait relentir le PC lors de l'utilisation de 1-2-3.

        Alors moins haut la basse !
    • [^] # Re: Binaire c'est mal(TM)

      Posté par  . Évalué à -2.

      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.

      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  (site web personnel) . Évalué à 3.

    J'avais commencé à suivre le thread complet (quand il n'y avait "que" 128 messages) :
    # http://marc.theaimsgroup.com/?l=linux-kernel&m=113378006(...) an horror story :-( starring binary modules

    * http://marc.theaimsgroup.com/?t=113378020600002&r=1&(...) the whole thread
    * http://marc.theaimsgroup.com/?l=linux-kernel&m=113383205(...) answer showing the need to educate buyers, make them choose hardware with open source drivers
    * http://marc.theaimsgroup.com/?l=linux-kernel&m=113383205(...) EXPORT_SYMBOL_GPL as a technical measure to identify derivatives of the linux kernel
    * http://marc.theaimsgroup.com/?l=linux-kernel&m=113386088(...) "designed for Free Software" Label
    * http://marc.theaimsgroup.com/?l=linux-kernel&m=113388088(...) call the support center and sales people, requiring open drivers
    * http://marc.theaimsgroup.com/?l=linux-kernel&m=113389410(...) opengraphics
    * http://marc.theaimsgroup.com/?l=linux-kernel&m=113389936(...) Alan Cox' position

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

    Posté par  (site web personnel) . Évalué à 2.

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

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

    Faire pression sur ces "petites" societes permet en meme temps de mettre la pression sur ATI et Nvidia.
    • [^] # Re: Pilotes Cartes Graphiques

      Posté par  . Évalué à 2.

      compte tenu de cet article:
      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  . Évalué à 3.

        Même si effectivement, j'aurai tendance à privilégier ces cartes, à combien estimes-tu la part de marché de la communauté libriste ????
        • [^] # Re: Pilotes Cartes Graphiques

          Posté par  (site web personnel) . Évalué à 4.

          Aller, à vue de nez, 1%

          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  . Évalué à 1.

            Moui, enfin sur ces 1% d'utilisateurs du libres, combien sont intérréssés par une carte graphique avec des spec ouvertes?

            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  (site web personnel) . Évalué à 1.

          http://www.configspc.com/article881.html

          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  . Évalué à 6.

      Les 3 sociètés VIA, S3, XGI avaient plus au moins parler d'ouvrir leurs pilotes. quand est il ?

      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  . Évalué à 1.

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

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

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

    Posté par  (site web personnel) . Évalué à 2.

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

    Posté par  . Évalué à 4.

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

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

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

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

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

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

    Le choc inevitable du libre et du proprietaire est la.

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

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

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

    Est-ce un bien ou un mal apres tout...
  • # Driver Nvidia 8874 et Quake IV

    Posté par  . Évalué à 4.

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

    Posté par  (site web personnel) . Évalué à 8.

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

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

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

    Posté par  . Évalué à 2.

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

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

    • [^] # Re: Activisme ?

      Posté par  . Évalué à 2.

      La carte PCMCIA de chez MSI CB54G2 possède un ralink2500, ovislink également (même carte en fait)
    • [^] # Re: Activisme ?

      Posté par  . Évalué à 5.

      L'idée est bonne, mais les magasins spécialisés, ce sont des vendeurs, dedans, et eux, ils s'en tamponnent un peu. Ils redistribuent, c'est tout.
      Par contre, devant le siège français d'ATi, ça devient nettement plus utile.
    • [^] # Re: Activisme ?

      Posté par  . Évalué à -2.

      Sauf que les gens qui vont dans ce grand magasin vont se demander c'est qui ces mecs étrange qui me disent de ne pas utiliser le truc qu'on leur vend à la tv...
      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  . É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  . Évalué à 4.

      C'est une fiction, hein. Tout fait personnage ayant des ressemblances avec des personnes existant ou ayant existé... ne serait absolument pas une coincidence! Mais il ne faut pas tout prendre au pied de la lettre, ou au mot près. Si ce n'est pas broadcom, c'est je ne sais quel pilot wifi, ou autre matériel grand public.
  • # Pilotes ndiswrapper

    Posté par  . Évalué à 1.

    C'est pour une fois un super article ;)

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

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

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

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

      Posté par  (site web personnel) . Évalué à 5.

      Un firmware proprio est nettement moins grave qu'un driver proprio. Ne fut-ce que techniquement, si le driver est libre, le matériel peut encore être supporté pour le noyau suivant même si le fabriquant ne le supporte plus. Le problème des firmwares proprios actuellement c'est plutôt que bien souvent leur licence ne permet pas leur redistribution et donc il faut obligatoirement aller le rechercher sur le site du constructeur quand il y est encore ou sur le CD d'installation qu'on a jeté à la poubelle 3 ans plus tôt.

      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  (site web personnel) . Évalué à 3.

      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.


      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  (site web personnel) . Évalué à 4.

        ya des bugs planqués aussi dans le firmware hein ;-)
        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  (site web personnel) . Évalué à 3.

        quel est l'inconvénient des firmware proprio?
        Ils ne sont pas libres :op
        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  . Évalué à 4.

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

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

    Posté par  (site web personnel) . Évalué à -1.

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

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

    Sinon je suis pas pour les pilotes binaires, mais pour d'autres raisons : c'est pas des logiciels libres tout simplement.
    • [^] # Re: esfedq

      Posté par  (site web personnel) . Évalué à 4.

      Toi, tu as oublié de lire http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) , pourtant linké deux fois dans l'article.
    • [^] # Re: esfedq

      Posté par  (site web personnel) . Évalué à 6.

      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.

      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  (site web personnel) . Évalué à 3.

        La force du libre est juste ceci : pas de contrainte au niveau binaire.
        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  (site web personnel) . Évalué à 4.

          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.

          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  (site web personnel) . Évalué à 1.

            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.


            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  (site web personnel) . Évalué à 0.

              Le C++ suffirait ;-)
              (J'avoue n'avoir toujours pas compris les adeptes du C sur le C++... sans vouloir forcement troller :) )
              • [^] # Re: esfedq

                Posté par  . Évalué à 9.

                Interopérabilité : Le C++ peut utiliser le C, l'inverse est plus diffcile.

                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  (site web personnel) . Évalué à 4.

            Ça ne gêne que les éditeurs propriétaires.
            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  (site web personnel) . Évalué à 3.

              Je suis pas sûr que maintenir plusieurs interfaces parallèles fasse gagner du temps par rapport aux mises à jour nécessaires lors des changements d'API. Surtout qu'il est clairement expliqué dans le lien donné que dans Linux, c'est celui qui change l'interface qui doit mettre à jour le code de tous les modules qui l'utilise. 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.

              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  (site web personnel) . Évalué à -1.

                Surtout qu'il est clairement expliqué dans le lien donné que dans Linux, c'est celui qui change l'interface qui doit mettre à jour le code de tous les modules qui l'utilise.
                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  (site web personnel) . Évalué à 2.

                  Ton analogie avec OOo ne tient pas debout, un programme qui tourne sous Linux 2.2 peut très bien tourner sous Linux 2.6. Par contre ça m'étonnerait que l'API interne d'OOo n'ait pas changé au cour du temps.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: esfedq

                    Posté par  (site web personnel) . Évalué à 0.

                    un programme qui tourne sous Linux 2.2 peut très bien tourner sous Linux 2.6
                    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  . Évalué à 8.

        C'est absolument faux, ça n'est pas parce que c'est du logiciel libre qu'il faut faire n'importe quoi.

        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  . Évalué à 1.

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

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

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

Suivre le flux des commentaires

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