Blog de Ludovic Baillet

Astronomie, informatique et science

La fin des Microsoft Surface ?

Les Microsoft Surface sont un ensemble de matériels allant de la mini tablette Android jusqu’aux ordinateurs portables et ordinateurs fixes dont le premier exemplaire est apparu il y a 10 ans, donc en 2013.

De nombreuses générations se sont succédées, de nouveaux matériels sont apparus, parfois dans un esprit inédit avec un marché plutôt peu inventif.

Néanmoins, plusieurs de ces nouveaux matériels ont été critiqués pour leur bogues multiples et leur manque de fiabilité.

On apprend ainsi que Microsoft vient de mettre fin à l’aventure des Surface Duo.

Il existe aussi un aperçu des appareils Surface apparus au fil des années.

On peut maintenant se demander quels seront les prochains appareils qui seront arrêtés. On peut imaginer que ce sera les Surface Book. En effet, ces ordinateurs portables étaient assez originaux à l’origine. Mais ils souffrent de graves défauts de fabrication. Par exemple, la recherche surface batterie gonflée (ou surface battery swollen en anglais) fournit beaucoup de résultats.

Exemple en photo d’une batterie Lithium-ion gonflée d’un Surface Book qui déforme littéralement le boîtier :

Boîtier de Microsoft Surface Book déformé par sa batterie qui a gonflé
Boîtier de Microsoft Surface Book déformé par sa batterie qui a gonflé

On pourrait aussi évoquer les plastiques de nombreux accessoires (clavier et souris) qui deviennent gluants et collants au bout de quelques années seulement.

Dès lors ont peut s’interroger sur l’avenir de cette ligne de produit de plus en plus décriée pour son manque de qualité et durabilité.

Encore une nouvelle planète dans le système solaire

Et une de plus. Selon un papier diffusé dans l’astronomical journal Is there an earth-like planet in the distant Kuiper belt?, une nouvelle planète se cacherait dans le système solaire. Pas la planète 9, ni Vulcain ou Némésis. Mais bien une nouvelle planète qui aurait la taille de la Terre et qui orbiterait aux confins de la ceinture de Kuiper (à 200-500 unités astronomiques et avec une forte inclinaison de 30°). Une hypothèse basée comme pour l’hypothétique planète 9 sur un échantillon d’objets lointains qui auraient des orbites un peu trop particulières.

Et même si cette planète existait, sa détection est presque impossible avec nos moyens techniques. En effet, sa magnitude serait aux alentours de 25.

Une telle planète remettrait en cause les théories de formation du système solaire. À tel point que l’on peut raisonnablement douter de l’existence d’un tel objet, tout comme on peut sérieusement douter de l’existence de la planète 9. Dans tous les cas, il faudrait soit une découverte, soit des preuves nettement plus conséquentes.

Planètes aux confins du système solaire.
Embouteillage de planètes aux confins du système solaire. Image générée par Bing.

Le meilleur format graphique

Depuis environ une trentaine d’années, le format graphique JPEG règne en leader quasi incontesté. Notamment sur Internet, la majorité des images sont encodées en JPEG.

D’autres formats graphiques cohabitent pour quelques besoins particuliers : PNG (images simples ou besoin du canal alpha) et GIF (petites images animées) notamment. À noter aussi le format TIFF qui bien que très ancien et bien qu’il ne dispose pas de taux de compression intéressants, ni de canal alpha, ses dimensions maximales sont considérables : 2^32-1 x 2^32-1. Et il supporte une très importante profondeur de couleur : jusqu’à 16 bits par canal. Et du coup le format TIFF reste un format populaire pour numériser des documents ou des diapositives.

Si le JPEG était un choix pertinent à l’époque, on peut raisonnablement se demander pourquoi il est encore utilisé de nos jours. En effet, ce format graphique a dorénavant un faible taux de compression face à d’autres formats plus récents, et possède de nombreuses limitations, par exemple :

  • Taille maximale de 65535*65535
  • Pas de canal alpha
  • Profondeur de couleur limitée à 8 bits par canal
  • Taux de compression plutôt faible

