raphj a écrit 1627 commentaires

Je dirais que la notion de logiciel libre n'est ni antinomique ni orthogonale avec l'éthique ou la morale et que ce serait dommage de l'affirmer : on peut se dire qu'il est éthique de mettre son code sous licence libre parce que c'est la bonne manière de traiter l'utilisateur. La notion s'inscrit complètement dans un cadre éthique ou moral. Par contre, elle est certainement orthogonale aux autres notions éthiques ou morales. Ne pas tuer et sortir son code sous licence libre n'ont à priori rien avoir et on peut faire les deux choses indépendament l'une de l'autre (donc elles ne sont pas incompatibles). Elles ne sont pas antinomiques parce qu'elles ne s'opposent pas.

Mais je te rejoins sur le fond de ton commentaire. Alors, comment relier simplement les deux notions ? Je ne sais pas.

Non, les deux experts en sécurité qui ont entendu parler de Wayland n'ont pas réussi à le faire marcher. Ils ont finalement conclu qu'un programme pouvant exploiter X n'allait probablement pas le faire : il est de toute façon plus facile d'aller taper dans le répertoire de l'utilisateur, auquel il a certainement de toute façon un accès complet.

Ils ont souligné l'importance du bon fonctionnement des choses qu'on attend d'un ordinateur du début du 21ème siècle, et notamment des visios, du partage d'écran, des captures d'écran, du fait qu'un plantage de l'environnement ne devrait pas entrainer toute la session et les programmes ouverts avec lui, de la possibilité d'avoir un gestionnaire du presse papier et des gestes Barrier.

(ce commentaire est surtout une parodie)

L'introduction de restrictions éthiques / morales à des licences est régulièrement débattue, la dernière fois ici en fin janvier : https://linuxfr.org/users/bubar/liens/hyppocratic-v2-1-ajouter-de-l-ethique-d-usage-et-reduire-la-liberte-zero

En résumé : ça part d'un bon sentiment, la solution est tentante, mais chacun a sa morale et si chacun y va de ses petites restrictions spécifiques c'est la foire, il devient impossible de composer les logiciels et le monde du « libre » s'écroule (avec de gros guillemet, l'introduction de ces restrictions supprime l'aspect libre en fait). Ce n'est pas au niveau de l'outil / technique qu'il faut restreindre les usages mais au niveau social / légal si on veut faire avancer des causes qui n'ont rien avoir avec le monde du logiciel efficacement.

L'union fait la force, ne l'affaiblissons pas, évitons de tout mélanger et séparons les problèmes pour les résoudre chacun plus efficacement.

tu stream un tableau json infini dont chaque élément est un message.

Pourquoi pas, mais pourquoi faire ? SSE fournit un mécanisme propre, élégant et efficace à la fois côté serveur et côté client.

C'est un truc que j'ai eu du mal à comprendre : quand tu parle de requêtes longues, tu parle en fait de multiplexer des requêtes.

Pas du tout. C'est pour attendre des messages. Le serveur envoie des messages qu'en il y a des messages à envoyer. On n'arrête pas la requête dès qu'un message a été reçu (on pourrait).
Ce n'est pas une requête, une réponse.

C'est vraiment ce qu'on fait avec les Server-Sent Events.

On crée un objet XMLHttpRequest, on lui indique l’URL de la page à télécharger

Qui ? Le client ?

Yep. XMLHttpRequest est une classe qu'on ne trouve que dans les navigateurs web (habituellement en tout cas !).

Par contre, il faut se payer la gestion de la séparation des messages. Rien ne garantit qu’on va recevoir chaque message en un coup. Il « suffit » donc d’utiliser un séparateur (par exemple un ou deux retours à la ligne).
Un gars plutôt réseau comme moi ne comprend pas pourquoi il faut séparer les messages. On reçoit les messages au fur et à mesure, donc des paquets de données (plus précisément des PDU de niveau 7). C'est le paquet qui sépare les messages non ?

Ici on est à un plus haut niveau : un « message » pour moi est un objet JSON complet (par exemple). Ou un texte dont la taille est connue en avance. Ou un texte qui se finit par une nouvelle ligne. Il peut être composé de un ou plusieurs paquets TCP, et plusieurs messages peuvent être envoyés en même temps par le serveur, et il peut même y avoir un paquet TCP qui contient la fin d'un message et le début du suivant.

