Avancées technologiques du prochain noyau Linux

Posté par  . Édité par Benoît Sibaud. Modéré par Fabien Penso.
Étiquettes :
0
25
avr.
2003
Noyau
Voici un petit récapitulatif des avancées technologiques du futur noyau Linux 2.6. Après de grands débats au sein de la lkml (liste de discussion du développement Linux), la décision a été prise de favoriser tout autant les utilisateurs finaux que les administrateurs de gros systèmes. Linus Torvalds étant plus intéressé par les performances brutes du noyau que par sa réactivité, les grandes orientations du développement concernaient surtout les gros systèmes. Ainsi, un nouvel ordonnanceur de tâches, nommé O(1), a fait son apparition. Celui-ci tient beaucoup mieux la charge quand de nombreuses tâches concurrentes s'exécutent, et priviligie une répartition équitable du temps de calcul entre celles-ci. De même, le futur noyau sera capable de gérer plus de 4 Go de mémoire physique sur des machines x86 32 bits.

Sous la pression des développeurs d'application sonores, l'intéractivité du nouveau noyau a été largement améliorée, ce qui ne devait pas être le cas dans un premier temps. Ainsi, des modifications visant à diminuer le temps d'exécution des appels systèmes (patchs low-latency et preempt) ont été apportées. De plus, la granularité de l'horloge est passée de 10 ms à 1 ms. Grosse nouveauté, l'intégration de l'architecture ALSA en lieu et place d'OSS fournit un système avancé de gestion des cartes sons, et permet d'envisager l'utilisation d'applications audio exigeantes (traitement temps-réel d'effets). On ne pourra plus dire que les jeux sous GNU/Linux sont moins fluides que chez les concurrents.

Une dernière amélioration très importante est l'incorporation d'un ordonnanceur intelligent des accès aux disques durs. Celui-ci limite très largement les déplacements de la tête de lecture du disque, et apporte des débits élevés en cas d'accès concurrents. Ceci sera autant bénéfique pour les serveurs de fichiers que pour les utilisateurs finaux : cela permet les copies de fichiers coucurrentes, les lancements d'applications en parallèle sans perte d'efficacité dans l'utilisation des ressources.

Cette liste est très loin d'être exhaustive, je n'ai pas abordé le nouveau système de configuration, la VM...

Aller plus loin

  • # Re: Avancées technologiques du prochain Kernel

    Posté par  . Évalué à 2.

    On attends tous ca avec impatience.

    Une date est prévue ?
    Non c'était pas la bonne question :)

    • [^] # Re: Avancées technologiques du prochain Kernel

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

      lol

    • [^] # Re: Avancées technologiques du prochain Kernel

      Posté par  . Évalué à 10.

      Bah si ils veulent mettre tout plein de "features", aussi bien pour les serveurs que les stations de travail, ils ont intérêt a pas trop avancer de date :-) mais bon jusque là les versions du kernel ont su se faire attendre, et Linus ou Marcello doivent avoir une bonne vision d'ensemble qui, avec leur experience, peuvent leur permettre d'annoncer (ou justement de ne pas annoncer) de date.

      Juste un ptit mot sur le "scheduler O(1)" c'est pas qu'il s'appelle vraiment comme ca, mais c'est qu'en terme de complexité il est en O(1), c'est a dire qu'il prends un temps identique pour faire son boulot, qu'il y ait 1 ou 5000 processus.

      • [^] # Re: Avancées technologiques du prochain Kernel

        Posté par  . Évalué à -2.

        qu'il prends un temps identique pour faire son boulot
        Ah non, ça c'est O(0).
        O(1), c'est un temps proportionnel au nombre de processus.

        • [^] # Re: Avancées technologiques du prochain Kernel

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

          Sauf que O(0), ça veut dire 0, d'après la définition mathématique de O. Donc tu es en train de dire que ça ne prend pas de temps du tout, ce qui est bien sûr faux. Dans les évaluations d'algorithmes, on considère un ou plusieurs paramètres (ici, n le nombre de processus) et on estime le temps de calcul en fonction de ces paramètres. Puis on donne un comportement asymptotique (i.e., quand les paramètres deviennent "grands"). Ici, le scheduler est en O(1) c'est-à-dire qu'il ne dépend pas du nombre de processus n. Si le temps était proportionnel au nombre de processus, on aurait du O(n).

          Pour mémoire, on dit qu'une fonction positive f(n) est O(g(n)) s'il existe une constante C et un entier N tels f(n) < Cg(n) pour n>=N.

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 2.

            Bah les notations sont visiblement pas les memes d'une discipline a l'autre.
            Par chez moi j'ai toujours vu
            O(n^0) note O(0)
            O(n^1) note O(1)
            etc..
            et, a l'oral: <<d'ordre 0 en n>> et <<d'ordre 1 en n>>

            Il faut croire qu'en informatique, les notations sont plutot
            O(n^0) note O(1)
            O(n^1) note... O(n^1) aussi, je suppose
            mais ca doit etre plus lourd a prononcer a l'oral, non ?

            Alors finalement, ce scheduler, et avec une notation sans equivoque, il est en O(n^0) ou en O(n^1) ??

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              c'est une notion mathématique. Je te rappelle que par convention n^0 vaut 1. Donc la notation est sans équivoque O(n^0) = O(1)

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              En O(n^0).

              Pour ce qui est de l'oral, on se comprend parfaitement en parlant de de temps constant pour O(1), temps lineaire pour O(n), temps quadratique pour O(n^2), polynomial pour O(P(n)), exponentiel, factoriel, ... en fonction de la taille n des donnees.

  • # Re: Avancées technologiques du prochain Kernel

    Posté par  . Évalué à 5.

    De même, le futur noyau sera capable de gérer plus de 4 Go de mémoire physique sur des machines x86 32 bits
    Il me semble que les noyaux Suse les gère déjà depuis un bon moment (la 7.1 avec un kernel 2.4.0 si mes souvenir sont bons).
    J'ignore en revanche comment Suse gère au niveau juridique ses modifications.

  • # 2 liens supplémentaires

    Posté par  . Évalué à 10.

    1- le "kernel status", un "changelog" du noyau, où l'on peut aussi voir ce qui reste à intégrer pour le 2.6
    http://kernelnewbies.org/status/(...)

    2- le "What to expect" de ave Jones, ou la liste détaillée des principaux changements entre 2.4 et 2.6
    http://www.codemonkey.org.uk/post-halloween-2.5.txt(...)

  • # Re: Avancées technologiques du prochain Kernel

    Posté par  . Évalué à 8.

    O(1) n'est pas le nom de l'ordonanceur, mais la complexité de l'algorithme utilisé qui est lineaire ( ordre 1), et donc monte en charge de maniére bien plus efficasse.

    Cinon je vois pas le rapport entre Alsa, le pas d'horloge de l'ordonanceur et la rapidité des jeux.

    Apres la VM encore plus efficasse ou enfint au point, le nouveaux systéme de droits etandues, et quelques belle choses en previsions.

    • [^] # Re: Avancées technologiques du prochain Kernel

      Posté par  . Évalué à 3.

      Oups, O(1) c'est de complexité fixe, mea culpa ( c'est O(n) la complexité lineaire ).
      tous le monde aura corrigé de lui méme :-)

    • [^] # Re: Avancées technologiques du prochain Kernel

      Posté par  . Évalué à 2.

      J'veux pas te "Vexee_Berretta" (ohoh :) ) mais t'as une orthographe monstrueuse!

      aie mes n'oeils! :p

      • [^] # Re: Avancées technologiques du prochain Kernel

        Posté par  . Évalué à 2.

        Vue que tu es nouveau tu ne connais pas ma signature, qui a disparue avec la nouvelle version de DLF:

        --
        Les fautes d'orthographes sus-citées sont déposées auprès de leurs
        propriétaires respectifs. Aucune responsabilité n'est engagé sur
        la lisibilité du message ou les éventuelles dommages qu'il peut
        engendrer. Beretta Vexée

        Pour ta gouverne, je fais de plus en plus d'effort avent (2-3 ans), mes messages étaient completements incompréhensibles, j'admets que j'ai encore beaucoup de progres a faire?

        • [^] # Re: Avancées technologiques du prochain Kernel

          Posté par  . Évalué à 5.

          j'admets que j'ai encore beaucoup de progres a faire?

          C'est vraiment une question?

        • [^] # Re: Avancées technologiques du prochain Kernel

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

          Il faudrait aussi que l'Académie française fasse l'effort de simplifier le français. Son apprentissage demande un effort excessif.

          L'Éducation Nationale, après avoir raté l'enseignement du français pendant 40 ans grâce à la méthode globale, a promis de faire un effort.

          Beretta_Vexee a fait un gros effort, c'est vrai et je je certifie. Il faudrait que les deux autres en fassent autant ;-)

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 5.

            Hum, y a pas trop de raison de simplifier le francais.
            Mon arriére grand mére apprenait le francais, a des enfants qui n'en parlait pas un mot ou presque et pourtant a 6 ans il faisait moin de fautes que moin en rentrant au lycée ( cahier d'époque a l'appuis ).

            Donc oui y a eux un réel probléme avec l'apprenticage du francais, pendant des années et je ne pence pas malheureusement étre le seul dans ce cas. Et encore j'ai eux la chance d'avoir de la famille pour m'apprendre B A BA, apres mais une fois que le mal est fait ...

            C'est evidant que j'ai beaucoup plus de mal a me corriger maintenant, mais je pence pas que l'accademie soit en cause :-).

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              Nan serieux, t'as fait expres d'exagerer la, rassures moi ?

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              En fait, à la vue d'autant de fautes et surtout du fait que le commentaire était assez intéressent, j'pensais que tu le faisais exprès, avec quoi comme objectif??j'en sais rien... enfin remarquez, on aurait pu croire qu'il le faisait à titre d'exemple - y en a qui l'ont déjà fait - afin de montrer à quel point c'est MOCHE une ortho pareille!
              Et puis l'orthographe est un thème récurrent sur LinuxFr, ça m'a conforté dans mon idée, je sais c'est tiré par les cheuveux. ;-)

              tu peux remmettre ta signature va, je suis pas hyper nouveau mais si moi j't'en ai fait la remarque d'autres suivront. ( pourtant je ne suis pas aussi pointilleux, et je suis même le premier à gueuler sur le gars qui fait une remarque reloud parc'que un modéro a oublié un accent ou a fait un mauvais accord)

              Bon Mea Culpa si le français n'est pas ta langue maternelle, ceci étant dit ce n'est pas la mienne non plus.

              bye


              ma nouvelle signature? "ma logique n'est pas celle de tout le monde." ou J'réfléchis trop ^_^

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 5.

              Bon on va rentrer dans des considérations intimes et parler de dyslexie mais là j'ai un brin d'expérience personelle et professionelle (un frére et au moins un ancien étudiant concerné).
              C'est un des gros ratés de l'Educ' Nat' au cours des dernières décades, l'identification comme la prise en charge des enfants concernés étant très faibles. Si cette problèmatique est peut-être entrée dans la formation des maîtres récemment, il reste patent que de nombreux écoliers et lycéens ont subi les conséquences de cette affection. Les conséquences c'est la culpabilisation, la dépréciation de soi (" je suis un nul") voire le déni ("tout va bien, j'ai pas de raison de consulter"). au final souvent aussi l'échec scolaire et des difficultés professionnelles

              Alors il faut le redire (genre le médecin de France-Info pour le ton ;) les dyslexiques ne sont ni des débiles ni des attardés mais ils souffrent d'un handicap et ce handicap se traite avec du temps. D'autant que les orthophonistes ne sont ni des marabouts ni des sophrologues...Quant au choix : Ton toubib est ton ami et il est là pour te conseiller.

              J'ai trouvé ce site (sans garantie sur le sérieux de l'organisme ou des concepteurs)

              http://www.orthophonistes.fr/index.php?Menu=1(...)

              Ceci étant il fait bonne impression. Pourquoi ça ? Parcequ'il y a une référence aux obligations de déclaration à la CNIL des fichiers clients. Il suffit de pas grand chose pour rendre un juriste heureux...:)
              En tout cas, ça peut servir pour se dégrossir les idées...

              yojik
              --
              communication personelle : Mes amis Olivier & Christelle ont eu un fils hier, Hip Hip Hourra pour le petit Axel !! je me sens déjà tout tonton....

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              Tu peux l'avouer, si t'es un gars t'as fait une faute d'accord dans ton pseudo ? ;)

              • [^] # Re: Avancées technologiques du prochain Kernel

                Posté par  . Évalué à 2.

                Ca je l'ai jamais caché, je suis un Homme viril et tous et tous.
                Beretta Vexée, c'est une grosse reference a un personnage de BD et a mes premiers delirs sur IRC, vue que le pseudo était original il m'est resté.

    • [^] # Re: Avancées technologiques du prochain Kernel

      Posté par  . Évalué à 4.

      O(1) n'est pas linéaire mais constant.

      • [^] # Re: Avancées technologiques du prochain Kernel

        Posté par  . Évalué à 1.

        En fait, qu'est ce qui est constant ?

        La complexité de l'algo, ou l'évolution de sa complexité par rapport à sa charge (sa derivation quoi )???

        ou puis-je me renseigner pour comprendre ce jargon ? (j'en ai + ou - besoin pour mon taffe)

        • [^] # Re: Avancées technologiques du prochain Kernel

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

          La complexité de l'algo, ou l'évolution de sa complexité par rapport à sa charge (sa derivation quoi )???

          La complexité c'est, justement, le 'O(x)', et ça indique la croissance du temps mis à accomplir la tache en fonction du nombre de données.

          O(1) => temps constant quelque soit la quantité de données
          O(n) => temps croissant linéairement avec la quantité de données
          Les autres complexités fréquemment rencontrées sont O(N^2), O(exp(n)), O(ln(n)) et O(n ln(n)) (si ma mémoire est bonne, ça fait un bail que j'ai étudié ça en fac :-).

          Par exemple un algo en O(n^2) qui met 3 secondes pour processer un tableau de 100 entiers mettra 9 secondes pour en processer 200.

          Si je me souviens bien on avait démontré qu'un algo de tri était au mieux en O(n ln(n)).

          ou puis-je me renseigner pour comprendre ce jargon ?

          C'est pas un jargon, c'est de la théorie algorithmique de base, tu trouvera ça dans n'importe quel bouquin de cours sur le sujet.

          • [^] # Re: Avancées technologiques du prochain Kernel

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

            > Par exemple un algo en O(n^2) qui met 3 secondes pour processer un > tableau de 100 entiers mettra 9 secondes pour en processer 200.

            Non: le facteur constant de la majoration intervient dans les
            trois secondes.

            --
            Ueimor

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 2.

              oui,
              en fait, cette notation viens de developpements limités (IIRC, c'est vieu..)
              et en fait on ne parle pas d'egalité mais plutot d'ordre..
              et on note dans le petit o, la puissance de n la plus importante, par exemple si l'algo est en n^4+n+3 on note o(n^4)
              tout ca pour revenir sur ce que dit francois, si l'algo consome 3 secondes, en o(n^2) pour 100 items, en fait la partie constante peut a elle seule en prendre, par exemple 1 seconde.. (oui j'exagere)
              donc seule 2 secondes on été consomé par la partie variable.


              En tout cas, avec un algo o(1) on a atteint la puissante 0 (n^0=1), impressionant !

              • [^] # Re: Avancées technologiques du prochain Kernel

                Posté par  . Évalué à 5.

                Tu confonds O(f(x)) et o(f(x)).

                O(f(x)) c'est «du même ordre que f(x)»
                o(f(x)) c'est «négligeable devant f(x)»

                Par exemple en +infini
                -3x^2+2x-1 = O(x^2)
                -3x^2+2x-1 = O(x^3)

                Dans un dvl limité on peut utliser les deux

                (1) exp(x) = 1 + x + o(x) (en 0)
                (2) exp(x) = 1 + x + O(x^2) (en 0)

                (1) signifie «plus un terme négligeable devant x»
                (2) signifie «plus un terme d'ordre x^2»

                • [^] # Re: Avancées technologiques du prochain Kernel

                  Posté par  . Évalué à 2.

                  Petite correction (en espérant qu'on parle le même langage):

                  o(f(x)) est effectivement "négligeable devant f(x)"

                  O(f(x)) signifie "dominé par f(x)" (i.e. (je sens que je vais me planter, c'est loin tout ça) ton truc / f(x) borné aux alentours du point considéré, par exemple x -> +inf)

                  Et pour le "du même ordre", on utilise le theta grec majuscule (O avec une barre horizontale au milieu), défini par une "dominance" (cf ci-dessus) mutuelle: g est O(f) et f est O(g)

                  En pratique, le post parent reste vrai -- mais le O autorise un "terme suivant" nul, contrairement au Theta.
                  Je me relis et me trouve passablement pas clair, alors je vais reprendre les exemples.

                  En 0:
                  (1) exp x = 1 + x + o(x) "plus un terme négligeable devant x"
                  (2) exp x = 1 + x + O(x^2) "plus un terme dominé par x^2"
                  (3) exp x = 1 + x + Theta(x^2) "plus un terme d'ordre x^2"

                  Entre O et Theta, Theta contient une information mathématique plus forte, mais O a un plus grand intérêt (ça va durer moins longtemps ;)

            • [^] # Re: Avancées technologiques du prochain Kernel

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

              Oups oui, exact. Disons pour être plus général que si tu traces la courbe du temps mis à s'executer en fonction du nombre de données, tu obtiens plus ou moins une courbe en x^2 (sachant que, comme le dit Fabien, on ne tient compte que de la fonction ayant la croissance la plus forte).

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 4.

              Eh non! Les équivalences, ordres et negligeabilites pour les suites (c'est de ça qu'on parle), ça se passe à l'infini. Quand t(n) est le temps pour traiter n données, que l'algo soit en O(n) veut dire t(n)/n borné sur un voisinage de l'infini.
              Et n'en déplaise à certains, 100 ou 200 c'est pas encore tout à fait l'infini.
              C'est d'ailleurs le problème. Un algo extra sensass en O(1) peut très bien être super merdique : imagine que le temps soit du type constant égal à 10^100^100 ( unités je-sais-pas-quoi). L'algo est en O(1) mais ça veut pas dire grand chose.
              Mais là c'est pas très parlant. Imagine un algo en O(ln n). Je crois que c'est considéré comme pas mal. Seulement, pour n<10000, il s'écrit e^n+n^321 et ensuite c'est e^10000+10000^321+ln n. C'est bien pour les grosses quantités de données, mais faut pas l'utiliser si tu en a 10.

              La notation O(n^2) ne présage rien du comportement entre 100 et 200

              Le rabat joie de service

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 3.

            Par exemple un algo en O(n^2) qui met 3 secondes pour processer un tableau de 100 entiers mettra 9 secondes pour en processer 200.
            non il metra 12 secondes.
            (2*n)^2 = 4 * n^2

            Pour un algo linéaire, quand on a x fois plus de données ça prend x fois plus de temps. exemple: une addition de tableaux de x elements.
            Pour un algo quadratique (O(n^2)), quand on a x fois plus de données ça prend x^2 fois plus de temps. Exemple: un tris de listes "naif" (genre tris à bulle)
            Pour un algo exponetiel (O(exp(n)) quand on a x fois plus de données on va se tirer une balle ;-). Exemple le voyageur de commerce ou comment trouver le plus cours chemin passant par n points.
            Pour un algo en temps constant, quelque fois l'augmentation du nb de données, le temps reste le même.
            Les algo en O(n*ln n) sont les tris de listes intelligents (merge sort, quick sort, ...).

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 2.

              non il metra 12 secondes.
              (2*n)^2 = 4 * n^2

              Non, voir message de François Romieu ci-dessus. Le O(N*N) décrit le comportement asymptotique, pas la formule exacte du temps d'exécution.

              • [^] # Re: Avancées technologiques du prochain Kernel

                Posté par  . Évalué à 2.

                Oui, bien sure.
                On considére que 100 «c'est suffisament grand pour que l'on puisse négliger les autres termes»
                Evidament c'est un peu plus compliqué que ça. Mais quand on fait de la complexité on s'en fout, on veut juste voir comment ça se comporte lorsque ça devient grand.

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 1.

            > Si je me souviens bien on avait démontré qu'un algo de tri était au mieux en O(n ln(n)).

            Avec des hypothèses, tout de même.
            Parce que si on ne trie que des entiers de 32bits (ou toute autre taille bornée), on peut alors avoir un tri linéraire (tri radix par exemple). Une recherche très rapide sur google m'a donné : http://fr.wikipedia.org/wiki/Tri(...)

            En archi, on forme aussi des réseaux de tri qui font leur boulot en temps linéraire.

            La borne donnée n'est valable que pour les tris basés sur des comparaisons successives.

            • [^] # Re: Avancées technologiques du prochain Kernel

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

              Je vois le tri auquel tu fais référence, mais ça ne doit pas être le tri radix:
              http://www.google.fr/search?q=cache:4xe9pdvdITAC:michel.giacomazzi.(...)
              -> il fait n_bits*n parcours de la liste

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              Parce que si on ne trie que des entiers de 32bits (ou toute autre taille bornée)

              Vaut mieux que la taille soit petite, à moins d'avoir beaucoup beaucoup de mémoire rapide (un CPU à 4 Go de mémoire cache ?). En pratique, on se limitera à 16 bits plutôt que 32 ;)

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 3.

              Ah oui :

              En archi, on forme aussi des réseaux de tri qui font leur boulot en temps linéraire.

              Ca ne change rien à la complexité algorithmique. Parler de temps d'exécution est un abus de langage quand on dit O(f(N)). O(f(N)) désigne le nombre d'opérations élémentaires nécessaire à la résolution du problème. Avec certaines architectures matérielles (parallélisme...) il est possible d'obtenir un "temps linéaire" alors que la complexité est quadratique. C'est un truc similaire qu'a utilisé DJ Bernstein pour essayer de démontrer qu'il sait diminuer la "complexité" de cassage du RSA (le fameux article qui fit du bruit il y a quelques mois...).

        • [^] # Re: Avancées technologiques du prochain Kernel

          Posté par  . Évalué à 7.

          Rapidement, la complexite c'est le nombre de fois que la boucle principale de ton applis va s'executer pour faire le travail que tu lui a demande. On utilise souvent n comme symbole du nombre d'elements a traiter.


          Donc pour n elements a traiter (ou un element de taille n suivant les cas)

          --- complexite constante-----
          O(1) = On n'apelle qu'une seule fois la fonction, le nombre d'appels a la fonction ne depend pas du nombre d'elements a traiter (ou de la taille de l'element suivant les cas)
          O(x) = On apelle x fois la fonction

          ---complexite logarithmique---
          O(log(n)) = on apelle log(n) fois la fonction (souvent le cas du divide and conquer)

          ---complexite lineaire---
          O(n) = On apelle n fois la fonction (le plus souvent une fois par element)

          ---complexite polynomiale d'ordre k---
          O(n^k) = On apelle n puissance k fois la fonction (tres lent, c'est souvent le genre de complexite des AI).

          ---complexite exponentielle (de base k)---
          O(k^n) = on apelle k puissance n fois la fonction (Cassage de clef RSA, bonne chance au fait :) )

          Voila vite fait les principales complexites. Bine sur on peut avoir des complexites de type O(k^n+2n^k+4) mais ca veut pas dire grand chose, la plupart du temps on se contente du plus grand facteur (sauf pinaillage et temps reel ric-rac).

          Kha

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 5.

            Petite remarque:
            O(1000000 n) = O(n)
            O(k^2 + 100 k) = O(k^2)
            On garde que le terme de plus haut degré (dans les expressions polynomiales) sinon que le terme qui «croit le plus vite».

            F(x) = O(g(x)) <=>
            Il existe K tel que F(x)<=K*g(x) pour x assez grand.

            Donc pour g(x) on vire la constante devant et tout ce qui sert à rien. On s'arrange pour que g(x) soit le plus simple possible.

            Pour être plus précis on peut utiliser un ~ (équivalance).
            On a alors (en simplifiant un peu, car on néglige le cas ou g(x) prend parfois 0)
            F(x) ~ g(x) <=> F(x)/g(x) -> 1

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 0.

              On garde que le terme de plus haut degré (dans les expressions polynomiales) sinon que le terme qui «croit le plus vite».

              C'est un peu ce que j'ai essaye de dire dans mon dernier paragraphe, meme si en fait O(4) et O(6n) ne sont pas si peu frequents que cela.

              Par contre
              F(x)~g(x) <=> limite lorsque x tend vers plus l'infini de (F(x)/g(x)=1)

              kha

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 1.

              > F(x) = O(g(x)) <=>
              > Il existe K tel que F(x)<=K*g(x) pour x assez grand.

              Ou alors (c'est peut être plus parlant) F/g est bornée sur un voisinage de +infini.
              (par contre il faut préciser où. On peut faire la même chose en -infini, ou pourquoi pas en 1, en -2 ou en pi. Et dire que g n'est jamais nulle sur un voisinage de l'infini)

          • [^] # Re: Avancées technologiques du prochain Kernel

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

            Rapidement, la complexite c'est le nombre de fois que la boucle principale de ton applis va s'executer pour faire le travail que tu lui a demande. On utilise souvent n comme symbole du nombre d'elements a traiter.


            Très rapidement alors. Parce qu'avec les problèmes d'accès à la mémoire (induits par la structure hiérarchique des CPU modernes), tu peux écrire deux programmes avec une "boucle principale" qui s'exécute autant de fois sans que les complexités réelles soient les mêmes...

        • [^] # Re: Avancées technologiques du prochain Kernel

          Posté par  . Évalué à 5.

          En fait, qu'est ce qui est constant ?
          La complexité de l'algo, ou l'évolution de sa complexité par rapport à sa charge (sa derivation quoi )???

          Sa complexité rapportée à la taille des données. Si un algo est en O(N), cela veut dire que le nombre d'opérations nécessitées pour sa résolution est proportionnel à la taille des données traitées. Attention : on parle de pire cas ! Ainsi, un "tri rapide" est en O(N*N), bien que statistiquement les temps d'exécution soient plutôt proportionnels à N*log(N). Autre écueil : ne pas confondre "taille des données" (en bits) et "nombre de valeurs possibles".

          La définition rigoureuse est (si je ne me trompe) :

          Un algo est dit « de complexité O(f(N)) » si et seulement si :
          il existe un entier M > 0, il existe un réel K > 0, tels que
          pour tout entier N supérieur à M, pour tout jeu de données de taille N,
          le nombre d'opérations nécessaire à l'exécution de l'algorithme est inférieur à K*f(N)

          Il s'agit donc de pire cas asymptotique. Note : on parle de "résolution de problème" plutôt que d'"exécution d'algorithme" en général, sachant qu'on s'intéresse à un problème plus souvent qu'à un algorithme spécifique.


          ou puis-je me renseigner pour comprendre ce jargon ?

          Tu as intérêt à trouver un bouquin ou un cours de mathématiques appliquées, version débutant. Tu y trouveras toutes les bases de l'algorithmique et de la complexité des problèmes. Tu y feras également connaissance avec la célèbre machine de Turing, et ses éventuelles déclinaisons : machine de Turing avec oracle (non pas la base de données)...

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 4.

            La notion de complexité est assez relative, generalement les informaticiens "purs" (les chercheurs en informatique) s'interressent a la complexite asymptotique, donc pour faire simple la complexite "moyenne". Les informaticiens qui pratiquent sur des donnees reelles donc de taille non infinie regardent plutot le pire des cas ou une esperance calculee pour leur volume de donnee. Le resultat pouvant parfois etre tres differents.

            • [^] # Complexité asymptotique

              Posté par  . Évalué à 3.

              Les théoriciens (en tous cas, ceux qui travaillent dans le même labo que moi) ont plutôt tendance à envisager la complexité dans le pire des cas, parce que sur la plupart des problèmes combinatoires "difficiles" (ceux qui se situent dans la transition de phase), elle est proche de la complexité en pratique: si ton problème n'est ni trivialement soluble ni trivialement insoluble, il y a de gros risques pour que tu sois obligé d'explorer une bonne partie de l'espace de recherche avant de pouvoir répondre.

              Mais pour grossir le trait, on peut séparer les problèmes en deux catégories: ceux qui sont NP-difficiles (par exemple le voyageur de commerce), et dont la résolution prend dans le pire des cas un temps exponentiel dans la taille de la donnée initiale, et ceux qui se contentent d'un traitement polynomial. Pour ces derniers, on peut raffiner un peu, calculer la complexité en moyenne, l'espérance de solution, tout ça... parce qu'il faut bien comprendre que même si c'est polynomial, n^4 ça commence à devenir pénible. Pour les premiers, en revanche, on a trois solutions: soit on trouve des traitements polynomiaux pour réduire l'espace de recherche, soit on réussit à approximer la réponse à un facteur constant près en temps polynomial (c'est à dire qu'on sait donner "rapidement" une solution dont on peut garantir qu'elle n'est, par exemple, pas à plus de 50% de la meilleure solution possible), soit... on rame.

              • [^] # Re: Complexité asymptotique

                Posté par  . Évalué à 1.

                Je completerais ta vision "theorique" de la complexite par une autre vision :

                La complexite au pire cas n'est pas toujours adapte, on prefere parfois une complexite qui depend de la complexite de la sortie (notamment en geometrie algorithmique). Imagine que tu souhaites calculer les intersections de n segments. La complexite au pire est superieure ou egal a o(n^2) car il peut y avoir o(n^2) intersections, l'algoritme brutal en o(n^2) (tester tous les segments deux a deux) est bon relativement au critere du pire cas. En pratique on lui prefera un algorithme en o(n.log(n) + k) ou k est le nombre d'intersections ou meme en o((n+k).log(n)) car il est plus simple.

                parce qu'il faut bien comprendre que même si c'est polynomial, n^4 ça commence à devenir pénible.

                En pratique, pour bien des problemes on considere qu'au dessus de o(n^2) c'est limite (et meme souvent au dessous), un jour ou l'autre on tombera sur une instance qui fera que ca va ramer.

                Pour les problemes NP-difficiles, soit on trouve des traitements polynomiaux pour réduire l'espace de recherche, soit on réussit à approximer la réponse à un facteur constant près en temps polynomial (c'est à dire qu'on sait donner "rapidement" une solution dont on peut garantir qu'elle n'est, par exemple, pas à plus de 50% de la meilleure solution possible), soit... on rame.

                En pratique, les problemes d'optimisation reelles sont souvent NP-difficiles meme si l'on restreint enormement les instances et meme si l'on neglige certaines contraintes importantes. Les criteres d'optimisation sont eux multiples. Par contre, la recherche de l'optimalite n'a que d'importance, il s'agit de trouver une solution acceptable (50% de la solution optiomale, c'est souvent inacceptable en pratique, pour un voyage de commerce pex) et en tout etat de cause meilleure que les solutions existantes (ou concurrentes).

            • [^] # Re: Avancées technologiques du prochain Kernel

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

              Je ne comprends pas trop ta distinction. Le calcul dans le cas le pire et le calcul en moyenne sont toujours résumés par des équivalents asymptotiques du genre 0(n^2). Les résumés en question n'ont rien à voir avec le fait qu(on calcule la complexité dans le cas le pire ou en moyenne. Il se trouve simplement que le calcul en moyenne est en général beaucoup plus difficile à faire que le calcul dans le cas le pire (qui lui est relativement trivial pour un algorithme donné).

          • [^] # Re: Avancées technologiques du prochain Kernel

            Posté par  . Évalué à 1.

            merci, c'est juste le jargon qui me gene.

            donc pour N grand, si on a un algo en O(n^2) ou O(2) (T est pour le temps) :

            T(n+1) -> T(n)*n <=> T(n+1) -> C*n²


            pour N grand, si on a un algo en O(n) ou O(1) :

            T(n+1) -> T(n)*C <=> T(n+1) -> C*n

            Donc on tend pas vers un temps constant.

            • [^] # Re: Avancées technologiques du prochain Kernel

              Posté par  . Évalué à 2.

              Non pas exactement :
              - O(n*n) est un "temps quadratique" (abus de langage, il s'agit de complexité, voir d'autres posts)
              - O(n) est un "temps linéaire"
              - O(1) est un "temps constant" (pas du tout la même chose que O(n) !)
              - O(2) est équivalent à O(1) (les constantes multiplicatives sont ignorées, grâce à la "constante K" dans la définition que j'ai donnée) qui est la notation conventionnellement utilisée

              O(1) peut paraître bizarre, mais c'est en fait relativement courant. On peut le retrouver par exemple dans les structures à bases de tables hash (à la condition que la répartition soit parfaite ;-)), ou d'autres cas (par exemple récupérer le plus petit élément d'un ensemble déjà trié, comme un std::set en C++...).

        • [^] # Re: Avancées technologiques du prochain Kernel

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

          Une petite remarque pour compléter les réponses précédentes : les CPU modernes, l'accès à la mémoire est tellement étrange (à cause des caches) que la complexité en opérations n'est pas toujours très utile pour évaluer un algorithme. Par exemple, si tu fais un produit de matrice par matrice, la complexité en opérations (nombre de multiplications et d'additions) est en O(n^3) (on peut faire beaucoup mieux, mais c'est très compliqué et je n'ai pas envie d'entrer dans les détails, et de plus c'est délicat à mettre en oeuvre). Si tu programmes ça de façon classique, les accès à la mémoire sont aussi en O(n^3), c'est à dire que tu demandes à la mémoire O(n^3) fois un double. Or, tu peux t'arranger pour descendre à O(n^2). Pour des matrices de taille classique, c'est de coût qui domine largement le temps de calcul (malgré la théorie !) et le passage de n^3 à n^2 pour les accès peut réduire drastiquement le temps de calcul. Cf les papiers sur ATLAS : http://math-atlas.sourceforge.net/(...)

    • [^] # Re: Avancées technologiques du prochain Kernel

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

      Pour ceux qui voudraient des informations plus detaillé (technique) sur la maniere dont fonctionne ce type d'algorithme:

      http://www.ncl.cs.columbia.edu/publications/usenix2001_vtrr.pdf(...)

      Le seul truc c'est que je ne sais pas si c'est exactement le meme algo qui est utilisé dans le noyau 2.5

  • # Avancées technologiques du prochain Kernel backportées

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

    Le preempt et low latency patch sont installés dans le noyau 2.4 de pas mal de distribs par défaut me semble-t-il, non ?

    Idem, d'autres patches sont backportés, non ?

  • # Re: Avancées technologiques du prochain Kernel

    Posté par  . Évalué à 9.

    C'est vrai qu'entre le support quasi parfait de l'ACPI (malgre certains problemes en mode APM+ACPI) et les boosts assez magiques apportes par les patchs preemptifs on peut avoir une certaines impatience.

    Neamoins la question que tout le monde se pose reste "Est-ce que le noyeau 2.6 va etre le noyeau grand public ?". Bien que les ameliorations apportes au systeme touchent autant les admins que les utilisateurs finaux, on est plus tres loin d'avoir un noyeau pleinement fontionnel, facile a configurer et eficace.

    Je joue depuis un moment avec les noyeaux 2.5.6x et je dois reconnaitre que la notion meme de module ne veut plus dire grand chose. On peut tout fourer dans le kernel en bloc et ca fonctionne de base. Les progres des liaisons USB et FireWire sont aussi tres encourageantes.

    Par contre avec le changement de la gestion des threads, les modification sur le systeme de modules, et les systemes preemptif et faible latence tout le monde attend la VM avec un peu d'apprehension, surtout que ca avait ete le gros ratage du 2.4

    Kha

    • [^] # Re: Avancées technologiques du prochain Kernel

      Posté par  . Évalué à 0.

      Euh... je suis p-e inculte mais c'est quoi la "VM" ?

      Autre question qui n'a strictement rien à voir : les post qui sont "cachés" car jugés initéssants : comment ça marche ?

      JR.

      • [^] # Re: Avancées technologiques du prochain Kernel

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

        Hmmm, là je ne vais pas t'éclairer beaucoup en disant que c'est "Virtual Machine" mais comme je n'en sais guère plus (du moins pas certain), je préfère me taire et attendre sagement les explications plus éclairées de quelqu'un d'autre...

        Pour ce qui est des posts par contre, les posts cachés sont ceux qui ont un score inférieur à 0, donc mal notés et à priori inintéressants. Je dis bien à priori :) Rien ne vaut de se faire bien sûr une idée par soi-même.

      • [^] # Re: Avancées technologiques du prochain Kernel

        Posté par  . Évalué à 10.

        "VM" veut dire "virtual memory", qui est une abréviation pour "Linux Virtual Memory Manager", qu'on pourrait traduire par "gestionnaire de la mémoire virtuelle de Linux".

        Très grossièrement, il s'agit de l'ensemble des fonctions et algos internes au noyau Linux qui gèrent à la fois l'allocation de "morceaux" de la mémoire physique ou du swap aux différents processus d'un système, mais aussi tente d'anticiper les besoins de l'utilisateur de la manière à la fois la plus souple et la plus efficace possible. La "bonne" manière de gérer la mémoire fait toujours l'objet de débats houleux, car les besoins et logiques de fonctionnement d'un serveur ronronnant ou d'une station de travail lançant à tout bout de champs des applications diverses ne sont pas les mêmes. Par ailleurs, des algos trop sophistiqués ne peuvent être utilisés, parce qu'ils seraient trop coûteux en temps CPU, et qu'il n'est pas envisageable de lancer des calculs faramineux simplement pour décider où ranger une donnée en mémoire : donc, le sujet est à la fois complexe et très intéressant, mais très ardu pour le néophyte.

        à l'époque des 2.0, on admettait comme une fatalité le fait que quand linux swappait, ça "grippait" un peu, ou que quand il n'y avait pas assez de mémoire pour lancer d'énormes applis, on obtenait des résultats un peu troublants. Depuis 2.2, mais surtout 2.4, on essaie de faire mieux, avec plus ou moins de bonheur.

        Si tu as _beaucoup_ de courage (et du temps), tu peux éventuellement t'attaquer à :

        http://www.csn.ul.ie/~mel/projects/vm/guide/html/understand/(...)

        avec une boîte d'aspirine et cinquante litres de café (mais note quand même que ce document est en partie obsolète dans ses détails).

      • [^] # Re: Avancées technologiques du prochain Kernel

        Posté par  . Évalué à 6.

        La VM (Virtal Mémory) est une couche d'abstraction (une boite noire) entre d'une part la mémoire RAM c-a-d tes barettes, l'espace disque utilisé pour stocker temporairement des bouts du contenu de cette mémoire (des pages), et d'autre part les applications qui y font appel (gimp par exemple)

        Le problème est que le disque dur, bien que pratique pour suppléer à un manque de RAM (ça coute moins cher au Mo) est BEAUCOUP plus lent que cette dernière.

        Il est donc primordial que les algorithmes d'échange RAM<->Disque soient le plus optimisés possibles.

        Seulement, dans les premières version du 2.4, ils étaient... euh... comment dire ... tout pourris.

        En ce qui concerne le plussoiement/moinzuntage, on peut quand meme faire apparaître le post en cliquant sur le [+] qui précède le titre dudit post, surtout si c'est une boutade qui s'est faite descendre par quelques moinzunteurs précoces.... mais je me lache, là.

        • [^] # Re: Avancées technologiques du prochain Kernel

          Posté par  . Évalué à 1.

          Vous aurez sans doute corrigé: c'est Virtual Memory. (sans accent)

        • [^] # Re: Avancées technologiques du prochain Kernel

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

          sauf dire des conneries en cours, c'est pas entre les application et la RAM, mais plutot entre les application et entre le gestionnaire *hardware* de la mémoire. La où ca se complique, c'est que c'est du x86, donc y a des bouts de memoires virtuels qui sont mappé a des endroits fixes de la mémoire, et d'autres non, y a des barres spéciales (640Ko, 1Mo, 896Mo, et encore une autre vers les 3,5Go)

          A noter que dans les 2.4, la memoire BIGMEM (cad > 896Mo) est géré, je vais pas dire "à la porc" mais les performances s'effrondent un peu. la nouvelle génération de kernel règle cela aussi.

  • # question concernant alsa

    Posté par  . Évalué à 1.

    Possesseur de cartes cheap estampillées sound blaster qui ne sont pas full dupleix et qui n'ont pas de drivers alsa, qu'est ce qui est la carte la mieux supportée par alsa avec full dupleix inside et bon rapport qualité prix que vous me recommandez pour que j'envoie ces cartes nazebrokes dans les limbes de l'informatique (c-a-d que je les refile à un utilisateur de windos).
    Parce que ca se prépare un changement comme ça.

    Et pendant que j'y suis, ô glorieux kernelhackers, vous qui murmurez à l'oreille des devices, qu'en est il de devfs? Il l'a pas fait lui, le grand saut dans le noyau, comme alsa?

    • [^] # Re: question concernant alsa

      Posté par  . Évalué à 2.

      Dans le 2.4.20 (j'en ait compilé un ce matin ...) il y a une option devfs, mais comme mais devise est "tant que ça marche on touche pas" ... je ne l'ait pas coché ...

      Donc sauf si je dit une connerie il me semble que devfs est integré ds les 2.4.

      • [^] # Re: question concernant alsa

        Posté par  . Évalué à 2.

        le devfs est intégré au noyau depuis quelques temps déjà. J'ai essayé quand j'avais un noyau 2.4.17 et bien que le système bootait, une partie des applications ne fonctionnaient plus donc je suis revenu au système traditionnel et je n'utiliserai devfs que lorsque se sera le choix par défaut dans le kernel.

        • [^] # Re: question concernant alsa

          Posté par  . Évalué à 2.

          À mon avis ton problème venait du fait que tu n'utilisait pas devfsd (j'imagine).
          En effet, devfs crée les fichiers de périphérique suivant la nouvelle nomenclature, ainsi /dev/hda s'écrit /dev/ide/host0/bus0/target0/lun0/disc. Donc tous les programmes qui accèdent à un périphérique ne retrouvent plus leurs jeunes s'il ne sont pas adaptés à la nouvelle nomenclature.
          C'est là qu'intervient devfsd, parmis ses fonctionnalités il y a la possibilité de lui faire créer automatiquement des liens symboliques correspondant à l'ancienne nomenclature (ainsi, chez moi un ls -l /dev/hda me donne lr-xr-xr-x 1 root root 32 avr 25 13:20 /dev/hda -> ide/host0/bus0/target0/lun0/disc). Devfsd permet aussi d'exécuter automatiquement des actions lorsqu'un périphérique aparrait (Mandrake s'en sert pour son package dynamic) et d'autres choses amusantes.

          Je crois qu'il vaut mieux attendre que ta distrib l'intègre en standard si tu ne veux pas te prendre la tête.

          • [^] # Re: question concernant alsa

            Posté par  . Évalué à 2.

            Ce que je voulais dire c'est, devfs a t il reussi à supplanter le systéme tradi comme alsa a remplacé oss?
            Il y a quelques années j'avais lu des articles qui disaient que le systéme de nommage des device était pas terrible et que devfs le faisait bien lui. A la même époque, il y avait des articles pour dire qu'alsa serait le futur du son.
            Récemment, j'avais lu un article qui disait que devfs ne prenait pas, qu'il ne se répandait pas vraiment.
            Donc c'est plutôt sous cet angle que je me renseignais.

            • [^] # Re: question concernant alsa

              Posté par  . Évalué à 3.

              Il me semble que devfs n'est pas devenu tres populaire a cause de son initiateur (Richard Gooch). Le code semblait avoir quelques failles et la maintenance ne suivait pas trop.

              Ca ne m'empeche pas de l'utiliser personnellement et je trouve que ca rend le /dev beaucoup plus clair : on peut faire un ls dedans sans qu'il y ait 3 ecrans qui defile et si un fichier existe, c'est que le device correspondant a bien ete reconnu.

              Bref, j'en suis content au niveau utilisation mais je ne sais pas trop ce que ca vaut du point de vue de la qualité du code.

              • [^] # Re: question concernant alsa

                Posté par  . Évalué à 1.

                Heu pourquoi a cause de son initiateur ? Gooch serait-il réputé pour faire du mauvais code ? D'après ce que j'en ai vu, ce serait plutôt le contraire:
                • le devfs fonctionne très bien
                • devfsd fonctionne bien aussi, est très pratique et configurable à souhait
                • simpleinit n'est pas connu, car trop différent des autres systèmes d'init, et donc impossible à mettre en oeuvre en standard dans une distro, mais c'est mon système d'init préféré: simple, léger, rapide - un must si on prend la peine d'adapter sa distro De plus, devfs n'est pas très connu du grand public, car sur toutes les distro qui l'implémentent (et je crois qu'elles sont majoritaires), il y a devfsd qui rend tout ça invisible. Le seul bemol semblerait venir de LFS, car si devfs était un standard dans les LFS (et non juste un hint), beaucoup plus de personnes voulant connaître à fond linux s'y intéresserait.

          • [^] # Re: question concernant alsa

            Posté par  . Évalué à 1.

            sous gentoo on est plus ou moins obligé d'utiliser devfs ( avec devfsd )

    • [^] # Re: question concernant alsa

      Posté par  . Évalué à 4.

      qu'est-ce qui est la carte la mieux supportée par alsa avec full duplex inside et bon rapport qualité prix que vous me recommandez

      La card SB Live ne coûte vraiment pas cher et marche très bien (full duplex et multi-canaux).

      qu'en est-il de devfs? Il l'a pas fait lui, le grand saut dans le noyau, comme alsa?

      devfs peut s'utiliser depuis le noyau 2.4 il me semble. En tous cas, la Mandrake 9.1 l'utilise par défaut.

      • [^] # Re: question concernant alsa

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

        devfs peut s'utiliser depuis le noyau 2.4 il me semble. En tous cas, la Mandrake 9.1 l'utilise par défaut.

        Je pense que c'est ce truc qui m'a faitune petite blague sur mdk 9.1 : J'ai mis un beau disque tout neuf dans ma machine. Si on laisse passer kudzu, le disque n'est pas vu. Il semble qu'un disque qui n'a pas de partition n'est pas vu. Il faut créer une partition à partir de kudzu. Ça marche alors parfaitement. On peut lancer fdisk, mkfs pour modifier le disque.
        L'insertion dans une machine d'un disque déja partitionné ne pose aucun problème.
        Le savoir (et y penser) peut eviter quelques minutes de sueurs froides.

    • [^] # Re: question concernant alsa

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

      Devfs à conservé son message d'avertissemnt disgracieux, le même que dans les 2.4 et qui dit que c'est dangereux.

      Ceci dit, je l'utilise depuis un ans (ma 1ere Mandrake à l'époque ^_^), nottement pour ne pas avoir dans /dev un foutoire inutile (et ainsi avoir rapidement l'état des périphèriques). Et j'ai jammais eu le moindre problème lié à ça. Il faut juste penser à:
      demander au noyo de le monter tout seul au démarrage (dans ses options)
      demander à init de lancer devfsd en premier
      décomenter la ligne de config qui permet le bidouillage de compatiblité
      ajouter la ligne qui permet la sauvegarde des droits (vu que c'est un système de fichier virtuel)

      C'est bien expliqué sur le site de LFS:
      http://www.linuxfromscratch.org/~tushar/hints/devfsd.txt(...)
      (perso, j'aurais plutôt mis le dev-state dans /var)

    • [^] # Re: question concernant alsa

      Posté par  . Évalué à 2.

      devfs, à mon goût, c'est TRES pratique : d'une façon générale, les devices apparaissent dans /dev/X quand c'est nécessaires, disparaissent de même, ça me plait.

      J'utilise devfs sans devfsd depuis 1 an à peu près, et je n'ai pas eu de pb autres que liés à des softs utilisant "l'ancienne" structure dev et ne permettant pas de modifier ça simplement ( exemple : SDL )

      On y gagne franchement en clarté ( et puis c'est plus logique : à quoi bon avoir 12000 dev/hdXY alors qu'on a généralement un max de 4 périphs ? )

      L'essayer, c'est l'adopter.

      PS : j'utilise ça sur un LFS, je ne sait pas ce que ça donne depuis une autre distribution, peut être ( un peu ) plus de pbs à cause des précompilations ?

  • # Commentaire supprimé

    Posté par  . Évalué à -2.

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

  • # Tests possibles avec un noyau 2.4.x

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

    Pour ceux qui seraient intéressé par le test de ces différentes fonctionnalités (low-latency, preemptible kernel, scheduler O(1)...), Con Kolivas les a backporté pour le noyau 2.4.20.

    Il publie un patch (à l'heure actuel le ck6) pour le noyau 2.4.20 qui ajoute en plus le système de fichiers XFS, les derniers développements ACPI, Supermount. Un must sans avoir besoin d'attendre le noyau 2.6 ou de tester un 2.5.x. Vous trouverez ce patch et une FAQ ici : http://members.optusnet.com.au/ckolivas/kernel/(...)

    J'ai installé ce patch et recompilé mon noyau le WE dernier et je peux dire que les améliorations pour l'interactivité sont vraiment intéressantes et se ressentent lors d'une utilisation intensive d'une système desktop.

  • # Re: Avancées technologiques du prochain Kernel

    Posté par  . Évalué à 3.

    Attention aux noyaux suivant le 2.5.66: un changement d'ordonnanceur a été effectué, et dans certains cas, il est vraiment très mauvais. Dans un journal, je parlais de ce problème, mais il n'a toujours pas été corrigé (au moins jusqu'au 2.5.68-bk7). Le journal en question: http://linuxfr.org/~bmc/2031.html(...)

Suivre le flux des commentaires

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