Des nouvelles du noyau Debian

Posté par (page perso) . Modéré par Amaury.
Tags :
56
21
oct.
2009
Debian
Durant la dernière conférence Linux Plumbers s'étant déroulée à Portland les 23, 24 et 25 septembre, les membres de la kernel team du projet Debian ont tenu une réunion spécifique afin de traiter les points en suspens et de discuter des choix à faire pour l'avenir.

Dans l'esprit de transparence de Debian un long compte-rendu de cette réunion a été publié par Vincent Sanders afin de permettre aux utilisateurs de se faire une idée de la direction que va prendre le noyau Linux dans le projet. Synchronisation et coopération avec les autres distributions

Le noyau 2.6.31 est vu comme ayant plus de problèmes que la moyenne (beaucoup de régressions) et une sorte de consensus a été obtenu sur le fait que le 2.6.32 sera le noyau qui sera dans la prochaine Debian stable (Squeeze) et dans la prochaine Ubuntu LTS 10.04 (Lucid Lynx).

Greg Kroah-Hartman (le mainteneur des branches -stable) a été consulté afin de savoir si un support de long terme pouvait être envisagé sur le 2.6.32 comme ce qui est actuellement effectué sur le 2.6.27. Même s'il n'a pas pu s'engager au nom de SUSE il a confirmé que plusieurs autres distributions (comme Fedora) pensent la même chose et que le 2.6.32 semble un bon point de départ pour organiser une maintenance à long terme.

Microcodes

Les microcodes posant des problèmes juridiques de redistribution sont maintenant séparés du noyau Debian. Un sujet de troll qui disparaît.

Transition vers KMS

Avec le Kernel Mode Setting qui est apparu dans le noyau (pour les cartes Intel et AMD) une stratégie de transition doit être organisée par Debian afin de permettre à ses utilisateurs de profiter de KMS sans casser l'existant.
Il a été décidé que KMS sera présent dans le noyau mais ne sera activé que par les paquets du serveur X (en utilisant modprobe). Une synchronisation avec l'équipe X sera donc organisée.

Les patchs externes

