Mais si on considère l’empreinte environnementale du remplacement de tous ces ordinateurs x86 (extraction des matériaux bruts, fabrication, tous les transports jusqu’à l’acheteur final), est-ce que c’est vraiment une bonne idée ? Et si on considère tous les déchets générés par ces ordinateurs désormais inutilisés ? Combien d’années d’économie d’énergie par les nouvelles puces moins consommatrices « compenseront » cette empreinte ?
Le problème principal avec l’écosystème de gestion de paquets de Python, c’est qu’il est totalement en contradiction avec le principe « There should be one-- and preferably only one --obvious way to do it. » (PEP 20). Il y a beaucoup trop d’outils et de façons de faire, que ce soit pour générer des paquets ou pour les installer dans des environnements isolés.
Cette promesse est par contre très bien tenue par Julia : il n’y a qu’un seul gestionnaire de paquets (Pkg.jl), qui est capable de gérer des environnements isolés (des projets, en jargon Julia). Et pour créer un paquet, il suffit d’un fichier de description (Project.toml) et d’une arborescence de fichiers qui suit la convention (ce qui peut être généré automatiquement par PkgTemplates.jl).
Si vous développez ou utilisez des programmes s’exécutant au-dessus de l’interpréteur Python, il peut arriver que vous vous retrouviez avec un environnement très dégradé sur votre poste de travail..
La page NVIDIA publie des modules de noyau de GPU en open source indique que les pilotes GPU NVIDIA ont été conçus au fil des ans pour partager le code entre les systèmes d'exploitation et donc que le code actuel n'est pas conforme aux conventions de conception du noyau Linux et ne sera donc pas intégré au noyau Linux.
Juste après ce passage, ils disent que l'intégration au noyau est en projet :
There are plans to work on an upstream approach with the Linux kernel community and partners such as Canonical, Red Hat, and SUSE.
Ça prendra sûrement bien plus de temps, mais c'est vraiment la meilleure nouvelle de cet article !
les issues et pull requests contiennent des information précieuses sur les raisons de ces changements : solutions explorés, logs, etc.
C'est exactement parce que toutes ces informations sont précieuses pour un projet que Fossil offre la possibilité de stocker tout ça dans le dépôt. C'est expliqué dans sa documentation, et d'ailleurs tout le site web de Fossil est en fait servi depuis le dépôt lui-même. Fossil utilise SQLite, donc le dépôt est un fichier unique. Pour monter un dépôt partagé (+ site web, wiki, forum, tickets, etc. si on veut), il suffit d'installer Fossil sur un serveur et de lui dire de servir le dépôt.
Cette vidéo sur le jugement majoritaire m'avait bien convaincu à l'époque. Mais je dois dire que le vote par approbation (expliqué dans la vidéo de Mr Phi, le lien au dessus) semble effectivement meilleur, car il permet aussi de s'exprimer sur tous les candidats (même si de façon binaire seulement : je soutien ou non chaque candidat), mais en plus il est plus facile à mettre en œuvre avec des modifications mineures de l'infrastructure déjà en place (un bulletin avec des cases à cocher), et il est aussi plus facile à expliquer donc plus facile pour les votants d'avoir confiance dans le processus (ce qui est très important).
C'est bien ma critique : impossible de dire "les trois candidats d'extrême droite sont dangereux et aussi indésirables les uns que les autres" si ce mode de scrutin me force à les classer (et donc me force à dire quelque chose comme "la candidate d'extrême droite habituelle est moins pire que le nouveau candidat d'extrême droite", alors que ce n'est pas du tout ce que je veux dire).
S'il n'y a que deux candidats comme ça, je suis coincé : je ne peux pas dire que les deux sont à rejeter. Avec trois candidats, je peux donner un classement circulaire comme ça :
A > B
B > C
C > A
mais est-ce que ça exprime vraiment "les trois candidats sont à rejeter" ? Est-ce qu'un tel vote serait même considéré valide ? Et que dire d'un vote qui ne mettrait pas seulement un sous-ensemble des candidats dans une telle situation circulaire, mais tous les candidats ?
Jehan, si la méthode de Condorcet consiste à évaluer les candidats dans toutes les configurations « un contre un » possibles, alors comment est-ce qu’on peut exprimer avec cette méthode l’opinion selon laquelle « les trois candidats d’extrême droite sont à rejeter absolument » ?
Ce passage en particulier a retenu mon attention :
Dans la dernière ligne droite, le Parlement européen a aussi obtenu que soit ajoutée l’interopérabilité des services de messagerie qui permettra par exemple à un utilisateur de Signal de communiquer avec un contact utilisant WhatsApp (Meta).
Si ces mesures se concrétisent, j’ai vraiment hâte de ne pouvoir utiliser plus qu’une seule app de messagerie (ou au moins de réduire leur nombre, qui est devenu vraiment absurde).
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.
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 ?
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).
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 1 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 2. 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 ?
Façon de parler. Vu que la recherche publique est si mal financée en France, j'ai pas eu la chance d'y travailler depuis ma thèse, et c'est actuellement l'argent du contribuable suédois que je gaspille. ↩
"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.
[^] # Re: Architecture x86 à bannir ?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal économie d'electricité. Évalué à 10.
Mais si on considère l’empreinte environnementale du remplacement de tous ces ordinateurs x86 (extraction des matériaux bruts, fabrication, tous les transports jusqu’à l’acheteur final), est-ce que c’est vraiment une bonne idée ? Et si on considère tous les déchets générés par ces ordinateurs désormais inutilisés ? Combien d’années d’économie d’énergie par les nouvelles puces moins consommatrices « compenseront » cette empreinte ?
[^] # Re: Vision Data scientist ?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 4.
Le problème principal avec l’écosystème de gestion de paquets de Python, c’est qu’il est totalement en contradiction avec le principe « There should be one-- and preferably only one --obvious way to do it. » (PEP 20). Il y a beaucoup trop d’outils et de façons de faire, que ce soit pour générer des paquets ou pour les installer dans des environnements isolés.
Cette promesse est par contre très bien tenue par Julia : il n’y a qu’un seul gestionnaire de paquets (Pkg.jl), qui est capable de gérer des environnements isolés (des projets, en jargon Julia). Et pour créer un paquet, il suffit d’un fichier de description (Project.toml) et d’une arborescence de fichiers qui suit la convention (ce qui peut être généré automatiquement par PkgTemplates.jl).
# Entretien avec un écureuil
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Les IA des GAFAM sont-elles sentientes ?. Évalué à 3.
Ce blog humoristique explore aussi la question : https://www.aiweirdness.com/interview-with-a-squirrel/
# Environnement très dégradé
Posté par Guillawme (site web personnel, Mastodon) . En réponse à la dépêche Environnement moderne de travail Python. Évalué à 8.
Obligatory xkcd: https://xkcd.com/1987/
[^] # Re: Partie Kernel only
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien NVIDIA publie désormais ses pilotes graphiques pour Linux sous licence libre. Évalué à 3.
Juste après ce passage, ils disent que l'intégration au noyau est en projet :
Ça prendra sûrement bien plus de temps, mais c'est vraiment la meilleure nouvelle de cet article !
# Le DVCS du futur, c'est Fossil
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal GitHub supprime les issues et pull requests de comptes russes suspendus ... puis les restaure. Évalué à 2.
C'est exactement parce que toutes ces informations sont précieuses pour un projet que Fossil offre la possibilité de stocker tout ça dans le dépôt. C'est expliqué dans sa documentation, et d'ailleurs tout le site web de Fossil est en fait servi depuis le dépôt lui-même. Fossil utilise SQLite, donc le dépôt est un fichier unique. Pour monter un dépôt partagé (+ site web, wiki, forum, tickets, etc. si on veut), il suffit d'installer Fossil sur un serveur et de lui dire de servir le dépôt.
[^] # Re: Une excellente vidéo récente de Mr Phi au sujet des modes de scrutin
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Expérience pour le vote à jugement majoritaire : participez !. Évalué à 7.
Cette vidéo sur le jugement majoritaire m'avait bien convaincu à l'époque. Mais je dois dire que le vote par approbation (expliqué dans la vidéo de Mr Phi, le lien au dessus) semble effectivement meilleur, car il permet aussi de s'exprimer sur tous les candidats (même si de façon binaire seulement : je soutien ou non chaque candidat), mais en plus il est plus facile à mettre en œuvre avec des modifications mineures de l'infrastructure déjà en place (un bulletin avec des cases à cocher), et il est aussi plus facile à expliquer donc plus facile pour les votants d'avoir confiance dans le processus (ce qui est très important).
[^] # Re: Pourquoi pas une méthode de condorcet?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Expérience pour le vote à jugement majoritaire : participez !. Évalué à 1.
C'est bien ma critique : impossible de dire "les trois candidats d'extrême droite sont dangereux et aussi indésirables les uns que les autres" si ce mode de scrutin me force à les classer (et donc me force à dire quelque chose comme "la candidate d'extrême droite habituelle est moins pire que le nouveau candidat d'extrême droite", alors que ce n'est pas du tout ce que je veux dire).
S'il n'y a que deux candidats comme ça, je suis coincé : je ne peux pas dire que les deux sont à rejeter. Avec trois candidats, je peux donner un classement circulaire comme ça :
A > B
B > C
C > A
mais est-ce que ça exprime vraiment "les trois candidats sont à rejeter" ? Est-ce qu'un tel vote serait même considéré valide ? Et que dire d'un vote qui ne mettrait pas seulement un sous-ensemble des candidats dans une telle situation circulaire, mais tous les candidats ?
[^] # Re: Pourquoi pas une méthode de condorcet?
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien Expérience pour le vote à jugement majoritaire : participez !. Évalué à 1.
Jehan, si la méthode de Condorcet consiste à évaluer les candidats dans toutes les configurations « un contre un » possibles, alors comment est-ce qu’on peut exprimer avec cette méthode l’opinion selon laquelle « les trois candidats d’extrême droite sont à rejeter absolument » ?
# Interopérabilité des messageries
Posté par Guillawme (site web personnel, Mastodon) . En réponse au lien L’Union européenne va mieux encadrer les géants du numérique. Évalué à 3.
Ce passage en particulier a retenu mon attention :
Si ces mesures se concrétisent, j’ai vraiment hâte de ne pouvoir utiliser plus qu’une seule app de messagerie (ou au moins de réduire leur nombre, qui est devenu vraiment absurde).
[^] # Re: petite solution redonée
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Y'a le feu. Évalué à 3.
Super utile, merci d'avoir partagé !
Je voudrais ajouter une précision au cas où quelqu'un peu familier avec systemd lit ces instructions :
Après cette étape, il ne faut pas oublier de redémarrer
sshd.servicepour que les changements de configuration prennent effet. Ça se fait comme ça :[^] # Re: Question
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 10.
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 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.
[^] # Re: Efficacité du vaccin
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 3.
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/
[^] # Re: Fabrication
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 4.
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.
[^] # Re: Fabrication
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 4.
C’est une info que j’avais effectivement lue dans cet article de septembre 2020 : https://doi.org/10.1038/s41586-020-2798-3
[^] # Re: Efficacité du vaccin
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 10.
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 ?
[^] # Re: raid 6
Posté par Guillawme (site web personnel, Mastodon) . En réponse au journal Testez vos sauvegardes !. Évalué à 1. Dernière modification le 17 décembre 2021 à 12:36.
Certaines configurations RAID améliorent aussi beaucoup les performances en lecture et écriture, ce qui est nécessaire pour certaines applications.
[^] # 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é à 1.
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).
[^] # 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é à 9.
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. :-)
Tu préfères que je dépense tes impôts 1 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 2. 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 ?
Façon de parler. Vu que la recherche publique est si mal financée en France, j'ai pas eu la chance d'y travailler depuis ma thèse, et c'est actuellement l'argent du contribuable suédois que je gaspille. ↩
Enfin ça, c'est quand on a un gouvernement qui veut bien y mettre les moyens. ↩
[^] # 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.