Sortie du noyau Linux 2.6.18

Posté par (page perso) . Modéré par Nÿco.
0
20
sept.
2006
Linux
Comme l'année dernière Linus Torvalds s'est débrouillé pour faire coïncider la sortie d'une nouvelle version du noyau Linux avec la journée internationale du langage pirate. Son annonce (signée Linus "but you can call me Cap'n") est donc assez difficilement compréhensible et pleine d'insultes ésotériques de boucaniers.

Sur un plan moins anecdotique le nouveau noyau propose d'intéressantes nouveautés pour les machines multiprocesseurs comme un outil de debugging spécialisé ou encore une fonction améliorée d'économie d'énergie. Les grosses nouveautés sont donc :
  • lockdep : un outil de debugging qui permet de s'assurer que les verrous logiciels (lock) ne conduisent pas à une réservation infinie de la ressource. L'article de LWN sur ce sujet est particulièrement intéressant.
  • priority inheritance : un outil noyau qui permet aux applications en espace utilisateur d'avoir un comportement plus déterministe. C'est utile pour le temps réel.
  • SMPnice : un moyen d'augmenter et de diminuer la priorité de certains processus sur une machine multiprocesseurs.
  • SATA : Une grosse refonte de l'infrastructure Serial ATA est disponible dans le noyau 2.6.18. Cela autorise le branchement à chaud (hotplug) et le réordonnancement des commandes (NCQ). De plus les performances et la gestion des erreurs sont bien meilleures.
  • CFQ : L'ordonnanceur par défaut des entrées/sorties est maintenant CFQ (Complete Fair Queuing) qui permet de gérer les priorités entre les processus.
  • Secmark : Un outil utile à l'infrastructure de sécurité SELinux puisqu'il permet de marquer les paquets entrants afin d'augmenter la sécurité.
  • Gestion de l'énergie : l'ordonnanceur des processus est maintenant capable de gérer plus finement la gestion de l'énergie sur les machines ayant plus d'un processeur. Le fait que les ordinateurs modernes permettent de laisser un des coeurs en veille alors que l'autre fonctionne normalement est pris en compte. Ainsi au lieu de forcer la répartition des tâches sur tous les coeurs le noyau peut maintenant, si il n'est pas trop chargé, choisir de les diriger sur un seul coeur afin d'économiser de l'énergie.
  • Beaucoup d'autres choses sont présentes dans le noyau 2.6.18 ainsi que des corrections de bugs, des ajouts de pilotes, etc.

