Guillawme a écrit 219 commentaires

Super utile, merci d'avoir partagé !

Je voudrais ajouter une précision au cas où quelqu'un peu familier avec systemd lit ces instructions :

désactiver les connexions SSH par mots de passe, dans /etc/ssh/sshd_config:
PasswordAuthentication no

Après cette étape, il ne faut pas oublier de redémarrer sshd.service pour que les changements de configuration prennent effet. Ça se fait comme ça :

sudo systemctl restart sshd.service

Est-ce parce que les autres pays/entreprises n'ont pas réussi, ou carrément pas essayé d'en faire ?

Comme le journal l'explique, il est bien plus sûr de procéder à une conception rationnelle d'un vaccin sur la base de mécanismes connus (identifier la protéine la plus immunogène du virus, et en faire le principe actif du vaccin sous une forme isolée qui ne risque pas de provoquer la maladie), que de procéder à des essais empiriques pour inactiver le virus sans être nécessairement capable de déterminer pourquoi ça fonctionne. De mon point de vue, c'est déjà une justification suffisante pour préférer l'approche rationnelle.

Mais la conception et le développement d'un vaccin, ce n'est qu'une seule facette du problème. En pratique, pour vacciner des milliards de personnes, il faut aussi produire le vaccin à grande échelle. Dans le cas d'un vaccin à virus inactivé, ça signifie qu'il faut commencer par produire de grandes quantités de virus. C'est très difficile et très coûteux pour beaucoup de raisons, entre autres :

