Guillawme a écrit 254 commentaires

S’il s’agit juste d’avoir des paires d’identifiant et de mot de passe uniques pour limiter les dégâts quand des sites voient leurs bases d’utilisateurs exposées, alors la méthode déjà suggérée dans un autre commentaire est celle qui est à la fois facile à mettre en place et à utiliser, tout en étant efficace. C’est ce que je fais aussi, mais je ne stocke pas mon fichier de mots de passe dans un service de synchronisation.

Faire en sorte qu’il soit difficile de prouver que plusieurs identités en ligne appartiennent à la même personne, c’est une autre affaire. Une approche est d’utiliser plusieurs appareils, chacun dédié à une seule identité, mais même comme ça il faut beaucoup adapter son comportement pour ne pas compromettre la séparation des identités. Et même avec toutes les précautions possibles, si tu publies beaucoup de texte en ligne sous tes différentes identités (soit des textes assez longs, soit des textes courts mais fréquents) l’analyse de ces textes peut déterminer avec un certain degré de confiance qu’ils ont été écrits par la même personne.

Si tu deviens ton propre diffuseur, je suppose que tu deviens donc soumis aux mêmes règles sur le copyright que les grandes plateformes. Ça va si tu ne publies que ton propre code, mais le problème persiste si tu veux conserver des dépendances externes dans ton dépôt (par exemple pour conserver une certaine version d’une dépendance), non ?

Ce n’est pas le plus pratique vu que la chaîne de serveurs intermédiaires est choisie aléatoirement… tu recharges la page jusqu’à tomber par chance sur un serveur de sortie situé dans le pays de la chaîne que tu veux regarder ?

Désolé de te décevoir, mais c'est le problème le moins frustrant, et sûrement aussi le plus facile à résoudre, auquel tu auras à faire face en tant qu'expat. Rien, absolument rien n'est prévu pour les gens qui décident de vivre dans un pays différent de celui dans lequel ils sont nés… à moins de rester assez longtemps et de faire toutes les procédures pour être naturalisé, tu auras les inconvénients des bureaucraties des deux pays, avec très peu des avantages. Bien sûr ça doit dépendre du pays où tu vis, et c'est peut-être plus facile à l'intérieur de l'Union Européenne (je vis aux États-Unis depuis deux ans ; avant ça j'étais doctorant donc je suis déjà habitué à ne jamais avoir la case adaptée à ma situation dans les formulaires, mais c'est un peu décourageant quand même…).

Je l'ai donc exclu par souci de rigueur scientifique.

Dès le départ ce n'est pas scientifique du tout de prendre la moyenne, puisqu'elle est très sensible aux valeurs extrêmes… Imagine deux journaux pour le même langage X, l'un a une note de 50 et l'autre une note de 2, sa moyenne est donc 26. Le langage Y, quant à lui, a trois journaux ayant les notes 25, 26 et 27, soit une moyenne de 26 aussi. Est-il pertinent de les classer à égalité ? Déjà, le simple fait que Y ait plus de journaux signifie peut-être déjà qu'il est plus populaire. Le classement serait plus réaliste en prenant la somme des notes pour chaque langage (dans cet exemple, X et Y ne sont pas du tout à égalité selon le critère de la note totale).

Un autre problème : le classement change avec le temps tant que les journaux sont suffisamment récents pour recevoir des notes. Pour être complètement juste il faudrait faire l'analyse une fois que les journaux ne peuvent plus être notés.

Je sais que ce journal n'est pas 100% sérieux, mais je trouve que même pour plaisanter il faut un peu de sérieux. ;-)

Ah, et aussi, pas besoin d'interface graphique, DONC utilisable via ssh (bon, ça, emacs et nano aussi, mais emacs est pas installé par défaut sur les distros que j'ai utilisées et nano est franchement limité en fonctionnalités)

Justement avec Emacs pas besoin qu’il soit installé sur le système distant : il suffit d’utiliser TRAMP pour ouvrir les fichiers distants avec ton Emacs local.
Ouvrir un fichier distant à travers une session ssh n’est pas très différent d’ouvrir un fichier local : https://www.gnu.org/software/tramp/#Quick-Start-Guide

