Victor STINNER a écrit 1639 commentaires

J'ai notamment écrit la PEP 564 "Add new time functions with nanosecond resolution" pour Python 3.7 car le type float de Python (IEEE 754) perd de la précision quand on manipule des dates avec une précision d'une nanoseconde.
https://www.python.org/dev/peps/pep-0564/

Python 3.7 permet maintenant de lire l'heure sous forme d'un nombre de nanosecondes, nombre entier (int), plutôt qu'un nombre de secondes, nombre floattant (float).

Je bosse sur le projet Python qui manipule des durées dans des tas de format différents : time_t (secondes), timespec (secondes et nanosecondes), timeval (secondes et microsecondes), nombre de millisecondes (pour appeler poll()), etc. J'ai choisi d'utiliser le type C int64_t (appelé _PyTime_t dans pytime.c ci-dessous) avec une unité d'une nanoseconde (note : cette unité ne fait pas partie de l'API publique, c'est censé être interne).

pytime.c:
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/Python/pytime.c

Les systèmes d'exploitation aiment la diversité. Windows fournit QueryPerformanceCounter() : nombre à diviser par QueryPerformanceFrequency() pour obtenir des secondes. En utilisant des nombres flottants, la division est facile à réaliser. Mais en utilisant des nombres entiers (_PyTime_t), euh, c'est plus difficile, surtout pour éviter un integer overflow (dépassement de capacité du type int64_t provoquant des erreurs de calcul). J'ai notamment écrit _PyTime_MulDiv() pour QueryPerformanceCounter() :
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/Python/pytime.c#L46-L61

Avec un peu de mathématique, on évite l'integer overflow en pratique :

(ticks * mul) / div == (ticks / div) * mul + (ticks % div) * mul / div
Le code gère 4 modes d'arrondi (_PyTime_ROUND_HALF_EVEN, _PyTime_ROUND_CEILING, _PyTime_ROUND_FLOOR, _PyTime_ROUND_UP) car en plus, selon le besoin, il faut arrondir différemment… Depuis 2012, j'ai du corriger 4x les arrondis…
https://vstinner.github.io/pytime.html
(cet article date de février 2016, il ne mentionne pas le dernier correctif de 2017)

En utilisant l'Epoch Unix (1er janvier 1970) comme référence, ce type permet de stocker des dates de l'année 1678 à l'année 2262. Vous me direz que c'est largement suffisant. Sauf que Python fournit le module datetime qui gère des dates de l'année 1 à 9999. Pour ce module, il faut conserver le type time_t (qui peut être en 32-bit ou 64-bit selon la plateforme) pour gérer des dates "extrêmes". Bien sûr, jouer avec de telles dates provoque des soucis sur certaines plateformes comme Windows, AIX ou Solaris.

Le noyau Linux a un type opaque ktime_t https://lwn.net/Articles/167897/ mais ce type n'est pas (forcément) un entier, et on ne peut pas écrire t1 + t2 ou t2 - t1, contrairement au type _PyTime_t.

This type, found in , is meant to be used as an opaque structure. And, interestingly, its definition changes depending on the underlying architecture. On 64-bit systems, a ktime_t is really just a 64-bit integer value in nanoseconds. On 32-bit machines, however, it is a two-field structure: one 32-bit value holds the number of seconds, and the other holds nanoseconds.

Gérer le temps, c'est simple ! Bon, maintenant on va parler des timezones et de changement d'heure d'été …

Soit un mini programme :

    use std::io;
    use std::io::Read;
    use std::fs::File;

    fn readfile() -> Result<String, io::Error> {
        let mut f = File::open("hello.txt")?;
        let mut s = String::new();
        f.read_to_string(&mut s)?;
        Ok(s)
    }

    fn main() {
        let bla = readfile();
        match bla {
            Ok(_) => println!("success"),
            Err(e) => println!("failure {}", e),
        }
    }

Le fichier hello.txt fait 10 Mo, et je limite la mémoire du programme à 20 Mo avec "ulimit -v 20000". Résultat : le runtime Rust affiche "fatal runtime error: allocator memory exhausted", puis le programme Rust plante avec le signal SIGILL (Illegal instruction).

Sur IRC, on m'apprend que Rust n'a pas encore implémenté la gestion d'erreur sur les allocations mémoires. Ah. C'est dommage ça.

• RFC : https://github.com/rust-lang/rfcs/pull/2116
• Bug : https://github.com/rust-lang/rust/issues/32838

De là à appuyer tout l'argumentaire de Rust sur "les programmes écrits en C et C++ peuvent planter, un code écrit en Rust ne peut pas planter", je trouve que ça méritait quelques précisions :-) (Par planter je veux dire : signal fatal genre SIGSEGV… ou SIGILL.)

