🚲 Tanguy Ortolo a écrit 12509 commentaires

Bienvenue dans le futur de la monnaie.

Bitcoin est peut-être vu comme tel, mais c'est une vision à très court terme. Pour ceux qui ne seraient pas au courant, la masse monétaire maximale de bitcoin est de 21 millions d'unités — sans compter qu'il peut peut-être y avoir de la perte entre-temps, je n'ai pas vérifié ce que pouvaient devenir des bitcoins perdus ou jamais découverts — ce qui est ridiculement faible par rapport à la population mondiale. Certes, le bitcoin peut être subdivisé en cent-millionnièmes pour un total de 21×10¹⁴, mais ça n'aurait rien de pratiques d'utiliser des millionnièmes de bitcoins…

Ça, c'est hors sujet. On parle de faire passer plusieurs choses sur ALSA : mon PulseAudio, et MPD. Ou mon PulseAudio, et celui de MPD.

Pulseaudio marche trés bien en multi-utilisateur, mais il lui fait un daemon par utilisateur.

Sauf quand, chez moi par exemple, PulseAudio ne peut pas partager la carte son avec qui que ce soit d'autre, en particulier avec un autre PulseAudio… Reste à savoir pourquoi, maintenant.

Non, c'est plutôt indépendant de la puissance du processeur, pour ce que j'en ai vu.

Déjà il est pas parallèle à Alsa mais au dessus, ensuite en sélectionnant la bonne sortie il est parfaitement possible d'utiliser Alsa sans que PulseAudio ne le sache http://gentoouser.free.fr/anpulse.jpg

Pas chez moi.

Concernant l'utilisation de PulseAudio en environnement multi-utilisateurs, j'ai jamais testé, mais vu les objectifs du projet ça m’étonne que ça ne marche pas.

Ça marche, mais c'est fortement déconseillé et fortement bridé. http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/

Ah, curieux. Chez moi, PulseAudio monopolise la carte son, qui est inutilisable par autre chose en parallèle.

Ah, et puis aussi, une combinaison de caractéristiques haïssables de PulseAudio :

• il occupe la carte son de façon exclusive, pas possible de l'utiliser en même temps par ALSA ou avec un autre PulseAudio ;
• le mode « système », c'est à dire avec un PulseAudio global au système, lancé au démarrage sous un utilisateur dédié, est fortement découragé et même bridé parce qu'officiellement « pas utile dans la vraie vie, si vous l'utilisez vous avez tort », sans sauvegarde des réglages par exemple.

Résultat donc : PulseAudio est peu utilisable en environnement multi-utilisateurs. Ce n'est pas bien important pour un système de son, me direz-vous, puisque le son n'est utile qu'à l'utilisateur qui est effectivement devant les enceintes. Sauf que MPD. Le démon de lecture de musique est conçu pour tourner sous un utilisateur dédié, et ne peut donc pas accéder directement à la carte son par ALSA — elle est déjà réservée à PulseAudio — ni par PulseAudio — qui est réservé à l'utilisateur assis devant l'ordinateur. Du coup il faut lancer PulseAudio en mode système, avec tous les inconvénients que cela implique.

Un comble pour un logiciel développé par celui qui a introduit une usine à gaz que personne ne comprend, PolicyKit/ConsoleKit, pour pallier des manques de la gestion de permissions dans un contexte multi-utilisateurs par simples groupes Unix et introduire une finesse dont personne n'a vraiment besoin. Oui, ça permet de n'autoriser la lecture de son que par ceux qui sont connectés à la console physique, plutôt qu'à tous ceux du groupe audio y compris par SSH, mais qui s'en fout ?

Le son par le réseau […] est normalement bien mieux géré.

Pris en charge tout court.

Le son par […] Bluetooth est normalement bien mieux géré.

Non, seulement l'ajout et le retrait de cartes sont, que ce soit par dent bleue ou par USB. Donc, par corollaire, les cartes son bluetooth sont mieux prises en charge tout court parce que par définition, ce sont des cartes qu'on ajoute après démarrage.

Disons que sur les ordinateurs sur lesquels il fonctionne bien, j'en suis tout à fait satisfait. Comme dit plus haut, ce n'est pas le cas de mon ordinateur fixe personnel, malheureusement.

J'utilise PulseAudio parce que c'est devenu plus ou moins incontournable, mais je n'aime pas ça, d'autant que sur mon ordinateur fixe personnel, il produit un son abominable — saturé de grésillements et avec un écho d'une seconde — avec VLC, jusqu'à ce que je joue assez avec pavucontrol pour que ces artefacts cessent, parfois complètement, parfois en laissant un léger grésillement.

La fossilisation du web. Le courrier électronique a su évoluer en introduisant les enregistrements MX, mais le web, ou plutôt les navigateurs web, sont beaucoup, beaucoup moins capables de s'adapter ainsi.

Je dois être très fatigué ou très bête (ce qui expliquerait la note de mon commentaire précédent…) mais du coup je ne vois pas comment faire l'enregistrement DNS pour que http://example.com pointe vers mon serveur web…

Deux solutions :