Depuis sont apparus de nombreux prétendants au remplacement de ce format JPEG. Dont :

  • JPEG 2000. Ce format présente peu d’améliorations par rapport au JPEG d’origine, et n’a donc pas pu remplacer son prédécesseur.
  • WebP. Surprenamment, ce format est très limité : profondeur de couleur limitée à 8 bits par canal. Taille maximale des images limitée à 16383*16383 seulement. Néanmoins il accepte un canal alpha et a un taux de compression un peu meilleur que le JPEG.
    Une version 2 est en cours mais apporte peu d’évolution (profondeur de couleur légèrement améliorée à 10 bits par canal, taux de compression qui serait un peu amélioré)
  • HEIF/HEIC. Taille maximale de 16383*18383. Profondeur de couleur de 10 bits par canal.
  • AVIF. Taille maximale de 65535*65535 ou plutôt 8192 x 4352 avec des extensions possibles. Profondeur de couleur de 12 bits par canal.
  • JPEG XL. Un format récent mais taillé pour l’avenir tant il cumule les avantages. Dimensions maximales : 2^30-1 x 2^30-1. Profondeur de couleur par canal : 24 bits (entiers) ou 32 bits (flottants). Il supporte aussi pas moins de 4099 canaux (3 + 2^12), et donc le canal alpha est largement supporté. Et en plus il dispose d’un excellent taux de compression, etc.

Bien sûr il existe une multitude d’autres formats graphiques adaptés à des usages bien spécifiques (compression sans perte, support de très grandes dimensions, ou même formats simplement propriétaires).

À noter également que les dimensions maximales dans les 2 dimensions sont impossibles à obtenir en pratique pour de multiples raisons (notamment à cause des limitations d’offsets).

Logo JPEG XL

On comprend bien que le format JPEG XL est le format graphique du futur qui cumule quasiment tous les avantages. Ce devrait bien sûr être le format utilisé sur Internet pour réduire les données transmises et réduire la taille des supports mémoire, dans un réflexe de sobriété. Mais aussi le format de base pour les appareils photo, les appareils de numérisation, etc.

Hélas, tel n’est pas le cas. Google a décidé de mettre des bâtons dans les roues de ce format du futur. Sur fond de rivalité avec d’autres formats nettement moins bons (WebP et AVIF), et de sa situation largement dominante dans le domaine des navigateurs internet (Chromium / Chrome), le JPEG XL va avoir bien du mal à se faire la place qu’il mérite. Faudra-t-il que les autorités étatiques s’occupent de ce dossier ?

AVX et hyper-threading, nouveau chamboulement pour les processeurs

Intel a supprimé le support de l’AVX-512 à partir de sa 12e génération de processeurs (Alder Lake).

Les bouleversements ne vont pas s’arrêter là. Intel se prépare à faire évoluer les jeux d’instructions de ses processeurs, mentionnant l’APX (Advanced Performance Extensions) et l’AVX10 (Advanced Vector Extensions 10). Et en supprimant les instructions MPX (Memory Protection Extensions) qui étaient pourtant apparues récemment sur les processeurs Skylake (6e génération de processeurs). Sans compter que l’AVX10 va se décliner dans de multiples possibilités selon la catégorie de processeur (grand-public/entreprises) et les générations (AVX10.1 puis AVX10.2). Pour les développeurs pratiquant le langage assembleur ou les intrinsics functions accessibles depuis plusieurs langages (notamment le C++), la situation qui n’était déjà pas simple va nettement se complexifier.

L’utilisateur final devrait quand même voir un avantage au final. Le doublement du nombre de registres généraux (passant de 16 à 32) devrait largement aider à améliorer les performances des processeurs, conjointement aux compilateurs qui auront la lourde tâche de gérer cette évolution. Nouveau point positif, l’AVX10 sera possible sur tous les cœurs, qu’ils soient P-core ou E-core.

Autre changement significatif, mais pour le moment au stade de la rumeur : la fin de l’hyper-threading. De toute façon il n’était utilisé que sur les quelques cœurs de type P-core. La disparition de l’hyper-threading n’aurait donc pas un impact significatif. La simplification des cœurs de type P-core qui en résulterait pourrait permettre d’ajouter davantage de cœurs de type E-core. De nos jours, c’est bien ce que l’on attend, notamment de la part des développeurs : davantage de cœurs, davantage de vitesse et davantage de mémoire centrale.

Image d'un processeur fictif
Image d’un processeur fictif. Image générée par Bing.

L’étrange hors-série de Programmez.com dédié au langage python

Le hors-série N°11 de Programmez.com est consacré au langage python. Ce langage qui a connu une popularité croissante est en effet dorénavant utilisé dans de nombreux contextes pour de petits projets, ce qui peut justifier une série d’articles à son sujet.