En attendant, j'ai remis au propre l'app Mailman (2.x) (…) l'interface web est affreuse.

C'est un peu dommage d'avoir choisi Mailman 2 quand Mailman 3 est dispo et que son interface web est plus jolie ! Exemple au pif : l'interface web publique pour consulter les archives de la liste buildbot-status@python.org (une des premières à avoir migré à Mailman 3).

https://mail.python.org/mm3/archives/list/buildbot-status@python.org/

Pour avoir connu l'interface d'admin de Mailman 2, euh, je préfère carrément celle de Mailman 3. Pour info, on m'a dit que l'interface web ne permet pas encore de configurer tout ce que sait faire le backend.

Je ne sais pas pour Sympa, mais je peux dire que la migration à GitHub début de l'année a reboosté les contributions à CPython ! Je pense que c'est plus simple pour les contributeurs d'écrire une pull request et de la faire vivre jusqu'à ce qu'elle soit intégrée. D'ailleurs, les tests sont désormais lancés sur les pull requests, ce qui a beaucoup aidé !

CPython a implémenté une optimisation similaire dans Python 3.3:
https://www.python.org/dev/peps/pep-0393/

Si une chaîne ne contient que des caractères dans U+0000-U+00FF ("Latin1") : 1 octet par caractère. Que dans U+0000-U+FFFF ("BMP") : 2 octets par caractères. Sinon ("Astral"), 4 octets par caractère (désolé pour vos jolis emojis). Du coup, "toto" prend 4 octets au lieu de 16 avec Python 2 (en ignorant les entêtes des objets).

Je pense qu'il veut dire que l'exploit trouve par la NSA EternalBlue, a été développé volontairement par Microsoft.

Euh non pas du tout. Attention, je connais très Windows. J'ai répêté les infos que j'ai entendu à droite et à gauche. Mais je pense qu'il est encore tôt pour comprendre en détail ce qui s'est passé.

Ce que je voulais dire : c'est que le malware est assez malin et sait exploiter correctement les fonctionnalités d'administration de Windows. Je ne vois pas ce qu'il y a d'étonnant à ce qu'un admin puisse modifier des postes clients. Linux a des technologies similaires.

Je vous raconte pas le nombre de fois que j'ai buté sur la limitation Windows "on ne peut pas supprimer un fichier ouvert" en développant avec Python … Cette limitation explique certainement l'obligation de rebooter à tout va, nan ?

(1) Infection

La mise à jour automatique du logiciel de compatibilité Ukrainien MeDoc est suspecté d'avoir servi de moyen d'infection initial. Selon l'article TheVerge (cité plus bas), en général, les système de mise à jour automatique ont les droits d'administrateur Windows, utilisent des connexions chiffrées, sont mis en liste blanche par les parefeux, ont le droit aux connexions sortantes vers Internet, etc. Le "graal" des attaquants.

(2) Propagation du virus

Petya utilise élégamment les fonctionnalités Windows d'administration des postes de travail, Windows Management Instrumentation (WMI) et PsExec, pour infecter les autres ordinateurs du LAN. Autrement dit : une fois qu'un poste administrateur Windows est infecté, il peut infecter tous les postes de travail auxquels ils ont accès, même si ces postes sont ultra sécurité, car c'est volontaire de permettre d'exécuter du code arbitraire.

Techniquement, WMI et PsExec ne sont pas mis en cause, on peut aisément imaginer la même chose sous Linux (SSH, Ansible, Puppet, Chef & cie).

J'en comprends que le problème initial est le vecteur d'infection. Là je pense que Linux se défend mieux car les logiciels proviennent généralement de la distribution Linux utilisée qui signe les dépôts et les paquets, et sécurise correctement ses serveurs…

… Oui bon, parfois les serveurs Debian, Ubuntu, freedesktop, gnome.org, kernel.org, etc. se sont pirater, mais bon, c'est rare nan ? …

Source: https://www.theverge.com/2017/6/27/15883110/petya-notpetya-ransomware-software-update-wannacry-exploit

J'utilise un noyau 4.10 fourni par Fedora (Fedora 25) depuis plusieurs semaines. Merci pour avoir publié la dépêche 4.10 en même temps que la sortie de 4.11, ça m'a bien fait marrer :-D

Pour info, ces tokens utilisent un algorithme pour générer un code à partir d'un secret (l'algorithme standard pour cela s'appelle TOTP), mais tant que ça ne sort pas de l'appareil en question, ça relève bien de la propriété. En revanche, dès qu'on s'amuse à utiliser ça avec un générateur de code sur téléphone par exemple, ça s'approche un peu plus de la connaissance.

