Guillawme a écrit 219 commentaires

Tous ces articles sont excellents, j'ai particulièrement adoré lire (et jouer avec les animations interactives) les suivants :

• Earth and Sun
• Tesseract
• Cameras and Lenses

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.

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.

Merci pour le lien qui n’était pas dans le journal. :-)

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

Comme je vis et travaille en anglais depuis 5 ans je n’avais même pas remarqué, mais oui maintenant que tu le dis le nom de cette conférence est plutôt… 😆

Pluto est une application de notebook pour le langage Julia. Quelle différence avec Jupyter ? Pluto est réactif, c’est-à-dire qu’il détermine automatiquement les dépendances entre cellules et réévalue automatiquement et dans le bon ordre toutes les cellules qui dépendent d’une cellule après la modification de cette dernière. En pratique, ça signifie par exemple qu’on peut voir un graphique changer automatiquement quand on déplace un curseur pour changer un paramètre, et autres choses de ce genre. Cela lui confère aussi la propriété bien appréciable que l’état de la session correspond toujours à ce qui est écrit dans le notebook (si vous avez utilisé Jupyter, vous savez qu’il est facile de perdre la correspondance entre le contenu réel des variables et ce qui est affiché, puisque les cellules ne sont jamais réévaluées automatiquement). Pour avoir utilisé un peu les deux, je trouve que ce sont deux outils très complémentaires. Jupyter est un excellent historique de session, tandis que Pluto est très bon pour l’interactivité (mais n’est pas un bon historique, puisque seul l’état final de la session est écrit dans le notebook, et car les résultats ne sont jamais enregistrés et doivent être recalculés à la prochaine ouverture du notebook).

Je n’ai pas encore regardé toutes les présentations, mais « Pen Plotting with Pluto » était une excellente démo du type d’interactivité qu’on peut obtenir avec Pluto.

Tous les notebooks (et d’autres qui n’ont pas fait l’objet d’une présentation) sont visibles ici : https://plutocon2021-demos.netlify.app/
Les fichiers sont ici : https://github.com/JuliaPluto/PlutoCon2021-demos

Idéalement je pense que c'est un travail que devraient faire des entités comme github/gitlab/pip/rubygems/cpan/npm.

Un developpeur devrait pouvoir pousser du code sur son repo, mais un peer review indépendant et réalisé par des personnes aguérries devrait être fait à chaque pull request.

Je bricole un peu avec R et Python, en ayant commencé avec R (quelques années avant de commencer avec Python), et j'ai été très surpris quand je me suis aperçu que je pouvais créer un compte sur PyPI et publier des paquets que tout le monde peut dès lors installer via pip. Ça m'a fait sacrément repenser à mon usage de pip. Dans l'univers R, le dépôt de paquets s'appelle CRAN et il fonctionne comme un journal académique : tu veux publier un paquet que tout le monde pourra installer en une commande ? ok, mais il devra d'abord être passé en revue et approuvé par plusieurs personnes (qui peuvent potentiellement demander des modifications avant d'accepter la publication). CRAN fait ça surtout pour s'assurer que les méthodes statistiques implémentées dans les paquets font bien ce que dit leur description (donc pour éviter de causer des résultats faux), mais l'effet secondaire évident et appréciable c'est qu'il est virtuellement impossible de faire publier un paquet malicieux sur CRAN.

Les opérateurs de téléphonie aussi. Et leurs serveurs devrait bien sûr être fédérés. Et ils devraient tous se mettre d’accord sur un ensemble de fonctionnalités (XEP) à supporter : au minimum chiffrement de bout en bout, délivrance des messages asynchrone (sinon moins utile sur mobile), conversations de groupe, appels audio et vidéo à deux participants (au minimum, mais pourquoi pas jusqu’à 4 ou 8 ; plus que ça sur téléphone ça devient difficile à suivre). Et ils pourraient tous contribuer un peu à développer un client libre (si la poste et chaque opérateur embauchaient chacun un seul développeur à plein temps et qu’ils contribuent tous au même client libre, on arriverait sûrement rapidement à quelque chose qui marcherait bien).

Ça ne coûterait pas énormément, et ça rendrait un service immense. Mais c’est sûrement pas assez intéressant pour la startup nation, ce projet…

Personnellement, je me suis construit une petite image disque à coup de dd, je l'ai montée et je l'ai formatée comme partition chiffrée avec une grosse passphrase. Et depuis, j'utilise un petit script pour la monter automatiquement avec cryptsetup (LUKS). Je mets ce qui est confidentiel dedans sans être dépendant d'un logiciel particulier.

Ce que tu décris, ce n'est que réinventer ce que propose KeePassXC, mais en moins portable. Tu ne pourras pas monter ton image disque sous Windows, ou alors il faudra installer dd et cryptsetup, c'est-à-dire probablement installer toute une distribution Linux avec WSL, en supposant que tu sois sur un Windows qui soit à la fois assez récent pour ça et avec un compte d'utilisateur qui a les permissions suffisantes pour. Pas sûr non plus que ça fonctionne sur macOS sans rien installer (on peut monter une image disque ça c'est sûr, mais je ne sais pas si on peut déchiffrer des volumes LUKS). Donc si la portabilité est importante, c'est pas gagné.

