Il y a un gestionnaire de noyaux en mode graphique (du moins sous KDE, je ne sais pas pour les autres desktops). Il permet de choisir son noyau sinon, par défaut, il me semble qu'il prend toujours le dernier tout en laissant l'avant-dernier et l'avant-avant dernier disponibles au démarrage.
Pour la petite histoire, il faut noter que EDF a passé plusieurs mois à analyser les causes de la catastrophe, qui se sont révélées être un enchaînement d'erreurs des opérateurs de la centrale. Ils en ont conclu que l'ergonomie de la salle de commande était une des causes principales (dizaines d'alarmes clignotantes augmentant le stress et empêchant de voir la cause initiale, absence de mécanisme "intelligent" de filtrage des alarmes, absence d'aide à la décision, etc). Ils étaient alors dans l'élaboration du palier N4 (1400MW). Ils ont construit un simulateur de salle de commande et étudié pendant un an les réactions des opérateurs à tout un tas de scénarios combinés à différentes aides au pilotage. Puis ils en ont tiré les spécifications de ce qui allait devenir la salle de commande (et, plus, généralement, du système de pilotage) du palier N4, tant sur l'aspect matériel que sur l'aspect informatique. Three Mile Island a vraiment été pris au sérieux par EDF (du moins le EDF de cette époque).
Je n'ai pas trouvé d'infos concernant ce qui est envisagé en terme de licence, tant sur les spécifications de l'interface matérielle pour pouvoir créer de nouveaux modules que sur les spécifications logicielles. Il y a aussi un fil reddit https://www.reddit.com/r/Pockit que je n'ai pas encore consulté, ça répond peut-être à ces questions.
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 ?
# Il y a un gestionnaire de noyau
Posté par mahikeulbody . En réponse au message gestion noyau Manjaro. Évalué à 3.
Il y a un gestionnaire de noyaux en mode graphique (du moins sous KDE, je ne sais pas pour les autres desktops). Il permet de choisir son noyau sinon, par défaut, il me semble qu'il prend toujours le dernier tout en laissant l'avant-dernier et l'avant-avant dernier disponibles au démarrage.
# ça a influencé EDF
Posté par mahikeulbody . En réponse au lien 1979, la centrale nucléaire de Three Mile Island aux USA, un aperçu de l’enfer - podcast franceinter. Évalué à 10.
Pour la petite histoire, il faut noter que EDF a passé plusieurs mois à analyser les causes de la catastrophe, qui se sont révélées être un enchaînement d'erreurs des opérateurs de la centrale. Ils en ont conclu que l'ergonomie de la salle de commande était une des causes principales (dizaines d'alarmes clignotantes augmentant le stress et empêchant de voir la cause initiale, absence de mécanisme "intelligent" de filtrage des alarmes, absence d'aide à la décision, etc). Ils étaient alors dans l'élaboration du palier N4 (1400MW). Ils ont construit un simulateur de salle de commande et étudié pendant un an les réactions des opérateurs à tout un tas de scénarios combinés à différentes aides au pilotage. Puis ils en ont tiré les spécifications de ce qui allait devenir la salle de commande (et, plus, généralement, du système de pilotage) du palier N4, tant sur l'aspect matériel que sur l'aspect informatique. Three Mile Island a vraiment été pris au sérieux par EDF (du moins le EDF de cette époque).
[^] # Re: voir aussi les vidéos sur le site du concepteur
Posté par mahikeulbody . En réponse au lien un projet de mini-pc modulaire. Évalué à 2. Dernière modification le 19 mars 2021 à 16:45.
Ah, merci !
# voir aussi les vidéos sur le site du concepteur
Posté par mahikeulbody . En réponse au lien un projet de mini-pc modulaire. Évalué à 2.
les vidéos de la timeline du projet : https://pockit.ai/
Je n'ai pas trouvé d'infos concernant ce qui est envisagé en terme de licence, tant sur les spécifications de l'interface matérielle pour pouvoir créer de nouveaux modules que sur les spécifications logicielles. Il y a aussi un fil reddit https://www.reddit.com/r/Pockit que je n'ai pas encore consulté, ça répond peut-être à ces questions.
En tous cas, je trouve ça assez impressionnant.
# Vidéo très intéressante
Posté par mahikeulbody . En réponse au lien Peut-on annuler la dette publique ? - Heu?reka. Évalué à 7.
A voir absolument à mon humble avis de "monsieur Michu" dans ce domaine.
[^] # 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 ?