Psychofox a écrit 10949 commentaires

Je suis pas très au fait du multi-room mais justement je pense que le besoin que j'ai entre là-dedans : avoir la possibilité de diffuser le son de la TV dans d'autres pièces (terrasse, salle de bain) avec le moins de décalage possible (j'ai déjà un stream icecast qui le fait, mais le décalage est de plusieurs secondes dûe au buffering) . Est-ce bien ça dont il s'agit ?

Oui c'est ça.

Qu'est-ce qui existe déjà comme solutions multi-room libres ?

Ben ce projet justement.

Il y en a d'autres, le plus connu il me semble est snapcast qui est déjà packagé par certaines distribs, je l'avais testé avec des raspberry pi, ça marchait bien aussi:
https://mjaggard.github.io/snapcast/
https://github.com/strobe-audio/strobe-hub

Ce serait bien que les acronymes soient expliqués afin que le lecteur puisse connaitre le contexte sans lire un fouilli de liens.

J'ai eu du mal à comorendre ce que Microsoft avait à voir là-dedans ni ce qu'est LTT.

ben oui en fait la norme n'est pas si con que ça je suis d'accord. On peut quand même critiquer les valeurs par défaut.

Du coup pourquoi les distribs décident t'elles de maintenir le bordel à l'ancienne?

Si j'ai pas un /etc/skel tout prêt tout beau tout propre à la première install le bureau par défaut d'une distrib va me foutre le boxon. C'est balaud.

N'hésite pas à voter pour les bugs en questions du coup.

Ben du coup oui, ça me rend curieux et je vais configurer un de mes laptops pour ranger les configs, data et caches dand des endroits plus appropriés et je vais voir qui respecte ou pas ces variables XDG…

…la suite dans un prochain journal j'imagine.

Mais ce n’est lié à XDG que je sache

J'ai fais un raccourci, ce n'est pas dans les specs de XDG mais de Freedesktop. Mais comme XDG est une spec de Freedesktop, au final ça revient au même, juste que ce n'est pas dans la même doc ^{_^}

XDG est la seule tentative qui te permet de faire ce que tu demande.

On parie combien que 90% de developpeurs auront hardcodé ~/.config, ~/.local/share, ~/.local/state et ~/.cache plutôt que d'utiliser $XDG_CONFIG_HOME $XDG_DATA_HOME $XDG_STATE_HOME $XDG_CACHE_HOME ?

Et encore, si tu sais qu'il y a une application que tu vas ouvrir à tous les coups, pourquoi ne pas l'ouvrir automatiquement à l'ouverture de la session.

Vous avez beaucoup de sessions ouverte sans avoir au moins une fenêtre de navigateur?

À part un pc dédié à une tâche précise, genre écriture, MAO, contrôle de machines, et pour lesquelles on pourra mettre en autodémarrage une autre appli (pour justement éviter d'ouvrir le navigateur et procrastiner), je ne vois pas.

C'est toujours pas des arguments, c'est du même niveau que quand un utilisateur découvre un unix-like et trouve que /var, /usr et /bin. C'est le bordel. Je peux comprendre que ça ne te plaît pas. Mais j'aime pas n'ai pas plus pertinent que j'aime.

Mon argument est qu'ils sont partis d'un truc bancal, un home fourretout, pour continuer à le rendre encore plus bancale et encore plus fourre-tout.

Avant xdg, ce n'était pas pire que maintenant, au contraire.

Un truc intelligent, ça aurait été de dire maintenant on arrête de foutre de la config, du cache et des binaires dans le répertoire de l'utilisateur.

D'ailleurs une distribution ou un mainteneur pourrait faire la transition en douceur. Un script de post installation qui crée un lien symbolique entre l'ancien et le nouveau chemin, ou un patch pour que OpenSSH compilé sur Debian garde le chemin ~/.ssh par défaut quelques temps en prévenant quand c'est fini.

Et ils ne le font pas. Ça n'est probablement pas pour rien.

Il y a des bénéfices à essayer de clarifier tout cela. Pour la politique de sauvegarde des données ça permet de savoir qu'on a rien oublié,

Si tu veux être sûr de rien oublier, tu sauvegardes tout, XDG n'apporte pas de plus value.

ou à l'inverse d'ignorer des choses dont on a pas envie de sauvegarder.

XDG ne résout pas non plus ce problème vu que les dev d'applis qui utilisent xdg ne l'utilisent pas toujours correctement. Genre les applis basées sur chromium qui foutent leur cache dans .config par exemple. Et avec electron ça doit faire une tétrachiée d'applis maintenant.

S'il était bien fait le standard XDG, on n'aurait pas dans le home de l'utilisateur:
- des configs
- du cache
- des binaires et autres artefacts applicatifs genre modules pythons, ruby, node…
- des VMs
- des containers

Et on aurait juste les fichiers de données de l'utilisateur.

Ils ont juste rajouté 3 répertoires à la con, que quasi personne n'utilise bien, en plus des anciens. C'est juste du merdier en plus.

Et des répertoires idiots Documents/Downloads/Music/Pictures/Public/Templates/Videos c'est pas de la connerie inspirée de windows ça?

Le vocabulaire est contestable, mais le fond est valable AMHA. […] Avoir un $HOME qui est un foutoir sans nom, ne jamais savoir où chercher les configurations etc. des logiciels,

Non, XDG ne résout pas ce problème. Il a juste ajouté du merdier supplémentaire, et ajouté des horreurs inutiles pour faire comme windows.

C'est un système mauvais.

Et la preuve c'est qu'il ne fait pas consensus, qu'il n'est pas devenu un standard et qu'on a cette discussion.

Clairement sur ma machine pro xorg fonctionne moins bien que wayland. Par curiosité sur l'état de l'art des DE actuels, j'ai voulu passer quelques semaines sous XFCE. Si j'utilises xorg avec un écran branché sur hdmi sur mon laptop pro, j'ai régulièrement des freeze écrans dus à des erreurs du module i915. Je débranche et rebranche l'écran externe et ça repart mais j'ai finis par perdre patience et reswitcher sous gnome+wayland sur lequel je n'ai pas ces freezes.

J'ignore si ce problème est là sur une distro stable parce que de moins en moins de monde teste sous xorg où si c'est juste un glitch spécifique à ma machine, je ne suis pas encore allé jusqu'à faire un rapport de bug parce que je n'utilise plus très souvent xorg, mais ça m'a semblé étrange qu'un tel problème passe les différents filtres sur du gpu intel pourtant bien fréquent (mais relativement nouveau dans ce cas, vu que c'est du Iris Xe).

Je maintiens que l'exemple wayland n'est pas pertinent.

Parce que ce qui a pêché essentiellement les premières années ne venait pas que du protocole wayland lui-même, mais aussi de l'écosystème d'applications qui l'utilise qui a pris du temps à se mettre en place.

Il n'est pas libre mais que penses tu de photopea par exemple comparé à Gimp?

Son auteur est parti de 0 il y à 9 ans. Et il est fonctionnel déjà depuis de nombreuses années pour plein d'usages. Auteur unique, à part pour les traductions, qui ne sont pas forcément complètes[1]. Il a pris le parti d'être le plus proche possible de photoshop pour avoir moins de choix et d'étude d'UX à faire pour se faciliter la vie.

[1] mais beaucoup de celles de Gimp mériteraient une refonte générale.

Je ne suis pas bien sûr que le titre est correct.

D'après ce que j'ai compris, mais corrigez-moi si je me trompe, on parle de developpement de paquets, pas de code, dans RHEL et Fedora.

Et je crois qu'environ 50% avaient été repris dans les jours qui ont suivi son annonce:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WRHVGQBKKFU74CBO3CHIJC3Q5VEKH2AV/

(aucune idée si le reste est toujours orphelin)

La comparaison ne me parait pas correcte. Wayland n'est pas une réécriture de xorg, ne prétend pas être compatible ni avoir les mêmes fonctionnalités.

Mis à part le manque de support d'extensions et le fait qu'il avait crashé quelque fois, j'aimais bien le navigateur web Eolie écrit par gnumdk. Il s'intégrait très bien au bureau Gnome, contrairement à firefox. C'est bien dommage qu'il semble si compliqué de séparer le moteur quantum de firefox et son interface.

J'utilise sporadiquement Gnome Web / epiphany.

Sous Linux, on peut!

Il en existe déjà en fait. À voir si tout le monde peut contribuer où s'il faut aussi signer un CLA pour pouvoir contribuer:

https://github.com/diggerhq/open-terraform

Les gens de plus de 50 ans sont tous morts de la Covid en 2020.

Si on ne veut pas migrer les libs régulièrement, il faut coder avec winelib!

Je ne sais pas si détourné est le bon mot.

Je veux dire, je ne crois pas que les lourdeaux vont spécialement sur linkedin pour cibler des femmes. Je pense qu'ils se comportent ainsi sur n'importe quelle plateforme ils utilisent et peuvent envoyer des messages privé.

Par contre, la plateforme ne fait probablement pas bien son boulot de modération si ce genre de comportement se perpétue malgré le risque de voir son compte supprimé et perdre toutes ses connections.

Si tu es intéressé par une future perte, tu n'as qu'à cloner le repo git. Git est décentralisé, c'est ça qui est bien. On peut même s'envoyer des commits par radio, code morse, courrier ou pigeon voyageur.

Je dirais qu'il y a encore la place pour les deux, et qu'on commence déjà à avoir un peu de choix côté WM sous wayland.

J'ai mis un peu de temps à passer d'un site statique avec des pages faites à la main, à un site dynamique parce que ça a été du gros boulot de le faire.

Tu peux faire du statique sans avoir à tout faire à la main. Il existe pléthore de générateurs de site statique où tu peux juste te contenter d'écrire du markdown ou asciidoc. Et vu qu'il existe des éditeurs markdown WYSIWYG, tu n'as même pas à connaître le markdown sur le bout des doigts.

Et aussi, quand tu fais tes pages "à la main", dès que tu veux en modifier une, tu dois la renvoyer de nouveau.

Pas que je préconise ça mais si tu as accès ssh au serveur distant, tu peux éditer directement la page.

…le train, l'avion, l'hôtel ou la bagnole de location, je n'ai jamais pu obtenir un billet au prix mentionné dans les affiches et publicités. Même en tentant de choisir les pires dates, heures et lieu possible. J'en conclue qu'ils se contentent en général de vendre un billet unique à ce prix pour pouvoir dire à partir de.

J'avais aussi remarqué à une époque qu'il était parfois moins cher de prendre à un instant T un TGV en première classe qu'en seconde.

Bref, ça devrait clairement être régulé et facturé au km.