le noyau Linux 5.10 est bien un noyau LTS au même titre que les noyaux 5.4 ou 4.19, même s'il n'est supporté que 2 ans.
Exact, au temps pour moi.
En consultant le forum de Mnajaro, il s'avère que le noyau 5.10 sera bien traité comme toute autre LTS par Manjaro même s'il n'est actuellement pas décrit comme tel dans le gestionnaire de noyaux (pour une raison que je n'ai pas bien compris mais qui importe peu au final).
A ma connaissance, le dernier noyau LTS est le 5.4, pas le 5.10 (et ça se voit dans l'outil graphique de gestion des noyaux). Mais pour autant, je ne pense pas qu'il y ait lieu de flipper avec une 5.10 supportée jusqu'à fin 2022, sauf peut-être s'il s'agit d'un serveur en prod.
Et en principe il n'y a pas vraiment lieu de s'occuper de la gestion des noyaux (sauf besoins particuliers), elle est automatique.
Comme je le dis dans mon précédent commentaire, par défaut, il change automatiquement. Il me semble cependant qu'avant il se contentait de signaler qu'un nouveau noyau était disponible via l'installateur graphique (très simple, au demeurant). Ce même installateur graphique permet de décider de rester sur un noyau LTS si on préfère.
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.
[^] # Re: LTS
Posté par mahikeulbody . En réponse au message gestion noyau Manjaro. Évalué à 2.
Exact, au temps pour moi.
En consultant le forum de Mnajaro, il s'avère que le noyau 5.10 sera bien traité comme toute autre LTS par Manjaro même s'il n'est actuellement pas décrit comme tel dans le gestionnaire de noyaux (pour une raison que je n'ai pas bien compris mais qui importe peu au final).
[^] # Re: LTS
Posté par mahikeulbody . En réponse au message gestion noyau Manjaro. Évalué à 2. Dernière modification le 31 mars 2021 à 17:50.
A ma connaissance, le dernier noyau LTS est le 5.4, pas le 5.10 (et ça se voit dans l'outil graphique de gestion des noyaux). Mais pour autant, je ne pense pas qu'il y ait lieu de flipper avec une 5.10 supportée jusqu'à fin 2022, sauf peut-être s'il s'agit d'un serveur en prod.
Et en principe il n'y a pas vraiment lieu de s'occuper de la gestion des noyaux (sauf besoins particuliers), elle est automatique.
[^] # Re: Il y a un gestionnaire de noyau
Posté par mahikeulbody . En réponse au message gestion noyau Manjaro. Évalué à 2. Dernière modification le 30 mars 2021 à 20:48.
Comme je le dis dans mon précédent commentaire, par défaut, il change automatiquement. Il me semble cependant qu'avant il se contentait de signaler qu'un nouveau noyau était disponible via l'installateur graphique (très simple, au demeurant). Ce même installateur graphique permet de décider de rester sur un noyau LTS si on préfère.
# 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.