J’utilise ça souvent, parfois même quand le fichier distant est sur un ordinateur situé dans la même pièce (parce que cet autre ordinateur n’a pas Emacs).

Ce résultat doit venir du fait que tous ces utilisateurs sont coincés et n’arrivent pas à quitter Vim…

Ben je m'étais bel et bien planté… :P
La définition correcte c'est ça :

(defun factorielle (n)
  "Factorielle récursive."
  (if (= n 0)
      1
    (* n (factorielle (- n 1)))))

Avec la condition d'arrêt, ça fonctionne beaucoup mieux. :D Cela dit, on ne peut pas évaluer plus grand que (factorielle 63).

Seconde erreur de ma part : ce n'est pas un appel récursif terminal… Je ne sais pas encore comment écrire ça.

Ce serait quand même mieux d'attacher la fonction tap à une autre combinaison de touches que celle qui sert à enregistrer un fichier. Le préfixe C-c est là pour ça : il est réservé pour l'utilisateur (en supposant un Emacs de base ; dans la vraie vie, beaucoup de packages utilisent ce préfixe aussi…).

Ah, et il y a toujours un symbole non défini : sum: Symbol’s function definition is void: rest.

la récursion pas terminale, c'est mal

Quelle solution proposes-tu pour l'utiliser avec Emacs Lisp qui n'optimise pas les appels récursifs terminaux ? :-)

Par curiosité, après avoir lu ton message j'ai essayé d'écrire une fonction factorielle récursive, et je ne peux même pas évaluer (factorielle 2) sans me prendre une erreur Lisp nesting exceeds ‘max-lisp-eval-depth’. Si j'augmente la valeur de cette limite, je bute sur Variable binding depth exceeds max-specpdl-size (et si j'augmente cette dernière, je reçois à nouveau la première erreur). J'avoue ne pas bien connaître Emacs Lisp (je m'en sers seulement pour configurer Emacs, ce qui consiste principalement à changer la valeur de variables… par réellement programmer), mais l'interpréteur semble déconseiller activement les solutions récursives.

Je me suis peut-être planté dans la définition, mais je ne crois pas car c'est la fonction récursive la plus facile à écrire :

(defun factorielle
    (n)
  "Factorielle récursive."
  (* n (factorielle (- n 1))))

En moins d'une minute de navigation sur le site de XEmacs, j'apprends que la dernière version stable qu'ils proposent au téléchargement date du 30 janvier 2009, et la dernière version beta date du 24 juin 2013.

D'autre part, GNU Emacs propose une nouvelle version stable en moyenne une fois par an depuis 2001. La plus récente date du 11 septembre 2017. Le plus récent commit sur leur dépôt git date d'aujourd'hui (à l'heure où j'écris).

On peut donc raisonnablement considérer que XEmacs est mort, et que GNU Emacs est la version maintenue et à jour. :-)

Bon, puisqu'on est vendredi, allons-y. :-)

J'ai l'impression qu'Atom, Adobe Brackets, VSCode et autres éditeurs du même genre réinventent la roue… Ces efforts ne seraient-ils pas mieux investis en contribuant à améliorer Emacs ? (qui fait déjà tout ce qu'ils font, et plus).

Pardon d’avance si je transforme les commentaires de ce journal en « ask me anything ». Mais comme j’ai apprécié lire ton journal et tes commentaires sur Python, maintenant j’ai envie de poser la même question pour R que tu as aussi évoqué. :-)