Un avantage de l'image disque chiffrée, c'est que tu peux stocker n'importe quel fichier (donc aussi des données non structurées) dedans, mais c'est bien le seul avantage. On peut aussi stocker des fichiers arbitraires dans une base KeePass, c'est juste un peu pénible car la seule façon de le faire c'est d'attacher les fichiers comme pièces jointes d'une entrée de la base de données (donc plus compliqué que juste copier un fichier dans une image disque montée).

J'utilise un fichier KeePass, et pour les rares fois où j'ai besoin des infos qui sont dedans alors que je n'ai pas mon ordinateur personnel avec moi, j'ai le fichier et les versions portables de l'application KeePassXC sur une clé USB attachée à mon porte-clé (donc je l'ai toujours quand je pars de chez moi). La version Windows portable fonctionne sur n'importe quelle version depuis au moins Windows 7 (je ne serais pas étonné qu'elle fonctionne même sur des versions plus anciennes). Si je voulais en plus de ça du stockage de fichiers facile et chiffré, il me reste assez de place sur la clé pour stocker dessus une image disque chiffrée à côté, car le fichier KeePass et les applis portables KeePassXC ne pèsent quasiment rien.

Parce qu'il est dans le cloud, justement. Si encore on pouvait aussi l'utiliser uniquement avec un fichier de mots de passe local, ce serait certainement un des meilleurs gestionnaires de mots de passe. Mais comme ce n'est pas possible, je préfère personnellement utiliser KeePassXC (qui a la limitation contraire : il ne travaille qu'avec un fichier local, il faut se débrouiller si on veut synchroniser ce fichier entre plusieurs ordinateurs).

Ça n'empêche personne de rouvrir le navigateur et consulter tout l'historique, si le compte utilisateur sur l'ordinateur n'est pas verrouillé…

Et si le contenu est simple, pourquoi utiliser hugo?

Je suis tenté de simplement copier la fin de mon message précédent :

En tant qu'utilisateur, je trouve au contraire que Hugo rend le web beaucoup plus simple pour moi. J'ai seulement dû étudier un peu son principe de fonctionnement et trouver un thème qui me convenait, et paf j'ai des chocapics un site web présentable alors que je n'ai pas la moindre notion de développement web (et ni le temps ni l'envie d'apprendre ces technologies).

Mais puisque tu insistes, je devine que ça ne répondait pas complètement à ta question, donc voilà une réponse plus détaillée (mais qui dit en fait la même chose) :

Parce que je n'ai aucune envie de bidouiller du code HTML et CSS pour écrire des trucs sur un blog. J'aime bidouiller du code pour les trucs qui m'intéressent, mais les technologies du web ne m'intéressent pas, donc j'utilise un générateur.