Néanmoins, plusieurs articles sont rédigés d’une manière maladroite (en étant poli), notamment l’article qui compare la syntaxe de python avec celle de C# ou C++. Comme si on choisissait un langage de programmation en fonction de sa capacité à faire du code golf. Il est vrai que python obtient généralement de bons scores dans le domaine (j’apprécie python notamment pour ça). De mon côté, la capacité à écrire un Hello World de manière succincte n’est pas ma préoccupation première quand je dois résoudre un problème.

Par ailleurs, si un Hello World s’écrit effectivement brièvement en python :

print("Hello World")

Voici la version attribuée au langage C# :

using system;
namespace Hello
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }
}

Mais cette version ne représente pas la situation courante. En l’état actuel, un développeur C# écrirait plutôt simplement :

Console.Write("Hello World");

Le deuxième exemple choisi reprend la célèbre Conjecture de Collatz appliquée au nombre 299999. Et en comparant python avec C++ cette fois-ci.

Côté python, ça donne :

n=2999999
i=0
print(i,">",n)
while n!=1
    if n%2==0:
        n=n//2
    else:
        n=(3*n+1)//2
    i+=1
print(i,">",n)

Côté C++, voici le code verbeux attribué à C++ :

#include <iostream>
using namespace std;
int main()
{
    unsigned int n=2999999;
    unsigned int i=0;
    cout<<i<<">"<<n<<endl;
    while(n!=1)
    {
        if(n%2==0)
        {
            n=n/2;
        }
        else
        {
            n=(3*n+1)/2;
        }
        ++i;
    }
    cout<<i<<">"<<n<<endl;
    return 0;
}

Pourtant ce code peut être amélioré :

#include <iostream>
int main()
{
    int n=2999999, i=0;
    std::cout<<i<<">"<<n<<std::endl;
    while(n!=1)
    {
        n = n%2==0 ? n/2 : (3*n+1)/2;
        i++;
    }
    std::cout<<i<<">"<<n<<std::endl;
}

Et si le but est de faire un code court, alors allons-y en 7 lignes en C++ au lieu de 10 lignes en python :

#include<iostream>
int i,n=2999999;
main()
{
    for(printf("%d>%d\n",i,n);n>0;i++)n=n%2?(3*n+1)/2:n/2;
    printf("%d>%d\n",i,n);
}

Sachant que l’on peut encore faire mieux (ce qui veut dire pire en terme de lisibilité).

Ceci démontre que la longueur d’un programme n’est pas un argument en faveur d’un langage de programmation.

De toute façon, comparer les langages de programmation et arriver à la conclusion qu’un langage serait meilleur qu’un autre est une faute grave pour un développeur (c’est plutôt que le développeur devrait s’extérioriser). Tout ce qu l’on peut dire, c’est que certains langages sont plus adaptés que d’autres dans certains contextes. Par exemple, on évitera d’utiliser le langage interprété qu’est python pour de trop gros projets (ou simplement pour sauver la planète, cf. l’article Pourquoi l’utilisation du langage de programmation Python serait en train de « détruire la planète »). Par ailleurs, il ne faut pas oublier que la plupart des langages évoluent de nos jours rapidement (y compris python). Et du coup, les syntaxes attribuées a C++ pour les listes et les dictionnaires ont dorénavant des syntaxes améliorées ce qui annihile les critiques inutiles contre cet excellent langage. Sinon, pourquoi ne pas avoir utilisé la syntaxe de python par exemple version 2.7 ?

Enfin, concernant le supposé « coup de grâce » de python contre les autres langages au sujet de sa bibliothèque, il est difficile de faire ce genre de comparaison. D’autant plus que si C++ a a effectivement une bibliothèque standard incomplète, bien d’autres impressionnantes bibliothèques viennent en renfort (l’auteur semble ignorer boost).

En conclusion, un article, voire un hors-série, à ignorer.

La programmation informatique dans la série Citadel

La série Citadel en 6 épisodes est une série d’espionnage dotée d’un budget conséquent, mais souffre d’un scénario assez bancal. Toutefois le point qui nous intéresse ici, c’est la programmation informatique dans le troisième opus. D’une manière assez étrange, alors que l’héroïne consulte ses mails, en inversant l’écran horizontalement, on aperçoit un programme :