La fonction onreadystatechange de l'objet XMLHttpRequest peut être appelée n'importe quand, quand le navigateur le décide. Mettons que le serveur envoie deux « messages » en même temps. Il peut y avoir du buffering, on peut recevoir une partie du premier, puis sa fin et tout le deuxième message en entier, ou recevoir le tout en trois fois… Bref, il faut analyser le flux au fil de l'eau et trouver les messages dedans. Je ne sais pas si c'est plus clair dit comme ça.

Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client

Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.

Alors, non. Le serveur peut envoyer des messages sur une connexion WebSockets établie, demandée par le client. C'est une connexion TCP classique établie, le NAT n'est pas un problème. Le proxy, si c'est un proxy TCP, non, si c'est un proxy HTTP oui, il faut qu'il comprenne les WebSockets.

Là encore, je ne vois pas la différence avec du HTTP.

La différence, c'est la connexion établie. HTTP c'est : une requête, une réponse et on coupe la connexion. Les WebSockets laissent une connexion TCP ouverte, par laquelle le client et le serveur peuvent envoyer des données à tout moment.

Et du coup :

Sans les WebSockets :
Une requête HTTP est envoyée pour avertir le serveur.
Le serveur répond OK à la requête, puis,
transmet le déplacement à tous les joueurs, y compris celui qui a joué, par simplicité. Ce déplacement est reçu par le joueur via la requête de longue durée.

Avec les WebSockets :
Le joueur envoie le coup par la WebSocket
Le serveur répond ok dans la WebSocket
Le serveur envoie le déplacement à tous les joueurs, dont à ce joueur à travers cette même WebSocket.

C'est un peu exactement la même chose, je ne vois pas la différence.

Elle réside peut-être là :

Sauf que dans la vraie vie, le déplacement peut être reçu avant la réponse OK par le joueur.

Mais je ne comprends pas du tout pourquoi.

Sans WebSocket, vu que la requête et la connexion long polling son dans deux connexions différentes (sur différents ports - ou dans une seule connexion HTTP2 mais multiplexée, donc je pense que c'est le même problème), il n'y a pas de garantie d'ordre d'arrivée des messages.

le client envoie la requête, le serveur la traite, envoie la réponse au client, et envoie un message sur l'autre connexion correspondant à cette requête, on peut recevoir la réponse et le message dans les deux sens.

Avec un WebSocket, les messages seront bien ordonnés puisque tout passe dans le même tuyau et que TCP garantie l'ordre : la réponse à la requête arrive toujours avant le message, par exemple.

J'espère que ça répond aux interrogations :-)

Super !

proxy_buffering off;
proxy_cache off;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;

Ça m'intéresse, tu pourrais expliquer ce que ça fait / pourquoi ça évite la coupure ? Je crois que j'ai observé ça, je ne sais plus si j'ai corrigé, mais en tout cas ça ne pose pas de problème dans mon cas.

En effet, un vote concernant une General Resolution n’est pas secret, ce qui est une pratique totalitaire qui doit être changée

Je vois très bien pourquoi le caractère public d'un tel vote est très problématique mais… totalitaire ? Rien que ça ?

Ensuite, à propos de l'option 7 du vote en question : « Debian will not issue a public statement on this issue »

Sans la condamner, mais en refusant de participer à une chasse aux sorcières, l’option 7 constitue bien un soutien implicite à RMS

Wat? J'imagine très bien quelqu'un pensant que Debian ne devrait pas se mêler de tout ça et malgré tout contre le retour de RMS voter ça, et chercher à traiter le problème ailleurs qu'au sein de Debian, pour bien séparer les problèmes (c'est un sujet qui divise Debian et on peut se dire que l'union fait la force)

Là ça fait un peu « si tu n'es pas pour nous, tu es contre nous », la vie n'est pas si manichéenne…

Non c'est plutôt insupportable. D'une je trouve que la forme rend le fond cryptique et d'autres part oui j'y vois beaucoup de plaintes. Le fait qu'il y en ai des tartines et que ça n'est jamais véritablement désamorcé en fait pour moi une série de critiques sous un verni de moquerie.

Mais je ne l'aborde que parce que tu l'aborde, c'est mon ressenti et mon point de vu. Je ne te le reproche pas.

C'est bon à savoir, le retour tout à fait honnête est bon à prendre et je l'aurai en tête pour les prochaines choses que j'écrirai. Merci ! Le style marqué est assumé, je me doutais que je prenais le risque que ça ne plaise pas à tout le monde. Ça semble avoir bien plu à d'autres alors je ne peux pas promettre que je ne recommencerai pas, mais il y aura clairement des différences, ne serait-ce que parce que la moitié de la dépêche a été rédigée il y a près d'un an et qu'on a le temps de changer entre temps, je l'ai senti en la reprenant la semaine dernière.

Bien sûr, il y a un fond de vérité derrière certains (la plupart ?) traits humoristiques (sinon ça ne serait pas drôle), mais en tout cas, je ne me moque de personne, ça c'est important que ce soit bien clair. Je n'ai probablement pas le dixième des compétences des personnes qui ont pu être impliquées de près où de loin dans l'élaboration de toutes ces technologies dont je ne suis qu'utilisateur et une bonne dose d'humilité s'impose bien entendu.

C'est un choix tout à fait assumé où ils ont voulu simplifié la vie de leurs utilisateurs au détriment de la cohérence

On est d'accord :-)

C'est marrant que tu te plaigne que xmlhttprequest soit nommé ainsi alors qu'il peut servir pour autre chose

J'ai l'impression que tu perçois le ton se voulant humoristique de cette dépêche comme de la plainte, et ça doit franchement rendre sa lecture frustrante ;-)

