C'est vraiment une situation ubuesque en ce moment avec tout ce qu'il se passe, y compris dans le monde du matériel informatique...

Ou comment acheter de vieux graveurs de portables reconditionnés et vendus comme des neufs, avec parfois des problèmes de fiabilité à la clé.

"Entre TDP d'une puce et puissance réellement consommée, tout un monde existe. Pourquoi ? Réponse avec le comptoir."

Et pour creuser davantage : https://www.anandtech.com/show/13544/why-intel-processors-draw-more-power-than-expected-tdp-turbo

Le biomimétisme a parfois des inspirations étonnantes.

Je m'étais toujours demandé s'il existait des serveurs sous MacOS, et la réponse est affirmative. Voici les premiers d'entre eux.

CPUID, non pas le développeur de CPU-Z, mais l'instruction permettant de récupérer le nom du CPU. Il ne faut pas s'y fier aveuglément, car les informations retournées peuvent être modifiées à la volée.

Une petite rétrospective d'Intel.

Jusqu'en USB 3.0, les choses étaient encore simples à saisir, puis est venu l'USB 3.1 et la nomenclature en a pris un coup :

" With USB 3.1 the bandwidth doubled to 10 Gbit/s. But USB-IF called it "USB 3.1 Gen 2" with the "old" USB 3.0 to be refereed to as "USB 3.1 Gen1". They did it again in 2017 with what people would have liked to be "USB 3.2". We got 20 Gbit/s except it was to be called "USB 3.2 Gen 2x2". Accordingly "USB 3.1 Gen 2" became "USB 3.2 Gen 2x1" and "USB 3.1 Gen 1" was renamed "USB 3.2 Gen 1x1"."

Sans compter la possibilité de transmettre un signal Display Port, le Power Delivery (USB-PD), etc.

Voir aussi la cheatsheet que l'auteur a publié : https://fabiensanglard.net/usbcheat/index.html

Il faut toujours se méfier des discours marketing.

En résumé, la RTX 5070 est loin d'une RTX 4090 en puissance brute. Elle peut seulement espérer faire jeu égal en recourant à des artifices tels DLSS 4 avec MFG (multi-frame generation).

« En tout premier lieu, ces fameuses nouvelles fonctionnalités visuelles qui nous faisaient tant rêver quatre ans plus tôt s'avèrent lourdes, très lourdes sur les performances. Certes, il fallait s'y attendre – et puis, peut-on reprocher à une technologie graphique d'être lourde si son impact visuel est à la hauteur ? Oui, on le peut, quand elle offre trop peu de flexibilité. Lumen en est justement un exemple. Son idée fondatrice, très schématiquement, est de normaliser l'éclairage indirect en ray tracing, mais pas nécessairement sous forme de ray tracing avec accélération matérielle comme on l'entend habituellement : Lumen existe aussi (et surtout pourrait-on dire) dans une version « logicielle », capable de tourner sur de simples shaders. Cette version doit évidemment être privilégiée par les développeurs, car elle assure la compatibilité avec tous les GPU existant sur le marché ; mais elle n'est pas optimale sur les GPU équipés pour faire de l'accélération RT correcte – pas seulement les RTX de Nvidia, mais aussi les Intel Arc, et les Radeon les plus musclées. Cependant, la version matérielle de Lumen demande une implémentation spécifique et aux développeurs de rebâtir de larges portions de leur système d'éclairage. On comprend que beaucoup d'entre eux préfèrent s'en dispenser. »

Un « retour d'expérience très contrasté ».

J'ai déjà partagé un article de ce blog récemment, et même s'il y a encore peu de contenu, c'est dur de ne pas tout partager, tant c'est qualitatif, bien écrit, captivant.

Ici, il est question de la sécurité de Linux (je sais, on touche à un sujet quasi-religieux).

Et Linux traîne malheureusement quand même pas mal de casseroles en la matière, depuis des années...