Citadel saison 1 épisode 3 : programmation informatique à la lecture de ses mails
Citadel saison 1 épisode 3 : programmation informatique à la lecture de ses mails

Il s’agit d’un simple programme en langage C, avec une simple fonction main et une fonction de création d’un nouveau fichier. À noter l’utilisation des arguments de la fonction main (program_name = argv[0]) ce qui est généralement à faire avec d’énormes précautions.

Cette partie programmation n’a bien sûr rien à faire à cet endroit. Manifestement il fallait en rajouter avec un peu de coloration syntaxique, et comme on voit l’écran à l’envers par transparence, ça passe inaperçu pour la plupart.

Justement, à quand les écrans transparents ?

L’or est-il le plus conducteur des métaux ?

À cette question d’actualité, la réponse courte est bien sûr NON.

Du moins dans les conditions usuelles de température et de pression (20 °C et 101 325 Pa), et en considérant uniquement les 92 premiers éléments du tableau périodique des éléments.

Le métal pur ayant la plus forte conductivité est l’argent : 63 MS/m (million de siemens par mètre), suivi de peu par le cuivre (59,6 MS/s). L’or arrive sur la 3e marche du podium avec une conductivité de seulement 41,1 MS/m, suivi de peu par l’aluminium avec une valeur de 37,7 MS/m.

Un tableau assez complet est disponible sur Wikipedia version anglaise, la version française étant assez pauvre sur le sujet. Néanmoins, même si la version française était plus fournie, on peut douter que les complotistes et autres affirmateurs de théories invraisemblables diraient des choses moins farfelues qu’ils ne le font.

Pyramides couvertes d'or transmettant des éclairs par leurs antennes
Cette illustration montrant des pyramides couvertes d’or et échangeant des éclairs par leurs antennes n’est pas une photo prise il y a 50 000 ans, mais une image créée par une intelligence artificielle (Bing)

La fausse prise en compte de l’inflation pour les impôts

La déclaration des revenus démarre. À cette occasion, les médias sont nombreux à diffuser un article sur ce sujet, et à mettre l’accent sur l’inflation. Notamment, le relèvement des tranches d’imposition de 5,4% ferait littéralement gagner de l’argent. Avec un exemple à l’appui : un contribuable touchant 2500 euros par mois, économiserait 328 euros d’impôt cette année.

Néanmoins, ces économies d’impôts ne serait valables que dans le cas défavorable d’une stagnation des revenus, ce qui en période d’inflation correspond à une vraie perte de pouvoir d’achat, d’autant plus que l’inflation demeure élevée.

Il serait donc intéressant de savoir ce qui arrive concernant les impôts au cas où les revenus suivraient l’inflation (disons 5,4%). Est-ce que les impôts restent stables grâce/malgré la hausse des tranches d’imposition à hauteur de l’inflation ?

Faisons un minuscule programme en C# pour étudier les impacts :

Ce programme très simple permet de calculer pour tous les revenus entre 15 000 et 100 000 euros par tranche de 1000 euros le montant des impôts avec les anciennes tranches d’imposition, puis le montant des impôts avec les nouvelles tranches d’imposition, et enfin la différence entre ces 2 valeurs. On ne prend en compte que le cas d’un célibataire (quotient familial=1), n’ayant aucun autre revenu, et en ne choisissant pas les frais réels (donc en optant pour la déduction forfaitaire de 10%). Enfin, on ne tient pas compte des décotes qui ne s’appliquent que dans un nombre limité de cas.

Le programme calcule effectivement que pour des revenus entre 31 000 euros et 82 000 euros, le montant de l’impôt diminue de 329 euros (61 euros en moins pour un revenu juste en-dessous de 30 000 euros et 771 euros en moins pour un revenu un peu au-dessus de 88 000 euros).

Mais tous ces chiffres ne sont valables qu’à revenu constant. Que se passe-t-il si les revenus augment de 5,4% ? Relançons le programme en modifiant la constante 1,000 par 1,054 :

Dans tous les cas, le montant à payer est supérieur.

Ainsi, la revalorisation des tranches d’imposition au niveau de l’inflation ne garantit en rien une stabilité de l’impôt pour des revenus progressant selon l’inflation. Les contribuables sont perdants. Et étonnamment, aucun journaliste n’a pensé à vérifier ce cas.

Image générée par Bing

AVX-512, la confusion