Tu sais, en vrai, je m'en fiche un peu. Je trouve l'histoire de ce nom et de cet objet très intéressante, et c'est en partie ce qui a motivé l'écriture de cette dépêche. Non, ce n'est pas idéal, mais non, ça ne m'empêche pas de dormir la nuit.

et que tu ne vois pas de problème que limit_conn limite les requêtes et pas les connexions

Je comprends pourquoi c'est nommé comme ça et que ça se comporte comme ça. Nginx a été conçu au début des années 2000, on n'était loin d'imaginer HTTP2 à ce moment là et bien sûr qu'il y a des défauts comme ça.

Bien sûr que ce n'est pas idéal, mais c'est la vie !

Bref, dans le passage suivant :

De plus, les navigateurs, en HTTP 1.1, se limitent avec leur configuration par défaut à 6 connexions simultanées vers chaque hôte. Ce n’est pas le cas en HTTP 2, et donc peuvent surcharger plus facilement un serveur si celui-ci ne gère pas bien les connexions simultanées

Il serait plus correct de parler de « requêtes simultanées » que de connexion simultanées. Une personne dans l'équipe de modération pourrait-elle remplacer les deux occurrences ? (décidément, j'en demande beaucoup pour cette dépêche !! Un grand merci pour tout ce travail !)

XMLHttpRequest est anterieur de plusieurs années à json

D'accord, mais tu n'étais pas obligé de transmettre du XML avec. Tu pouvais transmettre des données plain text, des scripts javascript… bref, l'objet n'a rien de spécifique à XML et en programmation on a quand même pas mal l'habitude de séparer les probèmes…

Ce n'est vraiment pas moi qui le dit, pour le coup, je n'ai rien inventé c'est la personne qui a conçu XmlHttpRequest (premier lien de la dépêche) !

I got in touch with Jean Paoli who was running that team at the time and we pretty quickly struck a deal to ship the thing as part of the MSXML library. Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).

Le long polling c'est un peu plus subtile que ça. Il faut utiliser xhr, mais en gérant le timeout et en gérant une boucle.

C'est décrit dans la dépêche… qui reste une dépêche, pas une doc.

Non, fetch peut être rerouté vers un worker par exemple

Je ne sais pas précisément ce que tu entends par là mais sur cette page : https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

Note: This feature is available in Web Workers.

Donc si tu dis que fetch est utilisable dans un worker, ce n'est pas un contre exemple d'un truc que fetch peut faire et pas XMLHttpRequest

il y a un travail en cours pour pouvoir annuler des requêtes (particulièrement utile pour ton scope de requêtes longues).

