Journal Linux un bloat, ah bon ?

Posté par (page perso) .
Tags : aucun
13
23
sept.
2009
On aime bien Linus, sans ironie aucune, pour sa franchise (les nazis chez Gnome), sa sagesse (son peu d'enthousiasme pour les gueguerres entre les pro et cons de l'opensource), et sa lucidité.

Il vient d'en faire preuve une fois de plus en affirmant que Linux est devenu un bloat.


Personnellement, cela ne m'étonne pas pour plusieurs raisons :
  • L'informatique est vaste aujourd'hui, avec énormément de fonctions, de standards mais aussi de possibilité (ce qui est heureux) de par la débauche de puissance que tout un chacun peut avoir à disposition
  • En lien avec la première, avec toutes les normes à gérer (ACPI, BIOS, EFI, USB, FireWire, IDE, SATA, etc...), on ne peut passer outre une inflation du code
  • Les drivers deviennent de plus en plus nombreux, ce qui est encore heureux, influant sur la taille du code
  • [TROLL]
  • Enfin, le plus polémique pour la fin, sinon ce ne serait pas drôle, le langage C est en grande partie responsable de cette taille.
    Le C, excellentissime assembleur de haut niveau, est un langage procédurale, et même si le code est extrêmement bien écrit (je pense qu'on peut difficilement trouver mieux) dans le noyau, il n'en garde pas moins les défauts de ce paradigme. Je ne reviens pas dessus, ce point de génie logiciel a été étudié en long en large en travers.
    C est bas niveau : pas de chaînes (mais dans un noyau c'est pas très grave), pas de collections, etc...
    Mais surtout pas de jeu possible avec de l'héritage, dont l'idéal serait qu'il fut dynamique, car cela permet de limiter la taille de l'OS de par son design
    Bref, tout ça pour dire qu'un OS grand public codé en C est condamné au bloat.
    [/TROLL]



Sources :
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux(...)

http://www.osnews.com/story/22207/Linus_Linux_Bloated_and_Hu(...)

http://linux.slashdot.org/story/09/09/22/1239254/According-t(...)
  • # Tanenbaum avait-il raison ?

    Posté par . Évalué à 7.

    Quitte à partir dans le flamewar virulent ou le trollage industriel, je me permets de lancer la première question : Andrew Tanenbaum avait-il finalement raison ?
    J'ai suivi la discussion sur la news de PCI[1] parlant de cette déclaration de Linus, et plusieurs semblent arriver à cette conclusion : tôt ou tard, Linux (et les noyaux en général) devront se tourner vers les micro-noyaux...
    patrick_g, tes impressions ? :-)


    1 http://www.pcinpact.com/actu/news/53158-linus-torvalds-kerne(...)
    • [^] # Re: Tanenbaum avait-il raison ?

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

      Il y a aussi un débat là dessus sur reddit :
      http://www.reddit.com/r/programming/comments/9mt4k/linus_cal(...)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Tanenbaum avait-il raison ?

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

      Bah tu peux tester minix3 : http://www.minix3.org/download/
    • [^] # Re: Tanenbaum avait-il raison ?

      Posté par . Évalué à 10.

      'Micro noyau' ne veut pas dire plus léger (en terme d'empreinte mémoire mais également en nombre de ligne de code) ni plus rapide mais prône plutôt la robustesse et la sécurité.

      Je pense que ce qui manque à Linux c'est un peu de 'refactoring', nettoyage et documentation ... ce que les gens ont toujours de la peine à faire ;). Un logiciel qui ne passe pas de temps-en-temps par ces phases est condamné.
      • [^] # Re: Tanenbaum avait-il raison ?

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

        Un micro noyau a l'avantage d'avoir bien moins de code en kernel space. Ça facilite énormément la maintenance et permet de ne pas avoir à intégrer tous les pilotes avec parfois du code de merde dans le noyau.

        Le fait que les pilotes sont en réalité des traducteurs en user space permet aussi comme tu le précise d'avoir un systeme tres robuste et facilite énormément l'écriture et débogage des pilotes.

        Le point noir est alors le controle d'accès aux ressources. Il faut mettre des verrous un peu partout, sinon on fait ce que Hurd était au début et on en a pour 200 ans à gérer les accès concurrents...
    • [^] # Re: Tanenbaum avait-il raison ?

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

      Je sais plus qui avait comparé les micronoyaux avec de la bouffe emballée dans du cellophane. Je trouve que cette comparaison aide bien à comprendre ce qui ne va pas, fondamentalement, avec les micronoyaux.
      J'ai juste retrouvé cette citation ici : http://tunes.org/wiki/microkernel_20debate.html

      "Thinking that microkernels may enhance computational performance can stem but from a typical myopic analysis: indeed, at every place where functionality is implemented, things look locally simpler and more efficient. Now, if you look at the whole picture, and sum the local effects of microkernel design all over the place, it is obvious that the global effect is complexity and bloat in as much as the design was followed, i.e. at every server barrier.
      For an analogy, take a big heavy beef, chop it into small morsels, wrap those morsels within hygienic plastic bags, and link those bags with strings; whereas each morsel is much smaller than the original beef, the end-result will be heavier than the beef by the weight of the plastic and string, in a ratio inversely proportional to the small size of chops (i.e. the more someone boasts about the local simplicity achieved by his µK, the more global complexity he has actually added
      ".
      • [^] # Re: Tanenbaum avait-il raison ?

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

        Je ne suis pas convaincu par ça. Un micronoyau est un système modulaire qui ne permet de faire fonctionner que le minimum vital de la machine (ordonnanceur, allocation mémoire etc...) Le reste est géré en userspace.

        Ca veut dire que le noyau ne sera jamais un obèsiciel. Bien au contraire, sa maintenance devient simplifiée et laisse le temps à ses développeurs d'optimiser les mécanismes qui le composent sans avoir à trainer tous les boulets que linux se tape (qui a dit le pilote foireux de microsoft?)

        Le reste se passe en userspace. Les pilotes qui accedent a votre beau scanner tout neuf y sont. Si il leur prend l'envie de planter, le noyau ne tombera pas avec.

        Pour moi c'est tout bénéfique comme système, et je ne vois pas en quoi ça peut se raprocher d'un obésiciel.

        On dirait que le mec qui a écrit ça discutait surtout des perfs, c'est vrai qu'un systeme sur micronoyau serait sans doute un peu plus lent. Mais du temps des AMDel Corenom X36, je doute qu'on ressente quoi que ce soit. Ce commentaire a du être rédigé a l'époque ou Bill Gates disait qu'on n'aurait jamais besoin de plus de 64ko...
        • [^] # Re: Tanenbaum avait-il raison ?

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

          Au final, si un pilote plante, tu sera quand même dans la merde.
          (Quand Xorg plante, au final, toutes mes applications doivent être redémarrées. Même dans les cas ou le kernel tourne toujours. Et je dois aussi redémarrer quand mon clavier se blo
          • [^] # Re: Tanenbaum avait-il raison ?

            Posté par . Évalué à 3.

            Peut-être pas : a priori sous Minix 3, quand un pilote plante, un démon finit par le détecter et « reboote » le pilote qui ne répond plus.
      • [^] # Re: Tanenbaum avait-il raison ?

        Posté par . Évalué à 1.

        pas tout à fait d'accord non plus car il semble qu'on ne compare pas la même chose:
        en théorie un micro noyau en fonctionnement est moins un bloat qu'un noyau monolithique à matériel égal car en théorie seuls les modules nécessaires sont chargés
        par contre c'est au prix d'une complexité supplémentaire...
        mais n'est-ce pas justement le sens de l'évolution? complexité vs entropie?
        • [^] # Re: Tanenbaum avait-il raison ?

          Posté par . Évalué à 3.

          Euh non ca n'a rien avoir, monolithique ou micro-noyau, les 2 peuvent charger decharger les modules selon les besoins.

          La difference entre les 2 elle se situe au niveau de la separation des droits entre les modules et le coeur.
        • [^] # Re: Tanenbaum avait-il raison ?

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

          Le noyau Linux est modulaire lui aussi, et les modules sont chargé si nésséssaire. Donc cet argument est nul.

          (La différence avec un micro noyaux est que, sous Linux, les modules ont accès direct à l'espace kernel et tournent en mode privilègié.)
  • # Commentaire supprimé

    Posté par . Évalué à 10.

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

    • [^] # Re: Le troll

      Posté par . Évalué à 4.

      Je rajouterai une couche de troll en citant Poelvoorde :
      Tu ne te permets rien du tout, tu vas me soigner cette vilaine peau et puis tu te permettras. à propos de ce magnifique site : http://isaacproject.u-strasbg.fr/


      ---» []
      • [^] # Re: Le troll

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

        Je sais qu'il est horrible, mais il sera remis à jour en temps voulu.
        Sinon, je te ferai la même réponse que GCU : tout le monde n'est pas hyper fort en HTML, toussa

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Le troll

          Posté par . Évalué à 2.

          Et être hyper fort en HTML n'a pas trop d'intérêt pour faire un OS ou un compilo, bien au contraire.

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

          • [^] # Re: Le troll

            Posté par . Évalué à 0.

            Boh, l'un n'empêche pas l'autre, culture générale, toussa (dans la mesure ou Hyper fort est un peu exagéré pour réaliser un petit site web de type vitrine)
            • [^] # Re: Le troll

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

              Ca tombe bien, on aurait besoin d'aide :-)

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Le troll

                Posté par . Évalué à 10.

                Tu devrais demander au Jules de Ségo.
                Il parait qu'il te relooke en 30s un site top moumoute et pour pas cher !
  • # Et ben tous au Hurd!

    Posté par . Évalué à 10.

    C'est Stallman qui va être content!
    Finalement, tout le monde va l'aider à le finir, son noyau! \o/
    • [^] # Re: Et ben tous au Hurd!

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

      En fait, il doit être possible de faire fondre linux pour en faire devenir un micro-noyau sur lequel tournerait Hurd.

      Sinon, Hurd fonctionne déjà à peu pres. Il n'est pas trés stable par contre. Il faut aussi remarquer que Hurd est maintenu par 10 gars qui y bossent sur le temps libre, alors que linux est maintenu par plus de 2000 contributeurs réguliers, dont beaucoup sont à temps plein.

      Sur le papier, les micro-noyaux ont sans aucun doute d'indéniables avantages sur les noyaux monolythiques. Après, il faudrait pourvoir réussir à en faire aboutir un...

      Allez Linus, un petit coup de slim fast et on sort GNU/Hurd/Linux3.0 ^^
      • [^] # Re: Et ben tous au Hurd!

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

        >Sur le papier, les micro-noyaux ont sans aucun doute d'indéniables avantages sur les noyaux monolythiques. Après, il faudrait pourvoir réussir à en faire aboutir un...

        Genre QNX ?
  • # On ne parle pas de la meme chose...

    Posté par . Évalué à 10.

    L'auteur du journal parle de la taille du code, de la masse de code du kernel, alors que l'article initial mentionnait lui les performances.

    Petite citation de l'article :

    Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two per centage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. 'Is this a problem?' he asked.

    'We're getting bloated and huge. Yes, it's a problem,' said Torvalds.



    La taille du code n'est que peu en rapport avec la vitesse du kernel, meme si on pourrait argumenter que si, parce que du code plus gros pollue plus le cache L1/L2, voire ne rentre pas dans le cache L2, et donc c'est la cause d'une perte de performances.
    Ceci est vrai... mais... la plupart du code (de l'ordre de 95% il me semble, de memoire d'apres un Google Tech Talk de Greg KH) est consitue des drivers, et l'immense majorite d'entre eux ne sont pas charges en memoire a l'execution (je n'ai pas 200 cartes graphiques differentes, merci).

    La baisse de performance est sans doute plus liee au fait que Linux s'enrichit de nouvelles fonctions comme le support de la virtualisation, les LSM (Linux Security Modules), le support des architectures NUMA, l'isolation des processus, le passage a l'echelle jusqu'a 4096 coeurs, etc...
    • [^] # Re: On ne parle pas de la meme chose...

      Posté par . Évalué à 6.

      le passage a l'echelle jusqu'a 4096 coeurs, etc...

      C'est un bon exemple, c'est difficile de conçevoir un algo robuste pour traiter efficacement du monoprocesseur aussi bien que du 4096 coeurs.

      J'ai l'impression, mais je peux me tromper que l'aspect généraliste de Linux n'aide pas: on peut mettre Linux sur un téléphone ou sur un énorme serveur, sur des matériels qui ont des caractéristiques très très différentes ...
      • [^] # Re: On ne parle pas de la meme chose...

        Posté par . Évalué à 4.

        Troll Mode

        C'est un bon exemple, c'est difficile de concevoir un algo robuste pour traiter efficacement du monoprocesseur aussi bien que du 4096 coeurs.
        Solaris ?

        /Troll Mode
      • [^] # Re: On ne parle pas de la meme chose...

        Posté par . Évalué à 3.

        C'était l'argument de BFS qui a besoin d'un ARM ou d'un Atom pour que cela soit vrai, vu que c'est déjà faux pour un core duo.

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

      • [^] # Re: On ne parle pas de la meme chose...

        Posté par . Évalué à 1.

        C'est pour cela que dieu a créé la "make menuconfig" :
        HZ, CONFIG_PREEMPT, HIGHMEM, 4KSTACKS...
        • [^] # Re: On ne parle pas de la meme chose...

          Posté par . Évalué à 6.

          "C'est pour cela que dieu a créé la "make menuconfig" :"
          RMS ? Linus ? Theo ? Steve Jobs ? Jayce ?
          • [^] # Re: On ne parle pas de la meme chose...

            Posté par . Évalué à 10.

            Linus, RMS et Donald Knuth discutent pour savoir qui a eu le plus d'influence sur l'informatique moderne.

            Linus : "Dieu m'a dit que j'avais cree le meilleur noyau de systeme d'exploitation"
            RMS : "Dieu m'a dit que j'avais cree le meilleur editeur de texte"
            Knuth : "Eh, attendez, j'ai jamais dit ca !"
        • [^] # Re: On ne parle pas de la meme chose...

          Posté par . Évalué à 1.

          Ouais enfin :

          1/ Ça implique tout de même un modèle commun, ne serait-ce qu'au niveau des interfaces.

          2/ Certains sous-systèmes ne sont pas configurables, comme l'ordonnanceur par exemple.
        • [^] # Re: On ne parle pas de la meme chose...

          Posté par . Évalué à 2.

          Bien sûr, mais parfois ça doit être bien le bordel de maintenir tout ça en parallèle, et le code doit être bien robuste, le code commun à toutes ces version en parallèle, de tester les différentes combinaisons, et tout et tout.

          On en a eu un exemple récent avec le troll scheduler / réactivité. Je ne sais pas ou ça en est, mais on a bien vu que le scheduler intégré actuellement dans Linux était jugé trop peu réactif sur du monocoeur, et qu'il n'était pas vraiment d'actualité de maintenir plusieurs scheduler dans Linux en l'état actuel des choses ...
  • # Tss...

    Posté par . Évalué à 10.

    De toute façon c'est pas la taille qui compte.
    • [^] # Re: Tss...

      Posté par . Évalué à 8.

      C'est ce que disent ceux qui en ont une petite /o\
      • [^] # Re: Tss...

        Posté par . Évalué à 8.

        C'est ce que répondent tous ceux qui ne savent pas s'en servir! \o/
        • [^] # Re: Tss...

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

          C'est ce que pensent tous ceux qui croient encore leur femme ! \o_
        • [^] # Re: Tss...

          Posté par . Évalué à 3.

          "Women who think penis size is important are just shallow. Well, perhaps that's not the best choice of words..."
          -- Jimmy Carr
      • [^] # Re: Tss...

        Posté par . Évalué à 1.

        C'est pas ceux qui ont les plus grandes oreilles qui entendent le mieux...


        --
        Et ça m'arrange...
  • # ...

    Posté par . Évalué à 4.

    Il faut préciser que la taille du noyau est très importante dans le cas de l'embarqué (ça l'est beaucoup moins pour nos machines ou gros systèmes).

    Je lu que des sociétés utilisant linux dans l'embarqué étaient resté (pour des raisons de coût) à la version 2.4 du noyau car sa taille une fois compilé était sensiblement moins conséquente.

    De plus, je pense que Linus parle de code constituant le coeur du noyau et non pas des drivers car ça on le savait par avance que plus il y a de matériel supporté plus la taille du code (et non --forcemment-- du binaire) est grosse.
  • # Loi de Wirth

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

    Une illustration de la loi de Wirth ?
    "software gets slower faster than hardware gets faster"

    http://fr.wikipedia.org/wiki/Loi_de_Wirth
    • [^] # Re: Loi de Wirth

      Posté par . Évalué à 6.

      En suivant le lien, on apprend des nouveaux mots : « inflagiciel », « enfliciel », « énormiciel », « boufficiel » et « obésiciel ».

      Mon préféré étant l'obésiciel...

      PS : il faudrait mettre à jour le correcteur orthographique de linuxfr
      • [^] # Re: Loi de Wirth

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

        Jolis noms :-)

        Je trouve que boufficiel est très adapté pour un logiciel qui "bouffe" les ressources systèmes inutilement (et donc pas forcément un obésiciel).
  • # Euh

    Posté par . Évalué à 4.

    C'est quoi le rapport entre le fait que ce soit du C et qu'on ne puisse pas faire d'heritage ? Surtout que c'est le cas dans le noyau...
    • [^] # Re: Euh

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

      1/ Dans le papier que je cite, on explique pourquoi le fait d'avoir de l'héritage dynamique permet de simplifier le design et réduire l'empreinte mémoire (un seul parent à la fois). Sur 3 niveaux d'héritage la combinatoire explose vite, et ça devient vite intéressant.

      2/ Ca dépend comment c'est implémenté : si c'est de la CFT à la mano en C, les perfs sont catastrophiques (les processeurs, mêmes modernes ont du mal à optimiser une fonction dont l'adresse est dans pointeur en mémoire et non en statique). Mais je pense pas qu'ils aient fait comme ça.

      Le sujet de mon troll est fondamentalement : il me parait difficile à un humain d'écrire un C lisible qui permette de profiter des optims d'un C illisible mais optimisé au mieux qui serait généré par un compilateur.

      Mais je te laisse le bénéfice du doute, vu le niveau de compétence impressionnant des codeurs du noyau.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Euh

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

        s/CFT/VFT/

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Euh

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

          Je dirais même plus en:Virtual_method_table trouvé sur en:VFT et cité sur un article qui mériterait d'être amélioré : Lisaac (au § performances par exemple) :D
          • [^] # Re: Euh

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

            Merci. Je l'ajoute dans ma todolist. Mais on fera ça pour la prochaine version avec les shootout, ça sera plus simple.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: Euh

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

              ah mais tu fais ce que tu veux quand tu veux hein, ta vie sexuelle te regarde un peu.

              (/me n'a pas compris les shootout je pense, d'où un certain décalage de la réponse)
              mais pour Lisaac, bin tu nous tiens au courant, moi je ne retiens pas ma respiration en attendant :-)
    • [^] # Re: Euh

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

      Chouette, Linus veut passer à GObject :-).
  • # rentrons dans le vif du sujet

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

    Moi aussi je vais troller :
    Alors quand est-ce qu'on peut développer de façon modulaire avec compilation séparée en Lisaac ?
    Non parcque bon le principal soucis du kernel Linux, son côté bloatware, c'est pas tant le fait que le langage utilisé ne propose d'héritage, c'est surtout que l'architecture monolithique retenue en fait un gros bouzin là où les micro-noyaux apporte "bydesign" une plus grande modularité.
    Evidemment ca suppose que le langage soit "utilisable" pour cela...
    • [^] # Re: rentrons dans le vif du sujet

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

      et en Pascal ?
    • [^] # Re: rentrons dans le vif du sujet

      Posté par . Évalué à 3.

      c'est surtout que l'architecture monolithique retenue en fait un gros bouzin

      Le problème d'embompoint du noyau ne me semble pas imputable au choix d'une architecture monolithique mais à des choix plus politiques. On peut penser modulaire dans passer forcément par un micro noyau.
      La question n'est pas ici ce qui doit tourner en mode noyau/mode utilisateur mais ce qui doit être livré avec le noyau ou pas. De version en version le noyau est de plus en plus gros parce qu'il inclue des drivers pour tous les périphériques possibles et imaginables, y compris des trucs obscurs qu'on a peur de décocher de peur de faire une connerie.

      On pourrait déjà commencer par établir des interfaces claires que les pilotes doivent implémenter et ne livrer de base dans le noyau que le strict minimum. Quel intérêt de se taper le téléchargement d'un noyau contenant les sources de drivers dont on n'a pas besoin ? Quel intérêt de recompiler tout le bordel pour avoir juste une mise à jour d'un pilote qui corrige un problème ? Ne pourrait-on pas commencer par faire comme avec beaucoup d'autres OS : J'ai un problème avec un driver, j'installe la version mise à jour sans me retaper la compilation du reste.

      Linus a toujours refusé de standardiser les ABI pour ne pas être bridé si des changements sont nécessaires (s'il faut casser la compatibilité, on casse) et après on s'étonne que ça devienne difficilement gérable. Pour gagner en maintabilité, je pense qu'il faudra bien passer par une dose de standardisation.
      • [^] # Re: rentrons dans le vif du sujet

        Posté par . Évalué à 3.

        y compris des trucs obscurs qu'on a peur de décocher de peur de faire une connerie.

        ah oui, comme la fois ou j'avais décoché ramfs et que le initrd ne se chargeait plus.
      • [^] # Re: rentrons dans le vif du sujet

        Posté par . Évalué à 2.

        Le problème avec une ABI standardisée qu'on change, c'est tous les pilotes qui sont maintenus par des gens qui n'ont pas le temps de les maintenir.
        (Et ne me faites pas croire que tous les pilotes inclus de base ont tous un développeur disponible et réactif, prêt à réécrire la moitié du code au gré des changements d'ABI...).

        Après, c'est sûr qu'un pilote peu maintenu, c'est pas bien, mais d'un autre côté, demander à des développeurs de refaire leur pilote qui marchait très bien avant alors qu'ils ont très peu de temps pour s'en occuper, ça risque de les pousser à abandonner le pilote rapidement.

        Qui souhaiterait voir le pilote de ses périphériques être présent aléatoirement d'un noyau à l'autre suivant le temps disponible du mainteneur?
        • [^] # Re: rentrons dans le vif du sujet

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

          Le problème avec une ABI standardisée qu'on change
          Je penses qu'il voulait dire "stabilisé" plutôt que "standardisé" : en gros faut pas qu'il change, ou rarerement.
          On peut imaginer une ABI "stable" pendant 3 ans. Au bout de 3 ans une nouvelle version arrive, moyennant un coût supplémentaire le noyau peut gérer l'ancienne qui devient "deprecated" mais qui pête pas les drivers existants. Au bout de 3 nouvelles années, tu vires la vieille interface (on va pas la maintenir 107 ans) : en tout on a eu 6 ans de compatibilité binaire et 3 ans pour migrer les drivers encore maintenus/utilisés.
          Ca me paraît totalement réalisable.
          • [^] # Re: rentrons dans le vif du sujet

            Posté par . Évalué à 2.

            3 ans avant la sortie du 2.6.31 (09/09/2009) est sorti le noyau 2.6.18 (20/09/2006), soit 13 versions d'écart...
            Ma question est donc : les changements apparus entre ces 2 versions ne sont-ils pas trop importants ?
          • [^] # Re: rentrons dans le vif du sujet

            Posté par . Évalué à 2.

            sauf que tu doubles la base de code.

            Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.

            Si l'API introduit une faille de sécurité tu la gardes ?

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

            • [^] # Re: rentrons dans le vif du sujet

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

              sauf que tu doubles la base de code.
              Gni ?

              Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
              Euh, quand ils changent une API, c'est pas pour "corriger" les drivers, c'est généralement pour offrir de nouvelles possibilités (nécessaire pour le kernel ou les améliorations des périphériques supportés). Donc ils ne corrigent rien, au contraire, ils sont obligés de modifier tous les drivers (alors que certains étaient sans doute stable et éprouvés) en prenant le risque d'introduire de nouveaux bugs/régression. Ceci est d'autant plus dangereux que la fondation Linux n'a pas les moyens de faire des tests de non-régression sur l'ensemble du matos. Bref, ca se fait globalement au détriment de la qualité, sans parler du fait que ces bugs va falloir les corriger, et ca prend du temps.

              Si l'API introduit une faille de sécurité tu la gardes ?
              Bien sûr que non. Celà dis le cas est rare et justifie une évolution.
              • [^] # Re: rentrons dans le vif du sujet

                Posté par . Évalué à 2.

                Tu devrais lire le howto "stable api non sense" de la doc linux.

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

                • [^] # Re: rentrons dans le vif du sujet

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

                  Je l'ai déjà lu et j'ai déjà trollé de nombreuses fois sur le sujet. Pour moi c'est un choix purement politique : Linus veut phagociter tout ce qui tourne autour du kernel et ne veut pas voir d'équipe qui puisse développer des composants de manière indépendante. Des API non-stables est une façon de dire aux dev : intégrez votre driver dans notre repos ou vous allez en chier pour la maintenance.

                  Ceux qui trinquent au final, c'est les utilisateurs, j'en ai ras le cul d'avoir ce petit coup de stress quand je vois le kernel dans les updates proposées par ma distri : est-ce que mon matos va encore fonctionné correctement après ?

                  La pratique montre que chez les concurrents (MacOSX et Windows), les API stables ça marche. Ce n'est donc pas un soucis technique mais bien un choix politique.
                  • [^] # Re: rentrons dans le vif du sujet

                    Posté par . Évalué à 2.

                    les API stables ça marche.

                    Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...

                    Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout. Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau. (sous linux, une bonne source de plantage, c'était le serveur X comme par magie en espace utilisateur, alors que c'est normalement une garantie de stabilité...)

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

                    • [^] # Re: rentrons dans le vif du sujet

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

                      Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...
                      Je vois pas le rapport : là le problème c'est la maintenance des drivers : les API stables permettent justement de garantir que ca va marcher pendant quelques années. Evidemment les MAJ API arriveront tôt ou tard et là ca peut péter. Si le driver est pas maintenu, ben c'est la merde. D'où l'intérêt d'avoir des drivers open-source pour qu'on puisse les maintenir :)

                      Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout.
                      Tu sorts d'où ce chiffre ?
                      Les efforts de maintenance sont pour moi sur les drivers à chaque changement d'API. Des APIs qui changent moins souvent, ca demande moins de maintenance des drivers.

                      Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau.
                      Tout à fait. Windows a fait évolué son modèle de driver pour que le gros du code des drivers graphiques tournent dans l'espace utilisateur : en cas de plantage, le kernel "redémarre" le driver incriminé. Ca marche, ca plante pas.
                      Cela a bien sûr nécessisté de casser totalement le modèle d'API, mais ils le modifient pas tous les 4 matins.
                      • [^] # Re: rentrons dans le vif du sujet

                        Posté par . Évalué à 2.

                        Les efforts de maintenance sont pour moi sur les drivers à chaque changement d'API. Des APIs qui changent moins souvent, ca demande moins de maintenance des drivers.

                        il faut bien maintenir ton API qui est connecté qq part !

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

                        • [^] # Re: rentrons dans le vif du sujet

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

                          Ben c'est l'avantage l'API défini une interface unique pour tous les drivers d'un même type : faut mieux maintenir une seule API ou maintenir tous les drivers qu'il y a derrière, sachant qu'ils ont pas les moyens de vérifier les régressions ?
                          • [^] # Re: rentrons dans le vif du sujet

                            Posté par . Évalué à 2.

                            Non justement, tu as plusieurs génération d'API a te trainer.

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

                            • [^] # Re: rentrons dans le vif du sujet

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

                              Je vois pas le rapport, c'est encore un autre choix là.
                              Une API peut être stable pendant 2-3 ans, c'est un autre choix de décider de garder la compatibilité avec l'ancienne API. Et tu peux garder une seule ou plusieurs génération, là encore c'est une question de choix.
                              Si tu veux mon avis sur cet autre choix décorrélé du premier, oui, il faut garder la compatibilité avec la version précédente (et uniquement la précédente) : ca a un coût, mais cela permet de laisser du temps pour "migrer" les drivers vers la nouvelle API, le temps qu'ils deviennent fiables et stables.
                              La qualité a un prix, ça c'est sûr. Mais assurer l'absence de régression en changeant plus souvent les API est encore plus coûteux, voir innaccessible pour la fondation Linux.
                              • [^] # Re: rentrons dans le vif du sujet

                                Posté par . Évalué à 2.

                                C'est toi qui le dit et ce n'est pas l'avis des codeurs noyau.

                                Si il y a une regression, rien n'empèche d'utiliser le noyau précédent. Il sera corrigé ensuite. Personne n'a besoin d'avoir un nouveau kernel fonctionnel toutes les 6 semaines.

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

                                • [^] # Re: rentrons dans le vif du sujet

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

                                  C'est ça le problème : c'est à l'utilisateur de mesurer les conséquences d'une upgrade. Il doit assumer les problèmes de compatibilité éventuels et revenir en arrière s'il constate une régression. Merci pour la qualité du service rendu.
                                  Microsoft pousserait une upgrade du noyau NT qui explose le support de la carte graphique ou de tel imprimante, ça serait le scandale assuré. Pour Linux, c'est pas grave, le end-user il a pas besoin de qualité, et pour l'administrateur, il upgrade sa debian tous les 5 ans une fois que tous les end-users ont essuyés les plâtres.
                                  Ca serait tellement plus simple de décorreler le dev/maintenance des drivers du dev/maintenance du noyau, mais non, Linus veut tout maîtrisé.
                                  • [^] # Re: rentrons dans le vif du sujet

                                    Posté par . Évalué à 3.

                                    Non, c'est le boulot des distributions. Et si tu veux un truc à qualité garanti, tu utilises une distrib "stable".

                                    Et franchement quand tu vois la qualité moyenne des drivers offert pour le noyau linux, tu te dis que heureusement, ils sont repris par les codeurs kernel !

                                    mais non, Linus veut tout maîtrisé.

                                    Et cela marche mieux ! Regarde le bordel autour de X11 et des accélérations graphique, et de udev/hotplug.

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

                                    • [^] # Re: rentrons dans le vif du sujet

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

                                      Non, c'est le boulot des distributions
                                      Les distributions SONT des utilisateurs.
                                      Et les distributions ont pas plus les moyens de vérifier les régressions dans le kernel au vu du nombre de matos supporté. Donc c'est souvent l'utilisateur final qui trinque.

                                      Et si tu veux un truc à qualité garanti, tu utilises une distrib "stable".
                                      Vi c'est ce que je dis : l'administrateur il attend la debian stable, et l'utilisateur desktop qui veut utiliser son matériel un minimum récent, ben il fait office de beta-testeur.

                                      tu te dis que heureusement, ils sont repris par les codeurs kernel !
                                      Vu le nombre de régressions, je suis pas convaincu. Moi j'aime quand un truc qui marche on puisse continuer à l'utiliser tel quel. Je vois pas pourquoi un utilisateur devrait prendre le risque de perdre le support de sa carte son parcqu'il a voulu mettre à jour le kernel afin d'avoir le support d'un nouveau système de fichier.
                                      Et puis ca n'empêcherait pas les mêmes développeurs de s'occuper des drivers dont ils s'occupent déjà. Je veux juste décorreler la maintenance des drivers des évolutions du kernel.
                                      • [^] # Re: rentrons dans le vif du sujet

                                        Posté par . Évalué à 2.

                                        Dans ce cas tu auras des drivers tout pourris qui ne seraient jamais corrigé.

                                        Faire un drivers, ce n'est pas faire une petit appli KDE dans son coin. Il y a des interactions assez forte avec le reste du kernel !

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

                                        • [^] # Re: rentrons dans le vif du sujet

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

                                          Dans ce cas tu auras des drivers tout pourris qui ne seraient jamais corrigé.
                                          ? Pourquoi ?
                                          Si des développeurs veulent bien maintenir les drivers dans le cadre du projet Linux, y'a pas de raison qu'ils ne veulent pas reprendre des drivers fourni par un constructeur et faire le même boulot, avec plus d'indépendance de l'équipe du kernel.
                                          C'est la force du libre : tu peux reprendre/corriger/améliorer un logiciel tiers du moment que tu respectes la licence : tu forks le driver du constructeur si ca dérive trop.

                                          Il y a des interactions assez forte avec le reste du kernel !
                                          Je vois pas le rapport avec la stabilité dans le temps. Windows arrive à offrir cette stabilité, pourquoi pas Linux ?
                                          • [^] # Re: rentrons dans le vif du sujet

                                            Posté par . Évalué à 2.

                                            Tu n'as pas du bosser beaucoup dans le dev de kernel linux toi :)

                                            Quand un gusse pète une api kernel, c'est à lui de réparer les dégâts jusqu'à ce que tout compile. Il sait ce qu'il change c'est infiniment plus rapide que de compter sur la personne qui ne comprendra pas forcément la subtilité du changement.


                                            Je vois pas le rapport avec la stabilité dans le temps. Windows arrive à offrir cette stabilité, pourquoi pas Linux ?


                                            Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows, Linux n'a rien perdu !

                                            Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.

                                            windows a aussi la force d'avoir 90% du marché, cela oblige les constructeurs à suivre. L'obligation n'est pas la même pour Linux !

                                            Je trouve que la solution actuelle est la moins couteuse pour avoir la meilleur qualité possible.

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

                                            • [^] # Re: rentrons dans le vif du sujet

                                              Posté par . Évalué à 1.

                                              Quand un gusse pète une api kernel, c'est à lui de réparer les dégâts jusqu'à ce que tout compile. Il sait ce qu'il change c'est infiniment plus rapide que de compter sur la personne qui ne comprendra pas forcément la subtilité du changement.

                                              Et ce gus, tu crois qu'il comprend tous les drivers qui font usage de l'API ? Moi j'en doutes...

                                              Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows, Linux n'a rien perdu !

                                              Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.


                                              Mais ca n'a RIEN a voir...

                                              Le driver, si il reste libre, tu peux toujours l'adapter a la prochaine version de l'API. Le fait de changer d'API tous les 3 jours n'a aucune incidence sur la possibilite de corriger le code du driver, si tu peux le faire tous les 3 jours, tu peux le faire tous les 3 ans.
                                              La seule difference c'est qu'il y a une periode de stabilite, plutot qu'une ABI qui change tous les 3 matins.
                                              • [^] # Re: rentrons dans le vif du sujet

                                                Posté par . Évalué à 2.

                                                Si l'API change c'est qu'il y a une bonne raison. Elle ne change pas tous les 4 matins. Et souvent, elle change par petit bout.

                                                Ou alors, c'est de la grosse factorisation de code comme pour la pile wifi mais dans ce cas il ya une transition entre 2 drivers.


                                                Et ce gus, tu crois qu'il comprend tous les drivers qui font usage de l'API ? Moi j'en doutes...


                                                Sauf que comprendre un drivers est plus simple que comprendre le noyau.

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

                                                • [^] # Re: rentrons dans le vif du sujet

                                                  Posté par . Évalué à 2.

                                                  Si l'API change c'est qu'il y a une bonne raison. Elle ne change pas tous les 4 matins. Et souvent, elle change par petit bout.

                                                  Petit bout ou pas, au final il y a cassage d'interface, et cela arrive trop frequemment. Ca emmerde les utilisateurs, ca emmerde ceux qui ecrivent des drivers, pour pas grand-chose.

                                                  Ou alors, c'est de la grosse factorisation de code comme pour la pile wifi mais dans ce cas il ya une transition entre 2 drivers.

                                                  Moi je vois la realite : le noyau Windows a des perfs equivalentes, des features equivalentes. Bref, son modele de developpement n'empeche en rien d'avancer, pourtant il amene une stabilite au niveau de l'API des drivers

                                                  Sauf que comprendre un drivers est plus simple que comprendre le noyau.

                                                  Tout a fait, mais comprendre 42 drivers differents, pas forcement.
                                                  • [^] # Re: rentrons dans le vif du sujet

                                                    Posté par . Évalué à 2.

                                                    Ca emmerde les utilisateurs, ca emmerde ceux qui ecrivent des drivers, pour pas grand-chose.

                                                    Si, à long terme, cela réduit la maintenance.


                                                    Moi je vois la realite : le noyau Windows a des perfs equivalentes, des features equivalentes. Bref, son modele de developpement n'empeche en rien d'avancer, pourtant il amene une stabilite au niveau de l'API des drivers


                                                    tu sais très bien que c'est faux. Linux surpasse windows dans beaucoup de domaine : scalabilité, faible latence, IO...

                                                    Tout a fait, mais comprendre 42 drivers differents, pas forcement.

                                                    Tous les drivers d'un même type se ressemble beaucoup.

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

                                                    • [^] # Re: rentrons dans le vif du sujet

                                                      Posté par . Évalué à 2.

                                                      tu sais très bien que c'est faux. Linux surpasse windows dans beaucoup de domaine : scalabilité, faible latence, IO...

                                                      Latence(dans le sens real-time) probablement, pour le reste permets moi d'en douter fortement.

                                                      Tous les drivers d'un même type se ressemble beaucoup.

                                                      En partie oui, mais il y a des limites, et niveau scalabilite, inutile de dire que c'est invivable.
                                                      • [^] # Re: rentrons dans le vif du sujet

                                                        Posté par . Évalué à 2.

                                                        Latence(dans le sens real-time) probablement, pour le reste permets moi d'en douter fortement.

                                                        Il existe des machines windows à 4096 processeurs ?
                                                        Concernant les IO, j'ai encore en mémoire les benchs de serveurs http statique, certe, cela date, mais Linux était bien devant.

                                                        En partie oui, mais il y a des limites, et niveau scalabilite, inutile de dire que c'est invivable.

                                                        C'est sans doute pour ça qu'il y a bien plus de matos supporté par linux que par Vista

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

                                                        • [^] # Re: rentrons dans le vif du sujet

                                                          Posté par . Évalué à 2.

                                                          Il existe des machines windows à 4096 processeurs ?

                                                          Vois pas le rapport, je regardes Redhat, elle ne tourne pas sur 4096 processeurs.

                                                          Concernant les IO, j'ai encore en mémoire les benchs de serveurs http statique, certe, cela date, mais Linux était bien devant.

                                                          Ah oui, celui ou ils comparaient un Linux avec un mini-serveur web dans le kernel (TUX) compare a un serveur web en user-mode, ca ne dit absolument rien sur les perfs I/O de l'OS ca

                                                          C'est sans doute pour ça qu'il y a bien plus de matos supporté par linux que par Vista

                                                          Tu m'expliqueras le rapport, en quoi est-ce que Windows empeche d'avoir des drivers libres que la communaute maintient ?
                                                          • [^] # Re: rentrons dans le vif du sujet

                                                            Posté par . Évalué à 2.

                                                            Vois pas le rapport, je regardes Redhat, elle ne tourne pas sur 4096 processeurs.

                                                            Regardes SGI alors.


                                                            Ah oui, celui ou ils comparaient un Linux avec un mini-serveur web dans le kernel (TUX) compare a un serveur web en user-mode, ca ne dit absolument rien sur les perfs I/O de l'OS ca


                                                            Windows faisait pareil.

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

                                                            • [^] # Re: rentrons dans le vif du sujet

                                                              Posté par . Évalué à 2.

                                                              Regardes SGI alors.

                                                              Je le regardes, et je vois un cas unique, sur un hardware unique, chose que MS ne fait pas.

                                                              La ou je veux en venir c'est que le fait que MS bloque le scenario pour raisons de support et test ne signifie pas qu'il n'est pas realisable techniquement pas le noyau.

                                                              Windows faisait pareil.

                                                              Justement non, on a developpe http.sys specifiquement pour "contrer" TUX...
                                                          • [^] # Re: rentrons dans le vif du sujet

                                                            Posté par . Évalué à 2.

                                                            Tu m'expliqueras le rapport, en quoi est-ce que Windows empeche d'avoir des drivers libres que la communaute maintient ?

                                                            La licence du dev kit ?

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

                                            • [^] # Re: rentrons dans le vif du sujet

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

                                              c'est à lui de réparer les dégâts jusqu'à ce que tout compile
                                              Tu n'a pas du bosser beaucoup dans une équipe de dev où y'a des contraintes qualité toi :)
                                              Suffit pas que ca compile pour que ca marche ! D'où les régressions perpétuelles :-(

                                              Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows,
                                              Déjà c'est tous les 3-4 ans, et souvent une API est stable pendant 2 versions de Windows, soit une durée de vie moyenne de 5 ou 6 ans.
                                              Après si ca pète, c'est pas parcque Microsoft choisi de faire des API stables ! Si ca pète, c'est parcqu'il y a une lacune dans la maintenance. Parcque les drivers sont pas libre tout simplement. Ils seraient libres et utilisés, aucun doute qu'ils seraient migrés et maintenu !
                                              Rien à voir avec les choix de stabilité des API du kernel.

                                              Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.
                                              Z"ont qu'à faire des logiciels libres.

                                              Je trouve que la solution actuelle est la moins couteuse pour avoir la meilleur qualité possible.
                                              Et ben cette qualité est vraiment relative...
                                      • [^] # Re: rentrons dans le vif du sujet

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

                                        C'est clair.
                                        Il suffirait qu'on maintienne un outil pour vérifier que le driver soit bien propre, respecte bien les interfaces.

                                        Le fait que les ABI changent tout le temps décourage définitivement les industriels, qui en plus de se foutre complètement d'écrire un driver pour un os qui a 2% du marché, on pas envie de le faire parce que c'est inmaintenable ou être obligé de le libérer.

                                        Résultat, l'utilisateur gueule parce que sa carte wifi marche pas, et les windowsiens sont bien mort de rire quand tu parles d'installer Linux sur la machine de madame Michu...

                                        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                                    • [^] # Re: rentrons dans le vif du sujet

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

                                      Sans parler que cette façon de tout vouloir phagociter décourage sûrement les fabriquants de hardware de faire leurs propres drivers pour Linux : ils n'ont aucune garantie de la stabilité des API/ABI : tout ce qu'ils peuvent faire, c'est intégrer leur code dans le repos de Linux, ce qu'ils ne veulent pas forcement faire pour diverses raisons (indépendance, contrôle du projet, des évolutions, de la maintenance).
                                      • [^] # Re: rentrons dans le vif du sujet

                                        Posté par . Évalué à 2.

                                        Certe et donc, qu'il ne veulent pas suivre un développement libre et qu'ils n'ont surement rien compris aux avantages pour eux.

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

                                        • [^] # Re: rentrons dans le vif du sujet

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

                                          ?
                                          Un développement libre n'implique absolument pas qu'il faut phagociter tout les composants dans un unique environnement.

                                          Que je sache l'interface pour exécuter un programme est standardisé, je suis pas obligé d'inclure mon programme dans le repos du kernel il me semble. Ca m'empêche pas de faire du développement libre.

                                          Que je sache Gnome ou KDE ont des interfaces relativement stables et je peux maintenir mes logiciels dans mon coin sans les déposer sur les repos des environnements respectifs !

                                          Pourquoi devrait-il absolument en être autrement pour les drivers dans l'environnement kernel ?

                                          Le libre prône il me semble l'indépendance à tous les niveaux, notamment à travers des standards.
                                          Une API stable dans le temps irait beaucoup plus dans ce sens, mais ca fait chier l'équipe de dev du kernel, et les premiers à payer les pôts cassés sont les utilisateurs.
                                          • [^] # Re: rentrons dans le vif du sujet

                                            Posté par . Évalué à 2.


                                            Que je sache l'interface pour exécuter un programme est standardisé, je suis pas obligé d'inclure mon programme dans le repos du kernel il me semble. Ca m'empêche pas de faire du développement libre.


                                            Il est question de drivers pas de programme !


                                            Que je sache Gnome ou KDE ont des interfaces relativement stables et je peux maintenir mes logiciels dans mon coin sans les déposer sur les repos des environnements respectifs !


                                            Comparer des GUI et un noyau, c'est super gonflé. tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.


                                            Pourquoi devrait-il absolument en être autrement pour les drivers dans l'environnement kernel ?


                                            Parce que cela n'a rien à voir ?

                                            Le libre prône il me semble l'indépendance à tous les niveaux, notamment à travers des standards.

                                            Quand cela a un sens, oui.


                                            Une API stable dans le temps irait beaucoup plus dans ce sens, mais ca fait chier l'équipe de dev du kernel, et les premiers à payer les pôts cassés sont les utilisateurs.


                                            Pour te donner un exemple, en ce moment, la mode est à la basse consommation. Cela implique que les drivers puissent déterminer quoi sauver en cas de perte de contexte et comment restaurer tout cela, quand le faire, quel contrainte de latence cela pose au système, quel genre et comment un évènement externe peuvent réveiller le système.

                                            Tu crois franchement qu'avec une API figé c'est faisable ?

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

                                            • [^] # Re: rentrons dans le vif du sujet

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

                                              Il est question de drivers pas de programme !
                                              Un driver n'est qu'un type de programme particulier ;)

                                              tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.
                                              Oué bah comme toujours, les comparaisons ont leurs limites. Ensuite Gnome et KDE sont plus que des GUI hein, ces APIs peuvent s'incruster au coeur des applications (modèle objet, modèle de thread, etc). Les problématiques sont tout de même proche, il suffit de voir la transition de KDE3 vers KDE4 : la base de programmes basées sur KDE3 est énorme, à commencer dans KDE lui-même : la migration ne s'est pas faite sous le coude, le bout a été énorme de tout porté, heuresement que les API ne changent pas tous les 4 matins !

                                              Tu crois franchement qu'avec une API figé c'est faisable ?
                                              Quand l'interface est bien conçu et prévue pour être pérenne pendant 2 ou 3 ans, oui je penses. Sous Windows, ça marche.
                                              • [^] # Re: rentrons dans le vif du sujet

                                                Posté par . Évalué à 2.

                                                As-tu déjà codé un driver ? As-tu la moindre idée de la complexité d'un code réentrant "n fois" avec la complexité de partage de donnée entre application appelante mais appel dans différent contexte ?


                                                Quand l'interface est bien conçu et prévue pour être pérenne pendant 2 ou 3 ans, oui je penses. Sous Windows, ça marche.


                                                Linux a changer 3 fois de pile USB pour des raisons de perf ou de gestion d'énergie. Windows se traine n piles...

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

                                                • [^] # Re: rentrons dans le vif du sujet

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

                                                  As-tu déjà codé un driver ? As-tu la moindre idée de la complexité
                                                  Et ? La complexité empêche d'avoir des API stables ?
                                                  Je dirais que plus c'est complexe, plus la nécessité d'avoir une indépendance est forte, et plus la présence d'une API stable est pertinente.
                                                  Je te le rappelle encore une fois : les hackers du kernel ont beau être des mecs hyper-compétents, ils n'ont pas les moyens de valider les modifs, aussi infîmes soient-elles, qu'ils effectuent sur les drivers.
                                                  C'est un choix qui va à l'encontre de la qualité.

                                                  Windows se traine n piles...
                                                  Le principal, c'est que ça marche : la qualité a un coût.
                                                  Tôt ou tard, faire des choix qui vont à l'encontre de la fiabilité du code produit l'effet inverse : bugs à analyser, reproduire, corriger.
                                                  • [^] # Re: rentrons dans le vif du sujet

                                                    Posté par . Évalué à 3.

                                                    Et ? La complexité empêche d'avoir des API stables ?

                                                    Cela empèche que n'importe qui se penche sur le problème.

                                                    Le principal, c'est que ça marche : la qualité a un coût.

                                                    C'est exacte. Moyen que le libre n'a pas. Il ne fait pas 80% de marge sur des milliards !

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

                                            • [^] # Re: rentrons dans le vif du sujet

                                              Posté par . Évalué à 3.

                                              Il est question de drivers pas de programme !

                                              Et ? A part une orthographe differente c'est quoi la difference ?

                                              Comparer des GUI et un noyau, c'est super gonflé. tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.

                                              Moi si je prends Gecko ou autre composant de ce genre et je le compares a a peu pres tous les drivers, il est plus complexe, et de loin.

                                              Quand cela a un sens, oui.

                                              De nombreux OS avant Linux ont montre que ce n'etait absolument pas un probleme.

                                              Pour te donner un exemple, en ce moment, la mode est à la basse consommation. Cela implique que les drivers puissent déterminer quoi sauver en cas de perte de contexte et comment restaurer tout cela, quand le faire, quel contrainte de latence cela pose au système, quel genre et comment un évènement externe peuvent réveiller le système.

                                              Tout a fait, ca implique que l'API pour les drivers soit bien fait, et c'est tout a fait possible, cf. Windows
                                              • [^] # Re: rentrons dans le vif du sujet

                                                Posté par . Évalué à 1.

                                                Cela fait combien de temps que le réveil fonctionne réellement sur une majorité de machine sous Windows ?

                                                Combien de machine ne se réveille pas !

                                                De plus, je ne crois pas que Windows soit une référence en gestion d'énergie.

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

                                                • [^] # Re: rentrons dans le vif du sujet

                                                  Posté par . Évalué à 3.

                                                  Cela fait combien de temps que le réveil fonctionne réellement sur une majorité de machine sous Windows ?

                                                  Sacrement plus longtemps que sous Linux...

                                                  Combien de machine ne se réveille pas !

                                                  Une minorite, et certainement moins qu'avec Linux

                                                  De plus, je ne crois pas que Windows soit une référence en gestion d'énergie.

                                                  Pourtant sur la majorite des laptops, Windows tient plus longtemps que Linux:
                                                  - http://www.linuxinsight.com/files/ols2006/brown-reprint.pdf
                                                  - http://www.phoronix.com/scan.php?page=article&item=880&a(...)

                                                  Alors oui, il y a certainement des ameliorations possibles dans Windows(si je ne me trompes pas Mac OS X fait mieux), mais au final, en comparant les resultats de Windows et de Linux sur ces points, Linux ne sort pas gagnant, donc son modele de developpement ne ressort pas comme un avantage de ce cote la.
                                                • [^] # Re: rentrons dans le vif du sujet

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

                                                  C'est quoi cette argumentation de merde ?
                                                  Allez, je te renvoi la question :
                                                  Cela fait combien de temps que le réveil fonctionne réellement sur une majorité de machine sous Linux ?
                                                  Combien de machine ne se réveille pas (ou ne s'endorme pas d'ailleur) !
                                                  De plus, je ne crois pas que Linux soit une référence en gestion d'énergie.
          • [^] # Re: rentrons dans le vif du sujet

            Posté par . Évalué à 2.

            Le problème, c'est que le matériel ne met pas 3 ans pour évoluer. Si on à besoin de changer l'API pour supporter des nouvelles normes genre USB3, wifi N ou autre, l'utilisateur n'aura pas envie d'attendre 3 ans. Il veut sa fonctionnalité tout de suite.

            Et si tu réduit cette période, alors t'aura bien plus de rétro-compatibilité à faire, et donc tu bloate ton noyau
            • [^] # Re: rentrons dans le vif du sujet

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

              USB 1 : 1996
              USB 1.1 : 1998
              USB 2 : 2000
              USB 3 : 2010
              C'est compatible avec l'ordre de grandeur que j'ai donné.

              Je parle pas d'autoriser la modification de l'ensemble des ABI tous les 3 ans, mais pour un type de périphérique donné. Et 3 ans c'est un ordre de grandeur, pas un truc figé dans le marbre.

              alors t'aura bien plus de rétro-compatibilité à faire, et donc tu bloate ton noyau
              Des fois la rétro-compatibilité est "imposée" par la norme : que tu le veuille ou non, une implémentation de USB 2 doit supporter les périphériques USB 1. M'enfin bon USB est un mauvais exemple puisque c'est déjà une interface un minimum générique.
            • [^] # Re: rentrons dans le vif du sujet

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

              Evolutions normes Wifi : 1999, 2003, 2009. On est toujours dans la bonne fourchette.
    • [^] # Re: rentrons dans le vif du sujet

      Posté par . Évalué à 3.

      La modularité dans le design du code est indépendant de la technologie que tu emplois derrière pour faire tourner le tout.

      Linux n'est pas un microkernel pourtant tout les sous systèmes sont clairement identifié en interne. Les drivers ont un système objet pour se déclarer et être utilisé par l'OS.

      Concernant le coté compile global de Lisaac, c'est une faiblesse qui est à relativiser. La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être.

      On sait que Lisaac doit être capable de gérer des millions de lignes de code. Aujourd'hui, on sait que 50000 lignes se compilent en une dizaine de seconde sur un atom, mais derrière gcc rament franchement (qq minutes ?). Cela laisse de la marge.

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

      • [^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)

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

        De plus, la version en préparation/test gère maintenant assez bien l'interface avec le monde extérieur.
        Il y a quelques réglages à revoir d'ici la release à ce propos, mais on peut sans trop de problèmes générer des .o et les linker ensemble de sortes à ce qu'ils se parlent (via la section external).
        Il reste à faire en sorte que ce soit manipulable aisément par le programmeur, qui devra s'assurer à la main que les interfaces puissent discuter ensemble.
        La gestion de l'interface avec des programmes C classiques a été grandement améliorée et fonctionne assez bien maintenant (problèmes de gestion de la mémoire essentiellement).
        On peut même générer des modules linux !

        Le fait de pouvoir générer des lib C en lisaac et pouvoir les linker de manière classique tiendra lieu de compilation séparée dans un premier temps.
        Au pire, pour vérifier l'interfacage, on pourra lancer un début de compilation globale sur le tout, et séparer en petit morceau si le compilateur ne trouve rien à redire.

        Dans un second temps, ce sera essentiellement un problème de performance ie. comment ne pas faire chuter les perfs parce que chaque partie du programme n'a pas été optimisé en fonction des autres.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: rentrons dans le vif du sujet

        Posté par . Évalué à 3.

        La modularité dans le design du code est indépendant de la technologie que tu emplois derrière pour faire tourner le tout.

        Il y a des langages qui font les choses vachement bien aussi. Je pense à des trucs comme erlang par exemple.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: rentrons dans le vif du sujet

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

        Je ne parle pas de modules pour les perfs, mais tout simplement de modules pour des questions de distribution, de développement en équipe séparée, etc. Exemple : le kernel Linux est capable de charger un module "à chaud". Le module en question est déployé en tant que binaire séparé et n'est pas chargé automatiquement (sauf si la configuration de la machine l'indique bien évidemment).
        Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
        Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.

        Bref autant de critère qui rend la séparation en module indispensable pour tout gros projet, et un kernel est un gros projet.
        • [^] # Re: rentrons dans le vif du sujet

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

          Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
          Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.

          Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.

          A ces deux affirmation je répond : Pour tout langage qui font de la compilation globale (et par exemple génèrent du C), et il y en a qqun, il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout. Ce qui implique que s'il y a modif, seul le morceau modifié est recompilé.
          Smart Eiffel le fait.
          Alors il est vrai que de la compil globale fait bouger assez facilement pas mal de chose, mais pas toujours.

          C'est donc un faux problème, ou en tout cas aisément contournable.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: rentrons dans le vif du sujet

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

            Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.

            Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?

            Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
            Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
            Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.

            il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
            \o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
            J'attend aussi de voir le débuggueur...

            Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
            On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.
            • [^] # Re: rentrons dans le vif du sujet

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

              Dans tous compilateur utilisant de la compilation globale (Smarteiffel, Pypy peut être, Lisaac, et bien d'autres), tu bénéficies d'ors et déjà des optims sur le bouts de code que tu utilises, par rapport à des langages à JIT (ou AOT). Ie. Toute l'utilisation de ta lib est optimisée par le compilateur qui :
              - N'embarque que le code que tu utilise dans ta lib
              - Optimise l'utilisation de celui-ci

              Donc même si ton noyau est un petit morceau de code (et heureusement), il est déjà assez gros pour que tu profite d'un gain plus que substanciel par rapport à de la compilation séparée.

              Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
              Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main). Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau (des collections type array, liste chainées, tables de hashage, etc...)

              De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
              par exemple :
              http://www2.lifl.fr/lmo2004/slides_lmo2004/privat.pdf
              http://docs.google.com/gview?a=v&q=cache:onvvYLCD35UJ:ww(...)

              \o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
              J'attend aussi de voir le débuggueur...

              Ils font comment quand ils développent en C/C++ ?
              Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.

              De plus, c'est débile comme argument :
              Dans la SSII où je travaille, on utilise maven. Alors c'est clairement plus sophistiqué que Makefile, d"accord, mais c'est tout aussi bloat et lent.
              Et lors du debug, c'est toujours aussi peu maniable à utiliser (souvent le temps d'aller chercher un café, le temps que ça compile). Le seul intérêt étant le tracage à la main dans Eclipse, et le watching sur les variables.
              En SmartEiffel (compilation globale), Ils l'ont ! Certes pas couplés à Eclipse, mais ce ne serait pas un énorme boulot, car il s'agirait juste d'interpréter du mode texte.
              Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.

              Pour les tests, tu as la programmation par contrat, ainsi qu'une lib de tests unitaires, et je parle pour SmartEiffel aussi.
              Pour la documentation, tu as un outil dans chaque langage pour générer de la doc, qui ressemble à une javadoc d'ailleurs.
              Tu as un debugger intégré en SmartEiffel, embarqué dans le code.

              Pour le dev en équipe, le nouveau système (LIP) est fonctionnel, et il a juste besoin d'être un peu maturé pour s'assurer que même les cas les plus tordus ne posent pas problèmes.

              Donc, j'aimerai bien que tu m'expliques en quoi il faut absolument de la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: rentrons dans le vif du sujet

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

                Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main).
                Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.

                Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau
                Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
                Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.

                De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée

                Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".

                Ils font comment quand ils développent en C/C++ ?
                Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.

                Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.

                Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.

                la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
                C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
                Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
                Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compil
                ation (cf C#).
                Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
                • [^] # Re: rentrons dans le vif du sujet

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

                  Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
                  Je te renvoi à ce que t'as expliqué Nicolas plus haut (plus je te connais plus j'ai l'impression que tu es rétif à tout apprentissage): http://www.linuxfr.org/comments/1068755.html#1068755

                  Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
                  Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.

                  C'est difficile de savoir réellement parce que ça dépend du type d'appli sue tu compile, et le compilateur peu découvrir plein de trucs grace à la globalité... ou pas.
                  Au niveau global, c'est surtout la prédiction de type qui est faite et donc la suppression d'appels polymorphique (plus que 2% à la fin en moyenne).
                  Mais ça peut se faire aussi assez localement. Genre avec 3 prototypes et ta lib collection, ce qui est un code petit comme un module Linux, tu va avoir quand même pas mal d'optim. Surtout que la dernière version du compilateur effectue pas mal de détection d'optims locales.
                  Si tu veux, on peut déjà considérer que le simple fait d'optimiser sur ton objet + la lib de base que tu utilises (nombre + string + collections) ça optimise pas mal déjà.
                  Mais plus tu globalise mieux c'est.
                  Donc pour le MPEG 2, tu dois déjà avoir pas mal d'optims même en découpant en 10 parties.
                  'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
                  Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)

                  Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
                  Quand Ben aura le temps de s'y mettre, c'est absolument pas prioritaire.

                  Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
                  Ben, on fait pareil, vu que c'est du C derrière.
                  Comment ils font en Eiffel d'après toi.
                  Dans ma boite, en java, on a maven le gros bousin pour "compilo, linker, makefile", et eclipse pour l'IDE.
                  En Lisaac, tu as eclipse comme IDE, et le compilateur pour compiler (et shorter pour te générer la doc).
                  La chaine de production est là.
                  Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
                  Je répète : lit 10 fois http://www.linuxfr.org/comments/1068755.html#1068755 , tu vas peut être finir par comprendre....

                  C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
                  Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).

                  Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai, mais le mécanisme est généralisé pour ça (en fait c'est une dose d'aspect programming).
                  Tu peux poser des contrats sur du code, des données, en tant qu'invariant de prototype.

                  Tu peux m'expliquer ce qu'est "mocker dynamiquement le code " ? Parce que moi, j'ai du me les taper à la main, les mock, et je vois pas ce que c'est en "dynamique" (et ça m'intéresse parce que c chiant les mocks...).
                  Pour l'introspection, je devrais pouvoir jouer avec dans 2 ou 3 mois, c'est quasi implémenté.
                  Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compilation
                  Chez nous, ça s'appelle "shorter".

                  Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
                  composants "versionnable", "signables" : Dans la section header (en passant, en Java, je sais pas comment on fait)
                  Introspection, voir plus haut.
                  chargement dynamique (plugins) : C'est quoi ?
                  abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
                  déploiement à distance : C'est quoi ?

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: rentrons dans le vif du sujet

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

                    Je te renvoi à ce que t'as expliqué Nicolas plus haut
                    Nicolas ne dit rien du tout : il confirme que pour l'instant l'aspect composant en Lisaac n'existe pas.
                    Il précise qu'on peut faire des modules pour Linux (super), mais sans parler des perfs. Son message laisse uniquement sous-entendre que tout est une question de granularité, et qu'en Lisaac la granularité est plus grosse.
                    Bref, du blabla théorique.

                    'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
                    \o/ c'est la meilleur : pourquoi je demandes un exemple concrêt avec un découpage du compilateur MPEG2 à ton avis ? J'ai rien à prouvé moi : c'est Lisaac qui a tout à prouvé. Sur le papier, Lisaac permet d'avoir un gain de perf qui vient des optimisations globales. Pour moi le gain est forcement limité dès que tu procèdes à un découpage. A vous de me démontrer le contraire. Et toi comme Nicolas, vous ne faites que confirmer par des "ca dépend de la granularité" ou "y'aura moins d'optimisations possibles mais peut être que". Bref, vous pensez que la modularité ne pose pas de soucis, et de toute façon elle n'existe toujours pas en Lisaac.

                    Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
                    Quel argument :) Même si je suis un ingé csharpiste, j'ai fais des études et suivi des cours de compilation et d'optimisation hein, j'ai peut être pas le niveau de pratique et théorique que vous avez, m'enfin j'ai suffisament de compréhension du sujet pour voir qu'optimisations globales et modularité peuvent être contradictoire. A vous de me montrer que cette contradiction est à l'avantage des perfs dans tous la majorité des cas.

                    Ben, on fait pareil, vu que c'est du C derrière.
                    Encore une fois tu esquives : je te rappelle qu'on parle de ta solution modulaire suivante :
                    "il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout. Ce qui implique que s'il y a modif, seul le morceau modifié est recompilé. "
                    C'est ce truc que j'attend de voir dans un environnement de dev carré.

                    Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai,
                    En gros avec les contrats je peux "lire" les méta-données" d'un composant binaire écrit en Lisaac ? Ou bien tout est limité à la phase de compilation ?

                    Tu peux m'expliquer ce qu'est "mocker dynamiquement le code "
                    Ben, un outil qui utilises l'introspection et les méta-données inclus dans le binaire pour générer dynamiquement un composant qui se fait passer pour un autre.
                    Exemple avec Rhino en C# : http://www.ayende.com/projects/rhino-mocks/api/files/MockRep(...)

                    c'est quasi implémenté.
                    Et ben voilà, ca avance :)

                    Chez nous, ça s'appelle "shorter".
                    Url ? Exemple ?

                    chargement dynamique (plugins) : C'est quoi ?
                    Ben c'est : je regarde tous les composants binaire dans tel répertoire, je les charges à la volée, je cherche dedans les implémentation de mon contrat IPlugin et j'instancie un objet de ce type que je manipule ensuite. Un mécanisme de plugin quoi.
                    Bien sûr, je charge ce plugin dans un espace mémoire sécurisé pour pas qu'il vienne planter mon appli, mais pas dans un process différent hein, pas envie de nicker les perfs en faisant de la comm inter-process :)

                    abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
                    Ben, l'abstraction hardware, ca s'appelle une machine virtuelle qui fait totalement abstraction de la machine sur laquelle tourne le code. Pas de différence dans le code, une seule compil, un seul composant à déployer quelque soit la plateforme hardware cible.

                    déploiement à distance : C'est quoi ?
                    Si j'ai une application qui "cherche" des plugins sur un serveur distant, il faut que je puisse le télécharger, lui assigner un degré de confiance (en fonction d'une signature numérique par exemple) et l'exécuté dans un contexte sécurisé.
            • [^] # Re: rentrons dans le vif du sujet

              Posté par . Évalué à 2.

              Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code.

              Pas du tout, c'est même complètement idiot comme argument. Lisaac favorise la découpe en horizontal et optimise en vertical.

              En gros, toute lib est compilé en global mais si tu veux faire des modules pour Linux, tu pourra à terme. Le coté "composant" de Lisaac n'existe pas encore, mais il pourra exister plus tard en ayant toujours la compilation global sur les libs. Le grain est bien plus gros que le fichier C.

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

      • [^] # Re: rentrons dans le vif du sujet

        Posté par . Évalué à 3.

        « La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être. »

        Je ne suis pas tout à fait d'accord. Lorsqu'on active les optimisations inter-procédurales, c'est-à-dire l'optimisation de code entre des fichiers objets séparés, si le code est vraiment gros, ça peut vraiment faire exploser le temps de compilation. Au point que parfois c'est carrément le compilateur qui abandonne (j'ai déjà vu le cas se présenter avec les compilateurs d'Intel pour Fortran et C, avec des codes assez énormes, et où on avait activé l'IPO).
        • [^] # Re: rentrons dans le vif du sujet

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

          faire exploser le temps de compilation.

          exemple ?
          euh pas OOo, ça s'est amélioré en dual core depuis longtemps
        • [^] # Re: rentrons dans le vif du sujet

          Posté par . Évalué à 2.

          Tu parles de téchno qui font ça au niveau du linker, cela n'existe pas au niveau GNU, justement pour des raisons de perfs.

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

          • [^] # Re: rentrons dans le vif du sujet

            Posté par . Évalué à 2.

            Ben oui, mais c'est un peu le seul endroit où le compilateur peut faire quelque chose finalement : insérer des symboles pour le linker dans les fichiers objet. Et si sur de GROS codes ça explose, sur des codes de taille raisonnable ça va encore (et surtout, la compilation avec ipo peut être partielle : une partie des fichiers objet qui est compilée de façon classique, et une autre avec ipo).

            Est-ce vraiment pour des raisons de perf que GCC (au sens Compiler Collection) ne permet pas ça ?
            • [^] # Re: rentrons dans le vif du sujet

              Posté par . Évalué à 2.

              Disons que la FSF a décidé que le linker doit être stupide pour conserver des performances corrects.

              De plus, vu le peu d'info disponnibles, peu d'optimisation sont possible.

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

              • [^] # Re: rentrons dans le vif du sujet

                Posté par . Évalué à 2.

                ICC génère des fichiers objet « dummy » quand il fait de l'IPO, càd qu'il y a toutes les infos normales d'un .o, mais il y rajoute des symboles qui du coup empêchent ledit fichier objet de pouvoir être utilisé tel quel par un autre compilateur. En contrepartie, il y a bien plus d'informations pouvant aider à l'optimisation au moment de l'édition de lien.
  • # approche local vs. globale?

    Posté par . Évalué à 5.

    La question que je me pose, faut-il considérer la perte de performance de Linux seul ou étudier son impacte sur la pile logicielle entière? Sans parler de l'ajout de fonctionnalités, l'inclusion de certains traitements directement dans le noyau, donc l'alourdir ne peut-il pas proposer un gain moyen plus important à un processus en espace utilisateur que si ce processus avait tout à faire lui même?

    Je prends l'exemple tout simple de NFS. Si je compile son support dans le noyau, je vais l'alourdir un peu, le faire mouliner bien plus pour avoir mon serveur au meilleur de sa forme. Alors qu'au contraire, si je fais tourner NFS en espace utilisateur, je vais avoir des performances horribles mais un noyau se portant comme un charme.
    Pareil pour l'indexation des fichiers, ça fonctionne beaucoup mieux avec le module qui va bien plutôt qu'avec tout en espace utilisateur avec un processus qui passerait son temps à mouliner pour rien. Et pourtant là encore ça ne va toujours pas aider mon noyau à s'alléger.
  • # Peut être une approche encore plus découpée ?

    Posté par . Évalué à 1.

    Le noyau est gros. Tout le monde sait pourquoi et personne ne parle de la solution la plus logique : arrêter d'avoir un linux.

    A quoi ça me sert que mon noyau puisse gérer 4096 unités de calcul ? Intel ne va pas sortir de chipset/carte mère pour ce genre de choses avant une dizaine d'année.

    C'est un exemple. Ce que je pense c'est qu'il pourrait être découpé en deux ou trois genre serveur, desktop et embarqué. Chacun utilise une base commune et garde ses spécificités (et donc ces algo et ses drivers).

    Je sais que c'est un travail plus que colossale mais ça ne me semble pas si impossible.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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