Pour mettre les choses en contexte : je suis biochimiste de formation, on ne m’a jamais proposé de programmation dans mon cursus (à part 2 mois de Matlab, mais ça consistait surtout à adapter des codes fournis par le prof…). Au début j’ai commencé par bricoler un peu avec Python, principalement par curiosité (en essayant de résoudre les problèmes de http://rosalind.info ; c’était quand j’avais besoin de me changer les idées pendant la rédaction de ma thèse…), mais comme je n’avais pas de projet concret je m’en suis lassé assez rapidement.

Maintenant je m’y intéresse bien plus, parce que dans mon travail au quotidien ça m’aide à résoudre des problèmes conceptuellement simples mais affreusement pénibles à traiter manuellement. L'année dernière, je me suis mis à R cette fois pour résoudre un problème concret de mon quotidien (qui était faisable dans un tableur pour un jeu de données, mais devenait ultra-pénible dès qu’il fallait le faire 2 fois de suite ou plus comme c’était systématiquement le cas). Cette expérience a été bien plus amusante, en particulier j’ai trouvé très satisfaisant de créer mes propres outils. J’ai aussi eu l’impression que R essayait beaucoup moins de me mettre des bâtons dans les roues (dit autrement, j’arrivais plus facilement à mon but).

Je suppose que mes expériences avec ces deux langages diffèrent beaucoup principalement du fait d’avoir eu ou pas un projet concret sur lequel les appliquer. Mais je suis tout de même intéressé de comprendre s’il y a des raisons plus profondes dues à la conception des deux langages qui pourraient aussi en partie expliquer ces expériences différentes.

Juste pour clarifier un détail : tu dis « ça revient au même ». Je ne suis pas d’accord. Ça revient au même financièrement (moins de risque = assurance moins chère), mais c’est très très différent du point de vue des données personnelles : dans un cas l’assureur les vole et s’en sert pour justifier une augmentation du prix, dans l’autre cas l'assuré les donne lui-même pour peut-être gagner une réduction (il sait ce qu’il donne, et ce qu’il peut gagner en retour).

Si tu ne peux/veux pas justifier quoi que ce soit tu sera considéré comme « à risque » et tu paieras plein pot… Tu le formules différemment mais ça revient au même.

Ou bien tu seras évalué par défaut au risque médian, ce qui semble plus juste. Un assureur n’a pas trop intérêt à faire payer plein pot par défaut s’il ne veut pas que ses assurés partent chez la concurrence.

votre assureur peut décider de modifier le prix de votre assurance santé car il voit que vous ne faites pas beaucoup de sport et que vous mangez souvent dans des lieux de restauration rapide

Si tu mangeais sainement, faisais du sport, ne fumais pas, etc… ne trouverais-tu pas normal de payer moins que ceux qui vont fatalement « revenir plus cher que toi » car ils ont des conduites à risques ?

Le problème n’est pas le prix que tu devrais payer pour ton assurance, mais que ce prix puisse être choisi arbitrairement par l’assureur sur la base d’informations que tu n’as jamais souhaité partager avec lui.

Comme tu le suggères, c’est potentiellement justifiable de payer plus ou moins cher selon son degré de risque, mais pour être équitable ça devrait être proposé autrement : un prix standard tel que la compagnie d’assurance s’y retrouve, et des réductions optionnelles pour les assurés qui peuvent justifier d’un niveau de risque moins élevé que le risque médian (sur des critères objectifs autant que possible). Dans une telle situation, c’est l’assuré qui décide de donner ses informations à l’assureur sachant qu’au pire ça ne changera rien et qu’au mieux ça peut lui donner droit à une réduction.
Je ne sais pas si ça se fait en France, mais aux États-Unis (où j’habite depuis presque deux ans) certaines compagnies d’assurance font déjà ça pour les voitures : elles proposent de garder un capteur de vitesse pendant 3 mois (aucune obligation d’accepter), et à la fin de cette période au pire rien ne change, ou bien l’assuré se voit offrir une réduction estimée à partir des mesures de vitesse et d’accélération.

En Belgique par exemple toutes les cartes d'identité ont une puce numérique contenant bien entendu de quoi authentifier par clé numérique qu'une action numérique est faite par l'utilisateur. Du coup en Belgique les sites officiels sont accessibles par ce biais, ça fonctionne très bien. C'est très simple, pas très cher, pas besoins de nouveaux identifiants ou de demander quelque chose à l'État (contrairement à aujourd'hui en France où l'État t'envoie l'identifiant).

C'est une solution très intéressante. Peux-tu détailler un peu comment ça fonctionne ? En particulier, je me pose ces deux questions :

• en cas de perte ou vol de ta carte d'identité, la personne qui l'a trouvée ou volée peut-elle s'en servir pour se connecter aux sites du service public avec ton identité ? j'espère que c'est une authentification à deux facteurs, sinon c'est bien trop simple de voler une identité…
• techniquement, comment ça fonctionne ? si je veux m'identifier/authentifier sur le site des impôts avec ma carte d'identité à puce, est-ce qu'il me faut un équipement particulier ? (lecteur de carte, récepteur NFC ?).

Alors qu'aux États-Unis, les médias sont clairement indépendants du… euh, non, rien!

Beh, d'accord il y a bien pire ailleurs, mais ça ne devrait pas nous empêcher d'aspirer à un meilleur système politique.

D'où tiens-tu cette info ? Est-ce que ça vaut partout dans le monde ? Parce que le labo en question est aux États-Unis.

Ce n'est pas moi qui suis en charge de suivre ça, alors je ne peux pas y faire grand-chose. La personne qui s'en occupe relance régulièrement (et est régulièrement relancée par nous autres, utilisateurs), et apparemment si on change de fournisseur ou de modèle de GPU on sera relégués au bas d'une autre liste d'attente…

L'effet n'est-il pas précisément le contraire ? Grâce à la demande en co-processeurs pour des besoins primordiaux (jeux vidéos, crypto-monnaies…), des recherches quasiment inutiles sur le réel (biologie, chimie, physique) disposent de matériel peu cher développé à grand frais.

Les jeux vidéos sont peut-être une motivation pour faire baisser le prix des ordinateurs aujourd'hui, mais ne te leurre pas : ce sont bien des chercheurs qui ont inventé l'ordinateur et leur motivation principale était de s'en servir comme d'un outil pour aider leurs recherches. Sans ces "recherches inutiles" les jeux vidéos ne se seraient pas développés aussi rapidement. On peut donc dire que ces "recherches inutiles" ont au moins été utiles à une chose : rendre possibles les "besoins primordiaux" d'aujourd'hui. ;-)