Je ne doute pas que dans le futur, les APIs vont continuer à évoluer et je ne serais pas étonné si fetch finissait par faire des choses que XmlHttpRequest ne fait pas.

une sorte de keep-alive, quoi - et non, je ne sais pas pourquoi le keep-alive de TCP ne suffisait pas

Le keep-alive ne remonte pas jusqu'à l'application

À noter que le mécanisme de keep-alive ne remonte pas jusqu'au code utilisant l'objet WebSocket (ce qui ne contredit en rien ton affirmation, on est tout à fait d'accord).

De plus, les navigateurs, en HTTP 1.1, se limitent avec leur configuration par défaut à 6 connexions simultanées vers chaque hôte. Ce n’est pas le cas en HTTP 2, et donc peuvent surcharger plus facilement un serveur si celui-ci ne gère pas bien les connexions simultanées.

Je n'ai pas les moyens de le tester, mais je ne trouve rien qui va dans ce sens et ça m'étonne beaucoup. HTTP2 est là pour réduire le nombre de connexions pas l'augmenter. Qu'ils arrêtent de limiter le nombre de requêtes, ça ne m'étonnerait pas, mais le nombre de connexion ?

Pour le contexte :

• Avec HTTP/1.1, les navigateurs limitent le nombre de connexions simultanées à 6-8
• Avec HTTP/2, ils peuvent passer plusieurs requêtes dans une seule et même session TCP, et ce nombre est bien plus grand que 6.

Tu as raison, j'ai utilisé le mot « connexion » un peu négligemment mais ça ne change pas le sens de ce passage ni le raisonnement autour.

Le passage de la doc de Nginx n'a rien de surprenant : il avertit simplement que le paramètre dont il est question n'a pas exactement le même sens en HTTP 1.1 qu'en HTTP 2, justement pour qu'il ait « le même effet intuitif ». Ils font le même amalgame que moi (mais avec rigueur).

C'est pas ça qui t'a induit en erreur ?

N'hésite pas à poser des questions si tu trouves des imprécisions, les commentaires sont justement là pour discuter des détails intéressants.

Je tiens tout de même à rappeler que la dépêche n'est pas normative et, elle n'a pas la rigueur d'une RFC ni d'une doc, ni d'un papier de recherche. Tu va pouvoir trouver une quantité phénoménale d'imprécisions dedans.

Tu as raison, merci pour le retour.

Ce paragraphe n'est pas complètement faux (pour Java, on pouvait sortir de la sandbox en signant l'applet et en demandant la permission de l'utilisateur ; Flash n'était pas reconnu pour sa fiabilité extrême), mais il n'est vraiment pas terrible.

Si l'équipe de modération peut le remplacer par la phrase suivante, ça serait pas mal : « Des solutions s'appuyant sur les plugins Java ou Flash existaient également » (merci !)

qui est là plus pour libérer une frustration

Non, je te rassure ;-) Je me suis un peu laissé emporter en écrivant.

scp

À ce propos attention, scp n’utilise pas SFTP (à ma grande surprise quand j’ai découvert ça), mais un protocole tout buggué et pas très sûr basé sur rcp qui fait des transferts à coup de commandes toutes dégueu. Il faut éviter d'utiliser scp vers une machine à laquelle on ne fait pas confiance.

Cf Deprecating scp sur LWN :

The scp command is a historical protocol (called rcp) which relies upon that style of argument passing and encounters expansion problems. It has proven very difficult to add "security" to the scp model. All attempts to "detect" and "prevent" anomalous argument transfers stand a great chance of breaking existing workflows. Yes, we recognize it the situation sucks. But we don't want to break the easy patterns people use scp for, until there is a commonplace replacement.

et

one might type a command like:

$ scp admin:boring-spreadsheet.ods .

with the expectation of getting a file called boring-spreadsheet.ods in the current working directory. If the remote server were to give a response like "here is the .bashrc file you asked for", though, scp would happily overwrite that file instead.

sftp et rsync peuvent être utilisés à la place et c'est mieux :)

