Une petite rétrospective d'Intel.

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. »

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.

Offrir un support logiciel à long terme des smartphones sous Android, ce n'est pas forcément si simple, y compris pour les fabricants eux-mêmes !

Témoignage et explications d'Agnès Crepet (responsable de l'équipe informatique et de la longévité logicielle chez Fairphone) dans l'émission "Libre à vous !" (à partir de 27:01).

Pour résumer :
- Les fabricants de puces doivent continuer de fournir les pilotes dans le temps ;
- L'intégration des services de Google implique une phase de certification très chronophage et rigoureuse. Validation qui doit être refaite pour chaque version (majeure ?) de l'OS.

(Si vous avez le temps, n'hésitez surtout pas à écouter l'intégralité du sujet "Téléphonie mobile et libertés" !)

Un guide essentiel pour tout comprendre des nombreux sigles agrémentant les cartes (micro)SD !

Dans l'article cité en source : « The ASUS UEFI firmware exposes an ACPI table to Windows 10, called "WPBT" or "Windows Platform Binary Table". WPBT is used in the pre-built OEM industry (...) Put simply, it is a script that makes Windows copy data from the BIOS to the System32 folder on the machine and execute it during Windows startup - every single time the system is booted. »

Donc Microsoft offre, à n'importe quel fabricant de CM/UEFI, un moyen officiel et documenté pour installer silencieusement et durablement des binaires dans Windows ? Le tout avant le lancement de n'importe quel autre programme et avec les droits administrateur.

C'est à la fois impressionnant (techniquement parlant) et horrifiant !

Maintenant, y a-t-il un moyen de désactiver ce comportement via une GPO, par exemple ? 🤔

Un bon résumé des nouveautés des GeForce RTX.