"De fait, il est désormais inconcevable d'utiliser CentOS Stream en production."
C'est une affirmation un peu péremptoire…
Eh bien moi j'ai un exemple concret de la difficulté à utiliser CentOS Stream "en production".
Je suis chercheur, et dans mon domaine (la cryo-microscopie électronique) quasiment tous les logiciels d'analyse d'images exploitent l'accélération matérielle fournie par les GPU. Ces logiciels utilisent quasiment tous CUDA, une bibliothèque scientifique propriétaire de Nvidia. Cela cause deux problèmes :
Puisqu'on ne peut pas se passer de ces logiciels (ça reviendrait à renoncer à analyser les données issues de nos expériences), il faut acheter les GPU de Nvidia, alors que ce ne sont pas toujours le meilleur compromis selon les critères auxquels on attache de l'importance.
Il faut utiliser le pilote propriétaire de Nvidia, car CUDA n'est bien sûr pas compatible avec le pilote libre nouveau.
Il y a deux façons d'installer le pilote propriétaire de Nvidia :
en exécutant en tant que root un binaire téléchargé depuis le site de Nvidia, ou
en ajoutant le dépôt de Nvidia au gestionnaire de paquets pour ensuite installer le pilote selon la même procédure que les autres logiciels de la distribution.
La première méthode est à éviter, pour plein de raisons, mais surtout parce que le pilote installé ainsi n'est bien sûr pas mis à jour automatiquement. Par conséquent, les mises à jour automatiques du noyau par le gestionnaire de paquets cassent systématiquement le pilote. C'est une plaie de devoir réinstaller le pilote manuellement à chaque fois qu'une mise à jour même mineure du noyau débarque.
La seconde méthode fonctionne bien, car le gestionnaire de paquets n'installera jamais des versions du noyau et du pilote marquées comme incompatibles. Seulement, Nvidia ne fournit ces paquets pré-compilés du pilote que pour la version du noyau de la distribution RHEL stable. C'est expliqué ici. Puisque CentOS Stream a quasiment tout le temps un noyau plus récent que RHEL (par définition, puisque CentOS Stream se veut upstream par rapport à RHEL), ce paquet du pilote Nvidia n'est quasiment jamais compatible avec CentOS Stream. On se retrouve alors dans l'une des deux situations suivantes :
On a réussi à installer le pilote pendant une période où le noyau de CentOS Stream était toujours à une version compatible avec le paquet du pilote. On se retrouve par contre coincé sur cette version du noyau jusqu'à la prochaine mise à jour du noyau de RHEL quand Nvidia publiera la version correspondante du paquet du pilote. Du coup, utiliser CentOS Stream n'a pas trop d'intérêt (un de ses "arguments de vente" est que les mises à jour sont plus fréquentes qu'avec RHEL).
La version du noyau installée n'est pas compatible avec le paquet du pilote Nvidia. Il faut choisir entre rétrograder la version du noyau (pas vraiment recommandé en général) à la dernière version compatible avec le pilote, ou se passer du pilote jusqu'à la prochaine version du noyau compatible (comme dans la situation 1, mais dans le cas où on n'a même pas pu installer le pilote au départ), ce qui peut mettre plusieurs mois à arriver (car la prochaine mise à jour du noyau ne suffit pas, il faut aussi tomber sur une version que Nvidia accepte de supporter avec son pilote).
Pour résumer : quand on a besoin du pilote Nvidia, CentOS Stream c'est la galère en permanence, alors que RHEL ou ses clones qui suivent strictement ses versions (Alma, Rocky et autres) "juste marchent".
Ce n’est pas un lecteur, seulement un outil pour extraire automatiquement les liens vers d’autres flux RSS à partir d’un flux de départ. Une fois ces liens identifiés, c’est à l’utilisateur de décider de les ajouter à son lecteur RSS s’il trouve ces liens intéressants.
L’auteur explique que c’est une tentative d’automatiser la découverte de nouveaux contenus (qui est une fonctionnalité importante des réseaux sociaux, mais inexistante avec les flux RSS).
une instance de l’outil (un test rapide n’a pas marché pour moi… mais bon, l’auteur précise que c’est encore au stade alpha) : https://rdengine.herokuapp.com/
Tout à fait. Il s'agit surtout de la conversion automatique de ce que tu rentre en un format donné. Du genre tu tapes "1", il reconnait que c'est un nombre, si tu tape "un", il reconnait que c'est du texte, et dans chaque situation, le type de la cellule est automatiquement choisi.
Et effectivement, c'est très pénible dans un certain nombre de cas, et je ne suis pas sur que ce soit désactivable (mais je serais heureux d'avoir tord…). Le pire de la détection est justement celle qui reconnait (ou croit reconnaître) une date. Dans un des problèmes rencontré, tu veux le texte "MARCH-1", tu te retrouve avec la date du premier mars.
Pour moi le problème c’est surtout que la détection automatique de type dans les tableurs se fait individuellement pour chaque cellule. Avec R, pandas et sûrement d’autres implémentations d’une structure de dataframe, il y a aussi une détection automatique de type, mais elle opère par colonne (donc si une cellule ressemble à une date dans une colonne où toutes les autres cellules sont clairement du texte, toute la colonne sera typée texte). Si les tableurs encourageaient une organisation « tidy data » (les colonnes sont des variables, les lignes sont des observations), ils pourraient aussi faire la détection automatique de type sur les colonnes entières. Mais si on laisse l’utilisateur choisir ce que les colonnes et lignes signifient, la détection de type ne peut pas être autrement que par cellule, parce qu’on ne sait pas si ce sont les colonnes ou les lignes qui représentent les variables.
que faire d'un dev qui produit par hasard fortuitement un code suffisamment proche d'un code existant ?
Pour moi il n'est pas coupable, mais il pourrait être condamné s'il n'arrive pas à prouver qu'il n'a jamais vu ce code existant.
Dans une juridiction qui fonctionne avec la présomption d’innocence, c’est à l’accusation de prouver que ce développeur a vu le code ressemblant, et non pas au développeur de prouver qu’il n’a jamais vu ce code.
Principalement parce que je suis plus familiarisé avec CentOS, et comme c’est pour le boulot je n’ai pas trop le loisir de bidouiller, il faut que ça marche facilement (donc idéalement en changeant le système le moins possible). Mais si aucune alternative crédible à CentOS n’avait émergé d’ici la fin de l’année en effet je serais sûrement passé à Ubuntu LTS.
J’ai aussi bon espoir que cette distribution devienne la nouvelle CentOS.
Je suis un admin sys par nécessité au boulot, et vraiment à petite échelle (seulement deux stations de travail à administrer, des utilisateurs qui se comptent sur les doigts d’une seule main), mais malgré cette situation plutôt facile le passage de CentOS à un modèle de mise à jour continue est très problématique car j’ai besoin du pilote propriétaire pour des GPUs nvidia (pas le choix, c’est pour des programmes scientifiques qui dépendent de CUDA) et ce pilote ne suit que les changements de version du noyau de RHEL, pas de la nouvelle CentOS.
Je compte bien passer ces deux ordinateurs à Rocky d’ici la fin de vie de CentOS 8 (fin de l’année).
Je ne suis pas sûr que la comparaison ait du sens. Si Bayrou avait giflé un président en 2002, il aurait sûrement eu des problèmes, même à l’époque. Concernant la gifle d’aujourd’hui, il semble que ce n’est pas tant le geste qui a causé de l’émoi, mais bien le fait qu’il ciblait un président.
Quant à savoir si Macron mérite des baffes en retour de la violence fiscale, sociale et policière qu’il orchestre à l’encontre de pans entiers de la population, je ne me prononcerai pas. Chacun pourra se faire un avis en lisant les journaux.
C'était parce que je suivais les recommandations de l'article que j'ai cité plus haut, mais que je voulais une solution plus simple que d'installer un paquet Python comme cet article le propose ("Step 3" dans l'article). Télécharger un unique fichier semblait bien plus facile, et le développeur de curl semblait être une source de confiance. Quand j'ai fait ça il y a quelques années, je n'y comprenais pas grand chose, donc je voulais faire au plus près de ce que l'article indiquait, et il ne mentionnait pas qu'il existe normalement un fichier central dans le système. Mais c'est sûr que c'est en fait bien plus simple (et le fichier de certificats que j'utilise pour télécharger dans ce script est celui du système). Je précise que je n'utilise plus cette configuration depuis un moment.
Un truc important à savoir si tu utilises une configuration personnelle (non basée sur Spacemacs, doom ou autre) et des paquets téléchargés depuis ELPA ou MELPA avec package.el (le système de paquets intégré à Emacs) : par défaut les téléchargements sont en clair (HTTP au lieu de HTTPS), et configurer explicitement la liste des dépôts avec des URLs en HTTPS n'est pas suffisant pour forcer la vérification des certificats SSL/TLS. C'est expliqué en détails dans cet article : Your text editor is malware.
La solution que j'avais trouvée (depuis je suis passé à doom), c'était :
télécharger un fichier de certificats racines à jour mis à disposition par le développeur de curl (en utilisant les certificats du système hôte pour ce premier téléchargement, c'est la ligne 8 dans ce script, donc à ajuster selon l'emplacement de ce fichier sur ton système) ; ce script ne télécharge pas le fichier si la version locale existe et n'est pas plus ancienne que la version sur le serveur
dans la configuration d'Emacs, ajuster certaines variables de configuration, et surtout s'assurer que le script ci dessus est lancé à chaque démarrage d'Emacs (lignes 25-29 dans ce fichier de configuration ; ça ne ralentit presque pas le démarrage, puisque le téléchargement n'a lieu que si le fichier de certificats a été mis à jour), puis s'assurer qu'Emacs utilises bien ce fichier pour trouver les certificats TLS (lignes 31-32 ; d'ailleurs je m'aperçois que ce fichier n'est pas à jour sur GitHub, il faudrait bien sûr décommenter "~/.emacs.d/cacert.pem" dans cette liste)
Avec doom il n'y a pas besoin de faire tout ça car il n'utilise pas package.el : il clone les dépôts git des paquets directement. Et il me semble (mais à vérifier) que git opère bien la vérification des certificats SSL/TLS quand il clone ou fetch depuis une URL en HTTPS.
Le principe de fish c’est que tu n’as pas besoin de le configurer (ou seulement un minimum), et il « juste marche » comme ils disent. Dans le cas de la complétion, plus tu utilises fish et plus elle devient pertinente. Donc je te conseilles d’essayer de l’utiliser à plein temps quelques jours, et tu devrais déjà le trouver plus utile qu’après ton premier essai.
Concernant la syntaxe, tu peux tout à fait utiliser fish comme shell par défaut pour l’utilisation interactive et continuer d’écrire et d’exécuter des scripts bash/zsh/sh. Beaucoup de gens font ça, moi aussi, et je crois bien que rien ne me fera revenir à bash ni tester zsh comme shell, par contre je n’ai pas non plus besoin de désapprendre la syntaxe de bash et d’apprendre celle de fish pour les scripts.
[Emacs] est parfaitement efficace. Et ça marche sur mon ordi, en graphique, dans un terminal, ou même à distance via ssh.
Si tu as un accès ssh à un système distant, le plus simple est d’ouvrir les fichiers distants dans ton Emacs local à l’aide de TRAMP (inclus dans Emacs depuis la version 22.1). Pour l’avoir utilisé un peu, c’est vraiment excellent : rien à configurer, il faut simplement préciser que le fichier est distant lorsque tu fais un find-file (il y a une syntaxe pour ça qui ressemble un peu à la spécification d’un chemin distant avec rsync), et après ça marche de façon complètement transparente en se faisant oublier (mais bien sûr tu peux tout configurer si tu veux, ça reste Emacs après tout). Et surtout c’est beaucoup plus fiable que d’espérer que le système distant ait un Emacs relativement à jour installé, de devoir installer ta configuration sur le système distant, espérer qu’elle va marcher sans problème avec une version différente d’Emacs, et autres complications potentielles.
Une solution similaire mais qui donne aussi automatiquement accès aux fichiers distants à tous tes programmes locaux, c’est de monter sur ton système de fichier local le répertoire qui t’intéresse sur le système distant, en utilisant sshfs. Ça marche aussi super bien, rien à configurer non plus, et ça n’est pas limité à Emacs.
Il semblerait que le ruissellement fonctionne, mais à l’envers. La pandémie a accéléré l’enrichissement des riches et l’appauvrissement des pauvres (pas déclenché, seulement accéléré : ce ruissellement existait déjà avant la pandémie).
Ah vous voulez des sources ? Est-ce une demande raisonnable pour un vendredi ?..
Ces deux expériences, chez des éditeurs différents, me font penser que ces revues en libre accès ne sont que du libre washing, c’est-à-dire que les éditeurs y voient une nouvelle source de revenu (il faut payer pour publier) sans rien comprendre aux différentes licences comme les réponses que j’ai obtenues le laisse penser.
Cela n’étonnera personne connaissant un peu le milieu de la recherche, surtout venant de Springer. C’est bien connu que les grosses boites d’édition scientifique ont adopté l’accès gratuit pour les lecteurs comme une variante de leur modèle économique plus conventionnel basé sur l’abonnement, et qu’elles suivent un peu le mouvement du libre accès uniquement parce qu’elles en tirent des bénéfices.
Ces deux modèles de publication sont d’ailleurs habilement utilisés de concert. Par exemple, quand un article est rejeté sans peer review dans un journal comme Nature parce que l’éditeur (au sens « la personne qui décide si l’article sera envoyé à des reviewers », pas au sens « la maison d’édition » ; c’est embêtant qu’en français on n’ait pas deux mots pour publisher et editor) décide que l’article ne présente rien d’assez important ou nouveau pour être publié dans ce journal, les auteurs se voient souvent proposer de transférer leur article à Nature Communications avec la garantie qu’il sera envoyé au peer review par cet autre journal. La différence, c’est que si l’article est publié dans Nature les auteurs ne payent rien mais les lecteurs doivent avoir un abonnement, alors que pour Nature Communications l’accès est gratuit pour les lecteurs mais il y a des APC (article processing charges : des frais conséquents de l’ordre de plusieurs milliers d’euros par article) à la charge des auteurs si l’article est accepté après peer review. Donc l’éditeur (cette fois au sens publisher, maison d’édition) se sert de son journal prestigieux où tout le monde veut publier comme d’un rabatteur vers son journal open access un peu moins prestigieux mais où les auteurs seront quand même contents de payer pour avoir le mot « nature » dans le titre du journal.
La situation des licences est probablement plus claire chez les éditeurs dont l’accès libre est le modèle principal. Par exemple les journaux de PLOS, eLife, certains journaux édités par des sociétés savantes comme l’IUCR, etc.
Ah désolé, en relisant je m’aperçois que j’ai effectivement compris ce passage de travers. C’est sûr que la tolérance implicite pour des clients non officiels n’est pas une garantie suffisante pour ceux qui dépendent de ces clients.
Les contacts sont dans le téléphone, pas dans l’application Signal. Donc qu’est-ce qui empêcherait une application de paiement distincte de Signal de demander l’accès aux contacts pour faire son boulot ? Je n’ai lu nulle part que MobileCoin dépend du protocole Signal, et même si c’était le cas, un peu de duplication de code (mettre le même protocole dans deux applications distinctes) serait encore préférable à mettre la messagerie et le paiement dans la même application et donc à imposer aux deux usages le plus haut niveau de vulnérabilité (en termes techniques et juridiques) de l’un des deux.
Avec une application de paiement distincte, les utilisateurs pourraient décider de faire confiance à l’une ou l’autre application, ou aux deux. Même fonctionnalités, plus de choix pour les utilisateurs, ce ne serait pas mieux ?
officiellement les clients tiers ne sont pas autorisés, mais certains peuvent être tolérés (comme whatsapp quoi, donc on ne sait pas lesquels, pourquoi, jusqu'à quand)
Les clients tiers ne sont pas autorisés sur leur réseau, et justement WhatsApp ne se connecte pas au même réseau (si c’était le cas, il n’y aurait pas besoin de convaincre tes contacts de changer d’application : tu pourrais envoyer un message depuis Signal et eux le recevraient dans WhatsApp). WhatsApp utilise ses propres serveurs, non fédérés à ceux de Signal. La seule chose qu’ils ont en commun c’est qu’ils parlent le même protocole (ce qui leur permettrait techniquement de fédérer leurs réseaux, si la volonté de le faire existait).
Bah c'est un peu ça : les bons côtés de Jupyter et d'un tableur, mais réunis dans la même application ! Donc comme un tableur, mais avec l'avantage d'un langage de programmation plus agréable à lire (rien que pouvoir nommer ses variables, c'est bien plus pratique que des coordonnées de cellules). Et dans le cas de Julia en particulier, il y a un nombre impressionnant de bibliothèques pour faire à peu près tout et n'importe quoi, depuis des tâches généralistes comme des requêtes HTTP jusqu'à des trucs de pointe comme de l'apprentissage automatique accéléré sur GPU, en passant par du traitement d'images (bien sûr avec retour visuel immédiat, quand c'est fait dans un notebook Pluto : impossible de faire ça dans un tableur).
Cela dit, même en considérant les tableurs comme une application distincte, ce principe de notebook réactif n'est apparemment pas nouveau : les auteurs de Pluto écrivent qu'ils se sont beaucoup inspirés d'un autre système qui s'appelle Observable (je n'ai jamais utilisé ça).
[^] # Re: Utilisation en production
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ? . Évalué à 5.
Eh bien moi j'ai un exemple concret de la difficulté à utiliser CentOS Stream "en production".
Je suis chercheur, et dans mon domaine (la cryo-microscopie électronique) quasiment tous les logiciels d'analyse d'images exploitent l'accélération matérielle fournie par les GPU. Ces logiciels utilisent quasiment tous CUDA, une bibliothèque scientifique propriétaire de Nvidia. Cela cause deux problèmes :
Il y a deux façons d'installer le pilote propriétaire de Nvidia :
La première méthode est à éviter, pour plein de raisons, mais surtout parce que le pilote installé ainsi n'est bien sûr pas mis à jour automatiquement. Par conséquent, les mises à jour automatiques du noyau par le gestionnaire de paquets cassent systématiquement le pilote. C'est une plaie de devoir réinstaller le pilote manuellement à chaque fois qu'une mise à jour même mineure du noyau débarque.
La seconde méthode fonctionne bien, car le gestionnaire de paquets n'installera jamais des versions du noyau et du pilote marquées comme incompatibles. Seulement, Nvidia ne fournit ces paquets pré-compilés du pilote que pour la version du noyau de la distribution RHEL stable. C'est expliqué ici. Puisque CentOS Stream a quasiment tout le temps un noyau plus récent que RHEL (par définition, puisque CentOS Stream se veut upstream par rapport à RHEL), ce paquet du pilote Nvidia n'est quasiment jamais compatible avec CentOS Stream. On se retrouve alors dans l'une des deux situations suivantes :
Pour résumer : quand on a besoin du pilote Nvidia, CentOS Stream c'est la galère en permanence, alors que RHEL ou ses clones qui suivent strictement ses versions (Alma, Rocky et autres) "juste marchent".
# Compétition internationale
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal TapTempo Fortran. Évalué à 10.
Bon, pour le moment la France a une longueur d’avance avec toutes ces recherches sur TapTempo publiées dans ce journal et les précédents, mais il commence à y avoir de la compétition internationale : https://lobste.rs/s/dyxogq/bpm_is_tap_along_with_beat_song_discover
Si quelqu’un a un compte sur lobster.rs, ce serait marrant de montrer à ce type toutes les implémentations déjà postées dans des journaux ici.
[^] # Re: « Google is evil »
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Google is evil : ce qu’on trouve dans une plainte contre eux. Évalué à 2.
Est-ce que c’était l’extension de navigateur Treeverse ? https://treeverse.app/
[^] # Re: Liens complémentaires
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien RSS discovery engine. Évalué à 3.
Ce n’est pas un lecteur, seulement un outil pour extraire automatiquement les liens vers d’autres flux RSS à partir d’un flux de départ. Une fois ces liens identifiés, c’est à l’utilisateur de décider de les ajouter à son lecteur RSS s’il trouve ces liens intéressants.
L’auteur explique que c’est une tentative d’automatiser la découverte de nouveaux contenus (qui est une fonctionnalité importante des réseaux sociaux, mais inexistante avec les flux RSS).
# Liens complémentaires
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien RSS discovery engine. Évalué à 2.
Ces liens sont listés dans le README du dépôt git, mais les voilà ici aussi pour plus de visibilité :
[^] # Re: Mouai...
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien L'abus du tableur Excel peut conduire à des erreurs médicales, des faillites et des émeutes.. Évalué à 2.
Pour moi le problème c’est surtout que la détection automatique de type dans les tableurs se fait individuellement pour chaque cellule. Avec R, pandas et sûrement d’autres implémentations d’une structure de
dataframe, il y a aussi une détection automatique de type, mais elle opère par colonne (donc si une cellule ressemble à une date dans une colonne où toutes les autres cellules sont clairement du texte, toute la colonne sera typée texte). Si les tableurs encourageaient une organisation « tidy data » (les colonnes sont des variables, les lignes sont des observations), ils pourraient aussi faire la détection automatique de type sur les colonnes entières. Mais si on laisse l’utilisateur choisir ce que les colonnes et lignes signifient, la détection de type ne peut pas être autrement que par cellule, parce qu’on ne sait pas si ce sont les colonnes ou les lignes qui représentent les variables.[^] # Re: Un sacré merdier ?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 4.
Dans une juridiction qui fonctionne avec la présomption d’innocence, c’est à l’accusation de prouver que ce développeur a vu le code ressemblant, et non pas au développeur de prouver qu’il n’a jamais vu ce code.
[^] # Re: De l'espoir
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Première version stable de Rocky Linux (8.4). Évalué à 1.
Principalement parce que je suis plus familiarisé avec CentOS, et comme c’est pour le boulot je n’ai pas trop le loisir de bidouiller, il faut que ça marche facilement (donc idéalement en changeant le système le moins possible). Mais si aucune alternative crédible à CentOS n’avait émergé d’ici la fin de l’année en effet je serais sûrement passé à Ubuntu LTS.
[^] # Re: De l'espoir
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Première version stable de Rocky Linux (8.4). Évalué à 1.
J’ai aussi bon espoir que cette distribution devienne la nouvelle CentOS.
Je suis un admin sys par nécessité au boulot, et vraiment à petite échelle (seulement deux stations de travail à administrer, des utilisateurs qui se comptent sur les doigts d’une seule main), mais malgré cette situation plutôt facile le passage de CentOS à un modèle de mise à jour continue est très problématique car j’ai besoin du pilote propriétaire pour des GPUs nvidia (pas le choix, c’est pour des programmes scientifiques qui dépendent de CUDA) et ce pilote ne suit que les changements de version du noyau de RHEL, pas de la nouvelle CentOS.
Je compte bien passer ces deux ordinateurs à Rocky d’ici la fin de vie de CentOS 8 (fin de l’année).
# RC déjà postée, je sais
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Première version stable de Rocky Linux (8.4). Évalué à 1.
J’ai vu que le lien vers la release candidate à été posté il y a peu de temps, mais une version stable mérite aussi bien un lien. :-)
# Et si Bayrou avait giflé un président ?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Évolution de la société. Évalué à 10.
Je ne suis pas sûr que la comparaison ait du sens. Si Bayrou avait giflé un président en 2002, il aurait sûrement eu des problèmes, même à l’époque. Concernant la gifle d’aujourd’hui, il semble que ce n’est pas tant le geste qui a causé de l’émoi, mais bien le fait qu’il ciblait un président.
Quant à savoir si Macron mérite des baffes en retour de la violence fiscale, sociale et policière qu’il orchestre à l’encontre de pans entiers de la population, je ne me prononcerai pas. Chacun pourra se faire un avis en lisant les journaux.
[^] # Re: Paquets ELPA/MELPA et config perso
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Un noob et son Emacs: charger différentes configs au démarrage. Évalué à 3. Dernière modification le 22 mai 2021 à 19:55.
C'était parce que je suivais les recommandations de l'article que j'ai cité plus haut, mais que je voulais une solution plus simple que d'installer un paquet Python comme cet article le propose ("Step 3" dans l'article). Télécharger un unique fichier semblait bien plus facile, et le développeur de curl semblait être une source de confiance. Quand j'ai fait ça il y a quelques années, je n'y comprenais pas grand chose, donc je voulais faire au plus près de ce que l'article indiquait, et il ne mentionnait pas qu'il existe normalement un fichier central dans le système. Mais c'est sûr que c'est en fait bien plus simple (et le fichier de certificats que j'utilise pour télécharger dans ce script est celui du système). Je précise que je n'utilise plus cette configuration depuis un moment.
[^] # Re: Paquets ELPA/MELPA et config perso
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Un noob et son Emacs: charger différentes configs au démarrage. Évalué à 2.
En effet, et doom utilise straight ; j’ai fait un raccourci un peu trop rapide. :-)
# Paquets ELPA/MELPA et config perso
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Un noob et son Emacs: charger différentes configs au démarrage. Évalué à 5.
Un truc important à savoir si tu utilises une configuration personnelle (non basée sur Spacemacs, doom ou autre) et des paquets téléchargés depuis ELPA ou MELPA avec
package.el(le système de paquets intégré à Emacs) : par défaut les téléchargements sont en clair (HTTP au lieu de HTTPS), et configurer explicitement la liste des dépôts avec des URLs en HTTPS n'est pas suffisant pour forcer la vérification des certificats SSL/TLS. C'est expliqué en détails dans cet article : Your text editor is malware.La solution que j'avais trouvée (depuis je suis passé à doom), c'était :
"~/.emacs.d/cacert.pem"dans cette liste)package.elpour qu'il utilise les URLs en HTTPS pour les dépôts de paquets (lignes 9-23 dans ce fichier).Avec doom il n'y a pas besoin de faire tout ça car il n'utilise pas
package.el: il clone les dépôts git des paquets directement. Et il me semble (mais à vérifier) que git opère bien la vérification des certificats SSL/TLS quand il clone ou fetch depuis une URL en HTTPS.[^] # Re: Fish ?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal fzf et mon terminal. Évalué à 1. Dernière modification le 12 mai 2021 à 21:45.
Le principe de fish c’est que tu n’as pas besoin de le configurer (ou seulement un minimum), et il « juste marche » comme ils disent. Dans le cas de la complétion, plus tu utilises fish et plus elle devient pertinente. Donc je te conseilles d’essayer de l’utiliser à plein temps quelques jours, et tu devrais déjà le trouver plus utile qu’après ton premier essai.
Concernant la syntaxe, tu peux tout à fait utiliser fish comme shell par défaut pour l’utilisation interactive et continuer d’écrire et d’exécuter des scripts bash/zsh/sh. Beaucoup de gens font ça, moi aussi, et je crois bien que rien ne me fera revenir à bash ni tester zsh comme shell, par contre je n’ai pas non plus besoin de désapprendre la syntaxe de bash et d’apprendre celle de fish pour les scripts.
[^] # Emacs distant par ssh, il y a mieux
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Les doutes d'un gars qui écrit: sérieusement se mettre à Emacs, ou pas ?. Évalué à 3. Dernière modification le 12 mai 2021 à 21:26.
Si tu as un accès ssh à un système distant, le plus simple est d’ouvrir les fichiers distants dans ton Emacs local à l’aide de TRAMP (inclus dans Emacs depuis la version 22.1). Pour l’avoir utilisé un peu, c’est vraiment excellent : rien à configurer, il faut simplement préciser que le fichier est distant lorsque tu fais un
find-file(il y a une syntaxe pour ça qui ressemble un peu à la spécification d’un chemin distant avec rsync), et après ça marche de façon complètement transparente en se faisant oublier (mais bien sûr tu peux tout configurer si tu veux, ça reste Emacs après tout). Et surtout c’est beaucoup plus fiable que d’espérer que le système distant ait un Emacs relativement à jour installé, de devoir installer ta configuration sur le système distant, espérer qu’elle va marcher sans problème avec une version différente d’Emacs, et autres complications potentielles.Une solution similaire mais qui donne aussi automatiquement accès aux fichiers distants à tous tes programmes locaux, c’est de monter sur ton système de fichier local le répertoire qui t’intéresse sur le système distant, en utilisant sshfs. Ça marche aussi super bien, rien à configurer non plus, et ça n’est pas limité à Emacs.
# Mes articles préférés
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Excellentes explications interactives de plein de choses . Évalué à 3.
Tous ces articles sont excellents, j'ai particulièrement adoré lire (et jouer avec les animations interactives) les suivants :
# Ruissellement vers le haut
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Joe Biden : "L'économie du ruissellement n'a jamais fonctionné" - lalibre.be. Évalué à 6.
Il semblerait que le ruissellement fonctionne, mais à l’envers. La pandémie a accéléré l’enrichissement des riches et l’appauvrissement des pauvres (pas déclenché, seulement accéléré : ce ruissellement existait déjà avant la pandémie).
Ah vous voulez des sources ? Est-ce une demande raisonnable pour un vendredi ?..
# Différents types d’éditeurs scientifiques
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Journaux scientifiques en libre accès et foutoir avec les licences libres. Évalué à 10. Dernière modification le 22 avril 2021 à 21:02.
Cela n’étonnera personne connaissant un peu le milieu de la recherche, surtout venant de Springer. C’est bien connu que les grosses boites d’édition scientifique ont adopté l’accès gratuit pour les lecteurs comme une variante de leur modèle économique plus conventionnel basé sur l’abonnement, et qu’elles suivent un peu le mouvement du libre accès uniquement parce qu’elles en tirent des bénéfices.
Ces deux modèles de publication sont d’ailleurs habilement utilisés de concert. Par exemple, quand un article est rejeté sans peer review dans un journal comme Nature parce que l’éditeur (au sens « la personne qui décide si l’article sera envoyé à des reviewers », pas au sens « la maison d’édition » ; c’est embêtant qu’en français on n’ait pas deux mots pour publisher et editor) décide que l’article ne présente rien d’assez important ou nouveau pour être publié dans ce journal, les auteurs se voient souvent proposer de transférer leur article à Nature Communications avec la garantie qu’il sera envoyé au peer review par cet autre journal. La différence, c’est que si l’article est publié dans Nature les auteurs ne payent rien mais les lecteurs doivent avoir un abonnement, alors que pour Nature Communications l’accès est gratuit pour les lecteurs mais il y a des APC (article processing charges : des frais conséquents de l’ordre de plusieurs milliers d’euros par article) à la charge des auteurs si l’article est accepté après peer review. Donc l’éditeur (cette fois au sens publisher, maison d’édition) se sert de son journal prestigieux où tout le monde veut publier comme d’un rabatteur vers son journal open access un peu moins prestigieux mais où les auteurs seront quand même contents de payer pour avoir le mot « nature » dans le titre du journal.
La situation des licences est probablement plus claire chez les éditeurs dont l’accès libre est le modèle principal. Par exemple les journaux de PLOS, eLife, certains journaux édités par des sociétés savantes comme l’IUCR, etc.
# Alternatives ?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien duckduckgo ça craint du boudin ?. Évalué à 1.
C’est malheureux, mais l’article serait plus utile s’il proposait d’autres moteurs de recherche et expliquait les compromis à faire pour les utiliser.
[^] # Re: Des liens
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 1.
Merci pour le lien qui n’était pas dans le journal. :-)
[^] # Re: XMPP
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 1.
Ah désolé, en relisant je m’aperçois que j’ai effectivement compris ce passage de travers. C’est sûr que la tolérance implicite pour des clients non officiels n’est pas une garantie suffisante pour ceux qui dépendent de ces clients.
[^] # Re: Intégration
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 2.
Les contacts sont dans le téléphone, pas dans l’application Signal. Donc qu’est-ce qui empêcherait une application de paiement distincte de Signal de demander l’accès aux contacts pour faire son boulot ? Je n’ai lu nulle part que MobileCoin dépend du protocole Signal, et même si c’était le cas, un peu de duplication de code (mettre le même protocole dans deux applications distinctes) serait encore préférable à mettre la messagerie et le paiement dans la même application et donc à imposer aux deux usages le plus haut niveau de vulnérabilité (en termes techniques et juridiques) de l’un des deux.
Avec une application de paiement distincte, les utilisateurs pourraient décider de faire confiance à l’une ou l’autre application, ou aux deux. Même fonctionnalités, plus de choix pour les utilisateurs, ce ne serait pas mieux ?
[^] # Re: XMPP
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Signal envoie des signaux inquiétants. Évalué à 0.
Les clients tiers ne sont pas autorisés sur leur réseau, et justement WhatsApp ne se connecte pas au même réseau (si c’était le cas, il n’y aurait pas besoin de convaincre tes contacts de changer d’application : tu pourrais envoyer un message depuis Signal et eux le recevraient dans WhatsApp). WhatsApp utilise ses propres serveurs, non fédérés à ceux de Signal. La seule chose qu’ils ont en commun c’est qu’ils parlent le même protocole (ce qui leur permettrait techniquement de fédérer leurs réseaux, si la volonté de le faire existait).
[^] # Re: Contexte
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien PlutoCon 2021. Évalué à 2. Dernière modification le 10 avril 2021 à 19:30.
Bah c'est un peu ça : les bons côtés de Jupyter et d'un tableur, mais réunis dans la même application ! Donc comme un tableur, mais avec l'avantage d'un langage de programmation plus agréable à lire (rien que pouvoir nommer ses variables, c'est bien plus pratique que des coordonnées de cellules). Et dans le cas de Julia en particulier, il y a un nombre impressionnant de bibliothèques pour faire à peu près tout et n'importe quoi, depuis des tâches généralistes comme des requêtes HTTP jusqu'à des trucs de pointe comme de l'apprentissage automatique accéléré sur GPU, en passant par du traitement d'images (bien sûr avec retour visuel immédiat, quand c'est fait dans un notebook Pluto : impossible de faire ça dans un tableur).
Cela dit, même en considérant les tableurs comme une application distincte, ce principe de notebook réactif n'est apparemment pas nouveau : les auteurs de Pluto écrivent qu'ils se sont beaucoup inspirés d'un autre système qui s'appelle Observable (je n'ai jamais utilisé ça).