Un certain nombres de patchs externe au noyau Linux sont disponibles parmi les paquets Debian. Leur sort a été évoqué lors de la réunion et plusieurs décisions ont été prises à leur sujet.
Le patch Openvz (création de conteneurs "à-la-jails") sera toujours disponible car les développeurs du projet continuent d'assurer un maintien de bonne qualité.
Le patch Vserver (là aussi une solution de conteneurs permettant d'isoler des instances) est en situation plus précaire qu'Openvz. Du travail reste à faire pour l'intégration dans Squeeze. Une alerte d'abandon (deprecation) sera ajoutée dans les notes de version.
Le patch d'ajout du temps réel (patch -RT) n'a pas été considéré comme suffisamment mûr pour intégrer Squeeze et il ne fera donc pas partie de cette version.
Du coté de Xen en Dom0 (c'est à dire en virtualiseur accueillant les autres instances qui sont, elles, en DomU) la décision d'inclusion n'a pas été prise puisqu'il faut du travail supplémentaire pour passer les patchs en revue. Bastian Blank va travailler sur ce sujet mais là aussi une alerte d'abandon sera sans doute jointe dans les notes de version de Squeeze.

Transition vers Libata

La nouvelle bibliothèque libata qui gère les périphériques ATA (nommage des disques en sdX au lieu de hdX) nécessite elle aussi une transition en douceur pour les utilisateurs de Debian. Il a été décidé d'observer ce qui a été fait dans le cas d'Ubuntu qui a déjà effectuée la transition en s'appuyant sur udev. Les développeurs Ubuntu ont offert leur aide (Steve Langasek est développeur Debian et aussi employé par Canonical en tant que Release Manager pour Ubuntu) pour faciliter cette transition.

Noyau préemptif

Il a été décidé que l'option CONFIG_PREEMPT serait activée dans le noyau de Squeeze. Le temps de latence sera donc amélioré pour le plus grand bénéfice des gens qui utilisent Debian pour autre chose qu'un serveur. L'impact négatif sur les performances des serveurs est vu comme minimal voire même totalement négligeable.

OSS vs ALSA

Dans le domaine audio c'est ALSA qui est dans la branche principale et OSS n'est plus vu que comme une nuisance à éradiquer.
OSS sera donc désactivé complètement dans Squeeze et les derniers programmes qui reposent sur lui seront modifiés (voir le compte-rendu amusant de Vincent Sanders :"Mark Brown has an action item to find and kill OSS users (thats what was in my notes. I *think* we just meant the software which uses the OSS interface ;-)").

Rapports de bugs

La qualité des rapports de bugs qui arrivent dans le tracker est jugée insuffisante (souvent il n'y a pas de logs). Il a été décidé de créer une règle officielle (official policy) pour les rapports de bugs concernant le noyau et de faire respecter cette règle contraignante. L'outil reportbug sera aussi techniquement amélioré. Ces deux mesures permettront d'améliorer la qualité générale des rapports de bugs et de faciliter le travail de l'équipe en charge du noyau.

Git

L'outil de gestion de versions décentralisé Git a provoqué une chaude discussion entre les membres de l'équipe noyau de Debian (Vincent Sanders évoque "a robust discussion").
Afin de faciliter l'intégration avec la branche principale de Linux qui utilise Git et afin de profiter des avantages techniques de cet outil, une transition a été envisagée. Bastian Blank s'y est opposé en soulignant qu'il n'y avait pas de vrais avantages par rapport à SVN qui est actuellement utilisé.
En dépit de ce désaccord les autres membres de l'équipe ont insisté et une transition vers Git a bien été décidée (même si Bastian a tenu a ce que son opposition soit mentionnée dans le compte-rendu).

Coordination avec l'équipe de Debian-Installer

La génération des paquets udeb (paquets réduits sans documentation qui sont utilisés par l'installeur Debian) va peut-être revenir dans le noyau alors qu'une séparation avait été décidé auparavant. L'idée de la séparation était qu'elle devait permettre aux développeurs de l'installeur de générer leurs indispensables paquets allégés udeb sans devoir attendre la longue compilation du noyau.
Une coordination sera organisée avec l'équipe de l'installeur pour savoir si cette fonction est vraiment utile car il serait plus simple de remettre la génération des paquets udeb dans le noyau.

Modules externes

Les paquets linux-modules-extra et linux-modules-nonfree seront supprimés dans Squeeze car il est impossible d'assurer un support correct de ces modules externes. Il va être demandé à Greg Kroah-Hartman d'intégrer certains de ces modules dans la branche -staging de Linux afin qu'ils soient disponibles pour les gens voulant les utiliser.

Empaquetage du noyau

Les développeurs de l'équipe noyau ont décidé qu'il ne fallait plus utiliser le paquet make-kpkg car l'outil n'est plus maintenu.
La solution d'empaquetage à privilégier est le classique make deb-pkg qui marchera aussi sur les sources du noyau vanilla. Les développeurs d'Ubuntu vont eux aussi utiliser cette méthode (une coordination entre les équipes est prévue).

Mailing-lists

La mailing list kernel-packagersATvger.org dédiée à la coordination du travail sur le noyau entre toutes les distributions va peut-être renaître de ses cendres (du moins c'est un souhait de l'équipe Debian).
D'autre part des échanges auront lieu avec les développeurs Ubuntu sur la liste kernel-teamATlists.ubuntu.com

Paquets permettant le débogage

Afin d'aider à la correction des bugs il y a eu une discussion sur la génération d'informations de débogage directement incluse dans les paquets (sans avoir à passer par une version -debug). Cela posera peut-être des problèmes de taille de paquets à l'équipe en charge du FTP donc une coordination est nécessaire. L'équipe a discuté de la possibilité de restreindre cette fonction aux architectures x86 et x86-64.

Kautobuild

L'utilisation de l'outil Kautobuild a été envisagée par l'équipe du noyau Debian afin de remplacer à plus ou moins long terme l'outil kernel-archive.buildserver.net.
Kautobuild permet de récupérer automatiquement les sources du noyau Linux et de les compiler dans plusieurs configurations différentes afin de détecter le plus tôt possible des problèmes dans le code. L'idée a semblé intéressante aux développeurs qui vont poursuivre cette discussion et enquêter plus avant pour savoir s'il est possible de mettre en place l'infrastructure associée.


En définitive ce compte rendu publié par Vincent Sanders permet d'avoir un aperçu du travail de l'équipe noyau de Debian et de se rendre compte de leur professionnalisme et de leur méticulosité.
Il est aussi réconfortant de voir que la coopération avec Ubuntu (et peut-être la coordination sur le noyau 2.6.32 avec les autres distributions) semble être une réalité.
  • # Merci..

    Posté par . Évalué à 5.

    .. pour toutes ces bonnes nouvelles!

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Merci..

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

      A noter que ceci est une traduction (bien faite) et non un original.
      • [^] # Re: Merci..

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

        >>> A noter que ceci est une traduction (bien faite) et non un original.

        C'est plus un commentaire en français en reprenant tous les points du compte-rendu qu'une traduction.
        Maintenant c'est vrai qu'il n'y a pas ou peu de recherches derrière.
    • [^] # Re: Merci..

      Posté par . Évalué à -4.

      Merci à Patrick_g pour ses travaux. C'est toujours instructif à lire !
    • [^] # Re: Merci..

      Posté par . Évalué à 1.

      Je suis également heureux d'apprendre que Debian se libère progressivement. Je me souviens avoir vu une conférence de R. Stallman, qui, à la question des distributions entièrement libre, répondait gNewSense et Ututo. Et pourquoi pas Debian?

      J'apprécie aussi les nouveautés concernant OpenVZ. Jusqu'à présent j'installais des hôtes sous Gentoo (puisque c'est ma première distrib' et aussi celle que je préfère); maintenant je considèrerai aussi Debian avec le plus grand sérieux.

      Longue vie à Debian.
  • # Microcodes

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

    Les microcodes sont "séparés du noyau Debian". Ok, mais ils seront toujours disponible dans Debian non ? Et d'ailleurs, ça contient quoi un microcode ? Est-il possible d'écrire un microcode libre pour remplacer un microcode propriétaire ? Ça a toujours été un truc nébuleux pour moi, je sais juste qu'il en faut pour certains pilotes wifi (par exemple) :-)
    • [^] # Re: Microcodes

      Posté par . Évalué à 10.

      Ok, mais ils seront toujours disponible dans Debian non ?
      Oui, tout comme le reste des logiciels propriétaires, dans les dépots "non-free."
      Et d'ailleurs, ça contient quoi un microcode ?
      C'est plus ou moins le "système d'exploitation" d'un périphérique, le plus souvent livré par le fabricant sous forme binaire. On peut considérer que c'est pas libre (on n'a pas les sources) ou qu'on s'en fout (car après tout il pourrait être déjà embarqué dans le matériel).
      Est-il possible d'écrire un microcode libre pour remplacer un microcode propriétaire ?
      Oui, ça a été fait par exemple pour les microcodes Atheros (pour le Wifi), et plus récemment pour Broadcom.
      Parfois le constructeur est gentil et libère son code (ou les spécifications de son matériel), parfois c'est fait à grands coup de rétro-ingénieurie par des dingues de chez BSD. Voilà voilà.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Microcodes

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

      ils seront toujours disponible dans Debian non ?

      Disponibles pour Debian, via des dépôts non-free. Mais ils ne feront pas partie de Debian.

      Un microcode, c'est du code binaire destiné à être chargé sur un périphérique, dont le fabricant a préféré mettre de la mémoire vive plutôt que de la flash. Il doit donc être chargé à chaque démarrage du périphérique, par ton système d'exploitation.

      La différence entre un logiciel non-libre et un firmware non-libre, c'est que le firmware n'est pas exécuté sur ton processeur, mais seulement chargé sur le périphérique.
      • [^] # Re: Microcodes

        Posté par . Évalué à -8.

        Disponibles pour Debian, via des dépôts non-free. Mais ils ne feront pas partie de Debian.
        Hehe.
        Package par debian pour debian.
        Heberge par debian pour debian.
        Distribue par debian pour debian.

        Mais ca ne fait pas partie de debian on vous dit!!
        C'est beau l'hypocrisie.
        • [^] # Re: Microcodes

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

          Bah c'est surtout que le dépôt non-free n'est pas actif de base. Il faut l'activer manuellement. La séparation permet d'avoir un OS libre si on le désire. Mais ça permet aussi d'avoir un OS presque libre si on a vraiment besoin de trucs propriétaires. Je trouve que c'est un bon compromis :-)
          • [^] # Re: Microcodes

            Posté par . Évalué à -4.

            Je trouve ca aussi un tres bon compromis et tres utile.

            Par contre, ce qui me gene, c'est l'affirmation 100% libre et "ne fait pas partie de debian".
            Je trouve ca tres hypocrite.
            • [^] # Re: Microcodes

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

              Si on part dans ce sens là, on pourrait aussi parler de ton Église ...

              T'es bien libre de bouffer du non-libre, et avec debian, tu le fais en connaissance de cause. (Je m'en arrêterais là ;) )
        • [^] # Re: Microcodes

          Posté par . Évalué à 2.

          C'est vrai que je trouve les mainteneurs Debian trop gentils avec le logiciel propriétaire: les éditeurs de softs proprios n'ont qu'à construire leurs .deb eux-mêmes, non mais!
          Depuis quand Microsoft fait des installeurs pour les éditeurs tiers?

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Microcodes

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

            Depuis Windows 2000 apparemment http://en.wikipedia.org/wiki/Windows_Installer#Versions

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

            • [^] # Re: Microcodes

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

              Oui, enfin, comparé à dpkg, c'est de la merde en barre, ça.
            • [^] # Re: Microcodes

              Posté par . Évalué à 2.

              Sauf que là Microsoft fournit "un outil pour faire des installeurs.", et ne fait pas le travail d'installation.

              Ce que fait Debian, c'est prendre les binaires proprios, regarder leurs dépendances, faire un .deb qui tient la route, intégrer ça aussi proprement que possible au système.. Microsoft n'a jamais fait un tel travail, ils donnent les outils pour faire un installeur Windows et "Démerdez vous les éditeurs".

              Adobe veut que Flash s'installe facilement sous Windows? Ils font un .exe ou un .msi qui l'installe.
              Adobe veut que Flash s'installe facilement sous Debian? Ce n'est pas à Debian de faire un .deb, c'est à Adobe.

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

              • [^] # Re: Microcodes

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

                Sauf qu'il n'y a qu'un windows et qu'il y a plein de distrib linux.

                Je préfère qu'adobe file un tar.gz clair et propre sous linux et que les distributions enrobe cela dans de la crème chacun de leur coté. Si le tar est propre, la moulinette pour en faire un rpm, un deb... n'est pas des plus dur à maintenir (a mon avis).
          • [^] # Re: Microcodes

            Posté par . Évalué à 2.

            Debian travaille pour ses utilisateurs, pas pour les développeurs tiers.
            C'est dans l'intérêt des utilisateurs de faire un paquet Debian si l'upstream n'en propose pas.
            • [^] # Re: Microcodes

              Posté par . Évalué à -1.

              Si l'intérêt des utilisateurs c'est d'installer Flash facilement avec un .deb, alors c'est encore plus dans leur intérêt d'utiliser Linux Mint (où Flash est déjà installé) ou Windows (où Flash est mieux optimisé).
              À la base Debian se présente comme une distro "libre", les .deb pour Flash et autres trucs propriétaires (qui, dans l'esprit du libre, ne sont pas dans l'intérêt de l'utilisateur) ça fait tâche.

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

              • [^] # Re: Microcodes

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

                Debian a toujours fournit un gros effort coté licence pour avoir les choses les plus claires possible. Cela a coûté a quelques projets pendant un certain temps. Debian a ainsi obligé pas mal de développeur à spécifier une licence...

                D'un autre coté, Debian a toujours eu son dépôt non-free car dans sa charte, il est bien précisé que c'est une distribution pour utilisateurs. Si un logiciel est bloquant et qu'il n'y a une solution non libre, il va dans non-free. C'est le cas de flash aujourd'hui.

                Je préfère un flash propre dans non-free plutôt que chacun fasse son truc crade et ne mettent jamais à jour. Au moins, le .deb lorsque je le dé-installe, il ne reste plus rien d'adobe. Je ne suis pas sur de cela lorsque je fais une installation à la main...

                Bref, le non-free de Debian ne fait pas tâche, il rappelle le principe de réalité et indique des points à traiter. Il montre aussi la modestie de la distribution qui malgré tous ses efforts pour faire du libre à l'honnêteté de dire qu'il y a quelques trucs important pour un certain nombre de personne et donc réalise des paquetages marqués non-free qui tu es libre ou non d'utiliser.

                Je pense qu'à chaque fois qu'un paquetage est mis dans non-free, le développeur Debian doit avoir mal au coeur de faire cela. Il le fait donc par respect.

                Après, tu es libre de ne pas mettre contrib et non-free dans ta liste de paquetage.
    • [^] # Re: Microcodes

      Posté par . Évalué à 5.

      La différence entre un microcode et un pilote, c'est que le premier est exécuté par le périphérique, le second par la kernel. Théoriquement, un microcode est sensé remplacer de la logique câblée pour des raisons de coûts mais également légales pour le WiFi notamment (des histoires de fréquences, étendue, puissance, etc ...)
      Mais parfois, ils mettent des trucs en plus.

      Réécrire un microcode, c'est possible (si tu as la doc), c'est ce qui a été fait pour les chipsets broadcom, Fedora l'a inclus récemment (disponible pour F-10/11 dans les mises à jour).
      http://www.ing.unibs.it/openfwwf/
    • [^] # Re: Microcodes

      Posté par . Évalué à 4.

      C'est en train d'être fait par Redhat pour les cartes broadcom...
      les fameuses dont sont issues un si grand nombre de trolls chez debian. (modules bnx / bnx2 / bnx2x / bnxi ayant besoin de crc32 (lui même de libcrc32.ko) et/ou (selon les versions) de firmware_class. Et leur absence dans l'initrd de base ne permet pas de simplement faire un cat mes_blobs_fw.gz >> initrd.gz Le tout bien sûr arrosés d'un grand nombres de firmware, Redhat est en train de s'occuper du tout...

      Le fait que certains modules puissent rejoindre la branche -staging, si Novell accepte, est une bonne chose pour les utilisateurs de Debian, dans la mesure ou par exemple le web est rempli de question sans réponse, sans support. "c'est pas libre, pas de support" est une réponse +1 et compréhensible, mais ça aide pas à utiliser Debian :( Alors qu'il est assez simple, pour reprendre l'exemple des firmware et des drivers broadcom, d'expliquer que l'ajout du/des firmware dans l'initrd ne sufffira pas à le faire loader directement à ce stade (alors que ça suffit après), et d'expliquer comment faire pour enrichir l'initrd. Sinon ça devient embétant pour tout ceux utilisant du noyau/initramfs-toopiti local pour rapatrier un système squashfs sur le réseau (et un ~ nfs, mais on s'en fout).

      Bref plein de bonnes nouvelles, merci Patrick_G
      • [^] # Re: Microcodes

        Posté par . Évalué à 3.

        Arf je poste et GeneralZod nous informe que c'est déjà fini ;)
    • [^] # Re: Microcodes

      Posté par . Évalué à -1.

      La suppression des microcodes du noyau par les mainteneurs de Debian rend bon nombre de matériels supportés jusque là inutilisables. Si du point de vue de la FSF cette mutilation du kernel est justifiée, je trouve la communication sur ce sujet de la part de Debian largement déficiente.

      Flashback :
      Lorsque Lenny était encore en Testing après l'actualisation du noyau 2.6.22 à 2.6.24 je
      n'avais plus de son. En effet le microcode du pilote de la maestro3 avait été supprimé. Ce n'est après avoir fouillé dans les tréfonds du changelog du kernel que j'ai découvert la raison. Ce firmware d'ailleurs ne se trouve d'ailleurs pas dans non-free.
      Si cette façon d'agir est certes désagréable dans testing, cela est purement inadmissible pour une stable.

      Si les mainteneurs de Debian étaient des individus respectueux de leurs utilisateurs, il aurait été indispensable d'annoncer franchement la couleur et d'indiquer la liste exhaustive des pilotes mutilés dans les releases notes.
      • [^] # Re: Microcodes

        Posté par . Évalué à 5.

        Si les mainteneurs de Debian étaient des individus respectueux de leurs utilisateurs

        C'est assez étonnant de parler comme ça de bénévoles qui ne te doivent rien !
        Si j'étais mainteneur Debian, et que j'avais une discussion avec toi, je te garanti pas d'être respectueux.
        • [^] # Re: Microcodes

          Posté par . Évalué à -10.

          Si j'étais mainteneur Debian, ....
          Tu n'en est pas un alors ton avis......

          bénévoles qui ne te doivent rien !
          C'est vrai mais moi non plus. Après tout je n'ai pas besoin de Debian. D' autres distributions répondent meieux à mes besoins et d'ailleurs pourquoi devrais-je soutenir cette bande d'amateurs incapables (openSSL!!!) imbus d'eux-même qui par leur incompétence risque de compromettre les distributions linux dans leur ensemble.
      • [^] # Re: Microcodes

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

        Si les utilisateurs lisais les changelog et les README avant de se lancer dans des mise à jour et installation…

        Le respect ça n'est pas quelque chose qui fonctionne à sens unique…
      • [^] # Re: Microcodes

        Posté par . Évalué à 5.

        Merde, c'est vrai ça, au prix où t'a payé ton CD! T'as fait jouer la garantie au moins??

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Microcodes

      Posté par . Évalué à 7.

      >Et d'ailleurs, ça contient quoi un microcode ?

      Remplace microcode par firmware/micrologiciel: c'est une erreur de traduction.

      Ce que Debian a fait c'est mettre dans un espace à part les binaires chargés sur les périphériques qui sont non libres. On appelle normalement ces binaires firmware ou micrologiciel pour faire la difference avec les logiciels/software qui tournent sur le CPU principal.

      Le microcode est du logiciels qui tourne dans le CPU lui-même (donc pas restreinte au jeu d'instruction (ISA) 'externe' du CPU) et utilisé par les constructeurs pour corriger des bugs, implementer des instructions trop compliquees pour le hardware.

      Il me semble que tout les CPU x86 ont un microcode, et typiquement ce microcode n'est pas libre donc même si tout les pilotes de peripheriques utilisé sur un PC étaient libre, un PC x86 executera du logiciel non libre..
      • [^] # Re: Microcodes

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

        Ah merci pour la précision. Effectivement moi je traduisais firmware par microcode mais tu a raison j'aurai du employer micrologiciel.
        • [^] # Re: Microcodes

          Posté par . Évalué à 4.

          Note que si je savais que microcode n'est pas correcte, il a fallu que j'aille chercher sur wikipedia la traduction correcte de firmware: je ne m'en souvenais pas, elle n'est pas très utilisée..

          Merci pour tes articles.
  • # Suppression d'OSS et état de l'audio sous Linux

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

    Si j'ai bien compris, ça faisait longtemps qu'OSS était émulé au dessus d'ALSA, mais l'émulation était faite dans le noyau. Or c'est quelque chose de compliqué, lourd et bogué. Et puis, personne ne voulait plus le maintenir. J'ai bon ?

    Fedora veut également abandonner OSS. Je ne sais pas où ça en est.

    Sur LWN, il y a un excellent article « The past, present, and future of Linux audio » également issu de Linux Plumbers (comme la dépêche de patrick_g). Cet article parle d'OSS, ALSA, JACK et PulseAudio (erk!) notamment, mais également de Windows et Mac OS X.
    http://lwn.net/Articles/355542/
    (je ne sais pas si l'article est déjà public, si non, achetez vous un abonnement, LWN est une excellente source d'information !)
    • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

      Posté par . Évalué à 9.

      OSS dans le noyau est mort depuis longtemps et aurait du effectivement être erradiqué depuis un moment.

      En revanche, le développement d'OSS n'a jamais cessé, bien qu'il soit devenu un moment propriétaire, ce qui a surement attisé les esprits.

      Maintenant, il faut aussi constater l'échec d'ALSA. C'est une API impossible, qui se voudrait à la fois bas niveau et haut niveau, et dont l'adoption par les applications simples type bureautique a été un echec flagrant.

      Tous les programmeurs qui ont un jour voulu ajouter une simple sortie audio à leur programme linux doivent très bien connaitre le problème. Comparé à cela, l'API OSS était parfaite pour un usage grand public.

      Résultat, on se retrouve avec des sur-couche supplémentaires, pulseaudio, jack et compagnie..

      Ce n'est pas forcément une mauvaise chose, pourvu que, enfin, l'API d'un de ceux là, pulseaudio apparement, devienne standard ET relativement aisé à utiliser.

      Maintenant vouloir eradiquer toutes les applications utilisant OSS est stupide. Cela fait deja un paquet d'années qu'ALSA est en place et si un nombre relativement important d'applications continuent d'utiliser OSS c'est bien que l'API ALSA est inutilisable pour eux.

      Enfin il n'est pas exclu que les modules récents OSS fassent leur apparition en tant que module externes dans Debian, laissant le choix à l'utilisateur d'avoir ALSA ou OSS, puisque le logiciel libre est *aussi* une question de libre choix.

      Et, comme les sur-couche pulseaudio et companie supportent OSS comme API de sortie, tout le monde devrait s'y retrouver...

      Si, en plus, pulseaudio supporte l'émulation OSS plus correctement qu'ALSA il n'y a pas de raison de vouloir supprimer les applications utilisant OSS.
      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

        ALSA was designed to use some features which were not, at the time of its conception, supported by OSS:
        -Hardware-based MIDI synthesis.
        -Hardware mixing of multiple channels.
        -Full-duplex operation.
        -Multiprocessor-friendly, thread-safe device drivers.

        To provide these features cleanly, ALSA has a bigger and more complex API than OSS, so it can be harder to develop applications that use ALSA as their sound technology.
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

          Ce n'est pas parce que tu proposes des fonctionnalités complexes que tu es obligé d'imaginer une API complexe pour les choses simples.

          Exemple :
          http://curl.haxx.se/libcurl/c/
          Une interface simple pour 90% des utilisateurs, une interface plus évolue pour les 10% qui cherchent plus de choses.

          Complexifier la lecture toute bête d'un son "parce qu'il y a des fonctionnalités avancées disponible" est une excuse d'un mauvais design d'API, pas une explication.
      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

        Posté par . Évalué à 9.

        quand il est indiqué OSS, est-ce que cela veut l'ancien OSS + OSS4, ou alors c'est considérés comme deux choses différentes ? OSS4 est libre, et vraiment plus pratique qu'Alsa, c'est dommage de le virer alors c'est une bonne technologie.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

        Posté par . Évalué à 1.

        > Maintenant, il faut aussi constater l'échec d'ALSA.

        C'est bon de rire.
        Ce qu'il faut constater, c'est l'écher d'OSS.
        Ta remarque c'est comme dire que xhtml est un échec car html 4.2 est encore utilisé.
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à 3.

          Non.

          ALSA est un echec tout simplement parce que les APIs de son sont un bordel sans nom sous linux alors même qu'ALSA était censé uniformiser cela.

          L'API ALSA n'est satisfaisante pour personne. Ni assez documentée pour satisfaire les usages vraiment spécialistes, ni suffisament simple pour le reste.

          Il suffit de regarder l'historique des sur-couche inventées pour parer à cela: arts, esound, jack, pulseaudio, etc etc... Elles ont toutes été inventées dans le même but: avoir une API plus "simple" et uniforme à utiliser que ALSA.

          Si tu ajoute encore que chacune de ces couches émulent ALSA, OSS, et même plus ça devient vraiment toufu.

          Implémenter le simple support d'un output audio sous linux est absolument cauchemardesque du point de vue du développeur, et je ne parle même pas des utilisateurs qui ne s'y retrouvent pas quand ils ont un pb de config.
          • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

            Posté par . Évalué à 5.

            Tu oublie de dire aussi que arts, esound et compagnie ont été crée également pour palier aux problèmes de mixage de son. Je me souviens qu'au début d'alsa dmix et plug n'étaient pas couramment configurés par défaut et encore moins connus. Il fallait donc un mixeur software car la plupart des cartes actuelles (en gros les chipset son des CM, mais aussi les cartes son dédiées et pas cher) ne possèdent pas de mixeur hard.
          • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

            Posté par . Évalué à 5.

            Il suffit de regarder l'historique des sur-couche inventées pour parer à cela: arts, esound, jack, pulseaudio, etc etc... Elles ont toutes été inventées dans le même but: avoir une API plus simple et uniforme à utiliser que ALSA.

            Dans mon souvenir, esound et cie étaient surtout conçus pour contourner le gros défaut d'OSS à l'époque : un seul process pouvait accéder à la carte son à la fois ce qui empêchait par exemple d'avoir les sons d'un client de messagerie instantanée pendant que xmms jouait de la musique. D'ailleurs c'est ce qu'on lit toujours sur la page d'accueil historique : However, when two or more applications want to play sounds at the same time, it's on a first-come, first-served basis. Whoever gets to the audio device first wins. EsounD changes all of that... [http://www.tux.org/~ricdude/overview.html].

            Je ne suis pas assez réveillé pour faire des recherches historiques sérieuses (car oui, aller voir ce qu'il se passait dans le logiciel libre il y a 10 ans relève déjà de l'histoire tant la source principale d'information - le web - est changeante), mais il me semble que arts et esound au moins datent d'avant Alsa, disons qu'ils datent au moins de l'époque où OSS était encore le standard.

            Alek.
      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

        Ce n'est pas forcément une mauvaise chose, pourvu que, enfin, l'API d'un de ceux là, pulseaudio apparement, devienne standard

        c'est sans compter les merveilleuses possibilités d'emulation qui fait que *chaque* api audio sous linux se demerde pour emuler (mal) les autres apis.

        En fait l'auteur de pulseaudio lui-même ne recommande pas d'utiliser d'api pulseaudio sauf cas spécifique:
        http://0pointer.de/blog/projects/guide-to-sound-apis.html
        "For now, the PulseAudio API should be used only for applications that want to expose sound-server-specific functionality"

        Il recommande plutot d'utiliser le "Safe ALSA subset" (sans proposer de lien vers la liste des fonctions considerées comme safe)
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à 5.

          « [...] utiliser le "Safe ALSA subset" (sans proposer de lien vers la liste des fonctions considerées comme safe) »

          En descendant un peu dans la page que tu proposes, je vois un paragraphe intitulé « You want to know more about the safe ALSA subset? ». Un début de réponse ?
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à 5.

          L'auteur de pulseaudio ne recommande pas non plus d'utiliser pulseaudio pour un usage "professionnel" du son avec linux.
          On ne peux que reconnaitre sa franchise.

          /*mode ras-le-troll-bol*/
          Maintenant s'il reste à pulseaudio de gérer le son de Flash, ouaih ça c'est de la tuerie pour un ll \o/
          Ha si, il gère aussi les profils ad2p, seulement, curieux, j'ai jamais entendu IRL, pourtant c'est pas faute d'avoir essayé.
          Donc, bon, on a super outil -vraiment génial, tout le monde nous le dit- qui fait quoi ? du flash, du son sur le réseau, et du théoriquement bluetooth ? Et ça consomme des sommes folle sde cpu pour ça ? (consomme moins de mémoire depuis qu'il est passé à shm, quant même, il y a 1 an et demi je crois).
          Bref, un joli truc à cliquou dans la barre de taches, à_la_mode_kevin, de la gestion de trucs proprio, et du "mangez-moi" pour le cpu. Pas reluisant, quoi.

          Vivement que ça pête tout ça... mais vraiment que ça pête un bon coup.
          Novell avait créer une belle avancée avec Alsa, je ne pense pas qu'ils soient aujourdhui préoccupés par du son sur leurs clusters... Il faudra donc attendre que quelqu'un d'autre s'y mette. D'où (mon) grand étonnement d'avoir vu pulseaudio dans fedora à l'époque.
          /*mode ras-le-troll-bol*/

          A mon toopiti niveau j'espère juste que les dev de jack, de pulseaudio et de alsa s'entendront ensemble pour unifier leurs efforts, conservé tout les drivers alsa, ajouter une belle couche userland jack et au dessus des tucs_a_la_kevin. Le tout bien unifié.
    • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

      Posté par . Évalué à 1.

      OSS n'est plus dans Fedora depuis des plombes.
      Par contre, il y a toujours alsa-oss (qui n'est pas utilisé par les applis Fedora).
    • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

      Posté par . Évalué à 10.

      Si j'ai bien compris, ça faisait longtemps qu'OSS était émulé au dessus d'ALSA, mais l'émulation était faite dans le noyau. Or c'est quelque chose de compliqué, lourd et bogué. Et puis, personne ne voulait plus le maintenir. J'ai bon ?

      En fait dès que OSS est passé en source fermées, il est simultanément devenu très problématique au niveau technique.

      De façon générale OSS considère qu'il ne devrait y avoir qu'une seule API qui gouverne le Hardware en mode kernel et qui soit accessible via les fonctions POSIX d'accès fichier de base, avec juste une modification pour savoir si il y a du changement de fréquence ou pas. Ensuite charge à l'appli et au noyal de se démerder pour que le buffer son ne se remplisse pas et qu'il se vide correctement et dans les temps.

      Pour Alsa c'est assez différent, en fait on peut aussi accéder aux son Alsa via les méthodes POSIX de base, ou via 250 000 autres interfaces ou méthodes dont au moins 6 sont doccumentées. Alsa est conçu pour ne pas faire de lock exclusif en mode kernel du hardware (du moins en théorie, parcequ'en pratique ca plante si on essaye de partager) et de plus les API d'ouverture, de buffer ou de mixage ne sont pas nécessairement dans le noyeau mais peuvent être reportées en user space (ce qui plante aussi dans 90% des cas - et de toute façon la plupart des méthodespour faire ce genre de choses sont non documentées)
      De fait tout le monde utilise la bibliothèque libaudio, et au sein des 800 000 fonctions tout le monde utilise les 4 ou 5 mêmes... Bref à aujourd'hui Alsa a à peut près tous les défauts d'OSS tout en étant vraiment moins bien documenté.

      Généralement dès que quelqu'un arrive à faire marcher un truc dans Alsa de façon à peu près reproductible, ca devient de facto le standard. C'est pour çà qu'on a aujourd'hui l'appli sur gstreamer sur pulse audio sur Alsa... Avec les conséquences que celà peut avoir sur la lecture gapless par exemple. Si personne n'y arrive, l'API Alsa est modifiée en profondeur. Par exemple pour le mixage on a eu tout et le reste : Avant pulse audio (qui commence à marcher péniblement quand on le chatouille pas trop fort) on a eu le droit a un buffer software, un facteur d'amplification dans la connexion sonore, des devices virtuels à créer à la main, des devices virtuels qui se créaient tout seuls au besoin etc.

      Je fais parti des gens qui pensent que OSS4 est plutôt plus utilisable qu'Alsa au jour le jour.
      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

        Posté par . Évalué à 5.

        Héhé, j'avais oublié l'absence de documentation....

        Juste pour donner un exemple simple, si on veux fixer le rate (la fréquence) des données communiquées à la carte son sous ALSA, on utilise la fonction:
        snd_pcm_hw_params_set_rate_near
        Qui retourne la valeur la plus proche possible du hardware... Et donc, tout le monde doit ensuite de demerder pour faire la conversion dans son coin..

        Et ce n'est qu'un exemple :-)
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à -2.

          C'est débile de faire de la conversion de fréquence dans le noyau.
          Pourquoi pas y ajouter des effets spéciaux tant qu'on est dans cette bêtise (écho, softvol, etc).
          Puis on pourrait ajouter un décodeur mp3. Comme ça un "cat toto.mp3 > /dev/sound" marcherait. C'est bandant non ?

          Et donc, tout le monde doit ensuite de demerder pour faire la conversion dans son coin..

          Tout le monde utilise PA ou gstreamer, etc.
          • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

            Posté par . Évalué à 4.

            Ouais enfin ya aussi une lib userland livrée avec alsa, et elle ne le fait pas non plus, d'où la nécessité d'une nouvelle couche en plus...

            Enfin l'argument de séparation kernel/userland n'est pas aussi simple que cela. Prend par exemple les périphériques video, c'est tout un bordel dans ce cas et on n'est pas encore sorti de l'auberge...
      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

        Posté par . Évalué à 10.

        Ça se voit tout de suite que Linus n'utilise pas le son sous Linux: dès que le chef ne s'en mêle pas, c'est le gros merdier.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

        Posté par . Évalué à -5.

        Je passe sur ton blabla que personne comprend et qui te vaut un score de 10. Va comprendre...
        En passant, alsa, gstreamer, PA, libaudio etc ne font pas la même chose !
        Ne les mélange pas.

        > Je fais parti des gens qui pensent que OSS4 est plutôt plus utilisable qu'Alsa au jour le jour.

        Pour faire trois rien, c'est possible. Pour le support hotplug, non, pour le bluetooth, non, etc.
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à 3.

          Bah moi je comprend en tout cas.. et je crois que les autres lecteurs qui ont mis des bonnes notes aussi. Essaie de coder une simple application qui lise un fichier WAV avec OSS et ALSA et tu aura surement un début de réponse :-)
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à 2.

          En passant, alsa, gstreamer, PA, libaudio etc ne font pas la même chose !

          Non, libaudio est supposé aider à tirer parti d'Alsa, il y arrive modérément.
          Pulse audio permet de faire pas mal de choses, mais dans 90% des cas il est utilisé comme mixeur soft, ce qui est un boulot qui devrait être assuré par Alsa et facilité par libaudio. Quand à GStreamer... On va dire que c'est une interface générique, mais avec pas mal d'exception, qui permet de décoder, de répartir et d'égaliser du son mais dont le but principal ne semble pas du tout d'être que le son qui sorte des enceintes soit le plus propre possible (Gapless, respect de la dynamique, priorité d'une appli sur l'autre etc.).

          Pour faire trois rien, c'est possible. Pour le support hotplug, non, pour le bluetooth, non, etc.

          OSS a des défauts, mais en ce qui concerne ma petite personne sur mon matos il a les avantages suivants par rapport à Alsa :

          - Jouer la musique en Gapless sans surprises notables
          - Le mixage soft fonctionne et fonctionne bien
          - Marche assez bien avec Jack/ardour sans rajouter des latences démoniaques alors que je n'ai pas un kernel realtime
          - Fonctionne aussi sous Freebsd
          - Marche très très bien avec les clients MPD et XMMS

          Après çà Alsa a des avantages technologiques indenniables sur le papier, notemment au niveau de la propreté vis à vis du kernel, mais je vais attendre qu'il y en ai quelques uns qui se réalisent dans la vraie vie avant de changer de système...
          • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

            - Jouer la musique en Gapless sans surprises notables

            Pas Alsa ?

            - Le mixage soft fonctionne et fonctionne bien

            Depuis, que j'ai du matos de merde sur mes machines (plus de place pour ma sound blaster live pci), donc 4 machines avec un chipset intel (snd_hda_intel), j'ai aussi le mixage soft et ça fonctionne très bien, jamais eu à m'en plaindre !
          • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

            Ben moi ALSA je l'ai utilisé dans notre "prototype échelle 1:1" de laboratoire de langue LLSOLL qui au dernières nouvelle équipe au moins 2 salles de classe chez les helvètes.

            Il permettait _facilement_ ET en même temps d'écouter plusieurs sources audio et video, de parler dans un micro qui pouvait émettre en multicast ET s'enregistrer dans un fichier et de recevoir du son multicast sur le simple casque micro de l'élève.

            Juste avec de la configuration alsa logiciel, en utilisant les applications standards et qui fonctionnait sur des PIII 500 avec 256 Mo de RAM

            Maintenant, je ne connais pas le travail de ceux qui écrivent du code, mais pour comprendre alsa et faire des test-case en c pour ma p.o.c, j'avais étudié les sources de aplay (qui est le même binaire que arecord) et cela ne m'avait pas _semblé_ si compliqué.

            La problématique avec les éléments complexes, c'est que tout le monde (éxagération) veut que ca marche tout de suite sans investir le temps nécessaire pour obtenir la compétence dans le produit utilisé. Et c'est la même chose pour tout et dans tous les domaines.

            La config alsa te permet _facilement_ de mapper des 'channels' sons vers d'autres, de rééchantillonner à la volée, (pour par exemple pallier à des bugs dans les pilotes de périphériques ou dans le hard du périphérique lui même) -> exemple micro-casques usb revox qui sont donnés en 16 bit stéréo mais qui en fait ne fonctionne (sous linux ??) qu'en 8 stéréo ou 16 mono.
            C'est vrai que la doc alsa est pas forcément très complète et qu'il faut surfer des heures pour tomber sur un test case qui t'aide, et que le sujet audio est assez complexe par lui même. Mais je n'accepterais jamais qu'on dise que alsa ne fasse pas son travail.

            Il le fait, bien, même si c'est complexe et pas/mal documenté.

            Ensuite, ceux qui développent peuvent toujours prendre les sources d'alsa pour lire le code... On ne peut pas dire que les 'fonctions alsa' ne sont pas parlante...
    • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

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

      En même temps, la prochaine debian stable devrait disposer d'une «architecture» GNU/kFreeBSD, et pour autant que je sache, pas de alsa dans le noyau de FreeBSD.

      Alors la fin de OSS chez debian, ça ne me semble pas être pour demain. :)
      • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

        Posté par . Évalué à 4.

        Un avantage de OSS est que contrairement à ALSA il est multi-plateforme.
        Du coup je suppose que les applications ALSA ne sont pas portables sur d'autre OS que Linux.
        Si c'est le cas c'est tout de même un gros problème non ?
        • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

          Posté par . Évalué à 2.

          Si je ne me trompe pas OSS n'existe que sur les Unix, ce qui laisse de coté Windows..
          OK, c'est 1000 fois mieux qu'ALSA qui est limité à Linux uniquement mais cela reste très insuffisant je pense..
          • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

            Posté par . Évalué à 2.

            C'est vrai. Enfin, la portabilité d'une application POSIX est de toute façon problématique sous windows, et cygwin a une API OSS, donc au final, OSS est aussi un bon choix dans ce cas.

            Non, la plateforme qui manque vraiment est OSX..
    • [^] # Re: Suppression d'OSS et état de l'audio sous Linux

      Posté par . Évalué à 2.

      Coucou

      (mode = Avis d'un MAOiste)

      C'est vrai que lorsqu'on regarde les ou plutôt les couches sons sous GNU/Linux, c'est un peu le bordel.
      À la louche, on a : OSS, ALSA, aRts, Esd, Pulseaudio, Jack, Phonon, Gstreamer, et surement d'autres que j'oublie.
      Le problème n'étant pas la multiplication de ces couches, mais plutôt la communication entre elle et leur champ d'investigation.

      Je ne pense pas que Jack soit à considérer comme le reste, en fait, l'API de jack est dédiée à la création musicale qui demande des choses bien particulières comme un contrôle de la gestion de la latence bien spécial.

      Concernant la difficulté de programmer une sortie son pour les applications, KDE semble montrer la voie avec Phonon http://phonon.kde.org/ , avec lequel il est possible de programmer un lecteur audio en 20 lignes de code (c'est pas qui le dis, je ne programme pas).

      Je pense depuis quelques temps déjà que ce qu'il manque à l'audio sous GNU/Linux, ce sont des spécifications équivalentes à http://www.freedesktop.org . Quand on aura ça, et j'estime comme une évidence le fait qu'on aura quelque chose comme cela : clair, précis et collaboratif, alors la couche audio sous GNU/Linux (et plus même) sera vraiment opérationnelle et plus intuitive.

      (mode = off)

      Voilà, c'était mon petit point de vue :)
      Olivier ( http://www.linuxmao.org )
  • # Il n'y aura plus de paquet vserver dans les futures versions de Debian ?

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

    Le patch Vserver (là aussi une solution de conteneurs permettant d'isoler des instances)
    est en situation plus précaire qu'Openvz. Du travail reste à faire pour l'intégration dans
    Squeeze. Une alerte d'abandon (deprecation) sera ajoutée dans les notes de version.


    Ça veut dire quoi ''Une alerte d'abandon (deprecation) sera ajoutée dans les notes de version'' ?
    qu'il n'y aura plus de paquet vserver dans les futures versions de Debian ?
    • [^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi

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

      D'après ce que j'ai compris il sera dans squeeze avec un avertissement disant aux gens qu'il ne sera plus disponible dans squeeze+1.
    • [^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi

      Posté par . Évalué à 3.

      Probablement qu'ils feront l'effort de le porter pour la prochaine version (ce qui est très appréciable) mais qu'après, soit les mainteneurs de Vserver se sortent les doigts du cul, soit ça saute.
      On va pas demander aux mainteneurs Debian de faire le boulot des mainteneurs upstream ou de bloquer la version du noyau indéfiniment.
      • [^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi

        Posté par . Évalué à 1.

        Mouai... comment dire...

        http://wiki.openvz.org/Download/kernel
        et http://linux-vserver.org/Welcome_to_Linux-VServer.org

        Lesquels sont moins réactifs ?
        Vserver est disponible sur les nouveau noyaux dans la semaine qui suit leur sortie... openvz ... hum ...

        Ok les patchs sont taggés experimentaux mais marchent très bien. D'ailleurs c'est un patch experimental dans lenny (qui n'est pas sans bugs: [1]). Le boulot de stabilisation devrait commencer "prochainement".
        • [^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi

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

          Ça fait des années que je refais mes paquets de noyaux avec support vserver pour Debian. Personne dans les développeurs Linux-Vserver ne souhaite supporter une version donnée : la stable en cours par exemple. Leurs arguments sont souvent : « Ils (Debian) choisissent toujours des numéros de versions foireuses du noyau et en plus ils le poluent de patchs ». Et en plus le projet semble loin de s'intégrer dans libvirt.

          Je vais définitivement passer sur openvz bien mieux supporté, même si j'estime que certaines fonctionnalité des vservers sont bien plus avancées ou audacieuses (hashification/unification, token-bucket, etc.)

          Bye bye les conf. iptables à rallonge sur l'hôte, bye bye les gains d'espace disque.
          Welcome la gestion de mes VPS en quelques ligne de ruby via libvirt.
          • [^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi

            Posté par . Évalué à 1.

            Haha iptables, au moins sur ce point je suis d'accord ( les iptables -A INPUT -i lo -d ! 127.0.0.1 -j VSERVER , c'est un peu moche) par contre, en bricollant il y a moyen de faire un fichier de regles par vserver. C'est ce que fait vs-tools notamment.

            Le patch intégré actuellement dans la stable est en effet buggé (et même troué, dans un certain sens), visiblement les devs n'ont pas été consultés au moment de l'intégration.

            Du coup, le supporter les ennuie ... un peu, et on peut facilement le comprendre.

            Pour libvirt, les dev de vserver avaient fait un patch... qui n'a jamais été intégré par les gens de libvirt...
  • # Xen ne sera pas abandonné

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

    Petite précision concernant Xen en dom0. Contrairement à Redhat, il n'est pas prévu que Debian abandonne Xen. Cependant il n'y a qu'une personne (Bastian Blank) qui s'est déclarée volontaire pour le portage des patchs depuis l'upstream (Xen fait des patchs pour la 2.6.18) vers la version du kernel qui se sera choisie par debian. Et le travail de portage est quand même important ! Suse propose déjà des patchs Dom0 pour le kernel 2.6.31 mais Debian part vers la 2.6.32. Reste donc à voir si Bastian arrivera à faire le portage avant la release de squeeze.

    Par contre ce qui est sûr c'est qu'il n'y aura plus de kernel xen pour la prochaine release après squeeze. En effet, xen va tirer parti du travail paravirt_ops sur le kernel (interface multi-hyperviseur: xen, lguest, vmware) : [http://wiki.xensource.com/xenwiki/XenParavirtOps]. On n'aura donc plus besoin de patchs spécifiques à Xen et on pourra utiliser un kernel tout ce qu'il y a de plus standard en dom0 (c'est déjà le cas pour les domU). La finalisation est prévue pour la 2.6.33 ou 2.6.34 (m'enfin je dirais plutôt 2.6.34 ou 2.6.35, au départ c'était prévu pour la 2.6.32).
  • # Empaquetage du noyau

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

    J'utilise toujours make-kpkg pour recompiler mes noyaux.

    Cet outil permet de gérer les versions (--revision) et l'utilisation ou la non utilisation de l'initrd (--initrd).

    Il ne semble pas que make deb-pkg puisse faire les mêmes choses ?
    • [^] # Re: Empaquetage du noyau

      Posté par . Évalué à 3.

      Moi aussi j'utilise et je suis très satisfait des services rendus par make-kpkg. Jusqu'ici ça reste encore, amha, la solution la plus complète et la plus efficace pour effectuer une configuration / compilation / installation de noyaux à la sauce Debian (j'imagine d'ailleurs que bon nombre d'utilisateurs de noyaux custom passent également par cette méthode).

      Les développeurs de l'équipe noyau ont décidé qu'il ne fallait plus utiliser le paquet make-kpkg car l'outil n'est plus maintenu.

      Précisons déjà qu'il s'agit du paquet kernel-package et non make-kpkg (qui est en fait la commande intégrée à ce paquet, permettant de construire ses propres images de noyau empaquetées dans un .deb).

      Au vu de son aspect indéniablement pratique, des mises à jour régulières du paquet dans unstable/sid et du suivi plus que correct des rapport de bogues, ça me surprend un peu qu'il soit question de l'abandonner. D'autant que la méthode make deb-pkg semble plus confidentielle et moins bien documentée (je ne trouve pas de résultats pertinents sur Google, ni de howto traitant directement de l'usage de make deb-pkg, y compris sur le wiki de Debian).

      Bref, c'est bien dommage et ce n'est pas la première fois, me semble-t-il (il avait déjà été question de l'abandonner, mais, pour le coup, le mainteneur y avait apporté pas mal d'améliorations). Si quelqu'un pouvait donner plus d'information à ce sujet ?

      THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

  • # A propos du 2.6.32

    Posté par . Évalué à 3.

    Phoronix a levé une forte régression des performances de postresql sur ce noyau (avec ext4) : http://www.phoronix.com/scan.php?page=article&item=linux(...)

    Bon, en fait c'est pour la bonne cause, il s'agit d'éviter un risque de perte de données dans certaines circonstances... Et si on a le matos kivabien (genre un controleur raid matériel avec une batterie chargée), on a la possibilité de contourner le souci avec un -o nobarrier au montage.

    (Pour la petite histoire, ils ont pu tracer le problème en bricolant leur suite de benchmark pour recompiler chaque révision du git, rebooter sur le noyau et relancer le test, je trouve ça magnifique dans le genre « je suis obstiné mais flemmard, je vais écrire quelques centaines de lignes de code histoire que ma machine bosse sans moi »).
    • [^] # Re: A propos du 2.6.32

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

      >« je suis obstiné mais flemmard, je vais écrire quelques centaines de lignes de code histoire que ma machine bosse sans moi »

      c'est pas un peu le principe de l'informatique / informaticien ? ;-)
    • [^] # Re: A propos du 2.6.32

      Posté par . Évalué à 2.

      Note qu'il existe deja des personnes qui font ce genre de test de non-regression,Phoronix n'a donc rien fait de nouveau, ceci dit plus il y a de testeurs mieux c'est bien sur, donc j'applaudis bien fort leur travail.
    • [^] # Re: A propos du 2.6.32

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

      > (Pour la petite histoire, ils ont pu tracer le problème en bricolant leur suite de
      > benchmark pour recompiler chaque révision du git, rebooter sur le noyau et
      > relancer le test, je trouve ça magnifique dans le genre « je suis obstiné mais
      > flemmard, je vais écrire quelques centaines de lignes de code histoire que ma
      > machine bosse sans moi »).

      Cette technique est décrite dans la documentation Linux depuis au moins 1996 : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

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

      • [^] # Re: A propos du 2.6.32

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

        Moi ce que je veux surtout savoir c'est est-ce que les distros vont laisser l'option par défaut dans le noyau 2.6.32 ou bien vont opter pour l'option -o nobarrier.
        Le perte de perfs à l'air monstrueuse quand même donc j'espère que le choix se fera sur -o nobarrier.
        • [^] # Re: A propos du 2.6.32

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

          Le problème impacte-t-il seulement postgres ?
          • [^] # Re: A propos du 2.6.32

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

            Sans doute pas...cela a juste été mis en évidence dans le bench utilisant postgres mais ça doit impacter d'autres trucs.
            Il va falloir attendre les premières versions de dev des distros se basant sur le 2.6.32 pour voir ce qui aura été choisi au point de vue des options de montage.
        • [^] # Re: A propos du 2.6.32

          Posté par . Évalué à 4.

          Fiabilité vs performance, l'éternel compromis: je me souviens d'un essai de désactiver le cache en écriture des disques afin d'éviter des problèmes de corruption de FS, les performances étaient tellement mauvaise qu'on l'a réactivé..

          Le plus dommage la dedans, c'est que si les disques SATA/IDE ne mentaient pas a propos de "quand les données sont écrites réellement sur le plateau" on pourrait avoir de meilleure performance de manière fiable, mais a ce moment la les benchmark seraient moins favorable
          --> les constructeurs optimisent leur disques pour les benchmark et non pas pour la vie réelle, quelle ironie..
          • [^] # Re: A propos du 2.6.32

            Posté par . Évalué à 4.

            C'est tout le problème de tous ces "indicateurs" dont les décideurs, tant en entreprise qu'en politique, se délectent. Au final, ils sont nuisibles car ils deviennent un but.

Suivre le flux des commentaires

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