Le détail (en anglais) est disponible sur la page LinuxChanges qui fait un travail formidable pour présenter à tous l'avancée rapide du plus célèbre des multiples logiciels libres.
  • # A l'abordage !

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

    A' m'a l'air d'y avoir une sacrée bougre de nouveautés pour les multi core !
    Nomdediou, moi j'vous dit, pouvoir foutre et retirer les disques SATA sans redémarrer le bousin, ca c'est une put1** de feature comme on les aime !

    ya quelque chose que j'sais pas trop à quoi qu'ca sert : c'est "Add binding/unbinding support for the VT console". Est-ce que ca fait qu'on peut enlever un TTY d'une machine et le refoutre sur une autre ?

    allez, tous sur la bougresse !
    • [^] # Re: A l'abordage !

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

      Ahem...c'était le 19 la journée "talk like a pirate" ;-)

      Sinon il faut noter que ce noyau 2.6.18 va sans doute être le noyau de la future Debian stable (Etch) et de la future Red Hat Entreprise Server (5.0). C'est donc une version absolument cruciale puisqu'elle affrontera Windows Vista directement au début de 2OO7.
      • [^] # Re: A l'abordage !

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

        Arf, c'était donc pour ça que mes étudiants me parlaient comme ça en sortant de leur partiel hier ?
        • [^] # Re: A l'abordage !

          Posté par . Évalué à 4.

          Tu n'as pas a te plaindre dans certains établissements la proportion journalière est inversée, ce sont plus les journées sans jargon de napoléonien qui sont rares.
      • [^] # Re: A l'abordage !

        Posté par . Évalué à 4.

        Inclus dans Debian Etch? C'est une bonne nouvelle...
        Mais cette remarque me fait me poser une question: quelle est la politique de Debian (et des autres distribs en général) en ce qui concerne le choix du noyau à inclure par défaut? Car là, il s'agit d'un changement assez important, avec les risques que cela comporte (code jeune)... N'est-ce d'ailleurs pas trop tard pour l'inclure dans Etch?

        Merci d'éclairer ma lanterne
        • [^] # Re: A l'abordage !

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

          j'ai trouvé ce mail :

          Kernel
          ======

          There has been some discussions with the kernel and d-i team about the
          kernel version(s) for etch. Though there is no final agreement, current
          tendencies are to ship etch with 2.6.17 or newer.
          The kernel will be frozen on July 30th or shortly after, but there will be
          (at least) one chance to put ABI-changing kernel changes or even a newer
          kernel into etch in mid of October, shortly before building the final
          installer for etch. Currently, due to the massive number of local root
          exploits there is some delay relative to the original time line, but it
          looks like this is not going to delay the final release. We are currently
          sorting that out with the kernel- and installer-team.

          Donc la décision sera prise en octobre pour voir si ils passent sur 2.6.18 ou si ils restent en 2.6.17
          • [^] # Re: A l'abordage !

            Posté par . Évalué à 2.

            Vu le gros bug présent sur un driver PATA utilisé sur la plupart des meilleures cartes mères pour Core 2 Dual, qui touche pas mal de distros avec live CD (parce que malheureusement, la plupart des gens ont un lecteur optique sur PATA, et du coup, il n'est pas reconnu), le passage au 2.6.18 serait extrêmement sage, car ce driver buggé est présent dans le 2.6.17. Quoiqu'ils peuvent choisir de patcher aussi.
            • [^] # Re: A l'abordage !

              Posté par . Évalué à 1.

              Tu fais référence à quel problème ?

              J'ai de temps en temps un soucis avec mon lecteur de CD, dont le driver m'innonde brusquement de messages d'erreurs toutes mes consoles, et me laisse le lecteur HS.

              Je n'ai pas réussi à comprendre la nature du problème, et je n'ai rien trouvé sur le net. Des liens sur le problème que tu évoques peuvent m'intéresser.
              • [^] # Re: A l'abordage !

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

                Les lecteurs et graveurs de CD et de DVD ont une vie courte. Uniquement avec mes machines et celles de la famille, j'en ai fait une pile de sept en peu d'années. Cette pile est complétée par 3 disques durs (sans compter les 3 ou 4 tombés en panne sous garantie).

                Essaie d'emprunter un lecteur de CD ou même achètes-en un neuf car les prix sont très bas actuellement.
              • [^] # Re: A l'abordage !

                Posté par . Évalué à 2.

                Non, ce n'est pas la même chose.
                Je fais référence à ce problème : https://wiki.ubuntu.com/Core_2_Duo_Support

                Désolé, c'est en anglais.
        • [^] # Re: A l'abordage !

          Posté par . Évalué à 4.

          > quelle est la politique de Debian (et des autres distribs en général) en ce qui concerne le choix du noyau à inclure par défaut?

          Pour RHEL/Fedora.
          Déjà, il n'y a pas de noyau par défaut car il n'y a qu'un noyau. Il y a des "saveurs" différentes (Xen ou non, PAE ou non, etc) mais ils proviennent tous des même sources.

          Pour Fedora :
          C'est simple, c'est la dernière mouture en prenant en compte la phase de freeze d'une release Fedora. C'est donc la dernière mouture qui est prise jusqu'à la phase test 3. Si un noyau est en RC, il sera dans la version finale (que le noyau atteigne ou non la version finale).

          Pour RHEL :
          C'est plus compliqué si on regarde dans le passé. Je préfère regarder ce qui se fait aujourd'hui (RHEL 4 et la sortie de RHEL 5 fin 2006 début 2007). En gros RHEL est un fork d'une Fedora (en général d'une test 2).
          Au début de RHEL (nommé beta 1) il y a la dernière mouture de Linux (piquée de Fedora).
          Donc au début du développement d'une version de RHEL, RHEL a ce qu'il y a de plus récent (RHEL 5 a débuté avec un 2.6.17-rc6 je crois). Par contre RHEL a plus de tests (fait par Red Hat et des boîtes "partenaires" de Red Hat) et des ajoutes de fonctionnalités qui n'ont pas leur place dans une distribution communautaire comme Fedora. Aujourd'hui FC6 et RHEL5 partage les mêmes sources.
          Donc au début de RHEL il y a ce qu'il y a de plus récent et 4 à 6 mois après (donc après beaucoup de correction de bug) la version finale de RHEL sort. Evidemment, RHEL comme Fedora feront le "saut" 2.6.*-rc? vers finale si la version finale est disponible à temps.

          Pour Mandriva :
          En me basant sur la sortie de Mandriva Corporate Server 4.0, ils prennent un noyau éprouvé. Ici un 2.6.12 qui est probablement venu de Mandriva 2006.
      • [^] # Re: A l'abordage !

        Posté par . Évalué à 1.

        > Sinon il faut noter que ce noyau 2.6.18 va sans doute être le noyau de la future Debian stable (Etch) et de la future Red Hat Entreprise Server (5.0)

        Ce n'est pas 5.0, c'est 5 (un entier).
        Je confirme, ça sera dans RHEL 5. C'est actuellement un 2.6.17-rc7 mais ça passera rapidement à 2.6.18. Il y a quelques fonctionnalités de plus que le 2.6.18 et principalement une optimisation pour NFS avec cachefs. On trouve aussi les "classiques" Xen et GFS2. Il y a aussi des patchs pour contrôler/auditer le noyau (débordement, etc) mais je n'y comprend pas grand chose :-)

        RHEL 5 et FC6 (actuellement les deux sont en phase de test) partage le même noyau (à quelques options de configuration près).

        > elle affrontera Windows Vista

        A propos de gadget, normalement AIGLX sera dans RHEL 5 (Xorg 7.1.1) et dans quasiment toutes les distributions à la sortie de Vista.
    • [^] # Re: A l'abordage !

      Posté par . Évalué à 1.

      > c'est "Add binding/unbinding support for the VT console"

      Réponse un peu au feeling.
      Lorsqu'il y a une console, il y a un driver pour cette console. Sous i386 c'est le driver VGA, mais on peut aussi utiliser le driver framebuffer.
      "binding/unbinding" fait qu'on peut virer une console et la remettre. Le but étant me semble-t-il de changer de driver pour cette console.
    • [^] # Re: A l'abordage !

      Posté par . Évalué à 3.

      D'ailleurs ça se passe comment pour le changement de dur à chaud ? il faut que la carte mère supporte cette fonctionnalité ?
      • [^] # Re: A l'abordage !

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

        Pour la carte mère, je ne sais pas, mais pour le disque dur, c'est sur. Sur un que j'ai acheté récemment (Hitachi) il était clairement inscrit dessus (de mémoire) : This HD does not support hot plug.

        Je suppose que le matériel (CM+DD) doit supporter cette fonctionnalité pour que cela puisse être mis en oeuvre.
      • [^] # Re: A l'abordage !

        Posté par . Évalué à 10.

        il suffit de taper eject, mais il faut baisser la tête surtout si tu as overclocké les ressorts
    • [^] # Re: A l'abordage !

      Posté par . Évalué à 2.

      ya quelque chose que j'sais pas trop à quoi qu'ca sert : c'est "Add binding/unbinding support for the VT console". Est-ce que ca fait qu'on peut enlever un TTY d'une machine et le refoutre sur une autre ?
      En général sur les VTs de Linux tu peux attacher une console VGA ou une console en FrameBuffer. La contrainte était qu'une fois la console choisie pour les VTs, pas possible de revenir en arrière. Cette feature pave le chemin pour pouvoir, par exemple, commuter à chaud les VTs de Linux entre une console VGA ou FrameBuffer.
      • [^] # Re: A l'abordage !

        Posté par . Évalué à 1.

        Ca yabon, et si ça peut permettre aussi de récupérer les consoles irrémédiablement réduites à l'inutilisabilité parfois par certains pilotes graphiques sous X, ou quelques applis tordues en console, ça peut même être très très utile !

        Yth.
        • [^] # Re: A l'abordage !

          Posté par . Évalué à 5.

          On va vite le savoir : j'ai une radeon XPRESS 200M sur mon portable qui me cause souci, je teste ce soir même :)
          • [^] # Re: A l'abordage !

            Posté par . Évalué à 4.

            Bon, ben le problème est toujours là :(

            (testé avec xorg 7.1, driver radeon libre et le kernel 2.6.18 tout frais)
        • [^] # Re: A l'abordage !

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

          Dans ce cas ce ne sont plus des consoles, mais des terminaux
          (pas des VT mais des PTY). La console est un cas particulier de terminal.

          La fontionnalité a été implémentée au niveau console donc uniquement sur ce qu'on obtient avec les alt-Fx
          • [^] # Re: A l'abordage !

            Posté par . Évalué à 7.

            Ben oui, il est là le problème.
            Tu es sous console, avec tes atl-Fx, c'est rigolo tu t'amuses, ça marche.

            Là paf, un démon malfaisant entre dans ton esprit et te pousse à faire un truc débile comme lancer un serveur X. L'impulsion est fugitive, mais un serveur X ça se lance vite, paf il est lancé, mais finalement tu n'en veux plus, tu as retrouvé tes esprits.
            Donc ctrl-alt-Fx pour retourner sous console (ou ctrl-alt-backspace pour tuer le serveur X, au choix), et là beeerk, ta console est inutilisable. Ca arrive avec certains drivers, en général ça a tendance à bien marcher, mais parfois non, et je pense que ça vient du driver graphique, mais je n'ai pas poussé les recherches à ce sujet.
            C'est souvent radical : la console est totalement noire et l'écran ne recevant aucune donnée fini par s'éteindre, ou alors tu restes dans un mode graphique plus élevé que celui de la console, avec tes caractères en tout petit partiellement dans une portion de l'écran, partiellement dans une autre, ça se répète vaguement et ça bugge beaucoup, ou encore tu as un mode texte normal, mais les trucs qui s'affichent ne ressemblent à rien.
            Dans tout les cas, tuer tout les processus de la console ne résoud rien, en même faire un "reset" dans ton terminal n'arrange pas la situation.

            Je ne connais aucun moyen de récupérer ces consoles irrémédiablement aveuglées.
            Par contre le serveur X lui continue à tourner correctement, les consoles aveugles réagissent quand même donc on peut lancer des commandes, et par exemple relancer un serveur X, etc...
            C'est juste qu'on ne voit rien.


            Il s'agit bien ici de VT, non ?
            Et donc j'avais imaginé que cette modification dans le kernel aurait pu permettre de sauver ces pauvres consoles mutilées.


            Yth.
            • [^] # Re: A l'abordage !

              Posté par . Évalué à 1.

              Je ne connais aucun moyen de récupérer ces consoles irrémédiablement aveuglées.

              Je peux t'en donner un, mais il est hautement aléatoire : traiter le mal par le mal. Quelque fois, relancer un serveur X résoud le problème. Ça peut être au premier lancement, au 3ème, au 15ème (machine avec kdm). Et puis certaines fois il n'y a qu'après un rédémarrage que tout rentre dans l'ordre.
            • [^] # Re: A l'abordage !

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

              Non cette modification ne concerne que la partie qui fait l'affichage de la console.

              Je ne connais pas de technique pour récupérer une console, par contre je peux te dire comment en lire le contenu. Il suffit de lire /dev/vcsXX

              /dev/vcs la console en cours
              /dev/vcs1 la 1ere console
              ...
              Si tu utilise vcsa à la place de vcs tu as droit aux caractères de controle qui vont avec (ou le contraire je ne me souviens plus).

              Dans certains cas, on les trouve dans /dev/vc/
    • [^] # Re: A l'abordage !

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

      Nomdediou, moi j'vous dit, pouvoir foutre et retirer les disques SATA sans redémarrer le bousin, ca c'est une put1** de feature comme on les aime !
      Y'a moyen de le faire en IDE, faut utiliser hdparm pour éteindre le disque (voir l'interface IDE), puis brancher l'autre et demander au kernel de relire la table des partoches (encore avec hdparm).
      Bon, après c'est pas censé marcher, donc y'a les risques touça. Et puis je me souvient plus trop à quoi ça a pu me servir.
      Mais ça marche.
      • [^] # Re: A l'abordage !

        Posté par . Évalué à 3.

        Je sais que le hotplug de lecteur de disquettes marche bien aussi, par contre mieux vaut éviter d'essayer d'y accéder quand il est enlevé.
        C'est un truc de barbare, j'en conviens, mais ça m'avais dépanné une ou deux fois, j'avais besoin d'un lecteur et je ne voulais pas éteindre la seule machine en possédant encore un chez moi.


        Yth.
  • # SMPnice

    Posté par . Évalué à 10.

    SMPnice : un moyen d'augmenter et de diminuer la priorité de certains processus sur une machine multiprocesseurs.

    Je n'avais pas compris ça comme ça. J'avais compris que SMPnice permet de mieux répartir la charge sur chaque processeur en fonction de la charge de chaque processus, dérivée de sa priorité.
    Pour éviter d'avoir 2 processus "niced" sur un processeur et 2 processus de priorité normale sur l'autre (je prends le cas d'un bi-processeur).
    En tout cas je n'avais pas compris que ça change la priorié des processus, mais plutôt que ça en tient compte pour répartir les processus sur les processeurs.
    • [^] # Re: SMPnice

      Posté par . Évalué à 4.

      Rassure toi, tu as compris comme il faut ce que fait smpnice. La description donnée par patrick_g est fausse.
      • [^] # Re: SMPnice

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

        >> La description donnée par patrick_g est fausse.

        /Mode rattrapage aux branches avec les ongles/ON

        Ma description est vague mais c'était pour simplifier !

        /Mode rattrapage aux branches avec les ongles/OFF
  • # Email de Thorvalds.

    Posté par . Évalué à -10.

    "There's not too many changes, with t'bulk of the patch bein' defconfig
    updates, but the shortlog at the aft of this here email describes the
    details if you care, you scurvy dogs."


    J'ai pas tout compris dans son email d'annonce (notamment "scurvy"), mais Linus pète un peu son cable, remarque pas son 1er coup d'éclat (cf. insulte de "nazis" envers les gnomistes).

    Peut-être sa façcon à lui de se détendre...
    • [^] # Re: Email de Thorvalds.

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

      Peut-être que c'est un gars qui a beaucoup de pressions et qui est hyper stressé. :P
    • [^] # Re: Email de Thorvalds.

      Posté par . Évalué à 5.


      Comme l'année dernière Linus Torvalds s'est débrouillé pour faire coïncider la sortie d'une nouvelle version du noyau Linux avec la journée internationale du langage pirate. Son annonce (signée Linus "but you can call me Cap'n") est donc assez difficilement compréhensible et pleine d'insultes ésotériques de boucaniers.


      d'ou le langage plutot cheulou
    • [^] # Re: Email de Thorvalds.

      Posté par . Évalué à 7.

      scurvy
      1) n scorbut m
      2) adj [archaic, or liter] bas (basse f ), mesquin, vil (vile f )

      s/Thorvalds/Torvalds/
    • [^] # Re: Email de Thorvalds.

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

      mon google translate me suggère que "you scurvy dogs" doit être approximativement "bande de chiens ayant le scorbut".
      Tout à fait ce qu'un capitaine pirate dirait à son équipage pour le motiver ;-)
    • [^] # Re: Email de Thorvalds.

      Posté par . Évalué à 10.

      >mais Linus pète un peu son cable, remarque pas son 1er coup d'éclat

      Linus est une personne dotée d'un grand sens de l'humour, de l'auto-dérision, et capable de rédiger des emails assassins. Son coup de gueule contre les Gnomistes n'est en aucun cas son "1er coup d'éclat".

      exemples (tirés de wikiquotes et de mes bookmarks):

      HURD:
      "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people."

      ACPI:
      "The fact that ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry obviously makes running it at _any_ point pretty damn ugly."

      et un de mes préférés (Mach/HURD et FreeBSD):
      "I claim that Mach people (and apparently FreeBSD) are incompetent idiots."

      qui fut suivi de cette clarification:
      "I also claim that Slashdot people usually are smelly and eat their boogers, and have an IQ slightly lower than my daughters pet hamster (that's "hamster" without a "p", btw, for any slashdot posters out there. Try to follow me, ok?).

      Furthermore, I claim that anybody that hasn't noticed by now that I'm an opinionated bastard, and that "impolite" is my middle name, is lacking a few clues.

      Finally, it's clear that I'm not only the smartest person around, I'm also incredibly good-looking, and that my infallible charm is also second only to my becoming modesty."

      Juste pour resituer le pirate-talk day dans une longue tradition d'emails plus marrants et/ou polémiques les uns que les autres.
      • [^] # Re: Email de Thorvalds.

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

        A propos de la dernière citation y'avait eu un journal (et une traduction du post de Linus par lesensei) :

        http://linuxfr.org/~patrick_g/21467.html

        "J'affirme également que les lecteurs de Slashdot sentent généralement mauvais et qu'ils mangent leurs crottes de nez, et qu'ils ont un QI inférieur à celui du hamster de mes filles (c'est "hamster" sans "p", à propos, pour les contributeurs de Slashdot. Essayez de me suivre, d'accord ?).

        De plus, j'affirme que quiconque n'ayant pas encore remarqué que je suis un batard aux opinions forgées [NDT: pas terrible, mais je trouve pas mieux, là tout de suite], et que "impoli" est mon deuxième prénom, est légèrement en retard.

        Pour finir, il est clair que je ne suis pas seulement le plus intelligent ici-bas, mais également incroyablement beau, et que seule ma modestie peut se prétendre supérieure à mon infaillible charme.

        Voilà. Juste pour clarifier.

        Linus "faites moi une révérence, rebus" Torvalds"
      • [^] # Re: Email de Thorvalds.

        Posté par . Évalué à 10.

        Linus est une personne dotée d'un grand sens de l'humour, de l'auto-dérision

        Il aurait donc pu être Belge...
      • [^] # Re: Email de Thorvalds.

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

        Ou par exemple hier soir, sur la mailing-list de Git, suite à une demande de pouvoir attribuer un numéro séquentiel aux commits :

        I really don't think you can do it sanely.

        The thing is, the reason subversion can do it is simply that SVN is terminally broken.

        Really. SVN is crap. It may be prettier crap than CVS, but it's literaly
        no different from putting confectioners sugar on top of a cowpatty. It's
        not really "fixing" anything. And the revision numbering is actually very
        much part of the problem.


        En adaptation libre :

        Je ne pense vraiment pas que ça puisse être fait proprement.

        Le truc, la raison pour laquelle subversion peut faire ça c'est simplement que SVN est une foirade irrémédiable.

        Vraiment. SVN c'est de la merde. C'est peut-être une merde plus avenante que CVS, mais c'est littéralement la même chose que de mettre du sucre en poudre sur de la bouse de vache. Subversion ne "corrige" en fait rien du tout. Et la numérotation des révisions est un symptome typique des problèmes de subversion.


        (Suite à quoi il avait tort, non pas sur Subversion ;) mais il avait mal compris ce que le demandeur voulait.)
    • [^] # Re: Email de Thorvalds.

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

      [...] pas son 1er coup d'éclat (cf. insulte de "nazis" envers les gnomistes)

      C'est une erreur de traduction et d'interprétation bien de chez nous.
      Le mot "nazi" n'est pas aussi insultant en anglais qu'en français.

      "interface nazis" se traduirait plutôt par "dictateurs de l'interface", dans le sens ou les développeurs de gnome prennent des décisions arbitraires quant aux besoins des utilisateurs - alors que Torvalds préfère offrir plus de choix et d'options aux utilisateurs.
      • [^] # Re: Email de Thorvalds.

        Posté par . Évalué à 2.

        troll detected : "arbitraire"

        On peut dire que les gnomistes sont des dictateurs de l'interface, mais qu'ils prennent des décisions arbitraires, c'est vraiment diffamatoire !
        • [^] # Re: Email de Thorvalds.

          Posté par . Évalué à 1.

          Ce que cela peut être frustrant ton 'troll detected'...
          Je confirme pour arbitraire rien que pour le support multi-users de gvm (pam_console (redhat) et non pam_foreground (debian & lfs))...

          Au propos du "sujet":
          le 2.6.18 apporte un bien meilleur support pour les mac intel (macbook), (toujours avec les patch mactel), j'ai moins de freeze du disque sata (assez désagréable).
        • [^] # Re: Email de Thorvalds.

          Posté par . Évalué à 5.

          ffamatoire


          rah c'est bon..

          désolé
      • [^] # Re: Email de Thorvalds.

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

        Le mot "nazi" n'est pas aussi insultant en anglais qu'en français.

        Je ne suis pas un pro de la linguistique, aussi j'aimerais bien avoir un éclairage sur ce point....
        • [^] # Commentaire supprimé

          Posté par . Évalué à 4.

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

          • [^] # Re: Email de Thorvalds.

            Posté par . Évalué à 5.

            Par consequent, la notion de tabou sur les mots interdits tel que nazi n'existe pas et par consequent cela n'a pas la meme connotation qu'en francais.

            C'est contextuel et des fois le terme nazi est bien utilise comme on l'entend en France. Cf utilisation du mot Nazi par les opposants de Bush.

            On peut aussi remarque qu'ils n'ont connu aucune guerre sur leur sol

            Ils ont reclassifier la guerre d'independance et la guerre de cessession en "promenade dans les champs"?

            Ils se sont pour la premiere fois de leur histoire senti agresser et donc ils reagissent en mode reflex d'autodefense.
            Y a quand meme eu un "petit petard" au WTC en 93. Pour ce qui est du reflex d'autodefense, c'est pas nouveau et pas propre au 11 Septembre. Coree, VietNam, Guerre froide, Cuba... Certes, ils sont passe a la vitesse superieur depuis le 11 Septembre.
            • [^] # Commentaire supprimé

              Posté par . Évalué à 1.

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

              • [^] # Re: Email de Thorvalds.

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

                >> C'etait deux guerres civiles. Ils se battaient entre eux, c'est pas un etat qui leur declare la guerre et les envahis.

                C'est bien de répéter ce que tu lis dans les journaux mais faut songer à se documenter avant de dire des bétises. Les USA ont bien connu la guerre sur leur sol en plus de la guerre d'independance et la guerre de secession.
                C'est la guerre de 1812 contre les anglais.
                On en parle pas souvent car à l'époque l'Europe était en plein dans les guerres napoléoniennes.
                A noter que les anglais ont bien envahi le territoire des USA puisqu'ils ont brulé la maison blanche et que le President James Madison a été forcé de s'enfuir de Washington !

                En français (pas complet) : http://fr.wikipedia.org/wiki/Guerre_de_1812

                En anglais (plus complet) : http://en.wikipedia.org/wiki/War_of_1812


                Moralité : le journalisme c'est bien mais la fac d'Histoire c'est mieux.
              • [^] # Re: Email de Thorvalds.

                Posté par . Évalué à 0.

                C'etait deux guerres civiles. C'est pas un etat qui leur declare la guerre

                On peut chipoter mais pour ce qui est de la guerre de cessession, les etats du sud ne faisait plus partis de l'union. C'est d'ailleurs pour cela qu'apres la fin des combats, il a fallut les "reintroduire" dans l'union. Il y a eu tout un debat sur la definition des criteres permettant ces etats
                de oui ou non refaire partie de l'union. Puisqu'apparement tu es aux US, tu peux surement obtenir un "textbook" de l'histoire des US a ce sujet si tu as une universite pas trop loin. Attend le debut du prochain semestre. Il en reste toujours un peu a la librairie de l'universite et generalement ils sont en solde.

                La guerre du vietnam, la plupart des americains ne savent toujours pas ou c'est sur une carte...
                Ca c'est un super critere qui tue pour definir si on se sent attaque ou pas. Plus serieusement: Oui le 11 Septembre a ete ressentit comme une attaque. Y a pas de doute possible. Je dis juste que c'est pas la premiere fois. Pour ce qui est des sentiments que tu evoques et la methode "lance flamme", je crois que ca correspond a ma definition de "vitesse superieure".
              • [^] # Re: Email de Thorvalds.

                Posté par . Évalué à 3.

                La guerre du vietnam, la plupart des americains ne savent toujours pas ou c'est sur une carte...
                je me demandais... parmi les etats uniens incapables de situer le vietnam, combien savent situer new york?
          • [^] # Re: Email de Thorvalds.

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

            La liberté de parole peut être mais pas de penser. Je me souviens qu'en 1985 il y avait explicitement marqué que l'adhésion à un partis communiste était interdit sur les bulletins de vote en californie...

            Bref, le monde est loin dêtre parfait, ni d'un coté, ni de l'autre coté de l'atlantique ;-)

            Au niveau de la guerre, les japonais ont atteint l'île de Kodiak en Alaska pendant la guerre... ïle qui était l'ancienne capitale de l'Alaska au temps ou c'était encore la Russie. A l'époque, ils ont eu si peur qu'ils ont fait LA Route qui passe par le canada pour expluser les japonais....

            Bon OK, L'Alaska is the last frontier et il n'y a pas grand monde...
          • [^] # Re: Email de Thorvalds.

            Posté par . Évalué à 1.

            Oui, dans le fond, mais pour ce qui est du 11 septembre ...

            http://video.google.com/videoplay?docid=6302880871177953720

            a mediter .
        • [^] # Re: Email de Thorvalds.

          Posté par . Évalué à 3.

          Bah son explication est mauvaise, mais en fait en Anglais il y a 'grammar nazi' comme expression désignant les obsédés de la forme grammaticale correcte, perturbant sur des détails de forme les discussion sur le fond, etc.

          En Anglais c'est une série de discussion sans fin car c'est une langue assez "souple" avec des variantes proposée..
          Evidemment on a les mêmes en France, il n'y a qu'a voir le stupide tollé qu'a cause la réforme de l'orthographe, mon royaume pour un accent circonflexe!

          Donc 'grammar nazi' --> 'interface nazi', ce qui est une bonne caricature de Gnome: 'obsédé de la forme des interfaces par rapport au fond'.
          • [^] # Re: Email de Thorvalds.

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

            en Français, NAZI est précis mais FACHISTE est utilisé de façon générique alors qu'il recouvre une réalité aussi précise que NAZI (ie le régime de Mussolini). Ca ne choque personne.

            La bonne traduction de interface nazi serait dont assez proche de interface fasciste...
    • [^] # Re: Email de Thorvalds.

      Posté par . Évalué à -9.

      Et Bing !!! Un -10 dans ma gueule ! Suite à mon premier commentaire (http://linuxfr.org/comments/756370,1.html)

      Quel châtiment, bon c'est bien beau de parler de liberté d'expression et tutti quanti, quand je vois que le fait d'ouvrir un tant soit peu sa gueule sur linux.fr conduit souvent à se faire vilipender en place public...

      Ça aurait été cool au moins pour le fil de la discussion, et un peu par honnêteté intellectuelle de laisser mon post au moins juste à zéro, pour connaître le point de départ et l'objet de la discussion...

      Mon comm n'avait rien d'incendiaire ou de trollesque je pense, c'était juste une constation, mais je m'apperçois de plus en plus que pour peu qu'on s'éloigne de l'avis commun c'est forcément dénigrement (par notation négative) ça me dérange pas qu'on partage pas mon avis, mais que le moinssage devienne systématique us dès qu'on parle d'une autre voix je trouve ça triste pour ce forum...

      Ce 'forum' a d'ailleurs perdu de sa convivialité je trouve...

      Enfin bon je sais que ce commentaire ne changera rien, mais dorénavant je m'abstiendrai, c'est beau la diversité prônée par tant de personnes qui viennent ici et qui ne l'appliquent pas à eux-mêmes ou aux autres...

      Ciao.
      • [^] # Re: Email de Thorvalds.

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

        >> Ça aurait été cool au moins pour le fil de la discussion, et un peu par honnêteté intellectuelle de laisser mon post au moins juste à zéro, pour connaître le point de départ et l'objet de la discussion...

        Putain mais ça t'importe tant que ça le score de tes commentaires ?
        Je te signale humblement qu'à mon avis 90% des gens n'en ont rien à foutre et que la majorité des lecteurs surfe avec un seuil à -42 afin de voir tous les posts.
        Ne te fait donc pas de souci pour la visibilité de ta prose.
        • [^] # Re: Email de Thorvalds.

          Posté par . Évalué à -10.

          Stp t''es pas obligé de gueule comme un putois pr te faire entendre...
          Je me lustre pas la hampe avec mes scores de comm' pr ta gouverne...

          Je me cite :
          "Ça aurait été cool au moins pour le fil de la discussion, et un peu par honnêteté intellectuelle de laisser mon post au moins juste à zéro,"

          C'est pas tant le score qui m'imporet si tu lis, mais le moinssage systématique dont font preuve certains, y'a des fois c'est fondé, mais quand comme je le redis : ça devient systématique c'est juste reloud. Et quand on ne sait même plus le départ de la discussion, ça l'est encore plus, ce que je dis là est valable pr moi bien sûr, mais j'ai remarqué ça sur d'autres postes que je trouvais plutôt injustement malusé...

          Ca sert à rien de t'emporter pr si peu...
          • [^] # Re: Email de Thorvalds.

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

            >> Et quand on ne sait même plus le départ de la discussion, ça l'est encore plus

            Tu a compris ce que j'ai écrit sur le seuil de -42 ?
            La grande majorité des lecteurs voit tes posts même quand ils sont en négatif !
            Et pour les autres ils peuvent facilement déplier ton post pour le lire si ils le veulent.

            De façon générale cela ne sert à rien de chouiner sur les moinssages et sur la cabale qui s'acharne sur toi. C'est même un peu puéril AMHA.
    • [^] # Re: Email de Thorvalds.

      Posté par . Évalué à -1.

      déja, tu pourrais éviter d'écorcher son nom...
      c'est "Torvalds"...
      bien qu'il soit nordique, rien a voir avec Thor ( http://fr.wikipedia.org/wiki/Thor ) ...
  • # BTTV ????????????

    Posté par . Évalué à 1.

    le module bttv a disparu du coup .... sacrée regression !
    • [^] # Re: BTTV ????????????

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

      Tu es sûr? De mon côté, la télé fonctionne toujours. Ils auraient modifié les autres modules pour se passer de celui-ci? Je regarderais cet après midi mais je n'ai pas vu de différence, ça fonctionne toujours.
    • [^] # Re: BTTV ????????????

      Posté par . Évalué à 7.

      Non, il n'a pas été supprimé.
      Par contre il dépend maintenant de l'option V4L1, donc effectivement tant que tu ne selectionne pas cette option, le driver bttv semble avoir disparu.
  • # Question sécurité ?

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

    Je me demande s'il y avait quelques choses qui permettrait de limiter les accès d'un process dans un espace utilisateur. Les solutions de chroot sur des serveurs ca va... mais je pense à de simples utilisateurs qui lancent des programmes leur l'espace.
  • # Auto chargement de code optimisé

    Posté par . Évalué à 4.

    J'avais entendu qu'une future version du kernel intégrerait l'ensemble des codes optimisés (i686, K7...) et le chargerait automatiquement en fonction de l'architecture trouvée sur le systeme.

    J'espere m'etre fait comprendre car je ne sais pas le nom exact de cette "feature"... qu'en est il ?
    • [^] # Re: Auto chargement de code optimisé

      Posté par . Évalué à 6.

      Comme ça?

      SMP "alternatives" for x86-32. This features detects the configuration of the system at boot time, and patches certain instructions in the kernel image on the fly with optimized versions for UP or SMP, depending on what system is running. This is useful for distros, who can provide a single kernel which auto-optimizes itself for UP or SMP environments. The feature can patch both SMP->UP and UP->SMP. The UP->SMP case is useful for CPU hotplug (which may be useful in virtualized environments to hot-add/remove CPUs in virtualized guests in reaction to load changes in the host) (LWN article) (commit)



      http://lwn.net/Articles/164121/

      Ca a été implémenté dans le 2.6.17.
      • [^] # Re: Auto chargement de code optimisé

        Posté par . Évalué à 1.

        Effectivement ca doit etre ca ! Merci de l'info
        Ca s'appelle donc "SMP "alternatives" for x86-32." :-)
        • [^] # Re: Auto chargement de code optimisé

          Posté par . Évalué à 2.

          > Effectivement ca doit etre ca !

          Pas vraiment :-)
          Ce qui est dit au-dessus est exacte. Mais tu dois faire référence à autre chose qui a été implémenté il y a longtemps.
          La fonctionnalité est de fournir un noyau optimisé pour i586 et K7 par exemple. Au boot, le noyau détecte le cpu et utilise les fonctions optimisées pour le cpu.
  • # priority inheritance... encore un pas de plus :)

    Posté par . Évalué à 4.

    on peut retenir aussi "priority inheritance" ...

    le temps-réel avance petit à petit, et il n' est pas exlu que " ... soon real-time could become more widespread. Seiler believes Molnar's patch will be accepted soon into the mainstream Linux kernel"

    ce qui serait vraiment Royal. S' il était complètement intégré (complètement, je ne sais pas puisqu' une horloge hrt à fait son apparition en juin, et qu' il -me- semble que le patch de Sir Molnar en a une aussi, donc... bon bref l' essentiel ;) ) cela permettrai de très facilement avoir un kernel "preemption on acid".

    Même en partant d' un kernel patché à mort comme celui d' une mandriva ou d' une suse ! Il suffirait de choisir l' option "full preemption" (comme aujourdhui on peut choisir entre la preemption volontaire et "outofbox", plutôt que le choix par défaut, dit "server"). -aussi les options "rtc clock par défaut et en dur" et 1000hz bien sûr.. au fait hpet on garde ou pas ? ;) - Un kernel comme celui d' une SuSe ou d' une Mandriva, bien complet, avec full support hardware, mais en realtime complet juste en recompilant (et en mettant au diapason PAM pour l' audio) = le bonheur total...

    Bon je veux pas envoyer de pathfinder sur Mars, c' est sûr. Ni faire des missiles intelligents. Non plus hacker mon futur aldebaran-robotics... non juste pouvoir avoir un kernel qui permette de faire du son, sans lag aucun, parfaitement prévisible, et au dessus de tout ce qui se fait aujourdhui...

    Les GNU de LAUD se défoncent pour faire des applis de feu (ardour, rosegarden, jamin.... toutes les autres). Un tel kernel serait la cerise sur le gateau. Facilement accessible pour tous puisque l' option serait intégrée par défaut (et non plus prendre le patche sur people~mingo et l' appliquer au vanilla, mais se servir direct des kernels de nos chères distribs).

    Gain co-latéral ? que, enfin, Jack, décolle et s' impose... (pas seulement pour les pro du son)
    /troll : parcequ' y en a marre des arts / esd / phonon / pusleaudio .... /troll

    (et hop...)
    • [^] # Re: priority inheritance... encore un pas de plus :)

      Posté par . Évalué à 3.

      Note : je parle de SuSe et de Mandriva exprès : SLERT est annoncé... (salle de marché, etc etc)
      Et Mandriva est totalement pré-configurée pour le Son (il faut juste se faire le kernel)
      du côté de RedHat (the master of) c est RedHawk.. et en trollant on peut se demander ce que penses Concurent-soft de la possible intégration par défaut de ce patch.

      (les autres projets, hyperviseurs, sheduleurs et autres choix de micro noyaux ne seront pas impactés, mais concurent-soft et certains fournisseurs de services..si certainement)
    • [^] # Re: priority inheritance... encore un pas de plus :)

      Posté par . Évalué à 4.

      horloge hrt à fait son apparition en juin, et qu' il -me- semble que le patch de Sir Molnar en a une aussi


      Les hrtimers n'ont rien à voir avec l'horlogoge système. Pour le reste tu dois faire référence au patch dyntick d'ingo Molnar et Ted T'so.

      et 1000hz bien sûr.. au fait hpet on garde ou pas ? ;)


      Régler la fréquence d'horloge à 1000Hz n'est pas forcément une bonne idée car le temps passé à gérer l'interruption du timer prend une part non négligeable du temps processeur. HPET est une infrastructure très intéressante, d'ailleurs si ta CM à ce type de matos il est justement utilisé en prio (si tu l'as activé dans les options du noyau) pour l'interruption du timer...
      Un truc intéressant sinon est bien le patch dyntick qui propose du tickless ou du tick variable (cependant plutôt pour le domaine de l'embarqué par rapport à la conso énergétique).

      mais en realtime complet juste en recompilant (et en mettant au diapason PAM pour l' audio) = le bonheur total...


      Si par realtime complet tu entends hard real time, je doute que cela soit le bonheur total pour une utilisation "poste de travail" où l'interactivité avec le système est un aspect important. Le hard RT garanti (de façon mathématique) les latences max, au détriment de l'intéractivité justement.
      • [^] # Re: priority inheritance... encore un pas de plus :)

        Posté par . Évalué à 2.

        non justement tu pourrais garantir une latence max sur la réactivité. LE rt s'est des tache périodiques mais aussi une garantie de latence sur les taches évenementiels.

        Il y a longtemps j'avais créer un benchmark avec des taches qui tournaient autour de la seconde... Sur une même machine en idle, je pouvais avoir 30% de variation sur le temps d'execution ...

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

        • [^] # Re: priority inheritance... encore un pas de plus :)

          Posté par . Évalué à 2.

          Pour avoir beaucoup de réactivité, il faut traiter les interruptions de tout au plus vite, dans ce cas tu ne peux rien garantir pour une certaine tâche en particulier (je n'ai en aucun cas mentionné des tâches périodiques qui comme tu le dis ne sont pas la seule composante des sys RT). Dans un système RT, les tâches de prio forte doivent prendre le devant. Tu ne peux pas imaginer d'avoir de la réactivité pour tout. Celle dont je parlais c'était celle que souhaite un utilisateur devant son poste de travail : réponse au plus vite aux E/S. Ce qui est d'ailleurs valorisé au sein de l'ordonnanceur de Linux.
          • [^] # Re: priority inheritance... encore un pas de plus :)

            Posté par . Évalué à 2.

            "Dans un système RT, les tâches de prio forte doivent prendre le devant. "

            Si tu utilises un truc bête à priorité dont tu peux prédire le comportement qu'avec 2 ou 3 process au desssus, bonne chance...

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

            • [^] # Re: priority inheritance... encore un pas de plus :)

              Posté par . Évalué à 0.

              Quand j'ai employé "prio forte", c'était en fait pour parler des tâches dont l'échéance était la plus proche (même si c'est pas toujours le cas en fait ;). Je ne faisais pas de supposition sur la méthode employée. Ma phrase est cependant maladroite, c'est vrai...
            • [^] # Re: priority inheritance... encore un pas de plus :)

              Posté par . Évalué à 1.

              Par "prio forte" je voulais signifier "les tâches dont l'échéance est la plus proche" (bien que ce ne soit pas forcément tjs le cas). Je ne mentionnais pas de méthode ou d'implémentation. Mais il est vrai que ma phrase était maladroite...
      • [^] # Re: priority inheritance... encore un pas de plus :)

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

        Salut,

        Un avis perso, si le système devient temps réel, tous les appels système pourront
        être préempté - ce qui est loin d'être le cas actuellement.

        Donc fini les machines figées, et bonjour les chiens de garde. Maitenant reste à savoir
        si les concepteurs de carte mère fournirront des chiens de garde utilisables par un
        noyau libre...

        Perso travaillant pas mal avec Solaris sur des plateformes SUN, il est agréable d'avoir
        des compteurs de secondes qui ne dérapent jamais... Le même code (développé avec
        QT de trolltech) porté sur plateforme Intel / Gnu-Linux ne fournissent pas le même
        résultat.
        • [^] # Re: priority inheritance... encore un pas de plus :)

          Posté par . Évalué à 1.

          Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config).
          Maintenant dans certaines parties la préemption est désactivée, il reste encore quelques "noyaux durs" à supprimer, mais dans l'ensemble c'est fait.
          • [^] # Re: priority inheritance... encore un pas de plus :)

            Posté par . Évalué à 5.

            Eric L : >>Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config)
            -> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid

            grosso modo par défaut on est en "temps partagé"... L' ordonnanceur a pour but un partage des ressources équitables entre les process. On peut jouer sur la priorité d' un process parmis l' ensemble grâce à la "nice"

            sur un système dit temps-réel, on aura des taches qui auront un comportement dans des notions précises de temps défini. Le vrai terme "système temps-réel" pourrait être "système prédictible". C' est à dire que l' écriture, le traitement et la restitution de l' information sont effectuées dans un temps si faible que l' on nomme cette information comme étant "information préservée".

            Maintenant sur Linux, il y a plusieurs solutions de "temps-réel" (terme un peu fourre tout de manière générique mais on devrait définir par lui des choses plus précises, ici). Et tuons de suite le troll "ouaihg je joue a WoW en temps réel c est plusse mieux ça va plusse vite"... Non : un système temps réel, en consacrant de hautes priorités (et une mémoire dédiée) à certaines tâches, réduit les ressources disponibles pour l' ensemble. Un système temps-réel sur un bureau, comme le dit Eric L, est synonime d' amoindrissement des ressources pour l' utilisation bureautique et mulimédia classique du comput'...

            Il existe deux types de temps-réel :
            le temps-réel dur et le temps réel mou.

            Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous". C' est à dire qu' une certaine souplesse ai accordé aux tâches ayant pourtant accès à la priorité temps-réel (c' est à dire concrètement qu' il n' est pas interdit qu' elles dépassent 25millisecondes sir 25 est la définition du système rt)
            1. le patch "preemptif" de Mr Love : il agit sur l' ordonnanceur et réduit le temps de réponse de manière systématique. (c' est également la solution de MontaVista, pour lequel Mr Love travaillait)
            2. le patch "low-latency" de Mr Morton : il agit seulement sur des points précis du noyau, alors appelés "points de preemption" et ne s' occupe que de latence sur ces noeuds là.

            Quant au patch de Sir Molnar, il transforme le noyau linux en noyau preemption on acid (c' est à dire en noyau à capacités temps-réel dur). Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité. Et c' est bien ce patch (peut-être amputé de son horloge) qui pourrait peut être rejoindre les 2 précédents et être intégré par défaut, et accessible du coup sur tout kernel de toutes distrib, juste en recompilant ! (pour notre plus grand bonheur)

            Une fois ce type de noyau préparé, l' administrateur doit indiquer au système de sécurité quels utilisateurs et/ou groupes d' utilisateurs auront droit d' accès à ces capacités. Sur une distribution "moderne" (aucune idée de troll) c' est bien sûr PAM qui s' en charge. (et sur une distrib vraiment moderne et pas seulement à la mode, c' est pré-configuré /troll!)

            Voilà voilà.

            on pourrait parler du fameux Xenomai et de son micro-noyau hyperviseur qui fait tourner le noyau linux en tache. (Xenomai issu de de rtai lui même issu de rtlinux)
            ou encore "flamer" sur wince, annoncé comme révolutionnaire (windows c.e embarqué et temps-réel) mais... personne en veut, encore plus depuis qu' ils ont ouvert leurs sources... le machin est cantonné aux gadgets genre téléphone portables... mort de rire :)


            note inutile : ze devrais sortir dans pas longtemps un howto (bien humble) sur comment transformer facilement sa mandriva en diva-linux, pour péter les solutions actuelles grâce au travail des LAUD ... Et mettre en avant la qualité actuelle des solutions de traitment du signal audionumérique sous GNU/Linux... (troll : Apple ils vont pleurer longtemps pour le port Jack sur osX ;-) ? le site .com est sorti pourtant /troll) Si des gens lisant ceci sont éventuellement intéressés, ils peuvent m' envoyer un message privé. Toutes corrections/relectures/engueulades/merci/conseils/éclairage-de-gurus sont les bienvenues.
            • [^] # Re: priority inheritance... encore un pas de plus :)

              Posté par . Évalué à 2.

              Eric L : >>Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config)
              -> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid

              Quand je disais ça je répondais uniquement à Christophe Cazajus :

              tous les appels système pourront
              être préempté - ce qui est loin d'être le cas actuellement.

              -----------------

              Sinon quand tu dis "un module temps-réels (un linux security module)", il n'y a strictement aucun rapport entre un LSM et le temps réel.
              La péemption en mode noyau est une caractérisque commune aux noyaux RT. Les patchs de Love, Morton, permettent justement cela (on a soit un appel direct au scheduler par les tâches soit c'est en sortant de certains chemins noyau (ex. retour en usermode, etc.)) que le flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref...

              Le vrai terme "système temps-réel" pourrait être "système prédictible"

              Ce n'est pas suffisant, il faut la propriété de déterminisme également.

              Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité.

              C'est un certain Christophe Cazajus qui parle de watchdog...
              sinon le watchdog se charge de la sûreté de fonctionnement (safety) et _non_ de la sécurité au sens security !!!

              Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous".

              ben non... (par ex. VMware s'est pour du RT dur). Encore une fois, le temps réel est dit dur lorsque l'on a besoin d'avoir des _garanties_ sur les _échéances_ (Le temps de traitement peut très bien être important, ça dépend du système à piloter). Et ces dites garanties doivent être prouvées mathématiquement (RMA, etc.). Le RT mou est quant à lui adapté pour les traitements audio ou vidéo, car une garantie au sens math n'est pas nécessaire (il n'y a pas risque de mort)...

              Bref, il ya beaucoup de chose à dire... En tout cas il n'y a pas d'intérêt d'avoir un Linux patché RT dur pour une station de travail (c'est hors propos)..
              • [^] # Re: priority inheritance... encore un pas de plus :)

                Posté par . Évalué à 2.

                ok pour "sécurité c' était bien qq chose comme sûreté que je voulais employé.

                ok également pour "le temps de traitement peut très bien être important, ça dépend du système à piloter", ma phrase en ne parlant que de "minima" était réductrice. (bien que le minima soit plus souvent recherché)

                mais une question sur le temps réel "mou" : tu le dit adapté au traitment audio et/ou numérique : alors pourquoi sur un rt mou j ai des xrun bien plus souvent que sur un rt dur ? (et sans entrer dans un "bah tel patch est pas bon" loin de moi l' idée de juger ces travaux)
                En plus de nombeux exemples de solutions professionnelles en Vidéos sont RT dur (et pas seulement en diffusion/streaming, mais aussi en étalonnage, ce qui m' a d' ailleurs étonné)

                dernier mot
                " flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref..."
                tu aurais pas écrit une doc sur le sujet ou un bon rtfm à me pointer ? (même si c' est pas en rapport direct avec le son, cela m' intéresse fortement)
                Merci
            • [^] # Re: priority inheritance... encore un pas de plus :)

              Posté par . Évalué à 2.

              .. (troll : Apple ils vont pleurer longtemps pour le port Jack sur osX ;-) ?


              Pas la peine de troller, le port existe deja depuis pas mal de temps.
              http://jackaudio.org/download

              Il y a meme une version speciale multiprocesseur pour MacOSX
              http://lac.zkm.de/2005/proceedings.shtml#letz_et_al
              et
              http://www.grame.fr/Research/list.php?type=ARCH
      • [^] # Re: priority inheritance... encore un pas de plus :)

        Posté par . Évalué à 2.

        (oui bien sûr je pensais, au début du commentaire au patch dyntick)
        Eric L >> Régler la fréquence d'horloge à 1000Hz n'est pas forcément une bonne idée car le temps passé à gérer l'interruption du timer prend une part non négligeable du temps processeur

        hum très intéressant. faudra que je me penche, plus, sur ce sujet précis et que je fasse des tests entre 2 noyaux sur mon tit matos. Aurais tu un bon rtfm à me pointer ?

        question hardware :
        Ma prochaine carte mère sera celle-ci (enfin quant j aurais du pognon) :
        http://www.radisys.com/products/datasheet_page.cfm?productda(...)
        et pour la carte son, j hésite entre une française très bien supporté par Linux:
        http://www.digigram.com/pdf_manual/soundcards_comparison_cha(...)
        et une autre dont les (au moins un) dev. de la boite participe directement upstream a Alsa :
        http://audioscience.com/internet/products/sound_cards/asi661(...)
        (pour changer des hammerfaul et autres grandes classiques du nux...)
      • [^] # Re: priority inheritance... encore un pas de plus :)

        Posté par . Évalué à 1.

        Le realtime ça te rammène un petit peu dans une situation où les threads qui ont cette priorité font ce qu'elles veulent avec le temps CPU.

        Du coup si un thread RT tebouffes 99% du CPU alors tu perds toute interractivité avec les autres applications.

        Par contre si un thread RT te bouffe 1% de CPU, et ben tu vois pas la différence. Style si tu utilises Jack pour faire du son tu es dans ce cas et là c'est du bonheur.
  • # bug corrigé dans l'emulateur de term

    Posté par . Évalué à 3.

    apparamment y'a un truc qui a été corrigé dans l'emulateur de term.
    après avoir galéré 3h, j'ai trouvé qu'il fallait mettre

    export NCURSES_NO_UTF8_ACS=0

    dans un /etc/profile quelconque, sinon, on a pas les caracteres en forme de boites...
  • # Nouveau pépin et SAA7134

    Posté par . Évalué à 3.

    Petite FAQ pour le chip SAA7134 (Pinnacle PCTV Rave en l'occurrence).
    Dans le dernier noyau, 2.6.18, le module tda9887 n'existe plus en tant que tel.
    Ça nécessite de modifier les options des modules (/etc/modprobe.d ou équivalent) pour avoir un son correct.
    Avant : options tda9887 qss=1
    Après : options tuner qss=1
  • # bcm43xx: grosse régression

    Posté par . Évalué à 3.

    Salut.
    Juste pour vous dire que si vous utilisez ce pilote, un bug a été introduit dans le 2.6.18, qui freeze le système au bout de quelques minutes/heures.
    Je cite l'e-mail d'un développeur:

    There is a known bug. It will freeze the system.
    A fix will be available in 2.6.18.1.
    Until then, stick with 2.6.17.


    Apparemment, un problème de synchronisation:

    This patch fixes a bug in the bcm43xx driver in 2.6.18-rcX that hangs the machine due to improper
    locking. Between 2.6.17 and .18, longer portions of certain periodic work were made preemptible to
    improve latency, which is how this bug was introduced. It happens relatively infrequently - every 6
    - 10 hours, but when it does, the power button is the only possible recovery.
  • # Wifi sur Amilo

    Posté par . Évalué à 2.

    Pour ceux qui ont un Amilo, le module fsam7400 v0.4.1 ne se compile plus avec le noyau 2.6.18.
    J'ai contacté le développeur, Marcel Naziri (très sympatique au demeurant), et il a mis à dispo une mise à jour sur son blog, v0.5.0.

    Son projet sert à activer/désactiver la radio de la carte wireless sur les Amilo M7400, et il fonctionne également sur ma machine Amilo A1650G.

    http://linuxfr.org/~munshausen/22729.html
  • # Et dans la discrétion...

    Posté par . Évalué à 7.

    ... le pilote "pwc" pour les webcams Philips est revenu dans le noyau dans une version qui fonctionne !

    Pour rappel, il avait d'abord été retiré complètement parce qu'il contenait un module binaire pour le protocole de décompression depuis la webcam. Puis il avait été réintégré après avoir enlevé le module binaire, mais ne supportant plus les hautes résolutions par la même occasion. [1]

    Pour ma webcam pcvc840 (Philips Toucan II), ce module réintégré ne me donnait que du gris, mais point d'image...

    Dans le même temps, Luc Saillard développait une alternative [2].

    Dans le noyau version 2.6.18, le numéro de version du pilote pwc (1.0.12) correspond à la dernière fournie par Luc. À la lecture des sources, il semble que même le code de décompression (open-source cette fois) a été intégré. Ma webcam me fournit une image maintenant !

    Au départ, les version fournies par Luc avaient été critiquées parce qu'on avait supposé qu'il avait décompilé le binaire original plutôt que procédé par ingénieurie inverse. Cette supposition vient des tables de décompression que contient le pilote. Les sources contenues dans le noyau 2.6.18 contiennent ces tables, mais elles expliquent comment les obtenir mathématiquement, et pourquoi on les utilise (pour des questions de performances). Le doute semble donc être levé.

    Profitez bien de la vidéo-conférence ! [3]

    [1] http://linuxfr.org/2005/05/31/19026.html
    [2] http://www.saillard.org/linux/pwc/
    [3] http://tipote.free.fr/ekiga.png

Suivre le flux des commentaires

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