(et, oui, je continue à utiliser scp un peu par habitude, c'est pratique, ça fonctionne comme cp mais à distance, et ça marche même sur un serveur qui n'a pas (encore) rsync - cela dit, c'est rare et rsync est quasi aussi pratique à utiliser donc j’utilise de plus en plus rsync quand j'ai besoin d’un truc avec une UI similaire à cp)

Le port zéro est indiqué comme réservé page 9 dans la RFC 1340, en TCP comme en UDP.

Cette RFC est rendu obsolète par transitivité par la RFC 3232 :

Since 1994, this sequence of RFCs have been replaced by an online
database accessible through a web page (currently, www.iana.org).

Je n'ai pas trouvé l'info sur iana.org après 5 minutes de recherche et j'ai abandonné. Je suis un peu perdu, ça ne ressemble pas du tout à une RFC.

Oui, et c’est dommage. Des outils plus ou moins répandus utilisent les WebSockets ou sont en passe de le faire, comme Etherpad, Collabora Online ou Jitsi Meet.

Mieux vaut effectivement implémenter une solution de repli sans WebSocket. Par défaut, Trivabble essaie de se connecter en WebSocket et si ça merde, passe à du SSE + requête HTTP classique, et si ça ça foire, bascule sur XHR long polling + requête HTTP classique.

Selon le fonctionnement de votre code, je suggère de ne pas donner de réponse autre que des codes d'erreurs dans les requêtes classiques et de tout donner dans les WebSocket / requêtes longues si l'ordre des actions est important, sinon ça peut donner des bugs intéressants (ou de ne pas traiter les réponses des requêtes HTTP classiques si on sait que les données seront retrouvées dans les requêtes longues, ça permet parfois de garder son API cohérente ou de ne pas tout changer). Ça permet d'ordonner les messages plus facilement.

Ah oui, vous aviez peut-être le problème de la limite des 6 connexions simultanées à un même hôte. On a rencontré le problème dans Tracim l’année dernière. Depuis un an, on a un système de communication temps réel entre le serveur et le client, à l’aide d’un objet EventSource (et donc connexion permanente). Comme on est en HTTP 1.1, au-delà de 6 onglets ouverts, plus rien ne chargeait, impossible d’ouvrir un onglet de plus : page blanche, chargement infini. Forcément, le navigateur refusait de faire une connexion de plus et les autres ne se finissaient pas. On a brièvement essayé HTTP 2 et ça réglait le problème mais on a rencontré des problèmes de blocages serveur comme ceux décrits dans la dépêche.

Donc on a implémenté presque ce que propose Mouns dans ce rapport, sauf qu’on n’utilise pas le localStorage, mais broadcast-channel (qui fait effectivement une élection de leader, relancée automatiquement quand l’onglet leader disparait). Pour les curieux c’est géré ici.

Mais LinuxFr est en HTTP2, vous observez toujours ce problème ?

J’ai décliné la demande d’ajout d’un lien ou d’une section sur Mercure dans cette dépêche déjà très longue, parce que je ne connais pas trop et aussi parce que c’est plus haut niveau que ce qui y est présenté. Du coup, je lui dédie un commentaire, comme ça, si cela pique votre curiosité, vous pouvez y jeter un œil et ça permet aussi de lancer la discussion.

Si j’ai bien compris, c’est un protocole qui cherche à standardiser les échanges entre le client et le serveur en évitant les WebSockets et qui propose d’utiliser SSE pour récupérer des données du serveur depuis le client et faire des appels « classiques » sur une API HTTP pour l’envoi de données, comptant sur HTTP2 pour en fait un mécanisme de communication efficace à travers une seule connexion grâce au multiplexage complet.

• Dépêche en 2018 ici : https://linuxfr.org/news/mercure-un-nouveau-protocole-web-pour-mettre-a-jour-les-navigateurs-en-temps-reel-push
• Site web : https://mercure.rocks/
• Par Les-Tilleuls.coop (Nantes, Lille)
• Présentation vidéo par Kévin Dunglas

Il y a un gros socle commun, mais il clairement des différences entre les modèles. En utilisant les options qui ciblent du matériel spécifique, tu rends ton programme potentiellement incompatible avec les modèles précédents ou concurrents parce que ce matériel n'aura pas nécessairement les instructions que ces options génèrent.

