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é.
Aller plus loin
- Le résumé de la réunion (3 clics)
- Le compte-rendu complet (2 clics)
- PlumbersConf 2009 (2 clics)
- Aider le projet Debian (5 clics)
- Debian sur DMOZ (6 clics)
# Merci..
Posté par Grunt . Évalué à 5.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Merci..
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Merci..
Posté par patrick_g (site web personnel) . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 3.
D'un autre coté, une bonne traduction sais s'affranchir du texte initial pour s'adapter à la langue choisie ;-)
[^] # Re: Merci..
Posté par campagnard . Évalué à 9.
"Une traduction, c'est comme une femme : si elle est belle elle est infidèle"
C'est ce que me disais une de mes profs (femme) d'italien ^^
[^] # Re: Merci..
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Merci..
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Merci..
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Merci..
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Merci..
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Merci..
Posté par Uvoguine . Évalué à 3.
[^] # Re: Merci..
Posté par Sylvain Blandel . Évalué à -4.
[^] # Re: Merci..
Posté par FantastIX . Évalué à 1.
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 Victor STINNER (site web personnel) . Évalué à 7.
[^] # Re: Microcodes
Posté par Grunt . Évalué à 10.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
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 thedude . Évalué à -8.
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 Victor STINNER (site web personnel) . Évalué à 10.
[^] # Re: Microcodes
Posté par thedude . Évalué à -4.
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 legranblon (site web personnel) . Évalué à 3.
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 thedude . Évalué à 0.
Quelle eglise?
[^] # Re: Microcodes
Posté par Grunt . Évalué à 2.
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 Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Microcodes
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Microcodes
Posté par Grunt . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 8.
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 gemegik . Évalué à 2.
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 Grunt . Évalué à -1.
À 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 Sytoka Modon (site web personnel) . Évalué à 9.
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 GeneralZod . Évalué à 5.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 bubar🦥 (Mastodon) . Évalué à 3.
[^] # Re: Microcodes
Posté par Unixfix le Gaulois . Évalué à -1.
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 PachaFonk . Évalué à 5.
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 Unixfix le Gaulois . Évalué à -10.
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 psychoslave__ (site web personnel) . Évalué à 6.
Le respect ça n'est pas quelque chose qui fonctionne à sens unique…
[^] # Re: Microcodes
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Microcodes
Posté par Grunt . Évalué à 5.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Microcodes
Posté par reno . Évalué à 7.
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 patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Microcodes
Posté par reno . Évalué à 4.
Merci pour tes articles.
# Suppression d'OSS et état de l'audio sous Linux
Posté par Victor STINNER (site web personnel) . Évalué à 5.
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 Romain Be. . Évalué à 9.
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 gnumdk (site web personnel) . Évalué à 3.
-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 Zenitram (site web personnel) . Évalué à 10.
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 B16F4RV4RD1N . Évalué à 9.
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 IsNotGood . Évalué à 1.
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 Romain Be. . Évalué à 3.
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 dguihal . Évalué à 5.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Alek_Lyon . Évalué à 5.
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 Troy McClure (site web personnel) . Évalué à 3.
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 Laurent A. . Évalué à 5.
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 bubar🦥 (Mastodon) . Évalué à 5.
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 IsNotGood . Évalué à 1.
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 Jerome Herman . Évalué à 10.
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 Romain Be. . Évalué à 5.
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 IsNotGood . Évalué à -2.
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 Romain Be. . Évalué à 4.
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 Grunt . Évalué à 10.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par IsNotGood . Évalué à -5.
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 Romain Be. . Évalué à 3.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par gnumdk (site web personnel) . Évalué à 4.
Alsa n'a jamais été créer pour être simple, en tout cas vu ce que j'ai lu sur kerneltrap.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Jerome Herman . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 2.
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 hervé Couvelard . Évalué à 4.
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 psychoslave__ (site web personnel) . Évalué à 7.
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 Ghis . Évalué à 4.
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 reno . Évalué à 2.
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 Romain Be. . Évalué à 2.
Non, la plateforme qui manque vraiment est OSX..
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Olivier HUMBERT (site web personnel) . Évalué à 2.
(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 )
https://librazik.tuxfamily.org - http://linuxmao.org - https://liberapay.com/trebmuh
# Il n'y aura plus de paquet vserver dans les futures versions de Debian ?
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
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 patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi
Posté par GeneralZod . Évalué à 3.
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 geb . Évalué à 1.
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 Val (site web personnel) . Évalué à 3.
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 geb . Évalué à 1.
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...
[^] # Re: Il n'y aura plus de paquet vserver dans les futures versions de Debi
Posté par GeneralZod . Évalué à 3.
Et pour cause, il n'a jamais été soumis pour inclusion dans libvirt.
https://www.redhat.com/archives/libvir-list/2009-June/msg001(...)
# Xen ne sera pas abandonné
Posté par Sylvain AVRIL (site web personnel) . Évalué à 3.
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 Frédéric Massot (site web personnel) . Évalué à 5.
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 THR4K . Évalué à 3.
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 nodens . Évalué à 3.
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 CrEv (site web personnel) . Évalué à 7.
c'est pas un peu le principe de l'informatique / informaticien ? ;-)
[^] # Re: A propos du 2.6.32
Posté par psychoslave__ (site web personnel) . Évalué à 4.
–>[]
[^] # Re: A propos du 2.6.32
Posté par reno . Évalué à 2.
[^] # Re: A propos du 2.6.32
Posté par Krunch (site web personnel) . Évalué à 3.
> 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 patrick_g (site web personnel) . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: A propos du 2.6.32
Posté par patrick_g (site web personnel) . Évalué à 2.
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 reno . Évalué à 4.
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 gpe . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.