L'idéal ce serait d'avoir un service qui interroge régulièrement un site, qui isole ce qui est sous licence libre, récupère le contenu et la licence attachée, et mette tout ça dans un historique.
Ou alors l'auteur inscrirait, s'il le souhaite, la licence (et ses éventuels changements ultérieurs) dans une blockchain dédiée à ce type de problématique, associé à un hash de la photo. A défaut de le faire, la charge de la preuve lui reviendrait en cas de conflit.
(sous réserve que la gestion d'une blockchain pour ce genre d'usage soit un peu beaucoup moins consommatrice d'énergie que pour le bitcoin).
Imaginons maintenant que l’auteur supprime toute mention de la licence libre associée à sa photo. Comment prouver que la photo avait bien une licence libre dans le passé ?
En fait ma question était la suivante : quand bien même on pourrait prouver que la photo a été libre avant de changer de licence, à qui revient la charge de prouver que la copie qu'on utilise a bien été faite AVANT le changement de licence ? Ou bien est-ce que "libre un jour implique forcément juridiquement libre toujours" ? (l'exemple des forks logiciels n'est pas pertinent ici si la photo n'évolue pas)
L'auteur d'une œuvre peut en changer la licence, mais la licence d'origine peut évidemment toujours s'appliquer évidemment aux copies effectuées avant le changement de licence.
Ça c'est la théorie. En pratique il peut s'avérer difficile de prouver que la copie qu'on utilise a été faite AVANT le changement de licence.
C'est ainsi qu'on voit de temps en temps fleurir des forks libres issus d'anciennes versions de logiciels dont la nouvelle version est devenue propriétaire.
Je n'y connais rien alors ma question est peut-être idiote mais une photo libre est définitivement libre ou bien son auteur peut en changer la licence ?
Si oui, on n'éviterait pas la problématique que tu soulèves : comment prouver que la photo que nous utilisons est sous l’ancienne licence ?
Les photos en question sont classées dans une arborescence de type année/mois, ce qui représente au moins 60 répertoires. J'aimerais donc pouvoir lancer le script à la racine des répertoires d'années. D'un autre coté, j'imagine qu'on ne peut pas charger la barque de tblDng avec des milliers de noms de fichiers ?
La centralisation pose, entre autres, le problème de la confiance. Ce n'est pas parce que c'est libre que je fais confiance aux administrateurs.
Je ne vois pas le rapport avec la décentralisation : tu as toujours ton compte sur un serveur, géré par un administrateur auquel tu dois faire confiance.
Tu ne confonds pas avec solution distribuée (type Jami par exemple) ?
Je partage ton point de vue sur Matrix vs XMPP. Cependant, force est de reconnaître que le processus "idéal" de standardisation de XMPP induit une grande lenteur. L'alternative qui consiste à ré-inventer un protocole qui contient tout ce dont on a besoin (et une implémentation de référence pour un serveur et un client) puis à le proposer "out of the box" comme un nouveau standard ouvert va beaucoup plus vite. D'ailleurs, preuve pour moi que ce ne sont pas les bases techniques de XMPP qui seraient vieillissantes, c'est que certaines messageries propriétaires d'aujourd'hui sont parties d'une base XMPP et ça ne les a pas empêché d'avoir des fonctionnalités complètes et de conquérir une grosse part d'utilisateurs.
Comme le noyau Linux ? Je croyais que faire des monolithes, c'était mal :)
On parle d'un protocole, pas d'une implémentation, hein… Je n'ai rien contre la découpe en XEP, c'est le fait qu'elles soient optionnelles qui me paraît dommageable pour le succès de XMPP.
Pour avoir monté un serveur XMPP […] j'étais déjà à plus de 80% des tests de compliance.
Je parlais du protocole pas des implémentations et de leur configuration par défaut (dont tu confirmes toi-même qu'il manque quand même 20% dans une d'entre-elle et dont rien ne garantit que c'est celle qui va être choisie par l'administrateur du service).
Je persiste à penser que si le core du protocole XMPP incluait obligatoirement tout ce qu'on s'attend à trouver dans une messagerie moderne, on aurait moins d'implémentations (serveurs et clients) différentes formant la fédération et il y aurait moins de déceptions* de la part des utilisateurs qui pensaient trouver la solution pour un "whatsapp" plus respectueux de leurs données personnelles et qui marche "out of the box".
* même si celles-ci tendent à diminuer grâce aux nombreuses initiatives telles que joinjabber, snikket, quicksy, …
NB. C'est dommage mais le fait est que c'est souvent bien plus rapide de créer un protocole et l'implémentation de référence qui va avec, puis de proposer d'en faire un standard ou a minima de le rendre libre, que de construire ce protocole à plusieurs avec la nécessité d'un consensus à chaque étape. Et si en plus on rend optionnelle l'implémentation de ces étapes… C'est peut-être ce qui va faire que Matrix voire Jami vont réussir là où XMPP, pourtant parti bien avant et plein de qualités, ne va peut-être pas décoller.
Savoir que tes interlocuteurs ne sont pas capables de faire de l'A/V c'est bien mais ça ne résout pas mon problème si je veux communiquer avec eux. On en revient toujours au même point : comment convaincre quelqu'un de quitter whatsapp (ou consorts) si on n'est pas capable de lui assurer que la solution proposée inclut par défaut les services considérés comme le minimum requis pour faire de la messagerie ? Des initiatives comme joinjabber citée plus haut peuvent aider mais est-ce que ça sera suffisant pour compenser ce "défaut" (stratégique, pas technique) originel de XMPP : un core obligatoire minimaliste et une multitude d'options ?
Oui on peut avoir plusieurs terminaux avec le même compte , perso c'est sur smartphone Android, client lourd Linux et aussi client web (app.element.io).
Matrix peer to peer est présenté comme un Matrix "normal" du point de vue du client, c'est juste que le serveur est local sur le device. J'imagine donc que ton compte est sur ce serveur local. Si tu as plusieurs devices, avec chacun leur serveur local, comment ça peut être le même compte ?
Je me suis posé la même question mais j'ai tendance à rejeter "idéologiquement" Matrix pour avoir voulu ré-inventer ce qui existait déjà au lieu de contribuer à l'améliorer (y a t-il des raisons techniques empêchant d'implémenter des passerelles dans le cadre de XMPP ?).
Bon en fait j'attends la version swarm de jami ;-)
Moi aussi !
Je ne sais pas si Jami est mieux ou moins bien que XMPP, ni même si ça recouvre tout le domaine fonctionnel de XMPP (notamment des salons publics avec beaucoup de personnes) ou celui de Matrix (passerelles) mais au moins ils ne réinventent pas un énième standard qui fait la même chose que le précédent.
Ce serait formidablement utile d'avoir un lien vers des clients qui couvrent les principales plateformes utilisées, et garantissant entre eux texte, audio, vidéo […]
Il ne suffit pas qu'un client implémente les fonctionnalités souhaitées (texte, fichiers, appel A/V, …) il faut aussi que les serveurs concernés (le tien et ceux de tes contacts) les implémentent aussi.
Par ailleurs, il est vrai que XMMP permet de changer de client et/ou de serveur. Mais dans le cas d'un changement de serveur, comment ça se passe pour les données (conversations, fichiers), il y a une XEP qui décrit comment un serveur doit permettre de les exporter puis les réimporter ?
[^] # Re: Siècle des Lumières
Posté par mahikeulbody . En réponse au lien Lecture libre - "La révolte brisée. Femmes dans la Révolution française et l’Empire" (J-C Martin). Évalué à 2.
Il y a encore de la marge pour faire "mieux" :
https://www.lematin.ch/story/un-juge-propose-a-un-violeur-presume-depouser-sa-victime-573902863893
# typo
Posté par mahikeulbody . En réponse au journal L'Inde passe une nouvelle loi sur la publication sur Internet. Évalué à 5.
[^] # Re: libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 3. Dernière modification le 22 février 2021 à 21:18.
Ou alors l'auteur inscrirait, s'il le souhaite, la licence (et ses éventuels changements ultérieurs) dans une blockchain dédiée à ce type de problématique, associé à un hash de la photo. A défaut de le faire, la charge de la preuve lui reviendrait en cas de conflit.
(sous réserve que la gestion d'une blockchain pour ce genre d'usage soit
un peubeaucoup moins consommatrice d'énergie que pour le bitcoin).[^] # Re: libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 2. Dernière modification le 22 février 2021 à 21:03.
@Jehan : Merci pour cet éclairage.
[^] # Re: libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 4.
En fait ma question était la suivante : quand bien même on pourrait prouver que la photo a été libre avant de changer de licence, à qui revient la charge de prouver que la copie qu'on utilise a bien été faite AVANT le changement de licence ? Ou bien est-ce que "libre un jour implique forcément juridiquement libre toujours" ? (l'exemple des forks logiciels n'est pas pertinent ici si la photo n'évolue pas)
[^] # Re: libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 6.
Ça c'est la théorie. En pratique il peut s'avérer difficile de prouver que la copie qu'on utilise a été faite AVANT le changement de licence.
Tu forkes une photo comment ?
# libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 9.
Je n'y connais rien alors ma question est peut-être idiote mais une photo libre est définitivement libre ou bien son auteur peut en changer la licence ?
Si oui, on n'éviterait pas la problématique que tu soulèves : comment prouver que la photo que nous utilisons est sous l’ancienne licence ?
[^] # Re: Pour ajouter un grain de shell dash (sh)
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Je dois avoir les deux shells installés car les deux commandes marchent (je suis Manjaro/KDE).
[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Merci !
[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 3.
Merci !
[^] # Re: bashisme
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Ça marche, merci !
[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Il y a un moyen de rendre ça récursif ?
Les photos en question sont classées dans une arborescence de type année/mois, ce qui représente au moins 60 répertoires. J'aimerais donc pouvoir lancer le script à la racine des répertoires d'années. D'un autre coté, j'imagine qu'on ne peut pas charger la barque de
tblDngavec des milliers de noms de fichiers ?[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2. Dernière modification le 18 février 2021 à 15:51.
Ça marche, merci !
Merci également aux autres pour leurs variantes.
[^] # Re: bashisme
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
(J'ai ajouté un " manquant dans la ligne
echo "pas de fichier jpg pour ${FICHIER})Ça me dit :
pas de fichier jpg pour ./a.raw
pas de fichier jpg pour ./b.raw
pas de fichier jpg pour ./c.raw
ce qui n'est vrai que pour c.raw.
[^] # Re: À décomposer
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Merci d'avoir pris la peine de répondre.
J'ai essayé ton script sur cet exemple :
a.jpg a.raw b.jpg b.raw c.rawj'obtiens cette liste de fichiers à supprimer :
./a.jpg
./b.jpg
./c.jpg
alors que dans cet exemple, il ne faut supprimer que a.raw et b.raw (mais pas c.raw car il n'existe pas de c/jpg).
J'ai raté quelque chose ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 2.
Je ne vois pas le rapport avec la décentralisation : tu as toujours ton compte sur un serveur, géré par un administrateur auquel tu dois faire confiance.
Tu ne confonds pas avec solution distribuée (type Jami par exemple) ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3.
Je partage ton point de vue sur Matrix vs XMPP. Cependant, force est de reconnaître que le processus "idéal" de standardisation de XMPP induit une grande lenteur. L'alternative qui consiste à ré-inventer un protocole qui contient tout ce dont on a besoin (et une implémentation de référence pour un serveur et un client) puis à le proposer "out of the box" comme un nouveau standard ouvert va beaucoup plus vite. D'ailleurs, preuve pour moi que ce ne sont pas les bases techniques de XMPP qui seraient vieillissantes, c'est que certaines messageries propriétaires d'aujourd'hui sont parties d'une base XMPP et ça ne les a pas empêché d'avoir des fonctionnalités complètes et de conquérir une grosse part d'utilisateurs.
[^] # Re: EDF n'est pas un industriel
Posté par mahikeulbody . En réponse au journal Hercule démantèlera-t-il l'électricité de France. Évalué à 4.
Le palier N4 est de conception "purement française", selon wikipedia (soit 4 x 1450 MW).
[^] # Re: Matrix vs XMPP
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3. Dernière modification le 02 février 2021 à 10:28.
On parle d'un protocole, pas d'une implémentation, hein… Je n'ai rien contre la découpe en XEP, c'est le fait qu'elles soient optionnelles qui me paraît dommageable pour le succès de XMPP.
Je parlais du protocole pas des implémentations et de leur configuration par défaut (dont tu confirmes toi-même qu'il manque quand même 20% dans une d'entre-elle et dont rien ne garantit que c'est celle qui va être choisie par l'administrateur du service).
Je persiste à penser que si le core du protocole XMPP incluait obligatoirement tout ce qu'on s'attend à trouver dans une messagerie moderne, on aurait moins d'implémentations (serveurs et clients) différentes formant la fédération et il y aurait moins de déceptions* de la part des utilisateurs qui pensaient trouver la solution pour un "whatsapp" plus respectueux de leurs données personnelles et qui marche "out of the box".
* même si celles-ci tendent à diminuer grâce aux nombreuses initiatives telles que joinjabber, snikket, quicksy, …
NB. C'est dommage mais le fait est que c'est souvent bien plus rapide de créer un protocole et l'implémentation de référence qui va avec, puis de proposer d'en faire un standard ou a minima de le rendre libre, que de construire ce protocole à plusieurs avec la nécessité d'un consensus à chaque étape. Et si en plus on rend optionnelle l'implémentation de ces étapes… C'est peut-être ce qui va faire que Matrix voire Jami vont réussir là où XMPP, pourtant parti bien avant et plein de qualités, ne va peut-être pas décoller.
[^] # Re: Matrix vs XMPP
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4. Dernière modification le 01 février 2021 à 20:56.
Savoir que tes interlocuteurs ne sont pas capables de faire de l'A/V c'est bien mais ça ne résout pas mon problème si je veux communiquer avec eux. On en revient toujours au même point : comment convaincre quelqu'un de quitter whatsapp (ou consorts) si on n'est pas capable de lui assurer que la solution proposée inclut par défaut les services considérés comme le minimum requis pour faire de la messagerie ? Des initiatives comme joinjabber citée plus haut peuvent aider mais est-ce que ça sera suffisant pour compenser ce "défaut" (stratégique, pas technique) originel de XMPP : un core obligatoire minimaliste et une multitude d'options ?
[^] # Re: Mauvaise question...
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 2.
Les analogies, c'est bien pour aider à faire comprendre, mais ça a de sérieuses limites quand il s'agit de s'en servir pour démontrer.
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 2.
Matrix peer to peer est présenté comme un Matrix "normal" du point de vue du client, c'est juste que le serveur est local sur le device. J'imagine donc que ton compte est sur ce serveur local. Si tu as plusieurs devices, avec chacun leur serveur local, comment ça peut être le même compte ?
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4.
Le serveur de référence de Matrix est réputé super consommateur de ressources, ça va le faire sur un smartphone ?
De plus, est-ce que cette solution permettra d'avoir plusieurs devices reliés au même compte (comme le permet Jami) ?
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7.
Je me suis posé la même question mais j'ai tendance à rejeter "idéologiquement" Matrix pour avoir voulu ré-inventer ce qui existait déjà au lieu de contribuer à l'améliorer (y a t-il des raisons techniques empêchant d'implémenter des passerelles dans le cadre de XMPP ?).
Moi aussi !
Je ne sais pas si Jami est mieux ou moins bien que XMPP, ni même si ça recouvre tout le domaine fonctionnel de XMPP (notamment des salons publics avec beaucoup de personnes) ou celui de Matrix (passerelles) mais au moins ils ne réinventent pas un énième standard qui fait la même chose que le précédent.
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4.
Il ne suffit pas qu'un client implémente les fonctionnalités souhaitées (texte, fichiers, appel A/V, …) il faut aussi que les serveurs concernés (le tien et ceux de tes contacts) les implémentent aussi.
Par ailleurs, il est vrai que XMMP permet de changer de client et/ou de serveur. Mais dans le cas d'un changement de serveur, comment ça se passe pour les données (conversations, fichiers), il y a une XEP qui décrit comment un serveur doit permettre de les exporter puis les réimporter ?