Ou tout simplement, des optimisations qui rendent le code rapide / efficace pour ce modèle ne le sont pas forcément, voire causent des ralentissements sur un autre (en théorie possible, je ne sais pas si ça arrive en vrai).

Après, il existe des détections de fonctionnalités à l'exécution, c'est ce que font pas mal les compilateurs Just In Time avancés il me semble (JavaScript, Java (?)). C'est certainement possible avec des langages compilés, mais attention à la taille du code, un truc trop gros peut ne pas tenir dans le cache et le résultat est plus lent…

L’approche « stateless » parait particulièrement intéressante, et l’idée que des efforts soient faits pour que le code soit exécuté le plus efficacement possible me plaît beaucoup (bon, pour le coup j’utilise un processeur Intel, mais je ne voudrais pas m’enfermer dans une marque voire une architecture matérielle spécifique, donc je ne suis pas certain qu’une distribution dont l’objectif est de cibler des processeurs particuliers ça soit faite pour moi – après je suppose que rien n’empêche de faire un build pour d’autres processeurs si la distribution devenait populaire). Un autre bon point, ça a l’air d’être ouvert à la contribution, et le caractère open source est mis en avant.

Deux questions m’ont tout de suite traversé l’esprit en découvrant avec ce journal qu’il y avait une distribution Linux optimisée pour les processeurs Intel :

• Quel est le compilateur utilisé pour construire les paquets ? Intel a son propre compilateur, ICC, non-libre, censé produire du code plus efficace pour ses propres processeurs. Clear Linux semble utiliser GCC, d’ailleurs la première chose qu’on peut voir sur le site est une actualité sur GCC et la deuxième chose, un article dans lequel on découvre qu’un des auteurs a écrit un patch pour GCC. J’imagine également qu’il est difficile de se passer de GCC pour construire une distribution entière et qu’utiliser deux compilateurs différents pourrait ne pas valoir la peine. Il n’y a cependant pas de confirmation formelle sur le site.
• Est-ce qu’il y a une séparation stricte libre / non-libre dans les dépôts comme sur Debian, openSUSE ou Fedora ?

Quelques questions / remarques / idées :

• de quelles données parle-t-on ? Par exemple, est-ce que la recherche d’une mise à jour sur le site de l’éditeur devrait être considérée comme une fuite ? → il vaudrait certainement le coup de définir formellement « donnée de l’utilisateur »
• Quel processus pour catégoriser un logiciel ? Je ne veux pas avoir à faire confiance à l’éditeur du logiciel pour la catégorie, alors :
• qui fait l’audit ? Si le processus est collectif, comment la procédure est organisée ? Consensus ? J’imagine que l’évaluation d’un logiciel pourrait être faite par différentes personnes / différents organismes qui pourraient arriver à des conclusions différentes.
• y a-t-il une procédure systématique proposée pour catégoriser le logiciel ? (étude du code – comment ?, analyse des accès réseaux avec un outil tel que Wireshark, etc)
• Si plusieurs manières de catégoriser peuvent être employées, la ou les méthodes qui ont été utilisées devraient-elles clairement apparaître, de façon normée ?
• est-ce que le caractère libre ou source-available est un pré-requis ?
• est-ce que la production de binaire doit être reproductible ? (sinon difficile de garantir qu’un binaire correspond aux sources, et donc de garantir son bon comportement vis-à-vis de la norme)
• est-ce qu’il est prévu de documenter un niveau d’utilité des fonctionnalités est prévu (core, essential, optional…)
• est-ce que la direction de la fuite est considérée ? Par exemple on peut vouloir faire confiance à l’éditeur d’un logiciel mais pas à des « partenaires commerciaux » ou autre tiers.
• Dans le cas d’un logiciel composé d’un client et d’un serveur, l’évaluation n’est-elle pas différente si le serveur est installé chez soi ou chez un prestataire ? (zéro fuite chez soi, mais « tout » fuite chez le presta).
• Y a-t-il une notion de « tiers de confiance » à introduire pour rendre la norme plus informative pour ce genre de cas ?

Au passage, cela fait me fait un peu penser au système d’anti fonctionnalités dans F-Droid, même si c’est très différent : https://f-droid.org/en/docs/Anti-Features/

Pourquoi être gêné ?