Le jeu d’instructions AVX-512 va fêter ses 10 ans cette année. Toutefois, il existe une immense fragmentation dans ce jeu d’instructions puisqu’il existe de nombreuses évolutions telles que F, CD, VL, DQ, BW, IFMA, VBMI, VBMI2, VPOPCNTDQ, BITALG, VNNI, VPCLMULQDQ, GFNI, qui sont supportées par un petit nombre de processeurs.

Ce jeu d’instructions AVX-512 succède au jeu d’instruction AVX2 déjà ardu à implémenter. Même les précédents jeux d’instructions SSE et AVX ne sont pas simples à appréhender comme on peut le voir sur ce tutoriel « SSE & AVX vectorization ».

De plus, ces jeux d’instructions occupent une place non négligeable dans les processeurs modernes, ainsi qu’une complexité là aussi importante. Avec tous ces inconvénients, les développeurs de logiciels peuvent être excédés et préfèreraient à la place davantage de cœurs pour distribuer la charge.

Alors que les processeurs grand public chez AMD et Intel commençaient à inclure tout ou partie des jeux d’instruction AVX-512, Intel a finalement fait machine arrière et supprime maintenant le support de l’AVX-512 dans ses derniers processeurs grand public, la déclinaison Alder Lake. Il faut dire que les processeurs Intel supportent maintenant 2 types de cœurs : les performants et par opposition les « non performants » qui excluaient de fait l’AVX-512. Quant-à AMD, la dernière génération Zen 4 continue d’avoir un support de l’AVX-512. Reste à voir si ce support se maintiendra avec les générations futures.

Coup de théâtre : Intel vient de publier en open source son code source permettant un tri rapide à l’aide du jeu d’instructions AVX-512, ce tri rapide étant basé sur l’algorithme de tri bitonic. Cet algorithme de tri n’est pas le plus efficace puisque qu’il est en O(n(log(n))²). Mais pour certains cas particuliers, grâce à l’AVX-512, il permet de paralléliser une partie de travail et au final peut être plus rapide que les meilleurs algorithmes de tri. L’abandon de l’AVX-512 est donc malvenu pour ce cas particulier.

Enfin, on peut se demander si l’AVX-1024 verra le jour dans ces conditions.

ChatGPT et les injections SQL du OWASP Benchmark

Peut-on confier à ChatGPT l’analyse sécurité d’une application ? Notamment, ChatGPT peut-il détecter efficacement des injections SQL par exemple dans du code java ?

Pour cela, testons le en utilisant le célèbre OWASP Benchmark (https://github.com/OWASP-Benchmark/BenchmarkJava) qui a l’avantage de fournir des exemples d’injection SQL, avec en prime une mention s’il existe un problème ou pas pour chaque cas de test.

Essayons d’abord le premier cas de test de type SQL injection (CWE-89). Le code source est en ligne : https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00008.java. Le fichier XML associé (https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00008.xml) mentionne bien qu’il existe une injection SQL dedans.

Posons la question à ChatGPT : Is there a SQL injection in the following java code: et en fournissant le code source complet.
La réponse arrive instantanément, et est correcte :

Réponse de ChatGPT

The code you provided is vulnerable to SQL injection. The variable « param » is being obtained from the request header « BenchmarkTest00008 » and is being appended to a SQL query without proper validation or escaping. An attacker could manipulate the value of this header to include malicious SQL code, potentially allowing them to access or modify sensitive data in the database.

Par ailleurs ChatGPT fournit en plus des conseils pertinents :
It is recommended that you use prepared statements with parameterized queries, or use an ORM framework that will handle escaping data for you, to protect against SQL injection.

Essayons maintenant un cas de test de type SQL injection (CWE-89) bien plus subtil. Le code source est en ligne : https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00104.java. Le fichier XML associé (https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest00104.xml) mentionne qu’il n’existe pas d’injection SQL dedans. En raison bien sûr de la condition complexe dans le « if » de la ligne 69.

Posons la même question à ChatGPT.

Voici la réponse :

Réponse de ChatGPT

ChatGPT voit quand même une injection SQL car il n’a pas vu l’astuce pour ce cas complexe. Il n’obtiendra donc pas 100% au OWASP Benchmark. Seuls quelques rares outils spécialisés à base d’analyse dynamique de code sont capables de réussir ce genre de test difficile.

Page 1 of 3

Fièrement propulsé par WordPress & Thème par Anders Norén