1. introduire une nouvelle version d'HTTP utilisant des enregistrements de service, et attendre que les navigateurs la prennent en charge, comme ça a été fait il y a bien longtemps avec le courrier électronique lors de l'introduction des enregistrements MX ;
2. mettre l'IP directement.

Pas d'autre solution.

Ah, c'est ça, je me souviens en effet, ça parlait du choix du couteau approprié pour le tartinage de Nutella sur des sandwitchs à la morue aux fraises accompagnés de cassoulet. C'est pour ça que je ne le retrouvais plus.

Excuse-moi de te dire ça mon pauvre Rock, mais tu confonds un peu tout. Tu fais un amalgame entre la réalisation et la restauration. Tu es fou. […] Je préfère partir plutôt que d'entendre ça plutôt que d'être sourd.

La Classe Américaine, peut-être le moins connu de ses films, mais dont le réalisateur a la particularité d'avoir été également… Debian Project Leader !

Non non non. La Classe américaine, c'est de Michel Hazanavicius. L'ancien DPL, c'est Sam Hocevar, qui a restauré la Classe à partir des DVD des flims originaux.

Non, c'est une startup bien française développée uniquement par le privé.

Avec des développeurs qui aiment les gays vu les couleurs d'arc-en-ciel, mais qui ne sont pas gays sinon ce ne serait pas si, euh, comment dire, si criard, si… gerbant, comme vient de le suggérer. Excusez-moi, c'est vendredi.

Ah oui, ça c'est très, très agaçant. Il me semble que ça pouvait être pallié en forçant deux ou trois paramètres dans l'URL.

Si c'est bien ce qu'il me semble, ça s'explique mieux avec un exemple. Supposons que tu tes souviennes d'avoir lu une page web donnant de bons conseils pour choisir un couteau adapté pour le tartinage de nutella sur des sandwitchs de morues aux fraises. Tu vas probablement écrire la requête suivante : « couteau tartine nutella sandwitch morue fraises ».

Seulement, Google ne va pas trouver grand chose avec tout ça à la fois, du coup il va te proposer en première page des résultats contenant trois mots parmi tout cela, par exemple des pages parlant de couteau, de tartines et de nutella, ou de sandwitch, de nutella et de fraises, ou de couteau, de sandwitch et de morue.

Pas de chance, toi, ce que tu cherches, ce n'est pas du tout ça, mais une page très précise. Ta requête, ce serait plutôt « couteau && tartine && nutella && sandwitch && morue && fraises », et si ça donne très, très peu de résultats, c'est normal. Et bien, si je me souviens bien donc, le + devant un mot, c'était un moyen de dire à Google : « ne fais pas la malin, je ne veux que des pages avec ce mot-là dedans, bordel ».

Pour lancer systemd, je ne configure rien du tout : au démarrage, j'édite la ligne d'appel de Linux pour ajouter init=/bin/systemd. systemd n'est pas réservé aux gens qui n'utilisent que systemd en permanence, il y a aussi des gens qui veulent pouvoir le tester momentanément.

Mais ce n'est pas grave, on a l'habitude des décisions de Lennart sans concertation et en violation des normes, donc dans Debian, le paquet de systemd continuera à introduire le correctif pour cette mauvaise décision.

systemd ne peut être lancé par personne mis à part par le noyau.

Aucun logiciel ne peut être lancé par personne mis à part le noyau. Dans le cas de systemd, en lui fournissant le paramètre init= au démarrage. Dans le cas des autres logiciels, avec un appel système exec.

Ce n'est pas un binaire interne, et il est prévu pour être utilisé par un utilisateur bien particulier, l'administrateur.

Donc aucun intérêt à ce que le binaire soit dans le $PATH.

Dans le PATH non. À un endroit standard oui.

Non mais de demander moi-même à Linux de lancer un init particulier, typiquement systemd à la place de mon init System V habituel, oui.

En même temps je ne lance jamais aucun logiciel moi-même, la plupart du temps je demande à mon shell de demander à Linux de le faire…

Par les utilisateurs non, mais par l'administrateur, d'où la pertinence de /sbin plutôt que /bin. Je pense que l'utilisation de /bin pour cela est surtout historique.

Mais justement, ce qu'ils appellent « drivers », ce ne sont pas des pilotes, mais aussi des logiciels de gestion à la noix. Un pilote Windows, ce sont quelques fichiers et une description .inf. Or ce qui est fourni, c'est à peu près toujours un exécutable obèse, qui installe le pilote, plus un logiciel inutile avec une interface spécifique, laide et qui jure avec tout le reste un nom du style “Atheros wireless network manager”, “Intel audio assistant”, “HP Print Queue Services”.

Je me souviens d'un réflexe que j'avais acquis avec Windows 98, et donc j'ai pu vérifier qu'il est toujours valable : quand on a un nouvel {appareil photo|imprimante|accès à Internet}, première chose à faire, jeter le CD fourni avec. Ou mieux, pour éviter tout risque que quelqu'un installe leurs merdes, le broyer. Le brûler donne également des résultats satisfaisants mais dégage des fumées désagréables et peut-être dangereuses.