• Les normes de sécurité à suivre : pour travailler avec SARS-CoV-2, il faut des installations de sécurité niveau P4 (peut-être maintenant seulement P3, mais quand aucun vaccin n'existait encore, il fallait P4). Ces installations sont plus rares que des labos ayant affaire à des risques biologiques minimaux, coûteuses à construire si on en a besoin de plus, coûteuses à faire fonctionner, et requièrent du personnel plus spécialement formé.
• Le risque auquel on expose les travailleurs qui produisent le vaccin : le risque zéro n'existe pas, il peut y avoir des accidents même en suivant toutes les normes de sécurité. Quel niveau de risque on accepte ? La sécurité des travailleurs est bien plus facile à assurer avec l'ARN qu'avec le virus, puisque pour manipuler de l'ARN il suffit d'un labo de biochimie standard et des équipements de protection individuelle minimaux.
• Le coût de la production : on peut produire des virus à partir de cellules en culture, mais la culture cellulaire coûte bien plus cher que la biochimie.
• La reproductibilité des lots : si on veut vacciner des milliards de personne, il faut garantir le plus possible des lots de vaccins aussi identiques qu'on peut les produire. Sinon, le suivi des effets secondaires est bien plus compliqué. Garantir la reproductibilité est beaucoup plus difficile quand on utilise un système vivant comme des cellules en culture, car ces cellules évoluent et le virus qu'elles produisent aussi. Il faut commencer par établir une lignée de cellules dans laquelle on peut répliquer le virus, et vérifier qu'on obtient bien les résultats désirés ; tout ça prend beaucoup temps (ce qui influence les coûts, voir le point précédent). L'ARN messager pour les vaccins est produit entièrement in vitro, sans jamais impliquer de culture cellulaire, par des procédés bien caractérisés et fiables (ce qui a nécessité des efforts de développement, c'est le passage de ces procédés à grande échelle, mais pas leur principe de fonctionnement). On peut produire de l'ARN avec une séquence bien définie avec des garanties de reproductibilité bien plus grandes.

Les vaccins à ARN messager requièrent de produire de grande quantités d'ARN. Ce n'est pas une tâche facile en soi, mais tout de même beaucoup plus facile et fiable que de produire des virus inactivés si on tient compte de ces quelques contraintes. Ce sont les contraintes auxquelles je pouvais penser, en tant que chercheur académique ; mais posez la même question à un chercheur dans l'industrie pharmaceutique et il vous trouvera certainement une myriade d'autres contraintes que je n'imagine même pas, et auxquelles les différentes technologies de vaccination répondent différemment. Il s'agissait donc de trouver un compromis acceptable pour répondre aux mieux à toutes ces contraintes, et ce n'est pas étonnant que différents pays ou différentes entreprises aient choisi des technologies de vaccin différentes.

C’est exactement à cette question que les essais cliniques tâchent de répondre. Je ne sais pas comment trouver les résultats de ces essais, car il y en a énormément, déjà faits ou encore en cours. Le NIH recense ces essais ici : https://clinicaltrials.gov/

Le risque économique a été effectivement partagé par les états sous la forme de précommandes ou d’engagements à commander un certain nombre de doses une fois les vaccins autorisés.

C’est une info que j’avais effectivement lue dans cet article de septembre 2020 : https://doi.org/10.1038/s41586-020-2798-3

Currently, several manufacturers have already started the commercial production of vaccines—at [economic] risk—without any results from phase III trials.

Un point qui me semble important n'a pas été abordé: Comment se fait-il que ce type de vaccin a une efficacité qui diminue aussi rapidement?
J'ai récemment fait un rappel vaccinal dTP lors duquel le docteur m'a lancé: "On se revoit dans 20 ans!".

20 ans pour le dTP et 4-6 mois l'ARN Messager? o_O

Alors je ne suis pas immunologiste (seulement biologiste structural), donc pas sûr de cette réponse. Mais je crois me souvenir d'avoir lu quelque part que l'infection naturelle par le SARS-CoV-2 confère aussi une immunité de relativement courte durée, comparé à d'autres maladies infectieuses. Donc ce ne serait pas la technologie de vaccination qui serait en cause, mais plutôt la nature de l'antigène (en l'occurrence la protéine S de ce virus).

Y a-t-il a un immunologiste sur ce site qui pourrait nous en dire plus à ce sujet ?

Certaines configurations RAID améliorent aussi beaucoup les performances en lecture et écriture, ce qui est nécessaire pour certaines applications.

Merci, je ne connaissais pas cette option. Les deux stations de travail que j’administre sont déjà sous Rocky, mais je note, car ça pourrait m’être utile plus tard.

Cela dit, pour mon usage actuel je préfère le rythme de mises à jour plus conservateur de RHEL et ses clones que de CentOS Stream (il y a déjà certaines dépendances d’un programme que j’utilise qui sont trop récentes dans Rocky 8.4).

bin, suffirait de pas avoir besoin de nVidia ;-)

Va expliquer ça aux gens qui développent les logiciels que j'utilise. Moi je suis biochimiste de formation et de profession, et sysadmin par nécessité (et parce que j'y prends suffisamment plaisir, quand ça marche bien, pour ne pas vouloir le laisser à d'autres). Mais après tout ça, quand il reste du temps dans la semaine ce n'est pas le code, l'algèbre linéaire et les transformées de Fourier que j'aime pratiquer comme passe-temps. :-)

dommage d'être chercheur et de ne pas trouver :/ Là où la recherche est là pour expérimenter justement (voire innover).

Tu préfères que je dépense tes impôts ¹ comment ? En pratiquant ma spécialité qui consiste à déterminer des structures de protéines ? ce qui aide énormément à concevoir des trucs parfois utiles comme, au hasard, des vaccins ou des médicaments antiviraux pour se sortir du pétrin quand une pandémie nous tombe dessus ². Ou bien en bidouillant CentOS Stream en espérant que ça finisse par tomber en marche pour que je puisse enfin analyser mes images ?

Je suis d'accord avec toi que c'est important d'expérimenter. Mais une répartition des tâches est tout de même indispensable de nos jours, tant il y a de domaines complexes. Les polymathes comme Léonard de Vinci, ça n'existe quasiment plus. Est-il raisonnable d'attendre de biochimistes qu'ils soient aussi experts en informatique appliquée à l'analyse d'images ?

"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 :

1. 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.
2. 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 :

1. en exécutant en tant que root un binaire téléchargé depuis le site de Nvidia, ou
2. 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 :

1. 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).
2. 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".

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.

Est-ce que c’était l’extension de navigateur Treeverse ? https://treeverse.app/

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).

Ces liens sont listés dans le README du dépôt git, mais les voilà ici aussi pour plus de visibilité :

• l’article de blog dans lequel l’auteur explique pourquoi il a commencé à travailler sur cet outil : https://quakkels.com/posts/rss-is-wonderful/
• 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).

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. :-)

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.

En effet, et doom utilise straight ; j’ai fait un raccourci un peu trop rapide. :-)

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 :

1. 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
2. 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)
3. enfin, configurer package.el pour 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.

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.