Le principal défaut d'un OTP logiciel genre FreeOTP sur smartphone est qu'un smartphone est connecté à tous les réseaux qui existent et sont la cible d'attaques. Mis à part ce point, mot de passe + FreeOTP me semble carrément plus sûr qu'uniquement un mot de passe.

J'ai trouvé les temps d'exécution pour la version Cython, pour la version Pythran sans SIMD et la version Pythran avec SIMD. Hum, mais quel est le point de départ ? Quelles sont les perfs sans Cython ni Pythran, juste avec numpy avec CPython standard ?

Je me suis frotté aux erreurs d'arrondi en concevant une API C pour manipuler des dates : https://haypo.github.io/pytime.html

J'en garde un drôle de souvenir. Avec le langage C, l'arrondit est implicite et les erreurs faciles à commettre.

L'arrondit Python de la fonction round() est l'arrondit par défaut du très sérieux standard IEEE 754 : https://en.wikipedia.org/wiki/Rounding#Round_half_to_even

Cet arrondit est celui qui produit le moins d'erreur d'un point de vue statistique :

"This method treats positive and negative values symmetrically, and is therefore free of sign bias. More importantly, for reasonable distributions of y values, the average value of the rounded numbers is the same as that of the original numbers."

non

https://issues.apache.org/jira/browse/INFRA-7524

"Migrate Apache Subversion project over to the git repo". Ha ha, excellent :-)

Le "Language Summit" est un sous-événement de l'événement majeur annuel Pycon US. Les éditions 2015 et 2016 ont été couvertes par un journaliste !
* 2015 : https://lwn.net/Articles/639773/
* 2016 : https://lwn.net/Articles/688969/

Pour info, un sprint physique est organisé en Californie la semaine prochaine avec une vingtaine de core developers.

D'ailleurs, les différentes conférences Pycon (EuroPyhon, Pycon FR, Pycon <…> : il y a plus d'une dizaine) sont l'occasion pour les développeurs d'échanger de vive voix. Ces échanges aident à l'élaboration des évolutions de Python, directement ou indirectement.

Site web intéressant sur les problèmes et solutions pour obtenir des compilations reproductibles : https://reproducible-builds.org/ "Provide a verifiable path from source code to binary."

Ca parle par exemple d'une variable d’environnement $SOURCE_DATE_EPOCH pour la date de compilation.

Ça fait plaisir de voir de grosses applications qui supportent Python 3. Bravo ! ;-)

Tiens marrant, scheduler + énergie est justement le thème d'un récent article LWN:
https://lwn.net/Articles/682391/

"A few years ago, Linux scheduler maintainer Ingo Molnar expressed a strong desire that future improvements in CPU power management should integrate well with the scheduler and not try to work independently."

Lien gratuit si vous n'êtes pas encore abonnés à l'excellent LWN : https://lwn.net/SubscriberLink/682391/1b395639142d1fa3/

Comme dit dans l'article, les intrusions de ce genre sont malheureusement courantes. Je me demande à chaque fois comment une telle intrusion pourrait être détectée au plus tôt pour limiter la portée de l'attaque. Je suppose que Wordpress et phpBB sont hébergés sur un serveur qq. part. Faut-il installer un outil de détection d'intrusion dessus ?

Ma petite expérience. A un moment j'avais installé un serveur SSH accessible depuis Internet sur ma machine perso (authentification uniquement par clé SSH, pas par mot de passe, uniquement un login $USER, pas root). C'est tout con, mais j'ai remarqué que des bots l'attaquaient en essayant plein de mots passe parce que le ventilateur de mon CPU tournait très vite (était bruyant). Je suppose qu'il existe des outils plus subtils qu'écouter un ventilateur :-)

Il y a qq. années, j'avais testé Btrfs car j'ai lu que c'était trop super. Mais j'ai eu de gros problèmes de performances sur des machines virtuelles à cause du fonctionnement Copy-on-write. J'avais aussi eu des soucis de disque "plein" alors que non, 80% de l'espace disque (800 Go de mémoire) étaient libres. Il fallait faire qq. bidouilles. Ca m'avait saoulé, j'avais remis ext4.

Il y a environ 1 an, j'ai remplacé mes deux disques durs en RAID 0 par un unique SSD. Le boot est passé d'environ 3 minutes à 10 secondes. À priori les I/O étaient le goulot d'étranglement, pas le CPU :-D

J'en ai profité pour retenter btrfs. Déjà, j'ai crée une partition ext4 dédiée pour la virtualisation. Bien qu'entre temps, j'ai lu qu'on peut desactiver la fonctionnalité de Copy-On-Write (CoW) sur certains fichiers. Ca me semble pénible de devoir le faire sur chaque VM.