J’imagine qu’on peut se sentir gêné d’aimer un truc qui semble créatif alors que ça a été produit automatiquement, sans créativité, par une machine. La musique est une forme d’art, et donc d’expression, d’être sensible à être sensible, et donc c’est bizarre d’être touché par un truc de la même manière qu’une œuvre d’art, alors que ça ne peut pas en être puisque c’est une machine insensible qui l’a produite complètement. Le morceau ne peut donc pas être l’expression d’émotions / de sentiments d’un·e artiste.

Mais est-ce que c’est ça qui s’est vraiment passé ? Je n’ai pas l’impression, il y a eu plusieurs sources de créativité / d’art dans le processus :

• l’idée de le faire
• la sélection des morceaux pour alimenter l’algorithme
• la créativité de l’artiste original pour créer ses morceaux
• la réalisation, qui a demandé pas mal de recherche, d’idées, du tuning, d’essai-erreurs – le goût et les idées d’une ou plusieurs personnes ont été en jeu
• le choix probable parmi différents résultats, qui n’ont pas forcément toujours été bons

et… finalement, s’il est simple d’automatiser la production d’un morceau qui ressemble (jusqu’à s’y méprendre) à celui d’un artiste, peut-être que c’est parce que finalement, beaucoup de morceaux de cet artiste n’étaient pas aussi nouveaux / créatifs que le premier, et qu’ils sont en fait des variations plus ou moins légères d’un morceau, lui, original. Il y a eu du génie (idée nouvelle) pour celui-ci, et ce génie a laissé place au talent (faculté à faire un truc efficace / qui marche). Des petites variations au dessus de schémas et d’éléments qui font l’identité / la signature du genre ou de l’artiste.

C’est mon ressenti personnel : j’aime bien entendre un ou deux morceaux de Nirvana (et j’aime plutôt bien ce morceau généré sans en faire une folie), mais j’ai rapidement besoin de plus de variation et je me lasse rapidement au-delà. D’ailleurs, pour cette raison, j’écoute principalement de la musique en mode aléatoire avec des artistes et styles différents dans ma liste de lecture. Ce n’est pas une critique (c’est même souhaitable dans une certaine mesure : on aime bien les morceaux d’un artiste parce qu’on y retrouve sa signature !), et c’est pareil pour beaucoup d’artistes.

Et là, on se rend compte qu’on peut imiter la signature de Nirvana ! Maintenant, on peut se rassurer si besoin en cherchant des pépites dans les petites variations des morceaux « faits main ». Je ne sens pas le besoin d’être rassuré.

Ici, l’IA est certainement utilisée une nouvelle forme d’instrument de musique ?

En tout cas, félicitations aux artistes qui ont composé ce morceau généré, et merci pour le partage, j’avoue avoir été surpris :-)

Je ne comprends pas le moinsage sur ce message d'Ysabeau. Si c'est à cause de la précision que quatre occurrences ont été corrigées et pas trois, ce genre de précision qui peut paraître lourde est en fait indispensable pour vérifier qu'il n'y a pas de mauvaise compréhension.

Plutôt Compose + . + -.

Concernant l'ordre, beaucoup aiment l'ordre alphabétique, ce qui permet de ne pas toujours mettre un des deux en premier et de ne pas à priori le (dé)favoriser. Donc ici, auteur et autrice. Pour la suite, l'accord de proximité peut s'appliquer si besoin (ici, non).

Concernant l'accessibilité, si la pratique du point médian se répand, nul doute que les outils s'adapteront. Je trouve cet argument étrange, je ne l'ai jamais rencontré cet argument pour quand on faisait exactement la même chose mais en utilisant des parenthèses au lieu du point médian (et on le fait toujours pour le pluriel). Pourtant, ça doit poser le(s) même(s) problème(s).

Sinon, pour les gens qui utilisent la touche Compose, on peut saisir le point médian en faisant Compose + - + ..

Bonjour, ici la brigade du 1er degré, en partenariat avec l'association française de la protection des moutons. Ce message pour vous dire que nous ne sommes pas très contentes de votre message.

Nous vous prions par conséquent de bien vouloir nous donner votre localisation précise, pour qu'on puisse vous tomber dessus, littéralement.