Ça fait des lustres que les compilateurs lèvent un warning sur ce type d'erreurs sans aller vers la nécessité d'un "décodeur maître Yoda" visuel!
L'équivalent en Python sont les "linters" comme pylint, pyflakes, pycodestyle, etc. Il existe aussi des analyseurs de code plus orientés sécurité comme bandit, PyT, etc.
Python se met aussi à lever des warnings à la compilation (et pas juste à l'exécution) :
>>> def func(arg):
... return arg is "a"
...
<stdin>:2: SyntaxWarning: "is" with a literal. Did you mean "=="?
>>> def func():
... return "%s %s" ("hello", "world")
...
<stdin>:2: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma?
Une fois qu'un attaquant a un accès physique à une machine, ce n'est pas une mire de login qui va bloquer un vol de données. Il y a eu pas mal de failles USB, FireWire & cie. Sans parler des plus basiques boot loader sans mot passe qui permettent de passer "single init=/bin/bash" au noyau Linux pour être logué en root sans taper le moindre mot de passe.
The executive summary is "threads + libdbus = anyone's guess".
(…)
I'm not convinced that it's possible to give libdbus well-designed
multi-threading without a redesign and API break, at which point you
might as well use GDBus instead.
Est-ce que ça a changé entre temps ? Je suppose que le fait de ne pas être thread-safe n'est pas un soucis si libdbus est utilisé dans un seul thread.
Quand j'avais regardé, l'implémentation de libdbus est un mélange entre code bloquant et code asynchrone assez surprenant.
De mémoire, GDBus est une autre implémentation écrite proprement sous forme de code asynchrone avec l'event loop de la glib. Ca devrait moins poser de soucis de multithreading.
Aucun bug n'est spécifique à Fedora. Le premier était un bug Firefox (remonté à Firefox), le second un bug Gtk (remonté à Gtk, mais il était déjà corrigé, alors j'ai backporté le corrrectif dans Fedora).
"quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie…"
Sur quels paquets avais-tu rapporté des bugs ?
Utilisateur de Fedora de longue date, j'ai aussi vu plusieurs de mes bugs rapportés à Fedora rester lettres mortes.
Déjà, il faut comprendre que Fedora est une distribution Linux, et non pas l' "upstream" du projet. Le ou les responsables d'un paquet ont parfois des connaissances limitées du projet qu'ils empaquetent. Il n'est pas rare qu'une seul personne soit responsable d'une dizaine de paquet, sinon plus.
Parfois, le bug est rare et difficile à reproduire. Je maintiens Python pour Fedora, et récemment on a reçu un bug que le rapporteur reproduisait sans problème, alors qu'en s'y mettant à 4, aucun n'a réussi à reproduire le bug. Même en demandant des informations complémentaires à plusieurs reprises, on n'a pas réussi. Il faut comprendre que Fedora est un système complet : un bug dépend rarement d'un seul composant, c'est souvent la combinaison des plusieurs composants dans des versions précises combinées à une configuration utilisateur particulière. Reproduire la configuration de l'utilisateur produisant le bug n'est pas trivial. Exemple anodin : certains bugs dépendent de la locale (langue) de l'utilisateur.
Mais plusieurs fois, le bug que j'ai rapporté a été corrigé entre 1 semaine et 1 mois.
Fedora a un outil génial pour collecter des traces lors d'un crash ABRT. L'outil reconstruit la pile d'appel via un serveur dédié sans que l'utilisateur ait besoin d'avoir l'outillage (notamment les symboles de debug) installés en local. C'est efficace, mais encore une fois, "voir" un crash ne suffit pas à reproduire les conditions qui permettent de reproduire le bug.
Certains packageurs sont employés par Red Hat. Certains sont volontaires. Certains travaillent uniquement sur Fedora. Certains travaillent sur Fedora et RHEL. Il y a beaucoup de cas.
Firefox fait parti des dernières applications de mon desktop GNOME utilisant encore l'API X11 et nécessite le serveur Xwayland (émulation X11 pour Wayland). Parfois au lancement, la fenêtre Firefox était à moitié noire (genre à moitié dessinée), alors le motto Wayland est “Every frame is perfect” (chaque image est parfaite).
J'étais un des premiers à tester Wayland sous Fedora, en choisissant volontairement "GNOME (Wayland)" au login. Au début, plusieurs features me manquaient avec Wayland : raccoucis clavier (ALT+e pour lancer un terminal, m'enfin !) et capture d'écran. gnome-screenshot et GIMP peuvent à nouveau faire des captures d'écran. Le partage d'écran fonctionne dans Bluejeans. Et je peux à nouveau définir des raccourcis clavier via gnome-shell (à configurer dans les paramètres globaux de GNOME).
Dans Fedora 30, j'ai forcé l'usage de Wayland pour Firefox en mettant MOZ_ENABLE_WAYLAND=1 dans /etc/environment. Il est aussi possible de lancer "firefox-wayland", mais je préfère taper ALT+F2 puis "firefox" (plus court !) :-)
Bref, ça marchait bien jusqu'à une régression il y a une semaine :-( Entre deux versions mineures de Firefox 69, le rendu Wayland s'est mis à produire plein de glitches assez pénible à l'usage : https://bugzilla.mozilla.org/show_bug.cgi?id=1580152
Je suis plutôt content car mon collègue Martin Stránský a rapidement eu vent du bug et travaille d'arrache pied sur un correctif. Ce matin j'ai lu "Martin, I installed the firefox-69.0-7.fc31 build you did today and it does seem to fix this, on my local system at least. Not sure if it fixes the openQA issue yet (it'll be easier to tell when it's submitted as an update). Thanks!". À priori, le bug vient d'être corrigé dans Fedora 31 (mais pas encore dans Fedora 30).
Au passage, j'ai galéré à comprendre d'où venait le bug. Mon laptop a 2 GPUs ce qui rend le debug plus complexe. J'ai écrit un article pour expliquer cette technologie du futur un peu bizzare qui vise à augmenter l'autonomie des laptops, "Hybrid Graphics" :
Par le passé, j'avais déjà eu un bug majeur avec Firefox + Wayland, que j'ai du corrigé moi même en backportant un correctif Gtk. Sélectionner plus de 4000 caractères plantait tout Firefox :-( CTRL+a dans Gmail plantait Firefox, super pénible.
J'ai entendu qu'il y a une corrélation entre l'envolée de la popularité de Python et l'envolée de la popularité du {machine learning, data science, numpy, scipy, pandas, scikit-learn, etc.} : le milieu scientifique assez éloigné du développement logiciel classique.
J'ai entendu que doucement Python "remplace" plusieurs outils existants. Je ne saurai les citer, mais au pif je dirai : Matlab au moins (le seul que j'ai touché). À ce que j'ai compris, Python est supérieur aux outils existants parce qu'il est gratuit (hé oui), qu'il facilite l'intégration d'outils hétérogènes de métiers différents, et qu'il vient avec une grosse suite d'outils qui facilitent la vie (stdlib entre autres, genre lire un CSV dans un ZIP est trivial). Les notebooks Jupyter vont encore plus loin dans le remplacement de Matlab.
Quand je dis "milieu scientifique", c'est assez large. Récemment, j'ai appris que Python commence à remplacer les outils utilisés historiquement dans le domaine de l'astronomie (genre https://www.astropy.org/ ?).
En même temps, chaque fois qu'un outil s'améliore dans un métier, il peut être réutilisé dans un autre métier, parce que Python est maléable et permet de bien intéger des outils divers et variés (c'est sa force historique).
Perso je reste bluffé que le coeur de numpy/scipy reste du super vieux code (10 ans ? 20 ans ? je ne sais pas) écrit en Fortran. Info à vérifier, pas sûr des dates. Mais on m'a dit "le code marche et a été prouvé (stabilité numérique), pourquoi changer ?". Il existe des projets pour réécrire des briques de base (calcul matriciel) en C, mais l'existant en Fortran reste très populaire : OpenBLAS si ma mémoire est bonne. GitHub me dit qu'OpenBLAS est constitué de 50% de Fortran, 27% d'assembleur, 20% de C (+ qq. autres langages) : https://github.com/xianyi/OpenBLAS Ou bien peut être que je confonds avec ATLAS, une autre implémentation de l'API BLAS aussi écrite en Fortran.
Quand je lis LinuxFR sur téléphone, les liens Markdown et Epub sont gros et il m'arrive souvent de cliquer dessus par erreur. Je pense qu'il faudrait virer ces liens de la page d'accueil et des journaux. Uniquement afficher les liens quand on est sur la page d'un article.
_ tout court est utilisé par convention pour assigner une variable qui n'est pas utilisée. L'exemple typique est for _ in range(3): print('Bonjour') : l'itérateur est inutilisé. Autre exemple : nom, _, domaine = email.partition('@'), le 2e élément du résultat ("@") est ignoré. J'ai vu des cas avec plusieurs _ : x, y, _, _, z = func(). Bon, il ne faut pas en abuser :-) C'est purement une convention, la variable existe et on peut la lire :-)
Dans le REPL, _ est une variable magique qui contient le dernier résultat. Magique car elle est définie dans le module builtins : c'est la variable builtins._.
Et ils ont rajouté deux mots-clés. Non mais vraiment, j'aime bien python, j'aime bien son développement, mais on ne rajoute pas des mots-clés sur des versions intermédiaires. Ça casse tout.
async/await ont levé un DeprecationWarning depuis Python 3.5, sauf que ce warning était caché par défaut. D'où le travail sur l'affichage de ce warning dans __main__ et ma nouvelle option -X dev pour afficher tous les warnings partout. On ajoute des warnings, après si les devs ignorent les warnings…
Usez et abusez de PYTHONDEVMODE=1 à partir de Python 3.7 ! Pour les anciennes versions, perso j'utilise l'option -Wd (abbréviation de "-W default" pour afficher DeprecationWarning et ResourceWarning, par exemple).
Pour cette faille, je vois que l'embargo était prévu après le 13 juin 2018, et Theo de Raadt a donné une conférence sur la faille le 9 juin. C'est moi ou bien Theo ne respecte pas les embargos, puis il râle qu'on ne le mette pas dans le secret ?
Autre exemple au pif trouvé sur l'Internet : "OpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year". https://news.ycombinator.com/item?id=16440948
Info à la source : "What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed." https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz
Je comprends : "Nous, OpenBSD, décidons de la date de l'embargo."
Ensuite, faut pas venir pleurer et faire sa victime après…
Je trouve le comportement d'OpenBSD et de GRsecurity assez similaire. Leur seul argument de vente est la sécurité et ils ont du mal à collaborer.
Après j'suis pas un grand fan des embargos, et je trouve le projet Zero de Google assez courageux sur le très court délai avant publication des détails d'une vulnérabilité (genre 7 jours pour les failles les plus graves, 90 jours au pire). https://en.wikipedia.org/wiki/Project_Zero
Donc je vais la faire cross-platform*, mais aussi cross-langages. Le plan, c'est d'utiliser la GLib et l'introspection GObject pour pouvoir générer des bindings pour un peu tout les langages facilement.
Utiliser GLib directement dans la lib bas niveau rend la lib dépendante de la GLib, ce qui peut être un soucis pour l'utiliser avec Qt. (Question de guerre de clocher.)
Pourquoi ne pas avoir une lib en C avec une API en C et fait des appels C depuis Python avec cffi ?
Je suppose qu'idéalement ta lib serait réutilisée par Gnome Simple Scan et autres outils similaires.
[^] # Re: Yoda ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 7.
L'équivalent en Python sont les "linters" comme pylint, pyflakes, pycodestyle, etc. Il existe aussi des analyseurs de code plus orientés sécurité comme bandit, PyT, etc.
Python se met aussi à lever des warnings à la compilation (et pas juste à l'exécution) :
[^] # Re: Python se rapproche du Perl ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 9.
La PEP 572 liste les différentes alternatives proposées et donc rejetées.
https://www.python.org/dev/peps/pep-0572/#alternative-spellings
[^] # Re: Arguments exclusivement positionnels ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 10.
Ca permet aussi d'éviter ce problème :
Pas de soucis avec / :
[^] # Re: La classe A 0.0.0.0/8 est maintenant reconnue comme valide par le noyau Linux 5.3 :-)
Posté par Victor STINNER (site web personnel) . En réponse au journal La fin d'IPv4. Évalué à 4.
La classe A 0.0.0.0/8 = 16 777 216 d'IPv4… moins un : 0.0.0.0/32 reste illégal :-)
La présentation parle aussi de rendre 240.0.0.0/4 valide : là on parle de 268 435 456 IPv4.
"Wouldn't it be a better world with a few hundred million more IPv4 addresses in it?" demande John Gilmore, Dave Taht et Paul Wouters :-)
# La classe A 0.0.0.0/8 est maintenant reconnue comme valide par le noyau Linux 5.3 :-)
Posté par Victor STINNER (site web personnel) . En réponse au journal La fin d'IPv4. Évalué à 2.
"The kernel will now accept IPv4 addresses in the 0.0.0.0/8 range as valid."
# La faille est l'accès physique
Posté par Victor STINNER (site web personnel) . En réponse au journal Linux Mint, Mate et grosse faille foireuse au niveau du verrouillage d´écran. Évalué à 10.
Une fois qu'un attaquant a un accès physique à une machine, ce n'est pas une mire de login qui va bloquer un vol de données. Il y a eu pas mal de failles USB, FireWire & cie. Sans parler des plus basiques boot loader sans mot passe qui permettent de passer "single init=/bin/bash" au noyau Linux pour être logué en root sans taper le moindre mot de passe.
Note : à part ça, le bug est rigolo :-)
# libdbus et multithreading
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Communiquer avec D-Bus en Java avec JNIDBus. Évalué à 3.
Salut, la dernière fois que j'avais eu à utiliser libdbus, j'avais noté que la bibliothèque n'était pas thread-safe:
https://lists.freedesktop.org/archives/dbus/2013-July/015727.html
En 2013, Simon McVittie de Collabora écrivait :
https://lists.freedesktop.org/archives/dbus/2013-July/015728.html
Est-ce que ça a changé entre temps ? Je suppose que le fait de ne pas être thread-safe n'est pas un soucis si libdbus est utilisé dans un seul thread.
Quand j'avais regardé, l'implémentation de libdbus est un mélange entre code bloquant et code asynchrone assez surprenant.
De mémoire, GDBus est une autre implémentation écrite proprement sous forme de code asynchrone avec l'event loop de la glib. Ca devrait moins poser de soucis de multithreading.
[^] # Re: Firefox + Wayland : enfin !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 5.
Aucun bug n'est spécifique à Fedora. Le premier était un bug Firefox (remonté à Firefox), le second un bug Gtk (remonté à Gtk, mais il était déjà corrigé, alors j'ai backporté le corrrectif dans Fedora).
[^] # Re: Réactivité sur le bug tracker
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 9.
"quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie…"
Sur quels paquets avais-tu rapporté des bugs ?
Utilisateur de Fedora de longue date, j'ai aussi vu plusieurs de mes bugs rapportés à Fedora rester lettres mortes.
Déjà, il faut comprendre que Fedora est une distribution Linux, et non pas l' "upstream" du projet. Le ou les responsables d'un paquet ont parfois des connaissances limitées du projet qu'ils empaquetent. Il n'est pas rare qu'une seul personne soit responsable d'une dizaine de paquet, sinon plus.
Parfois, le bug est rare et difficile à reproduire. Je maintiens Python pour Fedora, et récemment on a reçu un bug que le rapporteur reproduisait sans problème, alors qu'en s'y mettant à 4, aucun n'a réussi à reproduire le bug. Même en demandant des informations complémentaires à plusieurs reprises, on n'a pas réussi. Il faut comprendre que Fedora est un système complet : un bug dépend rarement d'un seul composant, c'est souvent la combinaison des plusieurs composants dans des versions précises combinées à une configuration utilisateur particulière. Reproduire la configuration de l'utilisateur produisant le bug n'est pas trivial. Exemple anodin : certains bugs dépendent de la locale (langue) de l'utilisateur.
Mais plusieurs fois, le bug que j'ai rapporté a été corrigé entre 1 semaine et 1 mois.
Fedora a un outil génial pour collecter des traces lors d'un crash ABRT. L'outil reconstruit la pile d'appel via un serveur dédié sans que l'utilisateur ait besoin d'avoir l'outillage (notamment les symboles de debug) installés en local. C'est efficace, mais encore une fois, "voir" un crash ne suffit pas à reproduire les conditions qui permettent de reproduire le bug.
Certains packageurs sont employés par Red Hat. Certains sont volontaires. Certains travaillent uniquement sur Fedora. Certains travaillent sur Fedora et RHEL. Il y a beaucoup de cas.
# Firefox + Wayland : enfin !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 9.
Firefox fait parti des dernières applications de mon desktop GNOME utilisant encore l'API X11 et nécessite le serveur Xwayland (émulation X11 pour Wayland). Parfois au lancement, la fenêtre Firefox était à moitié noire (genre à moitié dessinée), alors le motto Wayland est “Every frame is perfect” (chaque image est parfaite).
J'étais un des premiers à tester Wayland sous Fedora, en choisissant volontairement "GNOME (Wayland)" au login. Au début, plusieurs features me manquaient avec Wayland : raccoucis clavier (ALT+e pour lancer un terminal, m'enfin !) et capture d'écran. gnome-screenshot et GIMP peuvent à nouveau faire des captures d'écran. Le partage d'écran fonctionne dans Bluejeans. Et je peux à nouveau définir des raccourcis clavier via gnome-shell (à configurer dans les paramètres globaux de GNOME).
Dans Fedora 30, j'ai forcé l'usage de Wayland pour Firefox en mettant MOZ_ENABLE_WAYLAND=1 dans /etc/environment. Il est aussi possible de lancer "firefox-wayland", mais je préfère taper ALT+F2 puis "firefox" (plus court !) :-)
Bref, ça marchait bien jusqu'à une régression il y a une semaine :-( Entre deux versions mineures de Firefox 69, le rendu Wayland s'est mis à produire plein de glitches assez pénible à l'usage :
https://bugzilla.mozilla.org/show_bug.cgi?id=1580152
Je suis plutôt content car mon collègue Martin Stránský a rapidement eu vent du bug et travaille d'arrache pied sur un correctif. Ce matin j'ai lu "Martin, I installed the firefox-69.0-7.fc31 build you did today and it does seem to fix this, on my local system at least. Not sure if it fixes the openQA issue yet (it'll be easier to tell when it's submitted as an update). Thanks!". À priori, le bug vient d'être corrigé dans Fedora 31 (mais pas encore dans Fedora 30).
Au passage, j'ai galéré à comprendre d'où venait le bug. Mon laptop a 2 GPUs ce qui rend le debug plus complexe. J'ai écrit un article pour expliquer cette technologie du futur un peu bizzare qui vise à augmenter l'autonomie des laptops, "Hybrid Graphics" :
"Hybrid Graphics issues on Linux"
https://vstinner.github.io/debug-hybrid-graphics-issues-linux.html
--
Par le passé, j'avais déjà eu un bug majeur avec Firefox + Wayland, que j'ai du corrigé moi même en backportant un correctif Gtk. Sélectionner plus de 4000 caractères plantait tout Firefox :-( CTRL+a dans Gmail plantait Firefox, super pénible.
https://bugzilla.mozilla.org/show_bug.cgi?id=1539773
https://gitlab.gnome.org/GNOME/gtk/issues/1783
https://src.fedoraproject.org/rpms/gtk3/pull-request/5
La bonne nouvelle est qu'avec le libre, on peut corriger les bugs soit même si on sait faire ;-)
# Possible explication de l'envolée de la popularité de Python
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 10.
J'ai entendu qu'il y a une corrélation entre l'envolée de la popularité de Python et l'envolée de la popularité du {machine learning, data science, numpy, scipy, pandas, scikit-learn, etc.} : le milieu scientifique assez éloigné du développement logiciel classique.
J'ai entendu que doucement Python "remplace" plusieurs outils existants. Je ne saurai les citer, mais au pif je dirai : Matlab au moins (le seul que j'ai touché). À ce que j'ai compris, Python est supérieur aux outils existants parce qu'il est gratuit (hé oui), qu'il facilite l'intégration d'outils hétérogènes de métiers différents, et qu'il vient avec une grosse suite d'outils qui facilitent la vie (stdlib entre autres, genre lire un CSV dans un ZIP est trivial). Les notebooks Jupyter vont encore plus loin dans le remplacement de Matlab.
Quand je dis "milieu scientifique", c'est assez large. Récemment, j'ai appris que Python commence à remplacer les outils utilisés historiquement dans le domaine de l'astronomie (genre https://www.astropy.org/ ?).
En même temps, chaque fois qu'un outil s'améliore dans un métier, il peut être réutilisé dans un autre métier, parce que Python est maléable et permet de bien intéger des outils divers et variés (c'est sa force historique).
Perso je reste bluffé que le coeur de numpy/scipy reste du super vieux code (10 ans ? 20 ans ? je ne sais pas) écrit en Fortran. Info à vérifier, pas sûr des dates. Mais on m'a dit "le code marche et a été prouvé (stabilité numérique), pourquoi changer ?". Il existe des projets pour réécrire des briques de base (calcul matriciel) en C, mais l'existant en Fortran reste très populaire : OpenBLAS si ma mémoire est bonne. GitHub me dit qu'OpenBLAS est constitué de 50% de Fortran, 27% d'assembleur, 20% de C (+ qq. autres langages) : https://github.com/xianyi/OpenBLAS Ou bien peut être que je confonds avec ATLAS, une autre implémentation de l'API BLAS aussi écrite en Fortran.
[^] # Re: discussion
Posté par Victor STINNER (site web personnel) . En réponse au journal Markdown et Epub. Évalué à 6.
Quand je lis LinuxFR sur téléphone, les liens Markdown et Epub sont gros et il m'arrive souvent de cliquer dessus par erreur. Je pense qu'il faudrait virer ces liens de la page d'accueil et des journaux. Uniquement afficher les liens quand on est sur la page d'un article.
# Validation de courriel : faille de sécurité dans Python
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Tchap, messagerie d'état basé sur Matrix et Riot. Évalué à 3.
Il s'agit du bug https://bugs.python.org/issue34155
# Eddie Murphy
Posté par Victor STINNER (site web personnel) . En réponse au journal Med Hondo (Voix francaise de L'Âne dans Shrek, Morgan Freeman, ...) bronsonisé. Évalué à 2.
Voix française de https://fr.wikipedia.org/wiki/Eddie_Murphy également.
[^] # Re: L’usage d’underscore dans les noms d’objet
Posté par Victor STINNER (site web personnel) . En réponse au journal Pythreries - Perl ou Python?. Évalué à 8.
_tout court est utilisé par convention pour assigner une variable qui n'est pas utilisée. L'exemple typique estfor _ in range(3): print('Bonjour'): l'itérateur est inutilisé. Autre exemple :nom, _, domaine = email.partition('@'), le 2e élément du résultat ("@") est ignoré. J'ai vu des cas avec plusieurs _ :x, y, _, _, z = func(). Bon, il ne faut pas en abuser :-) C'est purement une convention, la variable existe et on peut la lire :-)Dans le REPL,
_est une variable magique qui contient le dernier résultat. Magique car elle est définie dans le module builtins : c'est la variablebuiltins._.[^] # Re: Meilleur ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouvelle version de Notepad++. Évalué à 9.
gvim.exe
[^] # Re: Hackers sous Windows
Posté par Victor STINNER (site web personnel) . En réponse au journal La DGSE utilise Arch Linux.... Évalué à 2.
Il y a d'excellents outils Windows pour la sécurité informatique. Aujourd'hui j'ai vu passer un système de fichier pour monter une copie de la mémoire, "The Memory Process File System" :
* https://github.com/ufrisk/MemProcFS
* https://twitter.com/UlfFrisk/status/1067117027075260417
[^] # Re: Python : la stabilité avant tout
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Python 3.7. Évalué à 10.
async/await ont levé un DeprecationWarning depuis Python 3.5, sauf que ce warning était caché par défaut. D'où le travail sur l'affichage de ce warning dans __main__ et ma nouvelle option -X dev pour afficher tous les warnings partout. On ajoute des warnings, après si les devs ignorent les warnings…
Usez et abusez de PYTHONDEVMODE=1 à partir de Python 3.7 ! Pour les anciennes versions, perso j'utilise l'option -Wd (abbréviation de "-W default" pour afficher DeprecationWarning et ResourceWarning, par exemple).
[^] # Re: Embargo sur les failles de sécurité et OpenBSD
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Faille Lazy FPU state restore. Évalué à 4. Dernière modification le 19 juillet 2018 à 09:07.
Quelques liens sur la faille et OpenBSD :
# Embargo sur les failles de sécurité et OpenBSD
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Faille Lazy FPU state restore. Évalué à 7.
Pour cette faille, je vois que l'embargo était prévu après le 13 juin 2018, et Theo de Raadt a donné une conférence sur la faille le 9 juin. C'est moi ou bien Theo ne respecte pas les embargos, puis il râle qu'on ne le mette pas dans le secret ?
Pour les failles Meltdown et Spectre, le projet OpenBSD avait râlé qu'ils n'avaient pas été inclus dans l'embargo.
https://marc.info/?l=openbsd-tech&m=151521435721902&w=2
Autre exemple au pif trouvé sur l'Internet : "OpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year".
https://news.ycombinator.com/item?id=16440948
Info à la source : "What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed."
https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz
Je comprends : "Nous, OpenBSD, décidons de la date de l'embargo."
Ensuite, faut pas venir pleurer et faire sa victime après…
Je trouve le comportement d'OpenBSD et de GRsecurity assez similaire. Leur seul argument de vente est la sécurité et ils ont du mal à collaborer.
Après j'suis pas un grand fan des embargos, et je trouve le projet Zero de Google assez courageux sur le très court délai avant publication des détails d'une vulnérabilité (genre 7 jours pour les failles les plus graves, 90 jours au pire).
https://en.wikipedia.org/wiki/Project_Zero
[^] # Re: Scripts de démarrage
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Devuan 2.0 « ASCII ». Évalué à 4.
Après systemd, status donne beaucoup plus d'infos !
"Tasks: 0 (limit: 4915)"
0 processus pour un démon, c'est quand même louche
"juin 12 13:25:29 zoro burp[16880]: burp disabled; edit /etc/default/burp"
systemd montre aussi les logs, ce qui me semble très pertinent dans ce cas précis :-)
[^] # Re: Pourquoi le feraient-ils ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à 7.
Je pense que l'IA LinkedIn est imparable et que tu rêves intimement d'être influencé par Bill Gates.
Je suis tombé sur https://twitter.com/movingtogitlab hier : GitLab fait face à une montée en charge depuis les premières rumeurs de rachat. Il risque d'y avoir qq. soucis de perf ces prochains temps ;-)
https://www.dropbox.com/s/uzg9vc5oljr8lin/Screenshot%202018-06-03%2015.52.52.png?dl=0
[^] # Re: Ma jeunesse...
Posté par Victor STINNER (site web personnel) . En réponse au journal Lord Casque Noir est bronsonisé. Évalué à 2.
Oh… Je ne savais pas que Seb s'était suicidé :-( Père de deux enfants, il s'est suicidé à cause d'un chagrin d'amour selon ce que j'ai lu :-(
[^] # Re: Pas tant de ressources
Posté par Victor STINNER (site web personnel) . En réponse au journal L'État français adopte Matrix/Riot. Évalué à 7.
OpenStack tout court. Càd plusieurs millions de ligne de code.
https://www.openhub.net/p/openstack
"In a Nutshell, OpenStack has had 942,125 commits made by 10,764 contributors representing 9,105,385 lines of code"
75% de Python
[^] # Re: Python vers C?
Posté par Victor STINNER (site web personnel) . En réponse au journal Base de données de scanners : besoin de contributeurs. Évalué à 3.
Utiliser GLib directement dans la lib bas niveau rend la lib dépendante de la GLib, ce qui peut être un soucis pour l'utiliser avec Qt. (Question de guerre de clocher.)
Pourquoi ne pas avoir une lib en C avec une API en C et fait des appels C depuis Python avec cffi ?
Je suppose qu'idéalement ta lib serait réutilisée par Gnome Simple Scan et autres outils similaires.