On va te que tu peux voir ça via l'overview, mais c'est en effet moins pratique qu'à la souris.
Ça va si c'est juste pour « voir », si c'est pour interagir avec c'est une plaie.
Il y a encore tout plein d'applis de la dernière décénie qui mettent une icône en zone de notification avec un menu et diverses actions…
au hasard le gestionnaire de dictionnaire stardict (j'en ai besoin quand j'écris du texte, mais jamais dans l'overview)
divers logiciels de reconnaissance d'écriture ou de claviers virtuels comme cellwriter ou onboard (il faut passer par l'overview pour l'afficher ailleurs que dans l'overview, avec la contraposée qu'elle ne s'affichera pas dans l'overview même si c'est le seul endroit en tactile pour commander son affichage).
Certaines actions sont quasiment impossibles à faire en tactile seul : devoir faire une action dans l'overview pour qu'elle agisse sur un élément en mode normal, et avoir l'action dans l'overview est quasi impossible.
Enfin de toute manière, cette gestion de la barre de notification est foireuse, même sans tactile… Mais ça peut encore se comprendre et s'utiliser avec une souris clavier même si certains cas sont un peu tordus, en tactile c'est tout simplement inutilisable.
ce commentaire est sous licence cc by 4 et précédentes
D'un point de vue utilisateur, il y a toujours eu un mode « classique » donc ce ne peut être un retour en arrière.
D'un point de vue développeur, du vieux code va être mit à la poubelle, pour n'utiliser que les nouvelles briques de Gnome Shell et ne pas maintenir des vieilleries pour ça. C'est tout l'inverse d'un retour en arrière.
Cela dit le titre de l'article que tu lies est déjà faux, Gnome ne présente pas un « mode classique », mais sa nouvelle implémentation. Je cite le titre et le sous-titre de l'article de PcInpact :
GNOME 3.8 fait le plein de nouveautés et présente un mode classique
Suffisant pour empêcher les utilisateurs de se tourner vers MATE ?
Le titre étant faux, le sous-titre l'est aussi s'il sous-entend que le mode classique empêcherait des personnes d'utiliser Mate (le fork Mate a été créé alors que le mode classique existait déjà).
ce commentaire est sous licence cc by 4 et précédentes
Deux bons contre-exemple du « Gnome Shell c'est fait pour le tactile » :
on ne peut pas mettre en veille : il faut une touche Alt (donc un clavier)
barre de notification inaccessible au doigt : il faut un dispositif de pointage indépendant de l'écran (souris, trackball, trackpoint…) pour faire le geste qui va montrer ladite barre, le doigt ou le stylet sont inadaptés
Donc si la proposition « Gnome Shell c'est fait pour le tactile » était vraie, il se sont complètement plantés.
(J'ai un écran tactile et j'utilise Gnome Shell)
Sur un bureau je trouve Gnome Shell très pratique.
ce commentaire est sous licence cc by 4 et précédentes
Tu parles technique, moi je parle du point de vue utilisateur. A la base on s'en fiche que ce soit une extension ou autre chose : ce qui compte c'est la façon de l'utiliser …
Mais dans les faits ça signifie un changement de mentalité et d'orientation de la part de Gnome.
Justement… dans les faits, il y a TOUJOURS eu un mode « Gnome classic », c'est juste l'implémentation qui change. Avant il y avait deux logiciels, maintenant il n'y en a plus qu'un, mais ça l'utilisateur s'en moque : du point de vue utilisateur, il y a toujours eu un mode « classic ».
Donc non, pas de changement de mentalité ni d'orientation, c'est un changement d'implémentation (s'il y a un changement de mentalité il est sur la manière de coder, si par exemple ils se voyaient contraint de réimplémenter ce pourquoi Mint a forké).
ce commentaire est sous licence cc by 4 et précédentes
Je n'ai pas encore fini de lire l'article mais je ne peux m'empêcher de commenter.
ce type de phrase sent à plein nez l'idée suivante :
je ne veux pas commenter l'article, je veux témoigner mon pressentiment
Effectivement ce genre de commentaire est très courant sur beaucoup de médias, et heureusement encore faible sur LinuxFr malgré une augmentation sensible. C'est le règne des impressions et de l'affect sur la raison. « Je ne sais pas vraiment ce que tu as dit, mais ça me donne envie d'être d'accord/pas d'accord »
ce commentaire est sous licence cc by 4 et précédentes
Clair qu'il y a une différence… mais je crois qu'il faut comprendre qu'en TI-Basic (celui des z80 et celui des 68k) ainsi que dans le basic des casios et comme en C, on peut écrire une boucle for qui aurait pu être écrite par une boucle while de ce type :
Quand le lycéen a déjà fait ça dans sa vie, c'est facile de lui dire qu'en C on fait ainsi :
/* C */for(i=2;i<10;i+=4)
Le lycéen comprend tout de suite, en faisant remarquer tout de même que c'est un peu verbeux.
Alors oui on peut faire tout à fait autre chose avec le for du C (c'est pourquoi il est plus verbeux), mais ce qui compte c'est qu'il puisse retrouver ses marques et reproduire le peu qu'il connaît déjà.
Tu mets ce même lycéen devant un for i in 2 6 10 du shell ou du Python, il capte pas et c'est normal, l'exemple que je viens de donner n'est pas le bon exemple pour expliquer le for en Python. Pour utiliser for en Python dans le cas de figure présent (for i from 2 to 10 step 4), il va falloir enseigner d'abord d'autres concepts…
C'est pas tant que le TI-Basic est comme le C, c'est qu'on peut très facilement tordre C pour qu'il ressemble à du TI-Basic. Avec Python, certains concepts de base sont différents et homonymes.
ce commentaire est sous licence cc by 4 et précédentes
Ne confond pas le monde dans ta tête et le monde dans la vraie vie. Pendant au moins six interventions, personne n'a interagit avec toi en vrai. Les gens dans ta tête ne comptent pas.
ce commentaire est sous licence cc by 4 et précédentes
Un worker est un thread indépendant.
Quand tu l'initialize tu lui passe l'URL d'un fichier Javascript et il se charge de le télécharger et l'executer. Il n'est pas possible de l'initializer avec une fonction.
De plus il faut comprendre que ça implique que les workers ne peuvent pas directement modifier le DOM.
Si je comprends bien, un worker est un moyen technique permettant à une page web de lancer un script en tâche de fond dans la vm de mon navigateur, avec la garantie que le travail effectué ne pourra pas impacter le rendu de la page que je demande, ce qui signifie autrement qu'un worker ne peut être un moyen efficace pour répondre à ma requête (à moins de contournement) ? C'est une question de néophyte… mais vu comme ça, à quoi peut servir un worker autrement que pour utiliser mon CPU pour autre chose que la page que je regarde ? Peut-on avoir des exemples concrets avec lesquels un worker sert à autre chose qu'étendre un système de calcul distribué ?
ce commentaire est sous licence cc by 4 et précédentes
J'ai une question "après cette trop longue vacance" : cette syntaxe est-elle volontaire ?
En fait c'était une allusion à la « vacance du siège pontifical », la panne de LinuxFR étant survenue en même temps que le conclave. C'était une manière fumeuse (hihi) de comparer l'attente du lectorat de LinuxFR avec celle de quelques (millions ? milliards ?) de croyants pour un nouveau pape.
Dans ce cas précis, on parle bien d'une vacance au singulier, du latin vacare, être sans. Au pluriel, « les vacances » se réfèrent habituellement au repos, hors ce qu'a du vivre le lectorat pendant la panne n'est pas vraiment un repos, mais un manque.
C'est que l'absence de ce site a du éprouver nombre de ses fidèles ! En tout cas moi j'ai trouvé cela interminable. :)
J'avais trouvé l'allusion dans l'air du temps (j'en ai glissé d'autres)… mais elle n'est peut-être pas très accessible en effet.
Pour ceux qui suivent l'actualité, on parle ces jours-ci de la prochaine installation du pape. Y a moyen de faire des blagues sur les gestionnaires de paquet… Dans un domaine proche, on parle de l' érection d'une cathédrale. Il y a bien que les cathos pour utiliser encore de tels mots connotés et qui surtout ne sont plus compris dans ces sens là. ;)
journal très intéressant malgré une certaine longueur
J'ai eu un peu peur moi-même de la longueur, j'aurai voulu le faire plus court, mais j'ai trouvé dans ce cas pratique une bonne occasion de présenter ctypes et de lister quelques pièges difficiles.
Les tutos donnent toujours des cas généraux qu'on ne rencontre jamais dans la réalité. En l'occurrence ici les difficultés principales étaient de manipuler des pointeurs sur des objets que nous ne connaissons pas (!) et dont le type de n'est pas connu (je ne sais toujours pas ce qu'il y a au bout du pointeur *handle, par exemple), et de contourner l'usage de macros et autres usages du préprocesseur : la fausse fonction rencontrée dans le présent journal, les constantes…
On voit bien la difficulté de dialoguer avec une bibliothèque C quand elle n'est prévue que pour être utilisée depuis un langage compilé. On prend conscience aussi que certaines manières de programmer n'ont pu naître que parce que le concept de compilation le permet. Certains concepts comme le préprocesseur, par exemple, entraînent une différenciation entre les symboles source et les symboles binaires. Je n'aimerai pas devoir travailler avec ctypes sur une bibliothèque dont la compilation source prévoir l'usage d'outils comme moc par exemple. Les langages qui compilent vers le C (comme Vala) posent le même problème.
Suite à cette expérience, je sais que si je devais développer une bibliothèque en C, j'éviterai au maximum d'utiliser le préprocesseur si je prévois qu'elle puisse être utilisée directement telle quelle sans compilation.
J'ai donc essayé de faire plus court… mais je n'ai pas réussi à raccourcir sans retirer des clés. ;)
ce commentaire est sous licence cc by 4 et précédentes
En simple utilisateur tu dois pouvoir faire quelque chose du genre :
setxkbmap -device $(xinput list --id-only "Yubikey") us
En ayant repéré préalablement le nom exact avec xinput --list
(Juste pour information, pour faire exactement la même chose que ce qu'a indiqué rahan<, avec le variant et le model, ce serait ainsi : setxkbmap -device $(xinput list --id-only "Yubikey") us intl -model pc101`)
ce commentaire est sous licence cc by 4 et précédentes
En tant que développeur libre, j'ai autant de merdes avec H264 que VP8 : si je les fais évoluer, je me prend un procès au cul.
Oui et non, tout développement n'implique pas une évolution d'une partie. C'est justement l'objet d'un standard, faire comme les autres. Pour faire différemment c'est la galère, pour faire comme les autres c'est OK. Pour ça on peut dire que c'est une excellente nouvelle, beaucoup demandent d'avoir des standards plutôt que d'hypothétiques trucs de kéké vraiment mieux mais inutilisable en réalité.
Beaucoup de développeurs libres sont certainement content de pouvoir utiliser le standard Opus, en développent leur ingénierie sur d'autres point.
Par exemple j'utilise personnellement Opus, mais je laisse le développement d'Opus à d'autres.
Donc ce n'est qu'une fraction des développeurs libres qui sont impactés : ceux qui font évoluer les codecs. C'est super dommage pour eux. Mais l'annonce ne crée pas cette injustice, elle ne fait que la révéler.
ce commentaire est sous licence cc by 4 et précédentes
Tu notera qu'il ne parle pas d'un gain pour Google mais d'un gain pour le monde du libre (FOSS).
Ben c'est un gain pour tous les utilisateurs du standard VP8 (le monde libre étant un sous-ensemble des utilisateurs de standards). Donc c'est énorme !
Par contre oui, ce n'est pas un gain pour l'utilisateur de certains algorithme en dehors de VP8. Pour celui qui n'a aucun intérêt dans VP8, cette annonce ne fait que confirmer l'état déplorable de ce domaine de la recherche. Mais ça, c'était déjà vrai… Cette annonce n'est qu'un révélateur. Ne tirons pas sur le messager. ;)
ce commentaire est sous licence cc by 4 et précédentes
En parlant de librisme antibrevet, je pensais aux brevets qui constituent une menace possible (ce qui fait que certains projets libres se retrouvent dans non-free à défaut de ne savoir où les mettre).
Si on veut virer vraiment tous les brevets, même ceux dont on ne craint pas, ça va être dur ! Surtout si on compte les brevets déposés explicitement pour protéger des projets libres, afin d'avoir suffisamment de bonnes cartes à poser sur la table du poker des brevets, afin, au moins, de poursuivre la partie sans trop grosses pertes…
ce commentaire est sous licence cc by 4 et précédentes
C'est un peu l'effet que ça me fait. D'un certain coté il y a tout de même une bonne chose qu'on ne peut pas enlever : on peut utiliser VP8 sans crainte, et VP8, ce n'est pas que « VP8 de Google », c'est aussi « VP8 de la RFC 6386 ». Donc c'est très bien que ce format documenté et standardisé soit utilisable sans crainte, même si un quelconque VP8.31415926 n'est pas protégé. VP8 a donc deux avantages majeurs, d'une il est standardisé, de deux il est sans redevance, de trois il ne craint pas les attaques du MPEGLA. Ces trois arguments peuvent être suffisants pour choisir VP8, même s'il est techniquement moins bon qu'un autre. Je suis certain que ce genre de cas doit se produire, on ne choisit pas nécessairement le meilleur techniquement si des points non techniques sont jugés trop gênants.
Par exemple, je rippe personnellement mes DVD avec des options de de qualité indécente… En gros je demande « conserve au max la qualité de l'image au détriment de l'espace disque », il y a des chances que dans ce type de configuration, on ne sache pas faire la différence entre h264 ou vp8… Avec VP8, j'ai au moins l'espoir de pouvoir lire mes rips même avec un distribution pour intégroïdes libristes antibrevets…
J'imagine qu'il y a des cas où VP8 et h264 c'est kifkif, ou bien que la moindre performance ou moindre qualité pèse peu dans la balance vis à vis d'autres avantages.
Pour faire une analogie, il doit bien y avoir des usages où VP8 est préféré, un peu comme ceux qui utilisent Gimp même s'il est paraît-il moins avancé que Photoshop, mais parce qu'au moins Gimp est libre, tourne sous Linux et en plus est gratuit… (C'est aussi mon cas ;)) À quoi servirait à un produit d'être meilleur si l'on ne peut se le procurer ou s'en servir ? ;)
Donc on ne peut nier cette annonce qui est tout de même positive. On n'en sait rien pour les dérivés, mais on le sait pour le standard ! C'est énorme !
Après oui, ton commentaire décrit bien l'effet que ça me fait, et exprime bien les craintes que l'on peut se faire, je ne te pertinente pas toujours mais là oui ;). Effectivement, tout cela n'est pas rose dans l'univers des codecs vidéos, et le besoin d'un pacte de non agression Google / MPEGLA ne fait que confirmer que ce domaine est pourri. Donc on peut pleurer encore plus en constatant que oui, effectivement, même pour VP8 qui est sensé ne rien avoir en commun avec le MPEGLA il a fallu demander protection au MPEGLA… Donc c'est la misère, mais en même temps ça l'était déjà, on le savait déjà que c'est un champ de mine, ça ne fait que confirmer la chose, et si Google doit passer un accord avec le MPEGLA, à mon avis il ne faut pas vraiment le tenir pour responsable de n'avoir pu protéger que VP8. ;)
ce commentaire est sous licence cc by 4 et précédentes
Quel successeur ? Qui et quoi détermine quel probable projet successeur parmi d'autres sera protégé ?
Est-ce que, au moins, on peut dire « VP8 est protégé, et donc tout ce qui est dans VP8 et qui pourrait se retrouver ailleurs (comme dans un VP9 ou toute autre chose) » ? Avec l'idée qu'il ne resterait aux divers successeurs que de vérifier si et seulement si « ce qui diffère » est attaquable. Genre « OK je peux dès maintenant forker VP8, et pour les améliorations que je vais ajouter je vais faire attention, au moins je n'ai pas à vérifier cette grosse partie là ni l'ensemble, seulement les parties. », Ou bien « Tiens j'ai du mal sur mon codec maison, je vais piquer ça dans VP8, en indiquant clairement que cela vient de VP8 donc je suis protégé au moins sur cette partie ». Ça serait cool ! Pour le moment, tel que les articles grand publics présentent la chose, cela me semble bien flou.
Je préférerait lire cela, au moins on serait clairement fixé. « VP8 et son successeur » ne veut rien dire, ce successeur étant bien flou !
C’est cette menace qui vient d’être retirée suite à l’accord conclu entre MPEG LA et Google concernant les brevets gérés par le premier et sur lesquels VP8
Et si ces mêmes brevets sont susceptibles de me porter préjudice sur mon hypothétique codec maison qui ne serait pas VP8 mais qui partagerait avec lui certains algorithmes, est-ce qu'il me faut réussir à démontrer que « Toute cette partie c'est VP8 en fait », ou bien je risquerai de me prendre dans la figure la remarque « OK, tu fais exactement comme VP8, mais seulement dans cette partie là. C'est pas VP8, donc brousoufs ! ». Auquel cas ce serait difficile de protéger un « successeur », et certains vont se battre pour réclamer cette reconnaissance ! « C'est moi VP9 ! Non c'est moi »
Si quelque un en sait plus que les articles de vulgarisation, qu'il n'hésite pas à expliquer et détailler ! je remercie d'avance son commentaire. ;)
ce commentaire est sous licence cc by 4 et précédentes
idem pour le wifi, il y a plein de geeks pour dire « ma machinbox fonctionne très bien, aucun reboot en 6 mois », mais en fait avec un AP wifi dédié au cul. Hors chez certaines machinbox, à partir de deux ou trois connexions wifi simultanées… ça fume !
ce commentaire est sous licence cc by 4 et précédentes
ma livebox, branchée depuis 6 mois sur un onduleur
Effectivement avec un onduleur ça peut aider…
De la même manière, j'ai fais deux fois l'expérience, avec une alicebox, et avec une livebox, que « quand on n'utilise pas le DNS de la machinbox, il n'y a pas besoin de la rebooter toutes les deux semaines ».
Je crois que pour comparer des produits très grand public, il faut les comparer sans onduleur, parce qu'une livebox branchée sur un onduleur, ça doit pas être très grand public ! :)
ce commentaire est sous licence cc by 4 et précédentes
pour ceux qui cherchent, la compilation c'est gcc alsacap.c -o alsacap -lasound (j'ai cherché un moment le -lasound, trouvé avec pkg-config --libs alsa).
Voilà ce que ça me donne sur une machine de test :
$ ./alsacap | grep '^Card' -A 3 | grep -v 'Subdevice\|--\|Device' | sed -e 's/, (*[0-9]* .*//;s/, sampling rate/\n rate:/;s/Sample //' | sed -e 's/[0-9]\.\.\([0-9]*\) chann/\1 chann/;s/\([0-9]*\) channels/channels: \1/;s/ Hz//'
Card 0, ID `XFi', name `Creative X-Fi'
channels: 8
rate: 8000..192000
formats: U8, S16_LE, S32_LE, FLOAT_LE, S24_3LE
Card 1, ID `CODEC', name `USB Audio CODEC'
channels: 2
rate: 32000..48000
formats: S8, U8, S16_LE
Card 2, ID `LT3', name `Muse Pocket LT3'
channels: 8
rate: 44100..48000
formats: S16_LE
Card 3, ID `Intel', name `HDA Intel'
channels: 8
rate: 44100..192000
formats: S16_LE, S32_LE
Card 4, ID `Juli', name `ESI Juli@'
channels: 2
rate: 16000..192000
formats: S32_LE
Card 5, ID `Live', name `SB PCI512 [CT4790]'
channels: 2
rate: 4000..96000
formats: U8, S16_LE
Card 6, ID `Live1', name `SB Live! Value [CT4832]'
channels: 2
rate: 4000..96000
formats: U8, S16_LE
ce commentaire est sous licence cc by 4 et précédentes
dernière version il y a fort longtemps et le serveur ne répond pas (projet mort ? qui a les sources ?)
Bref, je préfèrerai utiliser python-pyalsa à cause de son coté « officiel », mais pour Python 3 seul python-alsaaudio est actuellement disponible, et rien n'est dans Debian. Dur dur !
ce commentaire est sous licence cc by 4 et précédentes
Oh ça c'est bon !
S'il faut compiler quelque chose, je préfère compiler alsacap que tout un module python !
Aussi, ça me fournit un exemple concis d'asoundlib, et je pourrais peut-être reproduire les quelques fonctionnalité qui m'intéressent en utilisant ctypes, cité plus bas !
ce commentaire est sous licence cc by 4 et précédentes
Justement, j'évite de trop m'avancer sur ce sujet de « D-Bus dans le noyau » parce que
je n'y connais pas grand chose au noyau
ça m'a l'air franchement lointain
je ne vois pas ce que ça changerai pour moi, et c'est peut-être la seule chose que j'ai vraiment dite, en fait.
Quand j'écris « Mais quelque soit l'avenir, il serait bon qu'Alsa soit interrogeable officiellement via D-Bus », ça n'a rien à voir avec le noyau, et ça reste vrai.
Je ne parle de D-Bus dans le noyau que parce que tankey< en a parlé (il doit faire référence à ça. Ce à quoi je répond prudemment « mais je ne sais pas trop ce que ça changera », et je termine en disant « faut-il encore qu'Alsa parle D-Bus », bref mon problème n'est pas « D-Bus et le noyau » mais bien « D-Bus et Alsa ». Il n'y a pas de confusion ici.
Donc merci pour tes explications sur D-Bus qui sont intéressantes, mais je ne vois pas où tu vois de la confusion quand je ne fais que répéter que « D-Bus et le noyau » ne me concerne pas.
Si tu veux parler Alsa via D-Bus, ça veut dire qu'il va falloir un démon qui applique la configuration qui était appliqué par libasound
Je n'en suis même pas à vouloir configurer quoi que ce soit ! Je veux juste une description de ce qui est accessible via Alsa :
Combien de cartes, leur nom, les canaux, les échantillonnages etc. Bref, un peu comme un un /proc/cpuinfo mais pour les cartes sons.
Franchement, il y a déjà pulseaudio pour ça
Euh, s'il faut chercher une confusion, elle est là ! Je veux une interface accessible depuis Python 3 pour savoir quel matériel géré par Alsa est disponible sur mon système.
D'une, je ne configure rien sur les cartes, de deux, ce n'est pas moi qui produit du son (je délègue ça), donc je ne parle pas aux cartes sons.
J'ai besoin de connaître les cartes gérées par Alsa, pas de connaître les hypothétiques cartes vues par PulseAudio, à travers PulseAudio.
PulseAudio est complètement hors-sujet ici. Je n'ai rien à faire de savoir ce que PulseAudio expose comme interface. Et surtout je n'ai pas besoin de PulseAudio pour envoyer le son aux cartes son (et surtout j'ai besoin de ne pas passer par PulseAudio pour le faire).
Alsa marche très bien, tout ce que je veux c'est une interface qui me dise ce qui est exposé par Alsa, pas ce qui est exposé par une abstraction au dessus de Alsa. Utiliser PulseAudio est la meilleure manière de ne pas répondre à ma problématique. J'aurai plein d'informations mais elles me seront inutiles.
Mon projet gère des entrées et sorties sons (cartes sons, flux réseau) et leurs connections. PulseAudio, ce sont des entrées et sorties sons comme d'autres, à coté de Alsa. En gros, Depuis PulseAudio arrive le son mixé des applis qui savent causer PulseAudio (totem, rhythmbox…), et vers PulseAudio part le son vers des applis de capture sonore qui savent causer PulseAudio.
PulseAudio peut envoyer le son des applis à Alsa, mais peut aussi ne pas le faire. PulseAudio peut fonctionner sans aucune carte son, PulseAudio peut être branché sur Jack au lieu de Alsa par exemple (Le même Jack pouvant hypothétiquement ne pas être connecté à Alsa, ça existe (cf. FFADO), ou même juste pour essayer, voir le pilote dummy).
Maintenant faisons une analogie. Imagine quelqu'un qui pose la question « Bonjour, je suis musicien et je voudrais configurer jackd, mais je ne sais pas si ma carte peut-être gérée sans latence avec l'option -hwmon, comment puis-je le savoir ? », et toi tu réponds. « Franchement il y a PulseAudio pour ça ». Confusion.
La confusion vient peut-être du fait qu'Alsa fait trop de choses, choses qui peuvent être comparées à des choses similaires dans PulseAudio, dans Jackd, et autres systèmes qui se branchent au dessus d'Alsa. Quand je parle d'Alsa, je ne parle pas de l'échantillonneur et convertisseur plug, je ne parle pas du mixeur dmix/dsnoop, non, je parle uniquement de la partie « pilotes de carte son » et « description du matériel », cette partie qui est utilisée par Jackd et PulseAudio.
Voilà, pour faire simple, un schéma juste après.
J'ai besoin de savoir ce qu'il y a au dessous de la ligne pour pouvoir connecter ce qu'il y a au dessus.
PulseAudio ne m'est pas d'une grande aide, ce n'est qu'une fonctionnalité supplémentaire que je peux choisir de gérer.
[^] # Re: Gnome 3 > tablettes/smartphones
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Gnome 3.8 : un retour en arrière ? . Évalué à 2. Dernière modification le 30 mars 2013 à 12:45.
Ça va si c'est juste pour « voir », si c'est pour interagir avec c'est une plaie.
Il y a encore tout plein d'applis de la dernière décénie qui mettent une icône en zone de notification avec un menu et diverses actions…
au hasard le gestionnaire de dictionnaire
stardict(j'en ai besoin quand j'écris du texte, mais jamais dans l'overview)divers logiciels de reconnaissance d'écriture ou de claviers virtuels comme
cellwriterouonboard(il faut passer par l'overview pour l'afficher ailleurs que dans l'overview, avec la contraposée qu'elle ne s'affichera pas dans l'overview même si c'est le seul endroit en tactile pour commander son affichage).Certaines actions sont quasiment impossibles à faire en tactile seul : devoir faire une action dans l'overview pour qu'elle agisse sur un élément en mode normal, et avoir l'action dans l'overview est quasi impossible.
Enfin de toute manière, cette gestion de la barre de notification est foireuse, même sans tactile… Mais ça peut encore se comprendre et s'utiliser avec une souris clavier même si certains cas sont un peu tordus, en tactile c'est tout simplement inutilisable.
ce commentaire est sous licence cc by 4 et précédentes
# le titre du journal est faux
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Gnome 3.8 : un retour en arrière ? . Évalué à 9.
D'un point de vue utilisateur, il y a toujours eu un mode « classique » donc ce ne peut être un retour en arrière.
D'un point de vue développeur, du vieux code va être mit à la poubelle, pour n'utiliser que les nouvelles briques de Gnome Shell et ne pas maintenir des vieilleries pour ça. C'est tout l'inverse d'un retour en arrière.
Cela dit le titre de l'article que tu lies est déjà faux, Gnome ne présente pas un « mode classique », mais sa nouvelle implémentation. Je cite le titre et le sous-titre de l'article de PcInpact :
Le titre étant faux, le sous-titre l'est aussi s'il sous-entend que le mode classique empêcherait des personnes d'utiliser Mate (le fork Mate a été créé alors que le mode classique existait déjà).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Gnome 3 > tablettes/smartphones
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Gnome 3.8 : un retour en arrière ? . Évalué à 2.
Deux bons contre-exemple du « Gnome Shell c'est fait pour le tactile » :
Donc si la proposition « Gnome Shell c'est fait pour le tactile » était vraie, il se sont complètement plantés.
(J'ai un écran tactile et j'utilise Gnome Shell)
Sur un bureau je trouve Gnome Shell très pratique.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ou pas
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Gnome 3.8 : un retour en arrière ? . Évalué à 7.
Justement… dans les faits, il y a TOUJOURS eu un mode « Gnome classic », c'est juste l'implémentation qui change. Avant il y avait deux logiciels, maintenant il n'y en a plus qu'un, mais ça l'utilisateur s'en moque : du point de vue utilisateur, il y a toujours eu un mode « classic ».
Donc non, pas de changement de mentalité ni d'orientation, c'est un changement d'implémentation (s'il y a un changement de mentalité il est sur la manière de coder, si par exemple ils se voyaient contraint de réimplémenter ce pourquoi Mint a forké).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas le temps, pas le temps.
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal «L’ouvertisation», le nouveau green washing.. Évalué à 3.
Surtout, ce type de phrase :
ce type de phrase sent à plein nez l'idée suivante :
je ne veux pas commenter l'article, je veux témoigner mon pressentiment
Effectivement ce genre de commentaire est très courant sur beaucoup de médias, et heureusement encore faible sur LinuxFr malgré une augmentation sensible. C'est le règne des impressions et de l'affect sur la raison. « Je ne sais pas vraiment ce que tu as dit, mais ça me donne envie d'être d'accord/pas d'accord »
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ça, c'est fait.
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Lycée et informatique : spécialité ISN en terminale S. Évalué à 9. Dernière modification le 23 mars 2013 à 20:50.
Clair qu'il y a une différence… mais je crois qu'il faut comprendre qu'en TI-Basic (celui des z80 et celui des 68k) ainsi que dans le basic des casios et comme en C, on peut écrire une boucle for qui aurait pu être écrite par une boucle while de ce type :
pour min = 2, max = 10, step = 4,
Quand le lycéen a déjà fait ça dans sa vie, c'est facile de lui dire qu'en C on fait ainsi :
Le lycéen comprend tout de suite, en faisant remarquer tout de même que c'est un peu verbeux.
Alors oui on peut faire tout à fait autre chose avec le for du C (c'est pourquoi il est plus verbeux), mais ce qui compte c'est qu'il puisse retrouver ses marques et reproduire le peu qu'il connaît déjà.
Tu mets ce même lycéen devant un
for i in 2 6 10du shell ou du Python, il capte pas et c'est normal, l'exemple que je viens de donner n'est pas le bon exemple pour expliquer le for en Python. Pour utiliser for en Python dans le cas de figure présent (for i from 2 to 10 step 4), il va falloir enseigner d'abord d'autres concepts…C'est pas tant que le TI-Basic est comme le C, c'est qu'on peut très facilement tordre C pour qu'il ressemble à du TI-Basic. Avec Python, certains concepts de base sont différents et homonymes.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Sérieusement ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Blagues et sexisme. Évalué à 6.
ouai t'es largué, les députés font la même chose à l'assemblée… et c'est bien connu, la démocratie en France se porte bien ! ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Trisquel bien sûr !
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au sondage Selon vous, quel est l'avantage d'un système libre type GNU/Linux sur un ordinateur de bureau ?. Évalué à 6.
Ne confond pas le monde dans ta tête et le monde dans la vraie vie. Pendant au moins six interventions, personne n'a interagit avec toi en vrai. Les gens dans ta tête ne comptent pas.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Trisquel bien sûr !
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au sondage Selon vous, quel est l'avantage d'un système libre type GNU/Linux sur un ordinateur de bureau ?. Évalué à 8.
C'est troublant, on dirait qu'il manque les messages des autres gens qui discutent avec toi !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: workers ...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 2.
Si je comprends bien, un worker est un moyen technique permettant à une page web de lancer un script en tâche de fond dans la vm de mon navigateur, avec la garantie que le travail effectué ne pourra pas impacter le rendu de la page que je demande, ce qui signifie autrement qu'un worker ne peut être un moyen efficace pour répondre à ma requête (à moins de contournement) ? C'est une question de néophyte… mais vu comme ça, à quoi peut servir un worker autrement que pour utiliser mon CPU pour autre chose que la page que je regarde ? Peut-on avoir des exemples concrets avec lesquels un worker sert à autre chose qu'étendre un système de calcul distribué ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Oui mais ...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal PyAlsaCap : Python, pointeurs, et cartes sons…. Évalué à 2.
En fait c'était une allusion à la « vacance du siège pontifical », la panne de LinuxFR étant survenue en même temps que le conclave. C'était une manière fumeuse (hihi) de comparer l'attente du lectorat de LinuxFR avec celle de quelques (millions ? milliards ?) de croyants pour un nouveau pape.
Dans ce cas précis, on parle bien d'une vacance au singulier, du latin vacare, être sans. Au pluriel, « les vacances » se réfèrent habituellement au repos, hors ce qu'a du vivre le lectorat pendant la panne n'est pas vraiment un repos, mais un manque.
C'est que l'absence de ce site a du éprouver nombre de ses fidèles ! En tout cas moi j'ai trouvé cela interminable. :)
J'avais trouvé l'allusion dans l'air du temps (j'en ai glissé d'autres)… mais elle n'est peut-être pas très accessible en effet.
Pour ceux qui suivent l'actualité, on parle ces jours-ci de la prochaine installation du pape. Y a moyen de faire des blagues sur les gestionnaires de paquet… Dans un domaine proche, on parle de l' érection d'une cathédrale. Il y a bien que les cathos pour utiliser encore de tels mots connotés et qui surtout ne sont plus compris dans ces sens là. ;)
J'ai eu un peu peur moi-même de la longueur, j'aurai voulu le faire plus court, mais j'ai trouvé dans ce cas pratique une bonne occasion de présenter ctypes et de lister quelques pièges difficiles.
Les tutos donnent toujours des cas généraux qu'on ne rencontre jamais dans la réalité. En l'occurrence ici les difficultés principales étaient de manipuler des pointeurs sur des objets que nous ne connaissons pas (!) et dont le type de n'est pas connu (je ne sais toujours pas ce qu'il y a au bout du pointeur
*handle, par exemple), et de contourner l'usage de macros et autres usages du préprocesseur : la fausse fonction rencontrée dans le présent journal, les constantes…On voit bien la difficulté de dialoguer avec une bibliothèque C quand elle n'est prévue que pour être utilisée depuis un langage compilé. On prend conscience aussi que certaines manières de programmer n'ont pu naître que parce que le concept de compilation le permet. Certains concepts comme le préprocesseur, par exemple, entraînent une différenciation entre les symboles source et les symboles binaires. Je n'aimerai pas devoir travailler avec ctypes sur une bibliothèque dont la compilation source prévoir l'usage d'outils comme moc par exemple. Les langages qui compilent vers le C (comme Vala) posent le même problème.
Suite à cette expérience, je sais que si je devais développer une bibliothèque en C, j'éviterai au maximum d'utiliser le préprocesseur si je prévois qu'elle puisse être utilisée directement telle quelle sans compilation.
J'ai donc essayé de faire plus court… mais je n'ai pas réussi à raccourcir sans retirer des clés. ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pour que cela fonctionne avec un clavier bepo
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Essais avec une Yubikey. Évalué à 7.
En simple utilisateur tu dois pouvoir faire quelque chose du genre :
En ayant repéré préalablement le nom exact avec
xinput --list(Juste pour information, pour faire exactement la même chose que ce qu'a indiqué rahan<, avec le variant et le model, ce serait ainsi :
setxkbmap -device $(xinput list --id-only "Yubikey") us intl -model pc101`)ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Oui mais ...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal PyAlsaCap : Python, pointeurs, et cartes sons…. Évalué à 4. Dernière modification le 15 mars 2013 à 14:58.
Ah oui en effet… en plus je suis certain d'en avoir corrigé au moins un parce que je connais mon défaut… mais ce n'est pas assez. ^^
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: VP8 et son successeur ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 3. Dernière modification le 10 mars 2013 à 16:32.
Oui et non, tout développement n'implique pas une évolution d'une partie. C'est justement l'objet d'un standard, faire comme les autres. Pour faire différemment c'est la galère, pour faire comme les autres c'est OK. Pour ça on peut dire que c'est une excellente nouvelle, beaucoup demandent d'avoir des standards plutôt que d'hypothétiques trucs de kéké vraiment mieux mais inutilisable en réalité.
Beaucoup de développeurs libres sont certainement content de pouvoir utiliser le standard Opus, en développent leur ingénierie sur d'autres point.
Par exemple j'utilise personnellement Opus, mais je laisse le développement d'Opus à d'autres.
Donc ce n'est qu'une fraction des développeurs libres qui sont impactés : ceux qui font évoluer les codecs. C'est super dommage pour eux. Mais l'annonce ne crée pas cette injustice, elle ne fait que la révéler.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: VP8 et son successeur ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 4.
Ben c'est un gain pour tous les utilisateurs du standard VP8 (le monde libre étant un sous-ensemble des utilisateurs de standards). Donc c'est énorme !
Par contre oui, ce n'est pas un gain pour l'utilisateur de certains algorithme en dehors de VP8. Pour celui qui n'a aucun intérêt dans VP8, cette annonce ne fait que confirmer l'état déplorable de ce domaine de la recherche. Mais ça, c'était déjà vrai… Cette annonce n'est qu'un révélateur. Ne tirons pas sur le messager. ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: VP8 et son successeur ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 2.
En parlant de librisme antibrevet, je pensais aux brevets qui constituent une menace possible (ce qui fait que certains projets libres se retrouvent dans non-free à défaut de ne savoir où les mettre).
Si on veut virer vraiment tous les brevets, même ceux dont on ne craint pas, ça va être dur ! Surtout si on compte les brevets déposés explicitement pour protéger des projets libres, afin d'avoir suffisamment de bonnes cartes à poser sur la table du poker des brevets, afin, au moins, de poursuivre la partie sans trop grosses pertes…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: VP8 et son successeur ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 3.
C'est un peu l'effet que ça me fait. D'un certain coté il y a tout de même une bonne chose qu'on ne peut pas enlever : on peut utiliser VP8 sans crainte, et VP8, ce n'est pas que « VP8 de Google », c'est aussi « VP8 de la RFC 6386 ». Donc c'est très bien que ce format documenté et standardisé soit utilisable sans crainte, même si un quelconque VP8.31415926 n'est pas protégé. VP8 a donc deux avantages majeurs, d'une il est standardisé, de deux il est sans redevance, de trois il ne craint pas les attaques du MPEGLA. Ces trois arguments peuvent être suffisants pour choisir VP8, même s'il est techniquement moins bon qu'un autre. Je suis certain que ce genre de cas doit se produire, on ne choisit pas nécessairement le meilleur techniquement si des points non techniques sont jugés trop gênants.
Par exemple, je rippe personnellement mes DVD avec des options de de qualité indécente… En gros je demande « conserve au max la qualité de l'image au détriment de l'espace disque », il y a des chances que dans ce type de configuration, on ne sache pas faire la différence entre h264 ou vp8… Avec VP8, j'ai au moins l'espoir de pouvoir lire mes rips même avec un distribution pour intégroïdes libristes antibrevets…
J'imagine qu'il y a des cas où VP8 et h264 c'est kifkif, ou bien que la moindre performance ou moindre qualité pèse peu dans la balance vis à vis d'autres avantages.
Pour faire une analogie, il doit bien y avoir des usages où VP8 est préféré, un peu comme ceux qui utilisent Gimp même s'il est paraît-il moins avancé que Photoshop, mais parce qu'au moins Gimp est libre, tourne sous Linux et en plus est gratuit… (C'est aussi mon cas ;)) À quoi servirait à un produit d'être meilleur si l'on ne peut se le procurer ou s'en servir ? ;)
Donc on ne peut nier cette annonce qui est tout de même positive. On n'en sait rien pour les dérivés, mais on le sait pour le standard ! C'est énorme !
Après oui, ton commentaire décrit bien l'effet que ça me fait, et exprime bien les craintes que l'on peut se faire, je ne te pertinente pas toujours mais là oui ;). Effectivement, tout cela n'est pas rose dans l'univers des codecs vidéos, et le besoin d'un pacte de non agression Google / MPEGLA ne fait que confirmer que ce domaine est pourri. Donc on peut pleurer encore plus en constatant que oui, effectivement, même pour VP8 qui est sensé ne rien avoir en commun avec le MPEGLA il a fallu demander protection au MPEGLA… Donc c'est la misère, mais en même temps ça l'était déjà, on le savait déjà que c'est un champ de mine, ça ne fait que confirmer la chose, et si Google doit passer un accord avec le MPEGLA, à mon avis il ne faut pas vraiment le tenir pour responsable de n'avoir pu protéger que VP8. ;)
ce commentaire est sous licence cc by 4 et précédentes
# VP8 et son successeur ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 2.
Quel successeur ? Qui et quoi détermine quel probable projet successeur parmi d'autres sera protégé ?
Est-ce que, au moins, on peut dire « VP8 est protégé, et donc tout ce qui est dans VP8 et qui pourrait se retrouver ailleurs (comme dans un VP9 ou toute autre chose) » ? Avec l'idée qu'il ne resterait aux divers successeurs que de vérifier si et seulement si « ce qui diffère » est attaquable. Genre « OK je peux dès maintenant forker VP8, et pour les améliorations que je vais ajouter je vais faire attention, au moins je n'ai pas à vérifier cette grosse partie là ni l'ensemble, seulement les parties. », Ou bien « Tiens j'ai du mal sur mon codec maison, je vais piquer ça dans VP8, en indiquant clairement que cela vient de VP8 donc je suis protégé au moins sur cette partie ». Ça serait cool ! Pour le moment, tel que les articles grand publics présentent la chose, cela me semble bien flou.
Je préférerait lire cela, au moins on serait clairement fixé. « VP8 et son successeur » ne veut rien dire, ce successeur étant bien flou !
Et si ces mêmes brevets sont susceptibles de me porter préjudice sur mon hypothétique codec maison qui ne serait pas VP8 mais qui partagerait avec lui certains algorithmes, est-ce qu'il me faut réussir à démontrer que « Toute cette partie c'est VP8 en fait », ou bien je risquerai de me prendre dans la figure la remarque « OK, tu fais exactement comme VP8, mais seulement dans cette partie là. C'est pas VP8, donc brousoufs ! ». Auquel cas ce serait difficile de protéger un « successeur », et certains vont se battre pour réclamer cette reconnaissance ! « C'est moi VP9 ! Non c'est moi »
Si quelque un en sait plus que les articles de vulgarisation, qu'il n'hésite pas à expliquer et détailler ! je remercie d'avance son commentaire. ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Une alternative ? Tant mieux
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 3.
Je crois que c'était juste une liste de « trop gros pour mourir » (mais morts quand même), pas uniquement pour une question de pilote pas libre. :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: suis chez free
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au sondage Votre FAI. Évalué à 2.
idem pour le wifi, il y a plein de geeks pour dire « ma machinbox fonctionne très bien, aucun reboot en 6 mois », mais en fait avec un AP wifi dédié au cul. Hors chez certaines machinbox, à partir de deux ou trois connexions wifi simultanées… ça fume !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: suis chez free
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au sondage Votre FAI. Évalué à 2.
Effectivement avec un onduleur ça peut aider…
De la même manière, j'ai fais deux fois l'expérience, avec une alicebox, et avec une livebox, que « quand on n'utilise pas le DNS de la machinbox, il n'y a pas besoin de la rebooter toutes les deux semaines ».
Je crois que pour comparer des produits très grand public, il faut les comparer sans onduleur, parce qu'une livebox branchée sur un onduleur, ça doit pas être très grand public ! :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avertissement (attention les yeux)
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 4.
pour ceux qui cherchent, la compilation c'est
gcc alsacap.c -o alsacap -lasound(j'ai cherché un moment le-lasound, trouvé avecpkg-config --libs alsa).Voilà ce que ça me donne sur une machine de test :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: PyAlsaAudio python3
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 2.
Hum pardon, j'ai confondu, tu parles de
pyalsaaudio, et non depyalsa!En fait il existe
pyalsaaudio(ditpython-pyalsachez Debian) :Et moi j'aimerai utiliser
pyalsa(ditpython-pyalsachez Debian) :À ne pas confondre avec
pyalsa:Bref, je préfèrerai utiliser
python-pyalsaà cause de son coté « officiel », mais pour Python 3 seulpython-alsaaudioest actuellement disponible, et rien n'est dans Debian. Dur dur !ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avertissement (attention les yeux)
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 3.
Oh ça c'est bon !
S'il faut compiler quelque chose, je préfère compiler
alsacapque tout un module python !Aussi, ça me fournit un exemple concis d'
asoundlib, et je pourrais peut-être reproduire les quelques fonctionnalité qui m'intéressent en utilisantctypes, cité plus bas !ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avertissement (attention les yeux)
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Exposer un ou des modules Python sur D-Bus [proof of concept]. Évalué à 5.
Justement, j'évite de trop m'avancer sur ce sujet de « D-Bus dans le noyau » parce que
Quand j'écris « Mais quelque soit l'avenir, il serait bon qu'Alsa soit interrogeable officiellement via D-Bus », ça n'a rien à voir avec le noyau, et ça reste vrai.
Je ne parle de D-Bus dans le noyau que parce que tankey< en a parlé (il doit faire référence à ça. Ce à quoi je répond prudemment « mais je ne sais pas trop ce que ça changera », et je termine en disant « faut-il encore qu'Alsa parle D-Bus », bref mon problème n'est pas « D-Bus et le noyau » mais bien « D-Bus et Alsa ». Il n'y a pas de confusion ici.
Donc merci pour tes explications sur D-Bus qui sont intéressantes, mais je ne vois pas où tu vois de la confusion quand je ne fais que répéter que « D-Bus et le noyau » ne me concerne pas.
Je n'en suis même pas à vouloir configurer quoi que ce soit ! Je veux juste une description de ce qui est accessible via Alsa :
Combien de cartes, leur nom, les canaux, les échantillonnages etc. Bref, un peu comme un un
/proc/cpuinfomais pour les cartes sons.Euh, s'il faut chercher une confusion, elle est là ! Je veux une interface accessible depuis Python 3 pour savoir quel matériel géré par Alsa est disponible sur mon système.
D'une, je ne configure rien sur les cartes, de deux, ce n'est pas moi qui produit du son (je délègue ça), donc je ne parle pas aux cartes sons.
J'ai besoin de connaître les cartes gérées par Alsa, pas de connaître les hypothétiques cartes vues par PulseAudio, à travers PulseAudio.
PulseAudio est complètement hors-sujet ici. Je n'ai rien à faire de savoir ce que PulseAudio expose comme interface. Et surtout je n'ai pas besoin de PulseAudio pour envoyer le son aux cartes son (et surtout j'ai besoin de ne pas passer par PulseAudio pour le faire).
Alsa marche très bien, tout ce que je veux c'est une interface qui me dise ce qui est exposé par Alsa, pas ce qui est exposé par une abstraction au dessus de Alsa. Utiliser PulseAudio est la meilleure manière de ne pas répondre à ma problématique. J'aurai plein d'informations mais elles me seront inutiles.
Mon projet gère des entrées et sorties sons (cartes sons, flux réseau) et leurs connections. PulseAudio, ce sont des entrées et sorties sons comme d'autres, à coté de Alsa. En gros, Depuis PulseAudio arrive le son mixé des applis qui savent causer PulseAudio (totem, rhythmbox…), et vers PulseAudio part le son vers des applis de capture sonore qui savent causer PulseAudio.
PulseAudio peut envoyer le son des applis à Alsa, mais peut aussi ne pas le faire. PulseAudio peut fonctionner sans aucune carte son, PulseAudio peut être branché sur Jack au lieu de Alsa par exemple (Le même Jack pouvant hypothétiquement ne pas être connecté à Alsa, ça existe (cf. FFADO), ou même juste pour essayer, voir le pilote
dummy).Maintenant faisons une analogie. Imagine quelqu'un qui pose la question « Bonjour, je suis musicien et je voudrais configurer jackd, mais je ne sais pas si ma carte peut-être gérée sans latence avec l'option -hwmon, comment puis-je le savoir ? », et toi tu réponds. « Franchement il y a PulseAudio pour ça ». Confusion.
La confusion vient peut-être du fait qu'Alsa fait trop de choses, choses qui peuvent être comparées à des choses similaires dans PulseAudio, dans Jackd, et autres systèmes qui se branchent au dessus d'Alsa. Quand je parle d'Alsa, je ne parle pas de l'échantillonneur et convertisseur
plug, je ne parle pas du mixeurdmix/dsnoop, non, je parle uniquement de la partie « pilotes de carte son » et « description du matériel », cette partie qui est utilisée par Jackd et PulseAudio.Voilà, pour faire simple, un schéma juste après.
J'ai besoin de savoir ce qu'il y a au dessous de la ligne pour pouvoir connecter ce qu'il y a au dessus.
PulseAudio ne m'est pas d'une grande aide, ce n'est qu'une fonctionnalité supplémentaire que je peux choisir de gérer.
¹ mixage : ici il ne s'agit pas du mixage du volume, mais du mixage de plusieurs sons simultanément
ce commentaire est sous licence cc by 4 et précédentes