Une plongée dans le développement de Linux

Posté par . Modéré par j.
1
15
déc.
2006
Noyau
Je peux vous garantir, en ayant fait moi-même l'expérience, qu'on ne ressort pas indemne d'une plongée dans le processus de développement de Linux ! Savez-vous par exemple que l'équipe de développement du noyau sort une version toutes les sept à huit semaines avec un nombre de lignes de code ajoutées, modifiées ou supprimées à chaque fois qui est de l'ordre du million ? Que le développement se fait en toute transparence sur Internet ?

Comparez avec Vista qui est sorti dans la douleur, au bout de 5 années de développement effectué derrière des portes fermées.

Mon article, essayant de décrire tout ce processus, est disponible sur Internet sous forme Wiki (donc éditable par tous). Les améliorations seront les bienvenues, je cherche en particulier de l'aide pour les chapitres consacrés aux distributions Fedora, Ubuntu, SuSE, etc. Pour information voici le sommaire de l'article :
  • 1 Un processus transparent de développement et de revue
  • 2 Un cycle de développement rapide
    • 2.1 Le cycle de développement
    • 2.2 Les différentes branches de développement
  • 3 Les distributions Linux
    • 3.1 Le périmètre de Linux: le noyau, la branche du noyau et les distributions Linux
    • 3.2 La modularité de Linux
    • 3.3 Le rôle des distributions de Linux
    • 3.4 Le cycle de développement de quelques distributions Linux
  • 4 La gestion de configuration du noyau
    • 4.1 Un peu d'histoire: de BitKeeper à Git
    • 4.2 Quelques caractéristiques marquantes de git
  • 5 Les tests et la correction des anomalies
    • 5.1 La métaphore amont/aval dans le développement des logiciels libres
    • 5.2 Le rétroportage des correctifs de sécurité
    • 5.3 Les reports de correctifs vers l'amont
    • 5.4 Les logiciels de suivi des anomalies

  • # prem's

    Posté par (page perso) . Évalué à 2.

    une petite faute dans le troisème paragraphe :
    consacrés aux distributions Fedora, Ubuntu, SuSE, etc.

    Sinon, l'article est très intéressant :)
    • [^] # Re: prem's

      Posté par (page perso) . Évalué à 1.

      C'est bête, parce que si linuxfr était un wiki, on aurait pu corriger l'article [de DLFP] ;) (comme l'article [de LibreProcess] :).
      Je crois qu'il faut ouvrir un tracker ( http://linuxfr.org/tracker/ ) pour proposer ça ;)
      • [^] # Le wiki

        Posté par . Évalué à 1.

        Pourquoi pas, je trouve l'idée du wiki très intéressante.
        Sinon l'article est très intéressant lui aussi.
    • [^] # Re: prem's

      Posté par (page perso) . Évalué à 4.

      Autre petite faute :

      "décrire tout se processus"

      s/se/ce
  • # interressant, mais...

    Posté par (page perso) . Évalué à 10.

    Article intéressant.

    Toutefois, il est pas trés lisible je trouve. En effet, il y a des tournures de phrases bizarres, mal formulées, comme si c'était une traduction (surtout dans la partie conçernant GIT). Et en fait, j'ai découvert que c'était le cas.

    http://begou.com/wiki/index.php?title=Main_Page

    J'ai trouvé tout de même bizarre que l'article, écrit par un français, soit une mauvaise traduction de ce qu'il a écrit en anglais. Ça me laissait perplexe.

    J'ai donc fait une recherche sur Google. Et google, sur une des phrases en anglais mal traduite, m'a trouvé des choses bien curieuses. Par exemple qu'un paragraphe entier sur GIT était identique à l'un de cet article : http://lwn.net/Articles/145194/

    (Celui commençant par "Watching the git development process snowball over the last few months has been fascinating...")

    J'ai pas vérifié pour le reste de l'article.

    Alors, qui a pompé sur qui ? (bon, vu les dates, il y a peu de doute pour ma part...)

    En tout cas, il y a un problème de licence. L'article de Monsieur Bégou est sous licence GNU Free Documentation License 1.2. L'article chez lwn.net est, semble t-il, uniquement Copyright © 2005, Eklektix, Inc.

    Dérangeant n'est ce pas ? ;-)
  • # copies

    Posté par (page perso) . Évalué à 10.

    L'article http://begou.com/wiki/index.php?title=RedHat_development_pro(...) contient un paragraphe commençant par "The official kernel provided on kernel.org is often" qui est un extrait de http://www.mjmwired.net/resources/mjm-kernel-fc4.html. Or cette page a une notice très claire : PLEASE DO NOT mirror, translate or duplicate this page without contacting me

    Ce n'est pas la fin du monde non plus, mais peut-on inviter l'auteur soit à effectuer un peu de reformulation personnelle, soit à citer ses sources (par exemple sur une page séparée) ?
    • [^] # Re: copies

      Posté par . Évalué à 1.

      Je suis d'accord, il faut que cite mes sources à la fin de l'article. LWN en est une que je n'ai pas citée, Greg Kroah-Hartman et Groklaw en est une que j'ai citée.
      Mon apport principal dans cet article est d'avoir effectué une synthèse de ce qui existe comme information mais qui est malheureusement trop fragmentaire pour que les non-initiés puissent s'en faire une idée claire.
      Or c'est vraiment dommage car la façon dont les gens développent Linux avec toute la puissance d'Internet est vraiment innovatrice et mérite d'être mieux connue.
      • [^] # Re: copies

        Posté par (page perso) . Évalué à 8.

        Euh, je ne sais pas ce qu'il en est mais il ne faut pas que citer les sources, il faut aussi et surtout en respecter les licences. Parce que aucun des deux ne donne à priori d'autorisation de reprise / traduction / copie / compilation
  • # Faut pas exagerer...

    Posté par . Évalué à 1.

    Depuis ce tout début, ce cycle de développement s'est un peu ralenti, cependant le noyau Linux continue à évoluer à un rythme très rapide comparé aux logiciels à source fermé (Windows XP est sorti fin 2001 et Windows Vista est attendu pour début 2007): une version 2.6.x toutes les 7 à 8 semaines comme indiqué dans le tableau ci-dessous:

    Faudrait aussi te rendre compte qu'entre XP et Vista il y a eu :

    a) 2 service packs
    b) D'innombrables patchs au kernel

    Quand au processus soi-disant ferme, c'est evidemment pas aussi transparent que Linux, mais il y a plein d'info disponibles sur ce qui a change, pourquoi, ...
    • [^] # Re: Faut pas exagerer...

      Posté par . Évalué à 2.

      Puis vu la totale instabilité de l'API du kernel linux c'est pas vraiment une gloire de sortir des versions comme on change de chemises.
      • [^] # Re: Faut pas exagerer...

        Posté par (page perso) . Évalué à 6.

        Puis vu la totale instabilité de l'API du kernel linux c'est pas vraiment une gloire de sortir des versions comme on change de chemises.
        Le standard ISO Posix a changé sans prévenir ?
        Sans compter les applications qui utilisent des bibliothèques portables: java, gtk,qt,wx,python,tcl...
        Il me semble que ce sont surtout les API spéciales marquées "experimental" qui changent, et on est donc au courant de leur instabilité quand on les utilise. Il y a aussi "deprecated" pour prévenir à l'avance qu'une API sera un jour enlevée.
      • [^] # Re: Faut pas exagerer...

        Posté par (page perso) . Évalué à 6.

        Justement on t'attendais. Que nous proposes tu pour sortir de cette impasse ? Et dans ta vie à toi tout seul, ça t'a beaucoup dérangé l'instabilité des API/ABI du noyau ?

        M.
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à 3.

          Moi personnellement je ça m'a beaucoup dérangé. Quand on a un pilote libre qui fonctionne avec un kernel version x et qui ne marche plus avec la version x+1, on peut supposer que c'est assez dérangeant. Bien entendu, ils pourraient demander à se faire inclure au kernel. Mais bon chacun à ses raisons, toussa.


          Moi comme solution, je proposerais un truc dans le style : Bien penser l'API à l'avance pour la garder le plus longtemps possible. Et si y'a des changements bah faire du versionning d'API et essayer de garder le support de chaque version de l'API. C'est surement beaucoup de taf mais est ce qu'il y a beaucoup plus de travail à maintenir les API plutot que changer tous les drivers dés qu'on fait un changement dans l'API ?
          • [^] # Re: Faut pas exagerer...

            Posté par (page perso) . Évalué à 6.

            Vous l'avez surement déjà lu mais les raisons pour lesquelles Linux ne veut pas d'API interne stable sont expliquées ici:

            /usr/src/linux/Documentation/stable_api_nonsense.txt

            Bien sûr, ça ne concerne pas les API entre le noyau et les applications utilisateurs qui, elles, sont stables.
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à 4.

          Un pilote libre wifi que j'utilisais demandait des retouches manuelles dans ses sources presque toutes les 0.0.2 versions du kernel qui passent.

          En comparaison j'ai des vieux pilotes proprio qui marchent toujours sous Vista.
          Les attaques gratuites sur windows, ça va deux minutes. Là j'aurais rien dit sur la stabilité des API si vous ne teniez pas le bâton pour vous faire battre.

          Depuis ce tout début, ce cycle de développement s'est un peu ralenti, cependant le noyau Linux continue à évoluer à un rythme très rapide comparé aux logiciels à source fermé (Windows XP est sorti fin 2001 et Windows Vista est attendu pour début 2007): une version 2.6.x toutes les 7 à 8 semaines comme indiqué dans le tableau ci-dessous:

          Moi, perso, je m'en branle qu'il "évolue à un rythme très rapide" si ça veut dire casser tous les pilotes qui n'ont pas été bénis et sanctifiés par sa Sainteté Linus.
          • [^] # Re: Faut pas exagerer...

            Posté par . Évalué à 7.

            lis ça : http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) avant de raconter des anneries.

            Moi, perso, je m'en branle qu'il "évolue à un rythme très rapide" si ça veut dire casser tous les pilotes qui n'ont pas été bénis et sanctifiés par sa Sainteté Linus."

            Sois le driver joue le jeu et est dans le tronc commun et il est mis à jour à chaque modification d'api, soit il n'est pas dedans et se gère tout seul comme un fork !

            "La première sécurité est la liberté"

            • [^] # Re: Faut pas exagerer...

              Posté par . Évalué à 1.

              Répéter la propagande des développeurs kernel ne change rien aux faits. Sous windows on code un driver et on y touche plus pour très longtemps. Sous linux si t'as un driver qui n'est pas dans le tronc tu peux te le foutre dans l'oignon.
              • [^] # Re: Faut pas exagerer...

                Posté par . Évalué à 10.

                Sous windows on code un driver et on y touche plus pour très longtemps

                c'est tellement vrai ce que tu dis. Je te raconte meme pas les enormes trous de securite qui en resulte et ce pendant des annees. Apres c'est tellement stable l'API windows que tout plein de scanner (par exemple) n'ont pas supporte le passage win98 -> winXP et la meme histoire est en train de se repeter avec Vista mais bon c'est vrai c'est pas la faute de MS juste celui des boites tel que Canon qui refusent de faire un drivers pour Vista (enfin l'API n'ayant pas change cela aurait meme pas du exister comme probleme...)
                • [^] # Re: Faut pas exagerer...

                  Posté par . Évalué à -3.

                  c'est tellement vrai ce que tu dis. Je te raconte meme pas les enormes trous de securite qui en resulte et ce pendant des annees

                  Vas y, donne moi donc ces trous de securite qui sont le resultat d'une ABI stable, j'attends et je vais bien rire je sens.

                  Apres c'est tellement stable l'API windows que tout plein de scanner (par exemple) n'ont pas supporte le passage win98 -> winXP

                  Si tu reflechissais 2 secondes, tu te rendrais compte que WinXP c'est pas la version suivante de Win98 mais un OS totalement different avec un kernel completement different.

                  et la meme histoire est en train de se repeter avec Vista mais bon c'est vrai c'est pas la faute de MS juste celui des boites tel que Canon qui refusent de faire un drivers pour Vista (enfin l'API n'ayant pas change cela aurait meme pas du exister comme probleme...)

                  C'est au contraire la preuve que MS fait des changements quand il faut les faire, la grosse difference etant qu'ils ne les font que quand c'est absolument necessaire et dans l'enorme majorite des cas les drivers continuent de tourner.
                  • [^] # Re: Faut pas exagerer...

                    Posté par . Évalué à 2.

                    PasBill pasGates : Si tu reflechissais 2 secondes, tu te rendrais compte que WinXP c'est pas la version suivante de Win98 mais un OS totalement different avec un kernel completement different.

                    taratatatata : En comparaison j'ai des vieux pilotes proprio qui marchent toujours sous Vista.

                    Que dois-je croire ? que les pilotes proprio fonctionnent toujours si changement de version de windows, ou qu'ils peuvent ne pas fonctionner car kernel différent ?
                    • [^] # Re: Faut pas exagerer...

                      Posté par . Évalué à 5.

                      Non, simplement comprendre qu'il y a 2 lignees d'OS chez MS :

                      Win9x : Win95, 98, Millenium

                      WinNT : NT4, W2k, XP, WS03, Vista

                      Les drivers sont senses fonctionner dans une lignee, pas forcement passer d'une lignee a l'autre sans dommage. C'est 2 types d'OS completement differents qui n'ont rien a voir l'un avec l'autre, meme si il y a une couche de compatibilite.

                      Bref, ca revient a dire : Tu peux t'attendre a ce que ton driver fonctionne quand tu passes du kernel 2.4 au 2.6 ou du 2.6.2 au 2.6.4, mais faut pas t'attendre a ce que ton driver fonctionne si tu passes du kernel Linux au kernel freeBSD
                      • [^] # Re: Faut pas exagerer...

                        Posté par . Évalué à 1.

                        Non, simplement comprendre qu'il y a 2 lignees d'OS chez MS :

                        Win9x : Win95, 98, Millenium


                        Tu consideres vraiment Millenium comme un OS? Tu dois etre la seule personne a le penser.
                        • [^] # Re: Faut pas exagerer...

                          Posté par . Évalué à 1.

                          A l'epoque il etait certainement plus utilisable malgre ses defauts par la majorite du public que n'importe quelle version de Linux, donc oui, a moins que tu consideres que Linux n'etait pas un OS a l'epoque.
                          • [^] # Re: Faut pas exagerer...

                            Posté par . Évalué à 5.

                            A bon? Linux etait pas utilisable en 2000? Je veux bien admettre que c'etait pas focement simple a installer mais a utiliser c'etait deja utilisable et surtout stable. Windows millenium ce fut jamais utilisable meme Microsoft deconseillais son utilisation (une fois que tu avais la licence naturellement).

                            Millenium n'etait pas utilisable, linux si sinon l'OS qui tournait sur les pc de ma boite a l'epoque devaient etre magique.
                          • [^] # Re: Faut pas exagerer...

                            Posté par (page perso) . Évalué à 6.

                            Linux a toujours été plus performant et utilisable que Windows.

                            déjà en 1993 Linux vs Windows 3 c'est sans comparaison tellement Linux été supérieur.
                            2 ans plus tard en 1995, Linux était encore largement supérieur à Windows 95. Disons 150 BSOD contre 0 kernel panic ! Un DOS 16 bits avec une GUI vs un système full 32 bits multi utilisateurs. Un système qui ne crois pas en Internet vs un système qui est construit grace à Internet...

                            Seulement a cette époque, la communauté Linux n'avait pas les moyen de se payer les Rollings Stones pour se faire de la pub !
                            • [^] # Re: Faut pas exagerer...

                              Posté par . Évalué à 10.



                              Seulement a cette époque, la communauté Linux n'avait pas les moyen de se payer les Rollings Stones pour se faire de la pub !



                              Et avait vim comme traitement de texte.
                              • [^] # Re: Faut pas exagerer...

                                Posté par (page perso) . Évalué à 6.

                                > Et avait vim comme traitement de texte.

                                Mais aussi
                                StarOffice, Wordperfect, Applixware, Siag Office...
                                • [^] # Re: Faut pas exagerer...

                                  Posté par . Évalué à 4.

                                  Exact, en pas libre (pour les premiers au moins.) Applis qui tournaient aussi sous d'autres Unix si je ne m'abuse.

                                  Je précise, c'est par rapport à cette histoire de driver proprios dans d'autres discussions.
                                • [^] # Re: Faut pas exagerer...

                                  Posté par . Évalué à 0.

                                  WordPerfect n'est apparu qu'en 1998
                                  StarOffice etait inutilisable et crashait constamment(ils venaient de faire le port) en 1996
                                  ...

                                  A croire que tu n'as aucune idee de quoi tu parles.
                            • [^] # Re: Faut pas exagerer...

                              Posté par . Évalué à 1.

                              >Linux a toujours été plus performant et utilisable que Windows.

                              Ridicule:
                              *performance: je me souviens d'un benchmark fait par Microsoft ou Linux se faisait taper par Windows, certes c'était un benchmark pas tres intéressant mais dire que "Linux a toujours été plus performant que Windows" est donc faux, 'Linux est généralement plus performant Windows' est vrai par contre.

                              * utilisable: la je suppose que tu parles de l'OS (l'utilisatibilité d'un noyau, bof): ce qui est dans bien des cas totalement faux: les fournisseurs de matériels fournissent des pilotes pour Windows et rarement pour Linux, donc il y a plus de matériel compatible Windows que Linux, donc pour ce matériel la, Windows est plus utilisable que Linux, pareil pour les logiciels (bien plus de logiciels disponible pour Windows que pour Linux), et la compatibilité avec les standards de fait (.doc, .xls, etc).

                              Etre sur linuxfr n'implique pas de se mettre la tête dans le sable et dire des c*** comme quoi Linux est plus fort que tout, il faut savoir rester réaliste.
                              • [^] # Re: Faut pas exagerer...

                                Posté par . Évalué à 2.

                                D'un autre côté faut essayer de ne pas contredire des conneries par d'autres :

                                - Même si c'est vrai, quel crédit peut-on avoir d'un benchmark fait par Microsoft entre Windows et Linux ? franchement ! c'est comme l'autolabel max havelaar !! ou comme si nvidia faisait un benchmark de ces cartes avec ATI et disait que les cartes nvidia étaient plus rapides !!

                                - les fournisseurs de matériels fournissent des pilotes pour Windows et rarement pour Linux, donc il y a plus de matériel compatible Windows que Linux : c'est marrant, moi qui croyait que Linux était l'OS qui supportait le plus de matériel ! tu ne serais pas en train de généraliser entre le matériel grand public et le matériel en général ? ton affirmation "il y a plus de matériel compatible Windows que Linux" est délirante, surtout qu'il faut distinguer Windows 9x et Windows NT (2000, XP...).

                                - etre compatible avec les pseudo-standards de fait ne fait pas un OS plus performant et utilisable. Avec Linux, tu as toujours pu écrire une lettre ou ton CV avec un traitement de texte (qui depuis on disparu de la circulation).
                                • [^] # Re: Faut pas exagerer...

                                  Posté par . Évalué à 1.

                                  >quel crédit peut-on avoir d'un benchmark fait par Microsoft entre Windows et Linux ?

                                  Le benchmark en question (me souvient plus trop mais c'était une histoire de servir des pages web sur un multi-processeur) était débile, mais les mesures refaites par des supporters de Linux ont établi que la supériorité de Windows dans ce cas la était réelle (depuis cela a été corrigé): donc le toujours est bien faux.

                                  >c'est marrant, moi qui croyait que Linux était l'OS qui supportait le plus de matériel

                                  Tu finasse: Linux "de base" supporte plus de matériel que Windows "de base", mais comme le matériel vient avec un CD de driver pour Windows, il y a quand même plus de matériel utilisable sous Windows en final que sous Linux.
                                  Et je parle bien sur de WindowsXP, le standard a l'heure actuel.

                                  >- etre compatible avec les pseudo-standards de fait ne fait pas un OS plus performant et utilisable. Avec Linux, tu as toujours pu écrire une lettre ou ton CV avec un traitement de texte (qui depuis on disparu de la circulation).

                                  Ah bon, ne pas pouvoir éditer simplement des documents dans un format utilisé par une énorme majorité des entreprises, cela ne rend pas un OS moins utilisable??
                                  C'est beau la mauvaise foi!

                                  La dernière foi que j'ai essayé d'ouvrir un .doc de ma boite avec OOo le résultat était loin d'être terrible: le formatage du document était complement foiré (ok depuis il y a eu plusieurs versions d'OOo) donc on utilise Crossover office, mais c'est loin d'être parfait: super-gourmand, se met souvent a utiliser 100% du CPU, crash parfois, etc..
                                  • [^] # Re: Faut pas exagerer...

                                    Posté par . Évalué à 3.

                                    Tu finasse: Linux "de base" supporte plus de matériel que Windows "de base", mais comme le matériel vient avec un CD de driver pour Windows, il y a quand même plus de matériel utilisable sous Windows en final que sous Linux.
                                    Et je parle bien sur de WindowsXP, le standard a l'heure actuel.


                                    - Au boulot nous avons des cartes d'acquisition qui ne fonctionne pas sous Windows XP.
                                    - la phrase initiale que tu as contredite prenait en compte toutes les versions de windows et de linux, et pas seulement windows XP.
                                    - j'ai connu un scanner agfa scsi qui ne fonctionnait que sous win98

                                    Et je parle bien sur de WindowsXP, le standard à l'heure actuelle.
                                    WindowsXP n'est pas un standard mais un système d'exploitation très utilisé à la maison, mais moins en entreprise qui pour beaucoup en sont encore à windows 2000. Il ne faut pas généraliser en encensant WindowsXP de standard. C'est comme si je disais que Apache était un standard sur le web!

                                    Ah bon, ne pas pouvoir éditer simplement des documents dans un format utilisé par une énorme majorité des entreprises, cela ne rend pas un OS moins utilisable??
                                    Le fait que Word soit utilisé dans la majorité des entreprises ne fait pas de windows un système plus performant. De plus, étant dans le monde du travail de l'informatique depuis plus de 7 ans, je dois avouer n'avoir jamais eu l'occasion d'éditer un document d'une autre entreprise. Les seuls documents que j'ai reçu de l'extérieur sont des PDF afin que je ne puisse pas les éditer. Ah si, je suis un peu de mauvaise fois, des fois je reçois des méls avec des documents words, mais ils auraient été en PDF, ça aurait fait la même chose (ou mieux, l'auteur aurait écrit son texte dans le mél m'aurait éviter de devoir lancer une application tierce pour lire le message). Donc je n'ai jamais eu besoin d'éditer un document venant de l'extérieur.
                                    Et puis, si j'avais du le faire, j'aurais demander à la personne du RTF.


                                    La dernière foi que j'ai essayé d'ouvrir un .doc de ma boite avec OOo le résultat était loin d'être terrible: le formatage du document était complement foiré (ok depuis il y a eu plusieurs versions d'OOo) donc on utilise Crossover office, mais c'est loin d'être parfait: super-gourmand, se met souvent a utiliser 100% du CPU, crash parfois, etc..

                                    Moi aussi, ça me le faisait il y a quelques années. Depuis, j'arrive à lire le texte et avoir une présentation convenable. Et puis si ce n'est pas identique, ce n'est pas grave, l'important est le contenu, pas le contenant.
                                    De plus, il m'arrive aussi d'avoir des crashs avec word. Donc on n'a pas de solution idéale (word) face à une solution dégradée (oo), mais deux solutions qui ont chacune leurs avantages.
                                    • [^] # Re: Faut pas exagerer...

                                      Posté par . Évalué à 1.

                                      Biensur que concerver la qualité du document original est primodial, même si c'est pas l'essentiel , il en va de la crédibilité de ton logiciel.
                                      - J'ai ouvert ton .doc avec Ooo j'ai changer les choses qui n'allait pas je te le refile...
                                      - Ok... mais... t'as tout explosé ma mise en page?
                                      - C'est normal, Ooo n'arrive pas à supporter correctement le format fermé de Word, c'est pourquoi blablabla
                                      - hummm
                                      - tu comprends?
                                      - Soit. Je comprend surtout que tu vas me faire le plaisir de recommencer ce que tu vient de faire avec MS Word, merci, j'ai pas que ça à faire.
                                      - mais Ooo plante pas...
                                      - T sûr? pourquoi tu n'arrives à pas ouvrir ce document et que tu le redémarre sans cesse alors?
                                      - disons.... moins... ok il plante aussi. Mais il n'a pas la procédure de recovery de document en cas de plantage, ce qui va te faire perdre un temps CPU indispensable.
                                      - Tu vois la porte?
                                    • [^] # Re: Faut pas exagerer...

                                      Posté par . Évalué à 0.

                                      Pour ce qui est du matériel tu es de mauvaise foi, on peut toujours trouver un matériel X accessible que sous un OS exotique, mais si tu vas dans n'importe quel grand magasin et que tu achetes du materiel, il sera fourni avec un pilote Windows XP, pas autre chose.

                                      > WindowsXP n'est pas un standard
                                      OK, disons l'OS majoritairement utilisé.

                                      >C'est comme si je disais que Apache était un standard sur le web!
                                      Dans le sens ou j'utilisais 'standard', c'est presque le cas..

                                      >Le fait que Word soit utilisé dans la majorité des entreprises ne fait pas de windows un système plus performant.
                                      Performant non, utilisable oui.

                                      >n'avoir jamais eu l'occasion d'éditer un document d'une autre entreprise.
                                      Et alors? Dans mon entreprise, le standard est .doc (comme dans une grande majorité des entreprise), et oui on s'édite mutuellement des docs.

                                      Si je demande a l'expéditeur de me fournir un RTF, il m'envera bouler: la boite a choisi de se standardiser sur .doc, il y a même des templates de documents a utiliser.
                                      Cela peut changer: avant le standard pour la doc technique était interleaf, mais ce genre de migration est lourd et compliquée a faire.

                                      Mouai, je ne dirais jamais que Word est idéal (personnellement je déteste Word), n'empèche que pour éditer des .doc, ça reste plus simple d'utiliser Office sous Windows que sous Linux, et donc l'OS est plus utilisable de ce point de vue.
                                      • [^] # Re: Faut pas exagerer...

                                        Posté par . Évalué à 2.

                                        Pour ce qui est du matériel tu es de mauvaise foi, on peut toujours trouver un matériel X accessible que sous un OS exotique, mais si tu vas dans n'importe quel grand magasin et que tu achetes du materiel, il sera fourni avec un pilote Windows XP, pas autre chose.

                                        Le problème est que le matériel d'acquisition ne se trouve pas en magasin grand public. Quand tu dis que Windows XP supporte tous les matériels, je corriges en disant que Windows XP supporte tous les matériels que tu peux acheter dans les magasins grand public. Là où je travaille, nous nous coltinons encore des win98 et winNT uniquement à cause de matériels non supportés sous XP.

                                        Dans le sens ou j'utilisais 'standard', c'est presque le cas..
                                        mais vaut mieux utiliser un autre mot que "standard", car toi tu comprends ce que tu veux dire, mais d'autres vont l'interprêter autrement. Tu connais le téléphone arabe ?

                                        Et alors? Dans mon entreprise, le standard est .doc (comme dans une grande majorité des entreprise), et oui on s'édite mutuellement des docs.
                                        Intra-entreprise, oui, et je ne comprendrais pas qu'il n'y ait pas de politique commune dans le choix des standards. Mais je parlais des échanges inter-entreprise qui sont souvent avancés par argument pour utiliser tel logiciel, mais que de mon vivant, je n'ai pas encore vu.

                                        Donc en conclusion, on pourrait dire que Windows est plus utilisable que Linux pour la façon dont on a décidé de l'utiliser. Mais on aurait très bien pu faire la même chose avec Linux.
                              • [^] # Re: Faut pas exagerer...

                                Posté par (page perso) . Évalué à 8.

                                > donc il y a plus de matériel compatible Windows que Linux

                                Dans tes rèves !!

                                Linux tourne sur la quasi totalité des architectures informatiques existantes, du périphériques embarques aux supercalculateurs.
                                Il tourne sur tout type de station de travail (sparc, powerpc, mips, ...). Il supporte des dizaines de milliers de périphériques toutes architectures confondues...

                                Franchement, Windows est à la traine et même incroyablement selectif quand au matériel sur lequel il peut tourner. Et avec Vista ça ne s'arrange pas, bien au contraire.
                                • [^] # Re: Faut pas exagerer...

                                  Posté par . Évalué à -3.

                                  Ca on s'en fout, l'enorme majorite des gens veut un OS qui fonctionne avec le matos qu'ils ont ou qu'ils trouvent dans les grand magasins, et la c'est vite vu.

                                  Tu peux toujours t'amuser a aller prendre des cas speciaux et exotiques, ca ne changera pas la realite, ca renforcera juste tes frustrations.
                                  • [^] # Re: Faut pas exagerer...

                                    Posté par . Évalué à 6.

                                    oui, et pourquoi Windows est-il fourni d'office avec les machines neuves ?
                                    tout simplement parce que sous windows, l'intrégration système, la gestion des drivers sur le matériel récent est aussi casse-tete que sur linux, pour ne pas dire plus compliqué.

                                    Donc ma conclusion est : pourquoi ca marche sous windows, "en sortant du caddy" : parce qu'un intégrateur à fait le boulot avant toi.

                                    Alors je relance la balle : si j'achete un PC tout intégré sous Linux, je suis presque certain de trouver la même facilité d'utilisation, puisque c'est l'intégrateur qui aurait tout le travail.

                                    Maintenant, si on sort de ce contexte intégration, je crois bien que Windows et Linux se valent. En gros, le résultat est fonction de la direction du vent, de la température extérieure, de la couleur de la jupe de Ségolène, de l'indice du CAC 40 ....
                                    • [^] # Re: Faut pas exagerer...

                                      Posté par . Évalué à 1.

                                      >pourquoi Windows est-il fourni d'office avec les machines neuves ?

                                      Parce que plus de 90% des utilisateurs utilisent Windows? Parce que Microsoft fait payer une license Windows pour tout les PC vendus par le fabriquant?

                                      >l'intégration système, la gestion des drivers sur le matériel récent est aussi casse-tete que sur linux, pour ne pas dire plus compliqué.

                                      Faux, du matériel récent n'a souvent pas de pilote Linux, alors le fabriquant fourni le pilote pour Windows.

                                      > si j'achete un PC tout intégré sous Linux, je suis presque certain de trouver la même facilité d'utilisation, puisque c'est l'intégrateur qui aurait tout le travail.

                                      En théorie oui, en pratique j'ai déja vue des revue de PC 'tout intégré sous Linux' ou le seul boulot fait par l'intégrateur était de prendre une distrib Linux de l'installer sur le PC et si la carte Wifi ne fonctionne pas, tant pis..

                                      > je crois bien que Windows et Linux se valent.

                                      Pour la majorité des utilisateurs, à l'heure actuelle et leur besoins (bureautique, jeux), je dirais que Windows est supérieur a Linux sauf que les problèmes de sécurité de Windows annulent tous gain voire même désavantage Windows, sauf pour ceux qui savent sécuriser Windows, ce qui est hors de portée du débutant mais quand même pas si compliqué..
                                • [^] # Re: Faut pas exagerer...

                                  Posté par . Évalué à 1.

                                  bonne argument :-)

                                  C'est vrai que pour le PC spécial ado (webcam de carrefour, imprimante de chez Aldi, dernière carte ATI/NVidia/Autre flambant neuve) il n'y pas souvent de drivers pour linux.

                                  En revanche, faire tourner windows 2000 sur Sparc ou MS SQL Server sur AIX, c'est très dur.
                                  • [^] # Re: Faut pas exagerer...

                                    Posté par (page perso) . Évalué à 1.

                                    bah le PC spécial ado, s'il a plus d'un an, il ne tournera pas non plus sur la prochaine version de Windows faute de drivers non plus hein...
                • [^] # Re: Faut pas exagerer...

                  Posté par . Évalué à 1.

                  Comme l'a dit pasBill pasGates, ce n'est plus du tout le même OS. Y'a les mêmes API pour les applications mais l'os en dessous n'a rien à voir.

                  Quand je parle de vieux pilotes qui marchent sous vista, je parle de pilotes pour Windows 2000. Qui est de la lignée NT5.
                  Ca fait donc un driver qui utilise les API d'un kernel vieux de 7 ans. Ce même driver fonctionne sur l'os qui va sortir en 2007.

                  En comparaison des cassures qu'on peut constater entre chaque versions du kernel 2.6 qui est tout jeune.. y'a pas photo. Le 2.6 est sorti en décembre 2003 et n'en a pas fini de casser les API comme je change de chemises. Et c'est pas avec des développeurs comme Greg Kroah-Hartman qu'on va changer la donne..
                  • [^] # Re: Faut pas exagerer...

                    Posté par . Évalué à 2.

                    Quand je parle de vieux pilotes qui marchent sous vista, je parle de pilotes pour Windows 2000. Qui est de la lignée NT5.
                    Ca fait donc un driver qui utilise les API d'un kernel vieux de 7 ans. Ce même driver fonctionne sur l'os qui va sortir en 2007.


                    ouhias enfin tous les drivers windows2000 ont pas trop supporte le passage a XP donc celui a Vista je doute enormement.
              • [^] # L'hopital qui se fout de la charité....

                Posté par . Évalué à 6.

                ben ouais, tiens c'est marrant, mon scaner agfa e26, ben c'est con il ne marche pas sous XP, Agfa a arreté de faire des scanner alors que le drivers ne gerait que du 2000. domage...

                et oui, c'est vrai, "on code un driver et on y touche plus pour tres longtemps" : en effet, s'il s'écoule 5 ans entre 2 version de windows, ton assertion est parfaitment juste, mais c'est uniquement a cause du retards de microsoft, parcequ'en attendant il est plutôt d'actualité que les drivers sous vista se font attendre.
                (c'est con pour toi, car c'est justement pas le moment pour sortir ce genre de connerie...)
                • [^] # Re: L'hopital qui se fout de la charité....

                  Posté par . Évalué à 3.

                  Ben le monsieur au dessus (pbpg) qui a l'air de s'y connaitre dans windows l dit que c'est la meme famille d'OS 2000 et XP. Je comprend rien moi comment ca peut avoir casser le driver alors?
                  • [^] # Re: L'hopital qui se fout de la charité....

                    Posté par . Évalué à -1.

                    Si tu lisais attentivement tu aurais lu :

                    C'est au contraire la preuve que MS fait des changements quand il faut les faire, la grosse difference etant qu'ils ne les font que quand c'est absolument necessaire et dans l'enorme majorite des cas les drivers continuent de tourner.

                    Ce qui explique que l'enorme majorite des drivesr pour 2000 tournent sans probleme sur XP et WS03.

                    Prendre les qqe cas ou ca ne marche pas ne va pas changer la realite pour l'enorme majorite des drivers.
                    • [^] # Re: L'hopital qui se fout de la charité....

                      Posté par . Évalué à 1.

                      Prendre les qqe cas ou ca ne marche pas ne va pas changer la realite pour l'enorme majorite des drivers.

                      idem pour les drivers linux!
                      • [^] # Re: L'hopital qui se fout de la charité....

                        Posté par . Évalué à -1.

                        Prends des binaires de drivers Linux de 2001, essaie de les faire tourner sur un kernel d'aujourd'hui, compte combien tournent.

                        Je te paries mes 2 bras qu'il y en aura tres tres peu.
                        • [^] # Re: L'hopital qui se fout de la charité....

                          Posté par . Évalué à 4.

                          jusqu'a maintenant (dans ce journal) je trouvais tes interventions bien plus cohérente que celles taratatata, mais là c'est limite un troll, effectuer une comparaison entre windows en 2001 et celui de fin 2006 : il s'agit du même (vista n'est pas encore sortie concretement, pas de boite a la fnac, et pas dans le shipment msdn pro de decembre). donc en fait.
                          comparer windows XP (2001) et windows XP sp2 (2006)
                          ce n'est pas la même chose que de comparer un kernel 2.4.3 et un 2.6.19

                          sinon, je suis d'accord, on ne peux pas faire une généralités d'un cas personnel (le mien avec mon agfa en l'occurrence).
                        • [^] # Re: L'hopital qui se fout de la charité....

                          Posté par . Évalué à 1.

                          Prends des binaires de drivers Linux de 2001, essaie de les faire tourner sur un kernel d'aujourd'hui

                          Ne le prends pas mal, mais c'est un peu con de vouloir faire ça !
                          • [^] # Re: L'hopital qui se fout de la charité....

                            Posté par . Évalué à 3.

                            C'est surtout inutile, car "la grande majorité" du materiel supporté par Linux en 2001 est toujours supporté sur un kernel d'aujourd'hui.
                            Et même si ce n'est pas le cas, la disponibilité des sources fait que le portage reste possible, donc en fait tout materiel supporté à une certaine époque peut être porté dans toute version plus récente.

                            Évidemment dans le monde fermé, il ne reste que les yeux pour pleurer quand le constructeur refuse de porter le-dit driver...
                          • [^] # Re: L'hopital qui se fout de la charité....

                            Posté par . Évalué à 1.

                            peut etre est-ce pour garder les bonnes habitudes acquisent sous windows, utiliser des drivers bien troues et qui marchottent a peine?
                            Enfin personnelement je prefere avoir des drivers qui evoluent avec le temps et pas uniquement avec le matos...
            • [^] # Re: Faut pas exagerer...

              Posté par (page perso) . Évalué à 0.

              Sois le driver joue le jeu et est dans le tronc commun et il est mis à jour à chaque modification d'api, soit il n'est pas dedans et se gère tout seul comme un fork !
              Ah elle est jolie la philosophie de l'interopérabilité ! Ah elle est jolie la critique de MS lorsqu'ils cassent la compatibilité avec un standard ! Faudrait standardiser les interfaces du kernel pour rigoler tiens. Heuresement que à la couche supérieur y'a eu POSIX, sinon j'imagine même pas dans quel bordel on serait. C'est pas au même étage, mais les problématiques sont les mêmes. Linus & Co veulent tout maîtriser et veulent forcer tout le monde à rentrer dans leur tronc commun (sous peine d'être un driver de seconde classe jamais synchronisé tellement ca change souvent).
              C'est quand même pas compliqué de conserver un API tel quel, et d'en faire un nouveau en repartant de 0 à côté, les 2 pouvant marcher côte côte, l'un pour les anciens drivers, l'autre pour les nouveaux.
              Non, faut dire ce qui est, garder la compatibilité, ca les fait chier. Ca serait pourtant plus simple que de perdre son temps à continuellement modifier une énorme base de driver.

              Une API de qualité est avant tout une API conçue pour être pérenne dans le temps, bref, conçu pour le présent et l'avenir. Le fait d'avoir les sources et la main mise sur l'ensemble des drivers ne doit pas être une excuse pour occulter ce manque de qualité.

              Enfin ca me fait marrer cette comparaison avec le fork... En tout cas ca montre bien le modèle de développement du kernel : complètement fermé vers l'extérieur. Ils veulent tout maîtriser, ils en ont rien à péter de s'interfacer avec des briques extérieures. Logiciel libre avec une interface fermée, ca me paraît à l'opposé philosophiquement. C'est quand même rigolo, à l'époque où les Unix étaient tous proprio, eux avait pensé interopérabilité avec POSIX.

              Exemple de problème de pérénité dans le temps : en tant qu'utilisateur j'aimerai qu'on me laisse ma liberté de conserver des anciens pilotes tout en en profitant des mises-à-jour de pilotes plus récent. Non, le noyau me laisse pas le choix, si t'upgrade, faut tout upgrader. Et non, les maj n'apporte pas que des améliorations, y'a aussi parfois des régressions.
              • [^] # Re: Faut pas exagerer...

                Posté par . Évalué à 8.

                Bon, je vais supposer que tu as lu le document déjà donné deux ou trois fois précédemment. L'API interne ne concerne que ... la tambouille interne du noyau. Mais ledit document précise bien un truc : si jamais quelqu'un modifie une api, c'est à sa charge de répercuter le changement d'API sur le code noyau, i.e. l'intérêt de tout ça c'est la factorisation de code, et d'avoir à effectuer le moins de changement dans les pilotes eux-mêmes. Si ces derniers sont inclus dans le noyau officiel, alors oui, ils seront aussi modifiés en conséquence ; sinon, c'est à charge de celui qui fournit le pilote de le modifier. Ça me semble assez logique, finalement.

                Le côté « oui mais bon, les API stables, ça permet de pouvoir garder une compatibilité plus longtemps, etc » ne tient pas selon moi dans une optique de logiciel libre, car si tu fais du code hors-noyau (le plus souvent propriétaire), alors de toute façon il ne te reste plus qu'à maintenir un seul et unique driver - ce qui suppose que tu suis les changements opérés dans le noyau, certes, mais d'un autre côté, ça fait partie du jeu : de ce que j'ai compris, seuls les pilotes codés avec les pieds [1] et ceux qui sont proprio sont concernés, au final. Dans le premier cas, je comprends qu'une équipe de développement n'ait pas envie de servir de debugger pour un pilote qui gagnerait à être proprifié. Dans le deuxième, si tu fais du propriétaire, et tu assumes un chouilla. Ça ne me semble pas démesuré, comme principe.

                Pour faire un rapide résumé/traduction de stable_api_nonsense.txt :

                - Croire qu'avec une API stable, on obtient une ABI stable est faux, car suivant le compilateur utilisé, par exemple, les alignements, lef ait d'inliner certaines fonctions, etc. changent ; stabilité = nil.
                - suivant les options noyau choisies, on se retrouve avec des champs qui apparaissent ou disparaissent dans les structures, l'alignement va changer, etc. ;
                - Il y a tout plein d'architectures différentes supportées par linux ; aucune compatibilité binaire entre elles donc.

                Donc on se retrouve avec l'obligation de devoir utiliser un compilateur pour une distribution et une architecture spécifiques, si on veut pouvoir garder cette propriété de stabilité. Sans parler du côté SMP/SMT/CMP/MonoProc qu'on doit choisir...

                Je m'arrête là. Comme il a été dit plus tôt ( https://linuxfr.org/comments/785368.html#785368 ) tout cela tient plus au modèle choisi qu'à quelqu'un ayant tort ou raison. Par contre, si pour un OS comme celui de MS (ou d'Apple, d'ailleurs), utiliser une seule architecture ainsi qu'un seul noyau permet de réduire fortement les inconvénients cités précédemment, je ne vois pas comment Linux pourrait faire de même.

                [1] D'après les critères de qualité de l'équipe de dév. du noyau, certes.
                • [^] # Re: Faut pas exagerer...

                  Posté par (page perso) . Évalué à 2.

                  Croire qu'avec une API stable, on obtient une ABI stable est faux, car suivant le compilateur utilisé, par exemple, les alignements, lef ait d'inliner certaines fonctions, etc. changent ; stabilité = nil.
                  Je suis bien d'accord. C'est par contre un problème purement technique, lié au langage C (pourri pour ce qui est de faire des ABI stable). Mais à la limite je m'en cogne d'avoir des ABI stable, on est dans le monde libre, je veux bien me "taper" la recompilation d'un driver.
                  Je demande pas la compatibilité binaire, juste une compatibilité au niveau source. Bref, des API stables.
                  • [^] # Re: Faut pas exagerer...

                    Posté par . Évalué à 2.

                    ben elles existent.
                    les API tels quels sont stables
                    Par contre la tambouille interne au noyau ... ben elle est interne au noyau , et pas forcément stable.

                    Enfin c'est ce que j'ai compris.
                    • [^] # Re: Faut pas exagerer...

                      Posté par (page perso) . Évalué à 2.

                      Le truc c'est qu'ils considèrent que les API des drivers sont de la tambouille interne, genre comme si les drivers faisaient partie intégrante du noyau.
                      • [^] # Re: Faut pas exagerer...

                        Posté par (page perso) . Évalué à 1.

                        Ben c'est absolument le cas, d'un point de vue technique. Les pilotes s'exécutent dans l'espace mémoire du noyau, avec ses droits d'accès, ses privilèges, sa capacité à tout péter... Aucun moyen de se protéger d'un pilote, qui peut d'ailleurs altérer tout le comportement du noyau s'il le souhaite.
                        • [^] # Re: Faut pas exagerer...

                          Posté par (page perso) . Évalué à 1.

                          D'un point de vu droit d'exécution oui. D'un point de vu purement technique non. Bien qu'étant un noyau monolithique à la base, Linux est quand même suffisament bien foutu pour accepter des drivers "externes", d'où la présence des APIs. Ce qui les rend pas "user-friendly", c'est la façon dont ils sont maintenus. Y'a aucune raison de cantonner les drivers au processus interne de dev du noyau, ca doit ête externaliser pour que tout le monde puisse développer ses propres drivers sans subir la politique d'évolution du kernel. Evidemment, ca demande un minimum de boulot d'ingénierie de la part du noyau.
                          Et puis si on en revient à la question des privilèges utilisateurs, il n'est pas non plus pertinent de faire tourner l'ensemble des drivers avec les droits du noyau. Si un grand nombre de driver tourne encore dans cet espace de droit, c'est simplement pour des questions techniques (vitesse toussa), mais d'un point de vue architectural c'est pas du tout préconisé. Pour comparer avec un OS proprio dernière génération, beaucoup de drivers sont gérés avec un niveau de droit inférieurs aux droits du kernel lui même, voir même en espace utilisateur.
                          Evidemment, tout cela demande une refonte technique et politique du noyau Linux, mais ca reste un objectif de qualité qu'ils devraient se fixer, et visiblement ils s'en cognent. Si tu veux développer ton driver et que tu n'as pas l'intention de l'incorporer dans la branche principal, ils ne font rien pour t'aider, tu te démerdes pour suivre ces API "internes".
                          • [^] # Re: Faut pas exagerer...

                            Posté par . Évalué à 2.


                            Evidemment, tout cela demande une refonte technique et politique du noyau Linux, mais ca reste un objectif de qualité qu'ils devraient se fixer, et visiblement ils s'en cognent. Si tu veux développer ton driver et que tu n'as pas l'intention de l'incorporer dans la branche principal, ils ne font rien pour t'aider, tu te démerdes pour suivre ces API "internes".

                            Rien ne t'empeche de patcher linux, le forker , contribuer à HURD, ou encore à nemesis.
                            • [^] # Re: Faut pas exagerer...

                              Posté par (page perso) . Évalué à 5.

                              Rien ne t'empeche de patcher linux, le forker , contribuer à HURD, ou encore à nemesis.
                              Comme je l'ai déjà expliqué, Linux contribue à "tuer" les initiatives concurrentes : le nerf de la guerre, c'est les drivers. Hors Linux rend non viable tous fork de son noyau (au risque de devoir forker et maintenir tous les drivers), et difficile toute alternative : les drivers ne peuvent être réutiliser.
                              je trouve vraiment dommage cette politique qui nuit clairement à la réutilisation (pourtant un des gros atouts des logiciels libres) et à la création d'alternatives.
                              Après l'initiative freedesktop, faudrait une initiative freekernel :)
              • [^] # Re: Faut pas exagerer...

                Posté par . Évalué à 10.

                Ha ça y est, t'as trouvé un sujet sur lequel te défouler :

                Ah elle est jolie la philosophie de l'interopérabilité ! Ah elle est jolie la critique de MS lorsqu'ils cassent la compatibilité avec un standard !

                Ce dont on parle n'a rien à voir avec un standard, c'est la cuisine interne du noyau. Critique gratuite à 2 fr qui n'a rien à voir avec le sujet.

                Faudrait standardiser les interfaces du kernel pour rigoler tiens.

                Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.

                Heuresement que à la couche supérieur y'a eu POSIX, sinon j'imagine même pas dans quel bordel on serait. C'est pas au même étage, mais les problématiques sont les mêmes.

                Bah justement, comme c'est à un niveau plus élevé, c'est d'une certaine manière plus facile à respecter, puisque le "sens" de l'API est plus élevé, et qu'on est pas dans la cuisine bas-niveau.

                Linus & Co veulent tout maîtriser et veulent forcer tout le monde à rentrer dans leur tronc commun (sous peine d'être un driver de seconde classe jamais synchronisé tellement ca change souvent).

                Ha oui, bien sûr, la conspiration contre les petits développeurs et les constructeurs ...

                C'est quand même pas compliqué de conserver un API tel quel, et d'en faire un nouveau en repartant de 0 à côté, les 2 pouvant marcher côte côte, l'un pour les anciens drivers, l'autre pour les nouveaux.

                Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
                Pour un exemple de compications dues à ça, regarde le temps qu'il faut pour intégrer la pile ieee80211 de Devicescape : ça fait un bout de temps qu'on en parle et qu'elle est toujours pas upstream, et pendant ce temps il faut continuer à faire évoluer en parallèle celle d'Intel.

                Non, faut dire ce qui est, garder la compatibilité, ca les fait chier.

                Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.

                Ca serait pourtant plus simple que de perdre son temps à continuellement modifier une énorme base de driver.

                Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !

                Une API de qualité est avant tout une API conçue pour être pérenne dans le temps, bref, conçu pour le présent et l'avenir. Le fait d'avoir les sources et la main mise sur l'ensemble des drivers ne doit pas être une excuse pour occulter ce manque de qualité.

                Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio : les changements d'API arrivent donc plus souvent, et d'un coté c'est clair que la disposition des sources incite d'autant plus à ne pas se restreindre à une vieille API car le mode de développement du libre permet de facilement faire évoluer tous les drivers ensemble.

                Enfin ca me fait marrer cette comparaison avec le fork... En tout cas ca montre bien le modèle de développement du kernel : complètement fermé vers l'extérieur. Ils veulent tout maîtriser, ils en ont rien à péter de s'interfacer avec des briques extérieures.

                N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés. Par contre, ils n'en ont effectivement rien à péter que des gens leurs imposent leur méthodes de travail : le libre avance comme ça et c'est tout. C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API ! Ce n'est pas au monde du proprio de dicter la manière dont doivent évoluer les déveoppeurs. Dans le libre, ceux qui peuvent avoir un poid sur les discussions, ce sont ceux qui jouent le jeu du libre. Et donc surement pas NVidia et ATI.

                Logiciel libre avec une interface fermée, ca me paraît à l'opposé philosophiquement.

                Encore du n'importe quoi, les changements sont généralement documentés.

                C'est quand même rigolo, à l'époque où les Unix étaient tous proprio, eux avait pensé interopérabilité avec POSIX.

                Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.

                Exemple de problème de pérénité dans le temps : en tant qu'utilisateur j'aimerai qu'on me laisse ma liberté de conserver des anciens pilotes tout en en profitant des mises-à-jour de pilotes plus récent. Non, le noyau me laisse pas le choix, si t'upgrade, faut tout upgrader. Et non, les maj n'apporte pas que des améliorations, y'a aussi parfois des régressions.

                Alors là, tu pousses un peu le bouchon : tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance. Moi aussi j'aimerais bien avoir la liberté de te faire fermer ta gueule des fois, mais bon ...

                PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve
                • [^] # Re: Faut pas exagerer...

                  Posté par (page perso) . Évalué à 2.

                  Ce dont on parle n'a rien à voir avec un standard, c'est la cuisine interne du noyau.
                  Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".

                  Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.
                  Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.

                  Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
                  Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.

                  Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.
                  Mais je parle pas de proprio du remarqueras. Je parles aussi des drivers en général.

                  Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !
                  T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?

                  Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio :
                  Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).

                  N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés.
                  C'est pas n'importe quoi, ca change beaucoup trop souvent.

                  C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API !
                  Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)

                  Encore du n'importe quoi, les changements sont généralement documentés.
                  Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".

                  Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.
                  Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.

                  tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance.
                  Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.

                  PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve
                  C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.

                  Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.
                  • [^] # Re: Faut pas exagerer...

                    Posté par . Évalué à 5.

                    Excuse-moi pour le message précédent, je vais la refaire plus calme :
                    Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".

                    La volonté des développeurs du noyau n'est pas de "fermer" son développement en préférant intégrer les drivers dans la branche principale, mais de prévenir les développeurs externes qu'ils vont devoir s'adapter régulièrement à des petits changements s'ils décident de rester en dehors. Comme ça, ils sont prévenus et n'ont pas à gueuler après, que c'est comme ça que ça se passe quand on fait du dev sur le kernel. Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.

                    Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.

                    Là, tu demandes à redéfinir les bases de notre discussion : jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur. Mais donc ce que tu proposes aujourd'hui c'est de standardiser l'interface driver ? Ca demande un autre débat ...

                    Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.

                    Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.

                    T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?

                    D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ? Le changement sera d'autant plus grand ! Des changements petit à petit ça permet justement de pas trop perdre de drivers d'un coup, de faire la transition "doucement" (même si ça casse à chaque fois, les modifications sont mineures). Arriver à une bonne API du premier coup est quasi impossible, c'est pour ça que le code n'est jamais vraiment réécrit "from scratch" quand on propose une nouvelle API. Et ce n'est pas parce que ce n'est pas refait complètement que c'est bancal ! Franchement, regarde les sources du noyau, ya des fichiers qui ont encore l'entête de linux avant la 1.0, et pourtant ils sont aujourd'hui, après modifications successives, très bien intégrés à l'ensemble.

                    Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).

                    Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ? (c'est pas pour te faire chier à montrer que j'ai raison ou que t'en trouves pas, c'est vraiment pour étudier le problème plus concrètement) Des changements d'ABI incessants, peut-être, et c'est normal, pour l'API par contre ... à moins que tu ne parles d'une section encore expérimentale ou en cours de développement ?

                    Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)

                    Pour ton problème spécifique, ça me paraît dommage en effet, c'est peut-être le manque de détermination du dev qui a fait que peu de personnes se sont intéressées à l'intégration... alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes (selon moi, je ne connais pas vraiment grand monde qui a une AIW), il faut arriver à convaincre les devs upstream que son problème est important. C'est toujours pareil, on est pas dans une entreprise, on est dans un projet communautaire ... Bon, ça doit pas devenir une excuse, effectivement pour ce cas là il y a effectivement un problème, mais ce n'est pas un problème d'API selon moi (sinon je veux bien quelques liens pour mieux comprendre).
                    Pour le coup des devs qui changent l'API rien que pour faire chier les devs proprio, je te laisse dans ta parano, ce n'est pas du tout ce que j'ai dit.

                    Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".

                    Je comprend ce que tu veux dire par là, mais je ne serais pas aussi extrême : oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".

                    Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.

                    Alors moi aussi je vais dire que tu fais exprès de ne pas comprendre : POSIX désigne une interface utilisateur, ce qui n'a rien à voir avec une interface driver. On aura toujours une API permettant d'ouvrir un fichier avec une fonction, de lire tant d'octets avec une autre, etc ... Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter. Et même les anciennes suivent le pas.

                    Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.

                    Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes (je n'ai pas dit que tu n'avais pas le droit de donner ton avis par contre, soyons clairs). Cela devrait être réglé par les devs. Je trouve ça dommage par contre si certains utilisent leur communauté d'utilisateur comme moyen de chantage sur d'autres devs.

                    C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.

                    J'ai cité l'intégralité de ton commentaire, en analysant phrase par phrase, et en m'efforçant de comprendre quand ce n'était pas des critiques lancées gratuitement en l'air.

                    Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.

                    Oui, dans l'idéal, ce serait comme ça qu'il faudrait faire. Mais trouve moi quelqu'un qui arrive du premier coup à rassembler toutes ces qualités dans son code. Il n'existe aujourd'hui aucun OS capable de cela sans un minimum de changement de code et de cassage d'API.

                    Je pense que tout le problème, c'est de décider entre avoir un truc très stable mais sur lequel il faudra bidouiller au cas où on a pas visé juste du premier coup, ou alors faire un truc qui évolue tout le temps, mais qui casse régulièrements les APIs. La solution choisie pour linux est la 2e, et la philosophie du développement kernel, ça a toujours été d'effectuer les changements petit à petit, sans trop gros accoups. Au final, cela permet d'évoluer plus vite, et la modularisation arrive petit à petit; un jour, on verra peut-être une interface stable aux drivers, quand le kernel aura bien été séparé et "standardisé". Par exemple, la possibilité d'utiliser une machine sans MMU (changement assez profond, quand même), n'a été intégrée qu'au 2.6, alors qu'il existait des patches depuis quelques temps pour le 2.4, mais il a fallu la volonté des devs et leur persévérance pour changer petit à petit le code du noyau, jusqu'à être intégrés upstream.
                    • [^] # Re: Faut pas exagerer...

                      Posté par (page perso) . Évalué à 3.

                      Excuse-moi pour le message précédent, je vais la refaire plus calme :
                      Merci, c'est beaucoup plus intéressant comme ca en plus ;)

                      Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
                      Toutafé :)

                      jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur.
                      Je n'employais pas le terme utilisateur au sens séparation espace noyau/espace utilisateur, mais au sens utilisation : le kernel offre des services et des points d'entrée pour s'interfacer avec lui. Pour moi les drivers sont un moyen d'utiliser le kernel (et réciproquement) au même titre que POSIX (même si c'est pas du tout le même cadre d'utilisation), les drivers ne doivent pas être "fagocités" par le kernel.

                      Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
                      La stabilité de l'API constitue également une qualité. Il y a pleins de choses qui font qu'une brique logicielle est de qualité : qualité du code, qualité de la documentation, qualité de la conception, etc. J'ai essayé d'expliquer que des API non stables peut être véritablement handicapant, que ce n'est pas une simple question de compatibilité avec le proprio, que c'est un problème de qualité plus général.

                      D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ?
                      Oui, en parrallèle. On met en place un groupe "d'architecte" qui concoivent une API pensée avec les technos d'aujourd'hui et celle de demain, on fait un truc "propre" avec une certaine durée de vie. Et surtout on s'arrange pour que ca soit facile à "échanger" contre un nouvel API dans le futur, car c'est évident que le boulot devra être refait dans plusieurs mois/années. Si c'est bien foutu, on pourra créer une nouvelle version de l'API plus tard, migrer ceux qui sont important, et garder la compatibilité avec l'ancien. Un peu comme de nombreuses bibliothèques au niveau applicatif. Ca marche très bien, on conserve la compatibilité avec les "vieux" trucs qui personne ne veut plus toucher (le plus souvent "parceque ca marche") et de l'autre on propose du neuf.

                      Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ?
                      Fut un temps ma clé USB était reconnue. Puis pouf plus reconnue. 1 an après re-reconnue. Relou. Pareil pour ma carte son, fut une époque où la sortie numérique fonctionnait, plus maintenant. Tu me diras sur ce coup je suis pas sûr, ca vient peut être du serveur de son qui a changé, je sais pas trop à quel niveau ca se passe ca.

                      .. alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes
                      C'est pour ca que dire "on a les sources, c'est pas proprio, ca va évoluer avec le noyau", c'est illusoire. C'est pareil dans le monde proprio, les vieux trucs qui deviennent "anonymes" ne sont plus maintenu par manque d'intérêt de la part des dev. Et c'est pour ca que j'aimerai bien que les API restent stables pour que je puisse garder mon vieux driver-qui-marchait plutôt que de le voir évoluer vers le néant.

                      oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
                      J'ai bien entendu forcé le trait. Mais l'idée est là : les dev du noyau veulent fagociter un maximum de chose, ils promettent le support du vieux matos mais le résultat n'est pas forcement là, et ca se comprend aisement. Et je suis près à parier que plus la base de driver va grossir, et plus on aura de problèmes.

                      Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes
                      Toutafé. Et moi en tant qu'utilisateur je constate parfois les "dégâts". Et j'ai la chance en tant que développeur de comprendre le contexte et le pourquoi du problème, et c'est pour ca que je gueule :)

                      Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter.
                      Toutafé. Mais moi je dis que y'a d'autres manière de "s'adapter" à mon sens.

                      Sinon je plussois toute la fin de ton commentaire ;)
                      Moi ce que je trouve dommage c'est qu'un des problèmes majeurs de Linux est le support du matos, à cause du manque de disponibilité de doc de la part des constructeurs. J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
                      Pfff, vivement le Hurd ;)
                      • [^] # Re: Faut pas exagerer...

                        Posté par (page perso) . Évalué à 3.

                        J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.

                        que manque-t-il comme lien explicatif sur cette page :
                        http://wiki.eagle-usb.org/wakka.php?wiki=CommunicationLibre
                        (tu noteras notamment la FAQ constructeur + les formations au dév kernel, mais j'ai essayé de retrouver les liens utiles pour avoir tout le contexte)
                  • [^] # Re: Faut pas exagerer...

                    Posté par (page perso) . Évalué à 1.

                    > Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique.


                    Tu peux préciser ?
                    Et puis si tu n'est pas content , reste sous Windows ! Ha, 2s... on me souffle dans l'oreille que ta Radeon AIW n'est plus supporté par ATI sous Windows et que tu peux te brosser pour la faire tourner sous Vista et qu'au final il n'y a plus que Linux pour être capable de la faire fonctionner !
                    • [^] # Re: Faut pas exagerer...

                      Posté par (page perso) . Évalué à 2.

                      Tu peux préciser ?
                      Ben concrêtement avant j'installait le driver Gatos, et j'avais la possibilité d'utiliser la sortie TV de la carte par exemple. Depuis "l'intégration" à X.org, marche plus. Et évidemment Gatos n'est plus maintenu en externe.

                      Et puis si tu n'est pas content , reste sous Windows !
                      Déjà faudrait que j'y sois :) Non, justement je préfèrerai profiter de ce qu'apporte les LL : à savoir des drivers qui peuvent être pérennes dans le temps. Mais visiblement le kernel en décide autrement.
                • [^] # Re: Faut pas exagerer...

                  Posté par . Évalué à 1.

                  Ha oui, bien sûr, la conspiration contre les petits développeurs et les constructeurs ...

                  Je ne pense pas qu'il soit question d'une conspiration, mais plutot d'un constat. Si on lit ça http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) on peut en extraire : "Simple, get your kernel driver into the main kernel tree". Pour moi ça veut quand meme dire que torvald, il préfére que l'on mette son code dans la branche principale. Mais bien entendu je trouve ça trés bien qu'on puisse inclure son driver dans la branche principale.

                  Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.


                  Peut être que la norme POSIX a été faite pour qu'un programme codé pour cette norme fonctionne partout et toujours où celle ci existe ? Et je pense que c'était ça le fondement de son propos. Faire qu'un driver un fois codé pour linux fonctionne le plus longtemps possible.

                  Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.


                  Bah si elles sont si pourries ces API pourquoi ils les ont mises dans le kernel ? Et tu entends quoi par des API stables ?

                  Pour moi un des gros problémes des API qui bougent, c'est simplement le fait que quelques fois tu es un gros noobs et tu achétes du matériel compatible avec un driver libre. Ce driver se trouve dans la branche X du noyau et toi t'as la version X-2 sur ton ordi. Comment tu fais ?
                  - Tu upgrades ta distro ? : T'as pas forcément envie, ça marche bien et t'as pas envie de tout casser.
                  - Recompiler ton noyau, faire un package , toussa. : Pas trés simple et ça fou les boules de recompiler son noyau.
                  - Récupérer les sources du module nécessaire sur le site du projet la version pour ton noyau X-2 : Pas trés simple et en plus on a pas forcément les derniers bugfix ce qui peut se révéler assez génant.

                  PS : T'énerve pas, c'est pas la fin du monde. On parle juste d'un programme informatique.
                  • [^] # Re: Faut pas exagerer...

                    Posté par . Évalué à 1.

                    Je ne pense pas qu'il soit question d'une conspiration, mais plutot d'un constat. Si on lit ça http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) on peut en extraire : "Simple, get your kernel driver into the main kernel tree". Pour moi ça veut quand meme dire que torvald, il préfére que l'on mette son code dans la branche principale. Mais bien entendu je trouve ça trés bien qu'on puisse inclure son driver dans la branche principale.

                    Oui, je suis d'accord que c'est une forte incitation à mettre son code dans la branche principale. Mais je réagissais au fait que TImaniac dise que Linus voudrais "tout maîtriser" et "forcer les gens", ce qui est un tout petit peu exagéré...

                    Peut être que la norme POSIX a été faite pour qu'un programme codé pour cette norme fonctionne partout et toujours où celle ci existe ? Et je pense que c'était ça le fondement de son propos. Faire qu'un driver un fois codé pour linux fonctionne le plus longtemps possible.

                    Oui, mais comme j'ai précisé plus haut, l'interface POSIX est une interface utilisateur et plus haut niveau. Les interfaces driver sont assez différentes de cela, et à mon avis c'est difficilement transposable.

                    Bah si elles sont si pourries ces API pourquoi ils les ont mises dans le kernel ? Et tu entends quoi par des API stables ?

                    OK j'exagère en disant pourri, mais des fois les devs se rendent compte que les choix qu'ils ont fait à une époque n'étaient pas les bons, et qu'il faudrait changer d'API. Et par API stable, j'entend .... qu'elles change pas du tout ?

                    Pour moi un des gros problémes des API qui bougent, c'est simplement le fait que quelques fois tu es un gros noobs et tu achétes du matériel compatible avec un driver libre. Ce driver se trouve dans la branche X du noyau et toi t'as la version X-2 sur ton ordi. Comment tu fais ?
                    - Tu upgrades ta distro ? : T'as pas forcément envie, ça marche bien et t'as pas envie de tout casser.
                    - Recompiler ton noyau, faire un package , toussa. : Pas trés simple et ça fou les boules de recompiler son noyau.
                    - Récupérer les sources du module nécessaire sur le site du projet la version pour ton noyau X-2 : Pas trés simple et en plus on a pas forcément les derniers bugfix ce qui peut se révéler assez génant.

                    Oui c'est vrai que c'est assez embêtant, mais c'est souvent dû au fait que les drivers arrivent beaucoup plus tard que la sortie sur le marché du matos, car les devs n'ont soit pas les docs (ou pas assez tôt), et alors ils sont obligés de faire du reverse engineering, et ça prend du temps.

                    Oui, faire des API stables et s'y tenir c'est difficile et ça prend du temps, chose que n'a pas toujours la communauté. Si les constructeurs matériel jouaient plus le jeu du libre, je pense qu'on aurait pas ce genre de problème et qu'on pourrait avoir des APIs changeantes sans problème.

                    PS : T'énerve pas, c'est pas la fin du monde. On parle juste d'un programme informatique

                    Oui désolé, merci d'avoir calmé le jeu !
          • [^] # Re: Faut pas exagerer...

            Posté par . Évalué à 4.

            Si tu t'en branles qu'il évolue, pourquoi le mets-tu à jour ??? Le fait que les pilotes soient cassés toutes les 8 semaines ne concerne que les gens qui mettent à jour leur kernel toutes les 8 semaines. Si un rtyhme de une fois tous les 7 ans te satisfait pleinement, rien ne t'empêche d'attendre 7 ans.


            Y a t il qqchose que je n'ai pas compris ?
            • [^] # Re: Faut pas exagerer...

              Posté par (page perso) . Évalué à 2.

              On peut avoir envie de profiter des évolutions sans avoir envie de subir également des régressions.
            • [^] # Re: Faut pas exagerer...

              Posté par . Évalué à 2.

              Bonne chance mon gars pour backporter les màj de secu ou de bug du kernel. À moins d'utiliser un truc comme une RHEL mais là faut accepter d'avoir le même desktop gnome (mais surtout GTK) ad vitam æternam.
              • [^] # Re: Faut pas exagerer...

                Posté par (page perso) . Évalué à 1.

                >mais là faut accepter d'avoir le même desktop gnome (mais surtout GTK) ad vitam æternam.

                En meme temps tu peux mettre à jour gnome et non le kernel.
        • [^] # Re: Faut pas exagerer...

          Posté par (page perso) . Évalué à 4.

          Perso, moi qui suis du grand public simplement amateur de logiciel libre, oui, ça m'a dérangé, de constater le comportement plusieurs fois différent de mes clés USB, par exemple.
          Ça a même dérangé deux développeurs de Mandriva, qui écrivaient récemment sur leur blog leur colère de voir le noyau toujours changeant et aux fonctions jamais maintenues plus d'une semaine, et qui accusaient les développeurs du noyau d'être des idiots, de ce point de vue-là seulement j'imagine ! ( ici, http://distrowatch.com/weekly.php?issue=20061002#news , descendre vers la 2ème actu).
          Si des profils d'utilisateurs aussi différents en souffrent, c'est qu'il y a quand même un problème, non ?
    • [^] # Re: Faut pas exagerer...

      Posté par (page perso) . Évalué à 4.

      Pourquoi une note négative sur le commentaire de PBPG ? C'est troll vélu ? Ca dérange un commentaire comme ça ?

      (J'ai pas regardé en détail, mais d'après ce que j'ai pu voir, il y a un bon paquet de doc sur les API windows, c'est vrai les changelogs j'ai pas trop regardé)
      • [^] # Re: Faut pas exagerer...

        Posté par (page perso) . Évalué à 8.

        Effectivement, j'ai l'impression que pour certains, des qu'ils voient "PBPG", ils cliquent immediatement sur "inutile", sans reflechir...

        Les boutons pour evaluer les commentaires devraient servir a faire disparaitre les commentaires hors sujet/deplaces, pas a indiquer si l'on est 100% d'accord avec ce qui est dit!

        Et puis il faudrait peut etre se rendre compte que l'attitude consistant a systematiquement refuser toute critique du libre n'est PAS celle qui va permettre de faire avancer le libre! Si sur la LKML tout le monde passait son temps a uniquement parler de ce qui va bien en refusant ce qui ne marche pas bien, nous en serions toujours a un clone de Minix...

        Mathias
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à 8.

          Son message, sans aucun lien, n'a aucun intérêt. On est sensé savoir de quoi il parle? C'est quoi les nouveautés kernel entre les SP? Y a de la transparence dans le développement aussi? Ben s'il le dit...

          Faudrait voir a pas tomber dans le travers inverse et applaudir tout ce que dit le camps d'en face. pbpg dit des truc intéressants il est pertinenté, il fait un post de merde il se mange un -10. Voila.

          Aprés, on pourrait peut-être lui envoyer un gateau pour la release de Vista. :p
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à -5.

          Effectivement, j'ai l'impression que pour certains, des qu'ils voient "PBPG", ils cliquent immediatement sur "inutile", sans reflechir...

          Oui, c'est mon cas :-)

          Les boutons pour evaluer les commentaires devraient servir a faire disparaitre les commentaires hors sujet/deplaces, pas a indiquer si l'on est 100% d'accord avec ce qui est dit!

          Moi, de toutes façons, je lis souvent les post fermés justement pour savoir pourquoi.

          Et accessoirement, je pense aussi que les évolutions des deux noyaux sont difficilement comparables si on fait une comptabilité bête et méchante des lignes de codes, patchs et services packs comme le ferait un manager qui comptabiliserait les lignes de code pour en faire un indice de productivité.
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à -10.

          Effectivement, j'ai l'impression que pour certains, des qu'ils voient "PBPG", ils cliquent immediatement sur "inutile", sans reflechir...

          Et alors ? C'est une attitude saine et rafraîchissante, mon enfant, qui ne peut que t'amener sur le droit sentier de la Justice et de la Vérité.

          Je sais que vous êtes tous d'accord avec moi lorsque j'affirme pBpG est un parasite a exterminer le plus rapidement possible et avec le moins de dégâts collatéraux. Seul la masse pronétaire possède la puissance suffisante pour faire plier cet être stupide, borné et maiprisant, presque indigne de nos attentions et assurément la pire loque humaine que le bon Dieu n'ai jamais osé crée.
    • [^] # Re: Faut pas exagerer...

      Posté par . Évalué à 2.

      Quand au processus soi-disant ferme

      Tu bosses pour Microsoft ou quoi? Parceque pour le commun des mortels (voir meme les informaticiens) les informations sur le developpement du kernel XP/Vista ou sur tout produit estampille Microsoft sont totalement opaque.
      • [^] # Re: Faut pas exagerer...

        Posté par . Évalué à 2.

        Tu veux un exemple d'ouverture ? le blog de Raymond Chen, qui explique toutes les raisons pour laquelle si et ça se comporte pas toujours comme prévu pour des raisons de backward compatibility.
        http://blogs.msdn.com/oldnewthing/

        Un de mes exemples favoris de ce blog :
        http://blogs.msdn.com/oldnewthing/archive/2005/01/18/355177.(...)

        Microsoft prends la stabilité des API et la compatibilité avec les vieilles applis très à coeur.
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à 2.

          Microsoft prends la stabilité des API et la compatibilité avec les vieilles applis très à coeur.

          C'est pas parceque tu le repetes que ca va devenir vrai. J'ai un scanner qui a pas supporte le passage a XP (il se comporte a merveille sous linux malgre les API non stable des drivers).

          Tu critiques que l'API des linux bougent mais ca gene qui? Uniquement les trucs dont les sources ne sont pas dispos et donc a l'ouest de la philosophie linux donc franchement pas du tout important.
          • [^] # Re: Faut pas exagerer...

            Posté par . Évalué à 0.

            C'est pas parceque tu le repetes que ca va devenir vrai. J'ai un scanner qui a pas supporte le passage a XP (il se comporte a merveille sous linux malgre les API non stable des drivers).

            La tu es en train de nous parler d'un driver qui n'a pas supporte le passage d'un OS X a un OS Y (X=Linux, Y=FreeBSD par exemple), rien a voir avec le passage de la version X d'un OS a la version X+1

            Tu critiques que l'API des linux bougent mais ca gene qui? Uniquement les trucs dont les sources ne sont pas dispos et donc a l'ouest de la philosophie linux donc franchement pas du tout important.

            Non, il parle aussi de ceux dont les sources sont dispos mais pas dans le tree du kernel.
            • [^] # Re: Faut pas exagerer...

              Posté par . Évalué à 3.

              Bon alors parlons de windows 2000 et windows 2000 sp4 qui a casse des drivers chez moi. A moins que tu dises que les service pack introduisent un changement d'OS je vois pas trop comment ca peut etre vrai ce que tu dis. En fait le scanner il fonctionnait tres bien sous 2000 c'est XP qui a tout casse donc bon puisque tu a l'air de t'y connaitre explique moi pourquoi
              • [^] # Re: Faut pas exagerer...

                Posté par . Évalué à 2.

                Si ton driver fait qqe chose d'illegal, il pourrait casser sans que l'API ait change, si par exemple on change des structure internes que ton driver touche alors qu'il ne devrait pas.

                C'est l'exemple typique, et ca arrive assez frequemment, notamment avec les drivers de firewalls et anti-virus car ils sont codes comme des cochons pour acceder a tout et n'importe quoi.
                • [^] # Re: Faut pas exagerer...

                  Posté par . Évalué à 2.

                  ah les drivers signes par microsoft ne sont pas verifie par ce dernier? Ca sert a quoi cette "signature" dans ce cas (en dehors de faire payer une "certification"/impot aux boites de hardware)?
                  • [^] # Re: Faut pas exagerer...

                    Posté par (page perso) . Évalué à 6.

                    faut pas leur en vouloir comme ça à Microsoft, que veux-tu qu'ils fassent avec des pilotes closed-source ? de la rétro-ingénierie ? ;-)
                  • [^] # Re: Faut pas exagerer...

                    Posté par . Évalué à -1.

                    Ils verifient certains points et un minimum de fonctionalites, t'as vu ou que c'etait une garantie que le driver etait parfait ?
                    • [^] # Re: Faut pas exagerer...

                      Posté par . Évalué à 4.

                      Y'a une différence entre parfait et "suit les recommendations pour que cela marche longtemps", non ?

                      Tu va me dire que non. Evidement. Dans ce cas, je ne vois pas l'utilité du programme de signature, si cela n'est pas de garantir des pilotes propres !

                      "La première sécurité est la liberté"

                      • [^] # Re: Faut pas exagerer...

                        Posté par . Évalué à 0.

                        se mettre tout plein de pepettes dans les poches. C'est tres cher la "certification" MS.
                        • [^] # Re: Faut pas exagerer...

                          Posté par . Évalué à 2.

                          HAHAHA la grosse connerie, c'est pas cher du tout cette certification, visiblement tu ne sais pas du tout de quoi tu parles mais tu te permets quand meme de sortir des aneries dessus.

                          Sinon, ca sert a garantir un minimum de fonctionnalites et garantir qui est a l'origine du driver, si qq'un ici a la methode de test parfaite qui permet une certification garantissant des drivers parfaits qu'ils nous fasse signe on est interesse.

                          D'ici la les recriminations sur ce programme ne valent pas grand-chose, c'est definitivement mieux que rien.
                          • [^] # Re: Faut pas exagerer...

                            Posté par . Évalué à 2.

                            puisque tu as láir bien renseigne c'est combien la certif MS?

                            (je ne connais pas de methode parfaite pour les drivers mais j'ai toujours moins de probleme avec les drivers linux que ceux certifie par MS... Enfin mon experience ne represente qu'un utilisateur parmis des millions)
          • [^] # Re: Faut pas exagerer...

            Posté par (page perso) . Évalué à 9.

            Tu critiques que l'API des linux bougent mais ca gene qui? Uniquement les trucs dont les sources ne sont pas dispos et donc a l'ouest de la philosophie linux donc franchement pas du tout important

            Il y a beaucoup de drivers opensource et GPL qui ne sont pas dans le main kernel tree. Pour ceux-là dès qu'une nouvelle release du kernel sort, c'est l'angoisse, ça compile plus et il faut ajouter un xième #ifdef dans le code du driver. C'est super épuisant car il faut suivre en permanence le développement des derniers kernels (et oui le client a le droit d'utiliser un noyau récent) et patcher en conséquence en fonction des humeurs et des expérimentations des développeurs du kernel Linux. De plus, c'est typiquement le genre de choses qui favorise l'apparition de bugs dans les drivers.
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à 3.

          Personnellement, je ne prends pas ce qui est dit dans un blog msdn comme une parole officielle microsoft. Peut-être est-ce ici l'erreur de microsoft que de diffuser de l'information sous forme de blog et non sous forme d'article dans MSDN par exemple.

          Mais c'est mon avis.

          PS: ne pas appliquer ce schéma au libre qui a un fonctionnement totalement différent.
          • [^] # Re: Faut pas exagerer...

            Posté par . Évalué à 2.

            Pourtant c'est la meme chose, libre ou pas. Ils essaient simplement de creer un contact entre les devs/testeurs de l'OS et le public, ce qui a mon avis est plutot positif.

            Ce que les gars ecrivent sur ces blogs msdn ils le font parce qu'ils savent que la boite est d'accord, sinon ils ne l'ecriraient pas.

            Tu remarqueras que dans ces blogs, ils ne te diront jamais "oui on va corriger ton probleme", parce que ce ne sont pas les seuls a decider quel bug est corrige et lequel ne l'est pas(les testeurs, PM, ... ont leur mot a dire aussi), par contre ils t'expliquent le pourquoi du comment, ... car ca c'est dans leurs pouvoirs. Personnellement je trouves ca largement plus interessant et sympa que des pages MSDN ayant toujours la meme tronche, le contenu est a peu pres le meme et tu as la possibilite de discuter avec le gars.
          • [^] # Re: Faut pas exagerer...

            Posté par . Évalué à 3.

            Personnellement, je ne prends pas ce qui est dit dans un blog msdn comme une parole officielle microsoft.
            Euh, en particulier, tout ce qui concerne les Old New Things,
            http://blogs.msdn.com/oldnewthing/archive/2004/03/19/92648.a(...)
            http://blogs.msdn.com/oldnewthing/archive/2004/03/16/90448.a(...)
            [etc] [etc]
            Tu peux en tester le comportement toi même. T'as réellement besoin d'un grand badge estampillé "ITS OFFICIAL!!!OMG" ?

            Sinon, mais c'est un peu plus figé, tu peux lire des livres estampillés Microsoft qui en disent quand même beaucoup sur le comportement interne de Windows. Ex :
            Inside Windows 2000,
            http://www.microsoft.com/mspress/books/4354.aspx

            Et les abonnés MSDN ont de nombreuses occasions d'essayer des versions beta de produits Microsoft.
            Le processus de dev chez MS n'est pas si obscur, "fermé" que ce que certains voudraient bien croire ici. Miguel de Icaza était en train de développer Mono alors que le framework dotnet de Microsoft n'était même pas encore releasé en version finale.
            • [^] # Re: Faut pas exagerer...

              Posté par . Évalué à 2.

              Je réponds aux deux commentaires.

              Oui, PbPg, c'est comme le libre dans le sens où ils essayent de développer une communication avec le public. Mais dans le cadre d'une entreprise commerciale, je m'attends à n'avoir du support ou des infos que depuis une source. Alors qu'avec Microsoft, il y a le site web, msdn, les blogs... on s'y perd et l'on ne sait plus chercher.

              Je n'ai rien contre ces blogs, mais à prime abord, je les considère plus comme des sources d'informations éparses provenant de developpeur microsoft. Mais peut-être ais-je tort.

              Sinon, taratatatatatatatatatata, il peut apparaître que le processus de developpement chez microsoft n'est pas si obscur que cela car Miguel de Icaza a pu développer mono, mais est-ce que les informations qu'il a reçu sont disponibles à tous (du simple geek au développeur fou en passant par ma grand-mère), ou a-t-il pu les récupérer car il travaillait sur un projet spécifique ?
              • [^] # Re: Faut pas exagerer...

                Posté par . Évalué à 1.

                Mais dans le cadre d'une entreprise commerciale, je m'attends à n'avoir du support ou des infos que depuis une source. Alors qu'avec Microsoft, il y a le site web, msdn, les blogs... on s'y perd et l'on ne sait plus chercher.

                Ben il faut faire la part des choses, ces blogs ne sont pas la comme un support officiel par exemple, le gars il va pas s'amuser a repondre a toutes les questions qui lui sont posees, c'est pas son boulot. Les blogs sont la pour rendre MS plus ouvert et que les gens interesses aient une idee de ce qui se passe a l'interieur et comment MS fonctionne. De la meme maniere que Torvalds va pas s'amuser a repondre aux questions techniques des 3000 gus qui lui ecrivent chaque mois.

                Si tu cherches des infos techniques pour un projet, c'est MSDN, les bouquins et le support developpeurs MS, comme toujours.
              • [^] # Re: Faut pas exagerer...

                Posté par (page perso) . Évalué à 3.

                il peut apparaître que le processus de developpement chez microsoft n'est pas si obscur que cela car Miguel de Icaza a pu développer mono, mais est-ce que les informations qu'il a reçu sont disponibles à tous (du simple geek au développeur fou en passant par ma grand-mère), ou a-t-il pu les récupérer car il travaillait sur un projet spécifique ?
                Grosso merdo le projet Mono se base principalement sur les specifications de l'ECMA, sur la documentation des bibliothèques de la MSDN et bien sûr le comportement réel du framework .NET. Effectivement Mono a commencé avant la sortie "officielle" du framework .NET, mais ca faisait déjà un bon bout de temps qu'il était en version beta (plus d'1 an), que la doc existait. Evidemment, certaines infos proviennent également directement des ingénieurs de MS. (le plus souvent il suffit de leur poser les bonnes questions sur les forums de MSDN, à travers les mailing list ou directement par mail voir, en face :) )
        • [^] # Re: Faut pas exagerer...

          Posté par . Évalué à 10.

          Microsoft prends la stabilité des API et la compatibilité avec les vieilles applis très à coeur.


          Je crois qu'il faut être clair : c'est un debat sans fin.

          quelle est la politique de microsoft ? faire en sorte que les drivers marchent. comment s'y prennent-ils => ils garantissent une certaine stabilité.

          quelle les la politique de linux ? faire en sorte que les drivers marche. en integrant le code du driver dans le tree. voilà ce qu'ils proposent aux dev de drivers, pour celà ils demandent a ce que le drivers soit GPL, ainsi celui marchera toujours, et même plus longtemps que sous windows... le source est suivis par les dev du noyau.

          Ensuite, ben tu choisit ton camps, je doute que microsoft change sa politique, je doute qu'ils passent en GPL.
          Mais les deux politiques de stabilité de l'API sont cohérente par rapport aux choix politiques !
          • [^] # Re: Faut pas exagerer...

            Posté par . Évalué à 7.

            ainsi celui marchera toujours
            Du moins tant qu'il sera maintenu/n'aura pas de changement majeur dans l'API.

            Par exemple si on passe au support des disques PATA avec la libata au lieu de la stack ide, certains drivers vont etre perdu en cours de route (et de nouveau vont etre supporté).
            -> on est dans le cas de changement majeur dans l'API.

            De meme un driver (bttv) pour ma carte tv marchais parfaitement dans les versions du noyau d'il y a 1 peu plus d'1 ans, maintenant il marche plus...
            -> on est dans le cas de manque de mainteneur/testeurs pour des cas specifique (SECAM/vielle carte).
  • # Plonger dans le code de Linux

    Posté par . Évalué à 2.

    Existe t-il un document (je suppose que oui) simple d'acces permetant de se plonger dans le code de Linux afin de pouvoir y coder sas problèmes?

Suivre le flux des commentaires

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