Je ne suis pas sûr car c'est pour une deuxième station de travail, et je n'en étais pas encore utilisateur au moment où on a décidé de s'équiper d'une deuxième station (vers mi-août). Mais si c'est comme pour la première, je suppose que ce sont des cartes nVidia GeForce GTX 1080 Ti que nous attendons.

Une conséquence bien réelle du minage de Bitcoins, en plus de la consommation d'énergie absurde que cette activité entraîne, c'est de ralentir la recherche dans tous les domaines qui nécessitent des calculs sur GPU, car le minage augmente fortement la demande pour ces composants. Dans mon domaine (la biologie), le traitement de données issues de cryo-microscopie électronique dépend énormément de l'utilisation de GPU (en gros, sur une station de travail à 4 GPU, on peut faire des traitements qui demanderaient un cluster si les programmes n'étaient pas accélérés sur GPU).

Le labo dans lequel je travaille attend 4 GPU depuis la fin du mois d'août : on n'arrête pas de relancer le fournisseur, qui à chaque fois nous répond qu'on remonte doucement dans la liste d'attente mais qu'il faudra être patients car ils n'arrivent pas à suivre la demande.

Est-ce que vous connaissez d'autres domaines qui souffrent aussi de la forte demande en GPU à cause des fermes de minage de Bitcoins?

Pour les recherches sur les autres sites, j'abuse des "recherches rapides" : WikipediaFR ? Je tape 'wp ma recherche'. wn pour WiktionnaireFR, wpe pour wiki english etc… Je dois bien avoir une vingtaine de mots-clés pour les sites que j'utilise régulièrement.

Je faisais ça aussi, puis je me suis aperçu que les !mot-clés de DuckDuckGo répondent à tous mes usages (y compris chercher sur PubMed, résoudre des identificateurs DOI et PDB, etc.), donc depuis un moment j'ai désactivé le champ de recherche et mis DuckDuckGo par défaut, et j'accède à ce que je veux très rapidement directement depuis la barre d'URL.

La page about:searchreset semble conçue pour imposer le retour à Google*.

Pas vraiment, elle donne le choix entre garder le moteur de recherche actuel (l'exact contraire de "imposer le retour à Google") ou revenir à celui par défaut. Par contre c'est dommage que celui par défaut soit Google, je suis d'accord avec ça.

J'ai aussi eu mon moteur de recherche par défaut (DuckDuckGo) remplacé par Google, sur les deux profils que j'utilise. Les développeurs de Firefox ont reconnu que c'est un bug, et il a été rapidement corrigé : https://bugzilla.mozilla.org/show_bug.cgi?id=1423811