Pour un PC de bureau, le principal gain que je vois avec Btrfs est la facilité pour créer un backup du système complet : un "snapshot". Ca ne protège ni du vol, ni de la casse matérielle, ni des catastrophes naturelles. Mais ça protège du "rm -rf" maladroit (oups, mauvais chemin, oups variable non initialisée en shell, etc.). Euh, de mon expérience, rm -rf est plus courant que les vols / casse / accidents :-) En 1 an, j'en ai déjà profité une fois ! J'ai pu récupérer mes photos du Japon effacées par erreur ! ("Tiens, j'ai supprimé la copie ou l'original ? Oups tiens l'original. Tiens où est la copie ? Y'a pas de copie ? Ah en fait, y'a plus aucune photo… Meeerde").

Créer un snapshot est trivial. Accéder à un snapshot : bah c'est un vulgaire dossier en lecture seule sur le disque. On peut également rebooter l'OS sur un ancien snapshot.

J'ai aussi lu que btrfs détecte les corruptions de données sur disque et sait récupérer une ancienne version d'un fichier dans les snapshots, mais je n'ai pas expérimenté ça. Je ne sais même pas si btrfs calcule effectivement un checksum des fichiers !?

Ah sinon pour les perfs … Euh désolé mais pour mon utilisation, je m'en fous un peu hein :-) Ca me semble plus important d'éviter de perdre des données que de gagner 10% de perf ou autre.

En tout cas, côté fonctionnalités, btrfs me semble supérieur à ext4.

Pour finir, je n'ai jamais perdu le moindre fichier à cause de btrfs.

Après être passé par la programmation agile avec des stands up meeting et une intégration continue, je dois avouer que j'étais un peu réticent à passer à la méthode R.A.C.H.E. Mais le site web m'a convaincu et j'ai été agréablement surpris. Depuis mes projets sont livrés en avance et j'ai même du temps libre pour évaluer le million de frameworks Javascript, bien qu'une migration à Perl 6 ait sûrement plus de sens en 2016.

Par contre, un ami m'a très bien vendu une autre méthode qui semble autrement plus efficace https://www.youtube.com/watch?v=p8oi6M4z_e0 (*) ! Quelqu'un a testé et pourrait me faire des retours ? J'ai un peu peur pour l'état de mon clavier, mais ce détail mis à part, c'est assez bluffant. Tiens, je vais retourner voir la vidéo du tutoriel d'ailleurs, au cas où j'aurai loupé des détails sur la mise en place.

(*) La méthode « Je code avec le cul, lalalalalère. Si ça bugue ou plante, j'men fous ! On m'paye pas pour tester ! Je code avec le cul, lalalalalère. Même si le programme marche pas, tu s'ras pas remboursé ! ».

Tu m'as presque convaincu d'abandonner Linux pour Windows, mais au dernier moment je me suis souvenu que c'était un OS de merde. Pas de gestionnaire de paquet, nid à malware et victime préférée des ransomwares, logiciels demandant de signer des CLUF sans arrêt, popups à gogo (ouh là là, ce logiciel libre n'est pas signé par Microsoft, c'est l'oeuvre du mal, il va pourrir ton ordinateur !), etc. Sur un Windows neuf, il n'y a pas de suite bureautique ni de logiciel de retouche photo. Bref, Windows tout seul ne sert à rien. Il faut installer tout un tas de logiciels pour avoir un ordinateur fonctionnel. Et pour développer, c'est aussi super galère. L'émulateur de terminal est inutilisable tellement il est limité (c'est quoi cette limite à 80 caractères de large, impossible à changer ?).

On dirait une réaction à http://linuxfr.org/news/in-memoriam-ian-murdock-1973-2015

« Et là… je continue de regarder l'asm et le débuggueur, je ne trouve plus rien. Pire, l'assembleur change d'un coup, il devient encore plus difficile à lire. (…) il semblerait que certains endroits du code incrémentent %pc de seulement quelques octets (…) En plus, les instructions qui font ça le font après avoir fait tout un tas de calculs absurdes (…) »

Tu décris la base de l'obfuscation du code machine, un classique pour ralentir le travail de l'ingénierie inverse. objdump est vraiment le desassembleur le plus rudimentaire qui existe, ce n'est pas étonnant qu'il butte sur ces bidouilles. Il existe des outils pour "simplifier" le code machine (supprimer les calculs absurdes que tu décris) automatiquement. J'en ai entendu parlé, mais je ne pourrai t'en conseiller. Ca ne m'étonnerait pas que radare2 sache faire ce genre de chose.

Ca me rappelle quand j'ai migré à Linux. Ayant passé pas mal de temps dans un débogueur en ring 0 (SoftICE) et IDA, j'étais un peu frustré de ne plus avoir de logiciels à déplomber. Tout le code source était disponible très facilement, et il était trivial de modifier un logiciel depuis le code source.