La complexité de Hugo lui-même en tant que logiciel ou du site que je produis en l'utilisant, c'est un détail qui ne m'intéresse pas (passé le choix initial d'un thème pour le site généré, car j'ai effectivement tâché d'en choisir un qui n'était pas trop complexe, selon mes critères flous puisque je n'y connais rien aux technologies web). Que Hugo en tant qu'outil fasse son boulot sans me distraire de ce qui m'intéresse, c'est ce qui compte pour moi. Il a peut-être plein de fonctionnalités que je n'utilise pas, mais si c'est le prix à payer pour que les quelques fonctionnalités que j'utilise marchent sans avoir à bricoler (parce que coder mon propre générateur de site statique, ça fait aussi partie des trucs qui ne m'intéressent pas), je trouve que c'est un compromis acceptable.

Du coup, tout le monde utilise des logiciels complexes (regardez la taille du code d'hugo…) pour le moindre truc.

Je réagis seulement à la remarque sur Hugo : certes c'est un logiciel complexe (comme beaucoup de générateurs de site statique, il réimplémente pas mal de fonctionnalités de make), mais il sert seulement à générer du contenu statique, contenu qui peut être aussi simple que l'on veut. Ce n'est pas Hugo qui rend le web plus complexe, ce sont les gens qui s'en servent pour générer du contenu complexe, et ils pourraient le faire avec n'importe quel autre générateur ou même sans utiliser un générateur de site statique.

En tant qu'utilisateur, je trouve au contraire que Hugo rend le web beaucoup plus simple pour moi. J'ai seulement dû étudier un peu son principe de fonctionnement et trouver un thème qui me convenait, et paf j'ai des chocapics un site web présentable alors que je n'ai pas la moindre notion de développement web (et ni le temps ni l'envie d'apprendre ces technologies).

Une autre raison, c'est aussi que c'est moins risqué car comme dit gouttegd l'ARN peut être synthétisé complètement chimiquement, ce qui signifie un risque nul de contamination du vaccin par des impuretés d'origine biologique.

Au contraire, les protéines recombinantes doivent être produites dans un organisme (du plus simple au plus compliqué expérimentalement : dans des bactéries, des levures, des cellules d'insectes ou des cellules de mammifères) puis purifiées. On peut être très strict avec le protocole de purification, mais il y a toujours un compromis entre pureté et rendement (ce qui augmente les coûts, si on veut une pureté plus grande). Et surtout, le risque de contamination par des protéines de l'organisme dans lequel a été produite la protéine recombinante existe (en pratique on peut rendre ce risque aussi faible qu'on veut, au détriment du rendement et donc en rendant la protéine recombinante cible plus chère à produire ; mais on ne peut pas réduire complètement ce risque à zéro).

Ça n'empêche pas les vaccins à protéines recombinantes d'être une stratégie viable et également explorée. Dans le cas des vaccins ciblant SARS-CoV-2, cette revue explique bien les compromis entre différentes technologies d'élaboration de vaccins : Krammer, F. SARS-CoV-2 vaccines in development. Nature 586, 516–527 (2020). https://doi.org/10.1038/s41586-020-2798-3

(Je précise que je suis biochimiste, pas du tout spécialiste de virologie ni d'immunologie, mais purifier des protéines recombinantes fait partie de la routine dans mes recherches et je confirme que c'est bien plus difficile que la synthèse chimique d'ARN.)

Pour avoir déjà contribué quelques RPM et essayé des paquets debian, je me demande comment les paquets debian peuvent avoir plus de popularité.

Cette lecture m’avait suggéré le contraire : https://linuxfr.org/users/guillawme/liens/argh-p-m-dissecting-the-rpm-file-format

Mais bon je n’y connais rien, j’ai seulement utilisé apt et dnf mais je n’ai jamais essayé de produire des paquets.

Suppositware ? (ce nom d’organisation est disponible sur GitHub, dépêche-toi).

Merci. Ça faisait un moment que je voulais tester borg, j'ai finalement commencé à l'utiliser pour le boulot à la fin de la semaine (motivé par la lecture des commentaires de ce journal). J'ai aussi mis en place la même sauvegarde avec kopia, pour comparer. C'est pour un dossier de seulement 25 Go (ce sont beaucoup de fichiers petits et moyens en taille, et dont certains changent très souvent), mais ça suffit pour se faire une bonne idée sur les deux outils. Je travaille aussi avec d'autre données plus volumineuses, qui occupent des dizaines de To et ne compressent pas très bien… mais qui ne changent pas une fois collectées, donc pour elles je me contente d'une copie (avec rsync) vers un serveur de stockage dont le système de fichiers est sauvegardé quotidiennement par quelqu'un dont c'est le métier.

J'ai utilisé kopiaUI et Vorta pour borg. Les deux permettent de mettre en œuvre une stratégie de sauvegarde simple en très peu de temps, c'est bien appréciable. J'ai trouvé Vorta plus facile à utiliser que kopiaUI.

Vers un disque externe, la sauvegarde initiale des 25 Go était beaucoup plus rapide avec borg (4 minutes ; je ne me souviens plus combien de temps kopia a pris). La différence sera normalement moins perceptible avec les sauvegardes incrémentales (du moins je l'espère). Le disque est bien plus volumineux que mes 25 Go, donc je peux conserver des versions très anciennes avant de devoir faire le ménage, c'est nickel.

Je n'utilise pas de service de stockage commercial (S3, etc.), donc ça n'est pas un critère pour choisir entre les deux outils pour moi. Mais le serveur de stockage mentionné plus haut, j'y accède simplement par ssh, donc c'est appréciable de pouvoir s'en servir comme d'un gigantesque disque externe avec kopia (sftp). J'adorerais pouvoir faire ça avec borg aussi, malheureusement ça ne marche que si borg est aussi installé sur le serveur (et je ne crois pas que ça sera possible sur ce serveur du boulot, même en insistant).

Merci pour la suggestion de kopia, je ne connaissais pas. Peux-tu nous en dire plus à son sujet ? Quels avantages comparé à restic et borg ? Des inconvénients ? Est-ce que c’est un outil fiable et stable ? (c’est plus récent apparemment).

Ce cours est donné par plusieurs des concepteurs du langage Julia. J’aime bien que ce soit basé sur des exemples pratiques et avec des notebooks interactifs (essayez les notebooks Pluto.jl, c’est très impressionnant comparé aux options habituelles comme Jupyter), c’est plus motivant pour démarrer que de lire la documentation du début à la fin.

On dirait que ce service fait ce que tu veux (d’au moins deux façons : intégration directe avec d’autres services, ou par une API si tu veux coder ta propre solution): https://buttondown.email/features/integrations
https://buttondown.email/features/api

Apparemment c’est moins cher que Mailchimp. Et bien sûr il y a une option gratuite.