Pour le citer : "un code ouvert ne remplace pas une architecture robuste (Zero Trust). Il faut regarder au-delà des conceptions idéologiques !"

Dans ses articles, l'auteur met souvent en lumière les différences des modèles de sécurité des OS "desktop" (qu'il préfère appeler "traditionnels") et les OS "mobiles" (dits "modernes").

Contrairement à ce qu'on pourrait penser (moi le premier !), AOSP (la base open-source d'Android) a un modèle de sécurité très robuste, avec de nombreux mécanismes de protection en place (verified boot, sandboxing strict des applications, chiffrement, privilèges restreints, CFI, ...). Si vous y couplez un hardware bien conçu et qui prend ces considérations en ligne en compte, en proposant par exemple une enclave sécurisée moderne (comme les Pixel), alors vous avez probablement l'un des OS les plus sécurisés (grand public) à l'heure actuelle !

Les plus gros problèmes des distributions AOSP (autrement dit, des ROMS Android) sont l'omniprésence des services de Google et des mécanismes de protection activées ou implémentées au bon vouloir du fabricant/développeur... Cela vaut aussi pour le matériel.

Dans les faits, on se retrouve alors quasi-exclusivement avec des Android peu sécurisés, bavards et trop rapidement abandonnés.

Et n'allez pas croire que les ROM alternatives, customs (LineageOS, /e/ et consoeurs), sont forcément mieux loties : https://wonderfall.space/modele-securite-mobile/ (à lire absolument)

Elles sont souvent "très négligentes" au sujet du modèle de sécurité d'AOSP, car "se contentent souvent de "fonctionner" à tout prix plutôt que d'être conservatrices du modèle de sécurité."

Sans oublier qu'une ROM custom à jour ne signifie pas forcément qu'elle bénéficie de toutes les mises à jour de sécurité pour l'appareil. Oui, c'est trompeur...

Selon l'auteur, le combo idéal est un Pixel (pour la partie hardware) + GrapheneOS (pour la partie software, avec ou sans les services de Google), dont j'ai partagé l'article de présentation et d'explications il y a peu.

Moi qui pensais avoir tout vu avec les unités de mesure... 😓

En photo numérique, il y a différentes tailles de capteurs. En gros, plus il est grand, mieux c'est (plus de lumière "capturée").

Dans les smartphones, la taille est souvent exprimée en fractions de pouces (ex. 1/1.7", 1/1.52").

Je possède un appareil qui comporte un capteur de 1 pouce. Difficile de se le représenter, mais un capteur 1" mesure concrètement 13.2 mm x 8.8 mm. Soit une diagonale de 15.9 mm (merci Pythagore). Hum, quelque chose ne va pas : 1", c'est 25.4 mm 🤔

WTF ?

La taille des capteurs n'est donc pas mesurée en diagonale comme celle des écrans ?

"(...) contrairement aux écrans, la dénomination des capteurs ne donne pas la diagonale réelle du capteur (comme c’est parfois écrit à tort sur internet) ! Inutile donc de faire le calcul de la diagonale à partir de l’appellation du capteur en pouces car le résultat obtenu sera loin de la diagonale réelle (...)"

Mais alors ça représente quoi ? (Spoiler : ce n'est pas non plus la surface !)

En réalité, c'est bien la la diagonale du capteur, mais mesurée en "équivalent tube cathodique", pour ainsi dire :

"L’explication est historique : les industriels mesuraient la taille des capteurs d’images en fonction du diamètre des tubes cathodiques (la technologie qui était utilisée dans les anciennes et volumineuses télévisions) : un tube cathodique de 1 pouce de diamètre permettait de créer une image d’environ 15,9 mm de diagonale (notre fameuse diagonale de capteur 1’’)."

Source : https://www.luzphotos.com/materiel/apn/taille-capteur-apn-comparatif

Autrement dit, dans les capteurs d'images : 1" = ~16 mm 🤪