Ce que je crois comprendre en lisant les commentaires sur Phoronix, c'est que pour l'instant Firefox fonctionne de la sorte : - Tu as un écran 1920x1080 réglé en 125% (soit 1536x864) - Firefox ne sait actuellement pas faire du 125%, il fabrique donc un rendu 200% en 3840x2160 - Et donne le résultat à Wayland qui fait l'ajustement 3840x2160 => 1536x864
Ça fait beaucoup de CPU pour rien.
C'est pourquoi le terme important est que désormais le support est "natif", c'est à dire que dans le cas ci-dessus Firefox, à partir de 146, va directement fabriquer l'affichage en 1536x864 et Wayland n'aura plus de calcul de "scaling" à faire pour l'afficher à l'écran.
Il doit y avoir un truc qui m'échappe puisque sur mon écran principal je suis en 150% depuis 2 ans avec gnome/wayland et firefox est correctement mis à l'échelle, comme les autres d'ailleurs.
J'espère en tout cas que ca n'entachera pas la qualité du service tant amazon que aws parce que sur ce plan force est de constater que l'entreprise est excellente.
"selon lequel le couple Macron aurait payé pour qu’une petite équipe du GIGN l'assassine. Ce faisant, elle reprend une thèse complotiste préexistante, selon laquelle le couple Macron aurait constitué une « armée de tueurs à gages » de « 40 à 50 assassins professionnels » dédiés à supprimer leurs opposants politiques."
J'apprends donc que ni le gign ni les tueurs à gages ne sont efficaces.
Ce n'est pas un SPOF que d'avoir un organisme unique qui pilote.
Un SPOF, c'est un machin qui s'il tombe en panne entraîne l'arrêt du système qui dépend de ce machin.
Les serveurs racines ont été conçus et définis pour qu'il en reste toujours en fonctionnement. UNE panne complète est impossible a priori.
Effectivement avec cette définition technique les DNS racines n'entrent pas dedans, d'autant qu'il y a un certain nombre de serveurs situés derrière 1 IP anycast/DNS racine
Analyser les vulnérabilités, c'est bien, mais ça prend plus de temps que d'écrire un commentaire sur Next. Donc, non, la racine du DNS n'est pas un SPOF, il y a onze organisations (ou douze, selon comment on compte) qui gèrent un serveur racine et, en prime, chacun peut avoir le sien https://www.bortzmeyer.org/8806.html (à la dernière réunion IETF à Montréal, une des discussions était de savoir s'il fallait généraliser cette pratique).
Salut Stéphane, je sais bien et mon commentaire était déjà assez long pour ne pas en écrire des tonnes (on est obligé de simplifier dans ce format), en revanche 2 choses : 1. oui chacun peut avoir le sien, d'où le : "mais personne n'a envie de redévelopper ses propres DNS de référence" 2. il y a certes 11 organisations mais elles sont administrativement coordonnées par l'ICANN, qui elle-même rend ses décisions en fonction de son conseil d'administration dont les membres sont issus de gros acteurs/référents techniques. On peut retourner le problème dans tous les sens mais il s'agit bien d'un SPOF en tant que tel. Pas un SPOF fragile type un état dans son coin (genre les US comme c'était le cas avant) ou un illuminé dans son coin, mais un SPOF quand même qui tient à la nature même d'avoir un accord mondial sur les ndd et leurs attributions
Oui mais l'un n'empêche pas l'autre, Internet est par conception décentralisé mais personne n'a envie de redévelopper ses propres DNS de référence (donc SPOF DNS racine), personne n'a envie de devenir une autorité de certification (donc SPOF d'une poignée d'entre elles), personne n'a envie de devenir un cloud provider (donc SPOF d'un poignée aussi), tout le monde veut du haut débit de contenu (donc SPOF de quelques acteurs CDN), etc.
A la limite on pourrait se dire mais pourquoi si peu d'acteurs pour chaque domaine ? La réponse est qu'en fait il y en a souvent plus que ce qu'on pense mais les plus intéressants commercialement sont peu nombreux et donc tous les DSI s'engouffrent dedans.
PS : et à ce rythme là on peut aller loin, quand on pense aux nombres de lib critiques utilisées partout qui sont à peine maintenues (xkcd 2347) ça donne le vertige
tu peux avoir tout l'argent possible il faut que les voisins soient d'accord pour te laisser t'armer
La seconde guerre mondiale a été déclenchée par un pays qui n'avait pas le droit de se réarmer, avec un énervé au pouvoir, sans que ses voisins n'interviennent. Donc je ne serais pas si sûr de ce que tu avances. Surtout s'il fait ça aux USA : je rappelle que les armes y sont une quasi-religion et que la corruption y bat son plein actuellement.
En ce qui concerne la seconde guerre mondiale on rappelle que la France et l angleterre n'ont volontairement pas intervenu en toute connaissance de cause. Pour les USA, que je connais bien, ce que tu dis est juste faux. Les armes ne sont absolument pas une religion, la plupart des états ont des lois assez dures à ce sujet et d'autres part le droit à s armer ne concerne que les armes et munitions légères, tout le reste (grenade, mitrailleuse, véhicules etc.) Est classé en tant que "destructive device" et est extrement compliqué à obtenir, interdit dans la plupart des états, sujet à autorisation administrative et contrôle annuel en plus d'un coût de procédure prohibitif. Au passage le non-respect des procédures ou le dépassement de délai t'envoie en prison quasiment automatiquement.
Pas besoin de 1000 milliards, des chefs de milice il y en a des centaines sur terre sur tous les continents. Par exemple, en Russie il n y a pas une seule armée mais plusieurs armées gérées par différents gouverneurs locaux car le pays est une ffédération.
Si tu parles d'une armee au sens moderne avec un armement technique, non, tu peux avoir tout l'argent possible il faut que les voisins soient d'accord pour te laisser t'armer sinon ils risquent de te rendre visite assez vite.
Il a fondu un plomb mais son fric il ne pourra rien en faire de particulier.
Sauf que je ne sais si c'est l'implémentation qui est nulle, mais 7z est extrêmement efficace, bien plus que zip.
L'implémentation de référence pkzip fournie par pkware (actuellement dispo pour windows et qq mainframes et historiquement qq unix mais jamais pour linux étonnament) est excellente, on peut même valider par certificats des fichiers ou l'archive entière. De plus la spec est ouverte à contribution et pkware prend toujours en compte les demandes. L'implémentation connue sous Linux, infozip, n'est plus maintenue depuis 15 ans mais les distribs continuent de patcher les CVE tant le programme est indispensable. On est au stade où l'implémentation 7zip (pour zip donc, je ne parle pas du format 7z) est meilleure que celle d'infozip, ce qui est quand même sacrément paradoxal.
Le format zip est vraiment excellent et excellemment bien pensé pour l'époque et à ce titre le format 7z n'a pas apporté grand chose par contre l'implémentation 7zip si (entre autres : support du multithread, ce qui est INDISPENSABLE aujourd'hui). De plus la spec est très bien rédigée, ça fait des années que je veux y redévelopper une implémentation from scratch pour linux mais c'est un taf à plein temps et personne ne me paierai pour les semaines à y passer malheureusement.
Imagine que tu veuilles sauvegarder un site. Tu le copies en zip. Ben avec Windows et powershell, tu es limité en 32bits, donc pas de fichier de plus de 4Go. Donc ... tu installes un outil pilotable en ligne de commande, comme 7z. Par ailleurs, 7z est affreusement bon en dédup, donc tu peux pousser dans le même 7z tous les fichiers jour par jour, c'est comme de l'incrémental.
Idem en zip, la spec l'a prévu depuis le départ à l'époque pour sauvegarder en incremental via des disquettes.
Tim Berners-Lee, chercheur britannique, a inventé le Web au CERN en 1989. À l'origine, le projet, baptisé « World Wide Web », a été conçu et développé pour que des scientifiques travaillant dans des universités et instituts du monde entier puissent s'échanger des informations instantanément.
https://home.cern/fr/science/computing/birth-web
Non, mais quand même, il y a la notion de partage. Les choses sont souvent plus nuancées qu'un court "oui" ou "non" .....
En effet j'avais la flemme de développer, mais entre un lan (en 1989 internet est une sorte de lan de qq université, centre de recherches et boite technos US) pour partager des infos comme n'importe quel intranet moderne et "partager la richesse du monde , à tout le monde" il y a un gouffre.
Entre le "flux" et le fichier vidéo final, comme le proposent ces sites, il y a un monde. Les vidéos streamées sont découpées en piste (vidéo, audio, metadata divers) elles-mêmes découpées en très courts morceaux dit "chunks". Le travail du lecteur est d'une part de réassembler l'ensemble et d'autre part de synchroniser les pistes. Ces chunks peuvent être gardés en mémoire ou non, selon l'implémentation du lecteur.
Je pense que tu surestimes Microsoft, amha eux-mêmes ne savent pas quelle direction suivre étant donné que leur développement logiciel ces 10 dernières années (Windows, suite Office, Teams & cie) ressemble bien plus à un agglomérat de micro-changements résultant en une bouillie générale qu'à une direction globale assumée, parfois changeante mais cohérente, comme on peut le voir chez Apple. Je précise que je n'ai jamais rien acheté de chez Apple. Ça commence à faire pas mal d'années qu'on entend que Windows ne sera plus qu'un terminal utilisant le cloud MS basé sur un abonnement or je constate que nous n'y sommes pas du tout.
Je pense pas que le problème des gens soit que Snap soit de la merde. Peut être que je parle juste pour moi mais ce qui gonfle c’est que toutes les autres distributions utilisent Flatpak.
Le but des applications conteneurisées c’était d’avoir enfin une sorte de format universel pour distribuer des logiciels sous Linux qui laisse l’éditeur gérer l’empaquetage en échange d’une promesse d’avoir à le faire une seule fois pour que ça fonctionne de partout. Dans ce contexte c’est débile d’avoir deux solutions qui à priori sur le plan technique se valent plus ou moins.
Surtout qu’au final même si Snap est dispo sur toutes les distribs, il n’a pas trop d’intérêt par rapport à Flatpak et se retrouve surtout relégué à Ubuntu.
Donc c’est vraiment pas un problème technique, Snap n’est même pas une mauvaise techno et a même quelques avantages, c’est plutôt que c’est un peu con que Canonical ait conçu un système de packaging sensément universel … mais tout seuls dans leur coin.
Si, snapcraft propose plus d'interfaces et est le seul parmi flatpak et appimage à permettre de tourner en headless. À savoir également que snapcraft est correctement maintenu tandis que flatpak l’est à peine et surtout n'évolue plus.
"Actuellement, quand un ordinateur sous Ubuntu démarre, ce n’est pas le système qui se charge en premier. La première étape est un mini-système qui se charge en mémoire vive. Nommé initramfs, il contient le strict nécessaire pour trouver le stockage, déchiffrer les disques si besoin et passer le relai au système de fichiers du « vrai » système."
Ce n'est pas vraiment ça même si c'est la vision la plus propagée. Pour le commun des gens sur x86, Grub charge le noyau et l'initramfs en ram, mais l'initramfs n'est qu'une archive représentant un fs contenant effectivement le strict minimum requis (qq scripts, modules et confs + un init qui sert de point d'entrée aux scripts) pour pouvoir démarrer le système. Grub renseigne ensuite la zero page puis passe la main au noyau qui va lire la zero page, déduire qu'il y a une archive en mémoire, la décompresser, exécuter l'init s'y trouvant pour ensuite pouvoir monter le vrai root dans une partition temporaire, switcher et flusher le fs de l'initramfs qui ne sert plus à rien. Raison pour laquelle, par exemple, la gestion des partitions chiffrées est différente selon qu'il s'agit de root (inclus dans initramfs) ou autre (généré à la volée par les generator systemd cryptsetup), ce qui peut-être déroutant lors d'un debug. Mais dans tous les cas, le noyau prend bien le relai de grub dès le départ, il n'y a pas d'intermédiaire.
Après des façons de booter il y en a 150 possibles, on peut booter sans initramfs comme c'est le cas sur grossomodo tout ce qui n'est pas x86, d'ailleurs sur x86 aussi mais ça peut vite devenir compliqué (ordre de périphériques non garantis, pas de chiffrement, raid logiciel etc.), par multiboot (qui n'a jamais pris à part sur xen), par shim pour signer grub, etc.
Aussi GStreamer qui est très présent dans l'embarqué.
C'est ce que j'allais dire, j'ai l'impression de voir régulièrement des dépendances aux libs gstreamer. Après je ne suis pas sûr qu'ils soient comparables.
Alors à 4Go/s sur un si petit format je serai bien curieux de connaître le temps d'usage avant throttle quand on sait qu'aujourd'hui avec des SSD à 7-10Go/s M2 2280 et un bon radiateur on tient une bonne minute avant de chuter.
Dans une vie antérieure, j'ai bossé dans un coin où certains des échanges d'emails ne pouvait se faire qu'avec PGP.
Et environ tout les 3 mois, nous devions renouveler nos clés PGP et détruire les anciennes. Est-ce que ce genre de pratique peut-être considérée comme un ersatz de confidentialité persistante ?
Si tu parles des sous-clés de chiffrement oui effectivement on peut le considérer ainsi.
Bien que PGP ne soit pas vraiment fait pour de l'échange synchrone, plutôt asynchrone, j'avoue que je me demande comment une attaque MITM permettrait de voler la clé RSA permettant de déchiffrer la clé AES256 interne.
PGP chiffre la donnée avec une clé AES256 (par défaut) générée aléatoirement, et c'est elle qui est chiffrée avec la partie publique de la clé RSA. Le déchiffrement via la clé privée sert principalement à récupérer la valeur de la AES256 pour pouvoir lire la donnée réelle (raison pour laquelle une clé RSA 4096 en PGP a peu de sens par rapport à une longueur de 2048). J'omet volontairement la partie signature.
Pour compromette un échange chiffré en PGP il faut donc avoir volé la clé privée du destinataire et son éventuelle passphrase. Ce qui me laisse à croire que ça se fait surtout en cas de compromission du client récepteur. Je ne suis pas expert en sécu IT, mais ici on est plus dans un schéma d'attaque du côté du client qu'un MITM qui arrive à récupérer des infos lors du transport pouvant compromettre la confidentialité immédiate de l'échange (comme le cas des proxy qui déchiffrent le trafic HTTPS en filant leur propre root CA au client). À quoi ressemblerait le schéma d'attaque MITM pour un échange chiffré via PGP ? Ça m'intéresse pour la culture :)
Pour la notion de persistance de la confidentialité, oui, en effet, une fois la clé privée obtenue, tout ce qui aura été chiffré avec sa partie publique est compromis.
Et pourtant c'est bien le cas, la confidentialité persistente n'a qu'un seul usage : protéger les conversations passées en cas de compromission d'une des clés privées (ex : DH en tls et ssh, signal/whatsapp, wireguard etc.). Il faut imaginer que tu peux te trouver durablement dans un environnement où le réseau est écouté passivement avec un tap (réseau public, d'entreprise, enregistrement par un gouvernement etc.) ce que j'inclus dans la notion mitm mais effectivement ça ne peut pas protéger contre un mitm actif (proxy transparent avec réécriture tls).
Donc en résumé en PGP si ton terminal est saisi avec ta clé privée tous les échanges passés interceptés sont déchiffrables. En DH, whatsapp/signal, wireguard et sûrement d'autres, même avec la clé privée ce ne serait pas possible.
Corrige-moi si je me trompe. La confidentialité persistance provient du fait que lors de l'établissement d'une session de communication (TLS, Signal...) une paire de clé de session entre également en jeu afin de garantir la confidentialité de l'échange même si les clés d'une des deux parties sont compromises.
Comme PGP n'inclut pas cette notion de session (car indépendant du canal de communication), cette confidentialité persistance disparaît, c'est bien ça ?
C'est ça, l'objectif est de protéger la confidentialité des échanges passés en cas de compromission des clés de session. En pgp si la clé de chiffrement est compromise tous les échanges effectués jusqu'à lors seront compromis. Tout cela dans un contexte mitm évidemment.
Ca nous pend au nez comment ? Par qui ? Je veux bien que la France ne soit pas toute blanche, mais là, on parle de la Russie qui impose une app pour espionner sans même s'en cacher. On n'en est pas là en France, encore moins en Europe... Il ne faut pas exagérer (sauf si je me trompe et dans ce cas, n'hésite pas à partager tes sources, je suis vraiment curieux de voir cela).
Non après on peut quand même se rappeler de SSF (la version française castrée de SSH) qui avait pour but de rendre toute communication chiffrée facilement lisible jusqu'en 2001 où le législateur a abandonné cette connerie.
PGP est complètement obsolète pour protéger les communications puisque il ne propose pas la confidentialité persistante, raison pour laquelle PGP est essentiellement utilisé pour signer des documents de nos jours (un peu utilisé également pour signer des commits ou des clés de d'autres utilisateurs). Il vaut mieux utiliser Signal ou tout équivalent pour ce genre de chose.
"Chacun doit comprendre comment ça fonctionne. Sans ca, nous serons toujours à la merci d'autrui en utilisant un produit "tout en un" et ses limites inhérente" Bon alors si chacun doit comprendre tu élimines à peu près tout le marché de la communication numérique, et je ne vois pas comment ne pas utiliser un produit sans être "à la merci d'autrui" à moins que chacun développe sa propre implémentation.
"des messages postés dans une blockchain" de quoi parles-tu ?
En ce qui concerne PGP pour le RCS/MMS j'aimerais bien que tu nous précises quelle implémentation le permet parce que je n'en ai jamais entendu parler (et c'est accessoirement complètement con comme approche).
Bref, tout cela nous montre bien qu'il vaut mieux arrêter le hakik.
On est bien chez mozilla : de la feature inutile qui sera abandonnée dans quelques temps au lieu de travailler sur les problèmes de coeur qui durent depuis longtemps comme le cache dns ou les perfs sur android
Et justement il n'en a pas, ce n'est que de la communication. En revanche dans les fameuses démocraties dont tu parles, à commencer par la france, il y a un cadre juridique pour nationaliser comme ça une entreprise et par ailleurs des entreprises sur lesquelles l'état essaie de prendre la main depuis des années comme par exemple dassault.
Ce n'est pas faux, mais dans ce cas il faut expliquer pourquoi autant de boites basculent vers K8s et la kyrielle de packages du CNCF dont le niveau d'intégration est bien plus faible que du côté des projets OpenStack.
Les boites basculent sur K8s à cause des microservices.
Les microservices ont vendu du rêve en simplifiant le développement. Dans les faits, on a juste déplacé la complexité du développement vers la complexité du déploiement/configuration. K8s est le mal nécessaire pour gérer cette nouvelle complexité.
Les micro-services n'ont rien vendu du tout, ce ne sont pas des humains. Les architectures micro-services sont inhérentes aux infras élastiques (aka cloud) et la combinaison des deux permet d'adapter finement la consommation de ressources en fonction de la charge, c'est tout. Personne n'a jamais dit que c'était particulièrement simple à architecturer.
Maintenant en ce qui concerne k8s, il faut faire le distingo entre le besoin réel du client et la branlette k8s que l'on retrouve sur les architectures. Il se trouve que je suis archi cloud publique (essentiellement aws, et on parle d'archi de boites du cac) et je passe mon temps à devoir re-concevoir des projets qui peuvent tourner très simplement sur ecs. Sauf que soit le commerce a décidé de vendre un truc de fou à un client qui n'y connaît rien, soit le client ne souhaite pas entendre parler d'autre chose parce qu'il a trop investi et enfin il y a les rares cas où k8s est difficilement remplaçable.
Pour le SB c'est juste faux, j'en ai un peu marre d'entendre cette histoire.
Les certificats db dépendent exclusivement des OEM/ODM qui intègrent les SDKs phoenix/ami/insyde et rien ne les empêche de mettre les certificats qu'ils veulent. La seule condition de MS pour que le PC soit certifié est d'avoir au moins le leur de présent + SB activé par défaut, MS n'a jamais interdit que d'autres clés soient présentes sauf que les OEM/ODM ne veulent pas se compliquer la vie avec X clés à gérer (au moins 1/distrib majeure) qui ne serviront qu'à quelques geeks (dont je fais parti) dans des marchés de niche.
Par ailleurs les OEM/ODM sont libres de laisser l'utilisateur gérer le PK (et donc les KEK et les certificats db/dbx) ou de le verrouiller. Par exemple j'ai le plein contrôle sur mon uefi Asus (CM de 2023) et Insyde (PC clevo de 2020).
Par ailleurs, MS signe même un mini bootloader (exécutable "shim" qui embarque la clé publique de la distrib X permettant ensuite de valider la signature de grub pour le charger) afin que les RH/Debian/Fedora/etc. soient autonomes et donc puissent assurer la chaîne SB. Bon ce n'est pas gracieux de la part de MS, ils le font pour ne pas se mettre à dos différents acteurs mais sur le plan technique, absolument rien n'empêche les OEM/ODM de gérer d'autres clés sans perdre la certification MS. C'est à eux qu'il faut s'adresser pas à MS.
L'open architecture & l'open source sont des philosophies DIY avant tout, avec des communautés, souvent même pas d'organisation, sans but lucratif.
Pas du tout, la majorité des dev open source sont des professionnels bossant pour des boites à but lucratif.
Voir par ex. https://lwn.net/Articles/1013892/ La majorité des dev kernel sont payés pour ça et travaillent pour de grosses boites, comme Intel justement.
L'open source s'est imposé même chez Microsoft parceque c'est beaucoup plus efficace que d'avoir à réinventer la roue à chaque fois, et donc que ça rapporte +.
Exactement, et quand on creuse plus loin sur les financements de tout un tas de projets open source (linux, debian, suite gnome, eff, freebsd, etc.) on se rend compte que les gros partenaires sont toujours un peu les mêmes noms (google, intel, etc.) sans compter les développements sous licence libre opérés par des boites privées type RH (network-manager, ansible, libvirt, systemd etc.).
J'ai toujours été surpris de voir à quel point les libristes (nb : j'en suis un) ne réalisent pas à quel point ce monde là repose sur le privé. Je suis très reconnaissant de tout ce qu'a fait la FSF, des contributeurs travaillant sur leur temps perso au noyau Linux etc. mais c'est loin d'être suffisant pour créer un environnement fonctionnel aux standards actuels.
Si c'est être obligé d'acheter un ensemble complet (recepteur, HP, sans compter le casque qui va bien si le sien n'est pas préèéquipé) pour, en mettant le son à fond, faire avec 300€ d'investissement dédié ce que font des intras BT à 30€ qu'on peut aussi utiliser pour autre chose, personnellement à part la volonté de se conformer aveuglément à une loi totalement conne je ne voit absolument aucun bon sens là dedans. Saut à vouloir utiliser la partie micro et les commandes pour téléphoner ce qui a moto est encore pus déconseillé qu'en voiture. C'est un exemple de plus d'une législation à 100% dans le contrat de moyen et 0% dans le contrat de résultat. J'ajouterais que tout ceci ajoute au poids du casque qui a toujours été à minimiser car sur certains chocs (ou une partie du haut du corps, genre épaule, freine voir bloque), le poids de casque+ tête qui va tirer sur les vertèbres aggrave notablement le risque de lésions neurologiques, à comparer à des intras qui font une différence de l'ordre de chevaux coupés ou non. Maintenant, chacun est libre de se conformer comme un mouton à des conneries qui n'apportent rien, au contraire.
Pour la raison que tu viens de donner : piloter le lecteur avec les commandes vocales. Perso se conformer j'en ai rien à cirer mais j'y vois les aspects pratiques. Pour le poids oui ça doit surement jouer m'enfin le poids du kit, en tout cas du mien (freecom 4+) et assez négligeable.
Et a moto aussi... faudrait des écouteurs intégrés au casque... sachant que le bruit généré par un casque impose quasiment le port de bouchons d'oreilles hors usage urbain, ce qui n'est pas interdit mais ne permet alors pas l'usage d'HP intégrés au casque, surtout quand on ouvre toutes les aérations en période chaude accentuant les bruits. Mais des écouteurs bluetooth assurant le rôle des bouchons et permettant d'entendre la navigation pré-programmée et les alertes radar de Camsan (je ne parle pas de coller la musique à fond, entendre, sans excès qui nique les oreilles, son environnement restant alors au niveau permis par les bouchons), bin interdit! Pour ma part, je continue donc à en employer et quand je vois qu'on va pouvoir profiter de la grande téloche des Mercos pour de la vision teams je dirais que si un flic me fais chier connement un jour il va avoir intérêt à en mettre, des bouchons... Il y a un moment ou il faut être un peu cohérent. Celui dont le temps coûte si cher qu'on veut qu'il bosse au volant, l'entreprise n'a qu'à lui payer un chauffeur. L'autre possibilité, c'est de remettre des limitations de vitesse qui permettent d'arriver plus tôt au lieu de les baisser jusqu'au ridicule... et au final, comme les journées ne feront jamais 48h, voir se développer les possibilités de faire autre chose au volant que conduire alors que l'attention est déjà un gros problème induit par les baisses de vitesse (homéostasie du risque toussa).
Heu la plupart des casques ont des emplacements HP et je te confirme que je roule quasiment tout le temps avec bouchons d'oreille + musique/gps dans les oreilles.
J'avais eu peur ces derniers jours de voir que mrmbeta n'était plus disponible mais c'était juste pour le passage en prod.
En tout cas c'est un outil excellent pour choisir un réseau selon son emplacement ou lieu de travail ou autre via la section "antennes et déploiements" qui indique tout ce qui est utile, il n'y a plus d'excuses désormais.
A part la gamme XCover 7 de Samsung qui permet de changer la batterie, il ne faut pas espérer beaucoup de modularité en IP68.
Et si vraiment c'est pour le travail en conditions difficiles, il faudrait plutôt un smartphone spécialisé donc non-modulable, genre les raretés à la Hammer Construction 2 5G qui est IP69. Il faudra s'attendre à des performances faiblardes par contre.
Sur les chantiers, quasiment personne n'a de téléphone spécialisé pour les raisons que tu viens d'évoquer : c'est + cher et moins performant, d'où la bénédiction du IP68 qui nous suffit (du moins dans le 2nd oeuvre) largement
Dans quels cas a-t-on besoin d'IP68 ? Vraie question, ayant eu un téléphone IP68, je faisait quand même tout pour éviter de le foutre sous la flotte. Avec succès. Et mon FP5 n'a jamais subi non plus de dommage lié à cette caractéristique.
pour ceux comme moi qui travaillent dans le batiment et donc poussière et parfois flotte, sans ip68 avec la poussière en 1 semaine tu flingues la caméra frontale et en quelques mois tu flingues HP, micro etc.
En général, faire des produits sans faire d'étude de marché, ça ne marche pas trop. Une bonne équipe marketing va faire des études de marché de qualité pour savoir comment satisfaire les attentes des clients potentiels.
Alors dans ce cas c'est pas plus mal de déléguer parce qu'on ne peut pas dire qu'intel brillait par la clareté de son offre et de ses produits, ça doit faire au moins 10 ans que leurs gammes et produits sont incompréhensibles avec des nomenclatures dont la définition change quasiment tous les ans
Alors, il y a un certain temps, j'aurais pu penser ça. Mais en fait, ce discours puant(1), depuis 2022, et surtout depuis la découverte de l'envers du régime Assad, merci, mais non merci.
(1) Je parle de ceux qui l'ont créé, parce qu'en général, c'est du psyops venant de ces pays, pour Assad, c'est clairement identifié; en France, il s'est notamment appuyé sur la nébuleuse catho intégriste.
La "nébuleuse catho intégriste" de france aurait appuyé Assad, euh tu as des sources si possible sérieuses à ce sujet ?
Non mais l'un n'empêche pas l'autre, il est évident que quand ils annoncent que la bombe sera prête demain c'est pour garder la face auprès de la population comme poutine avec son armement qui est supposément le meilleur de la terre mais pour autant ça ne les empêchent pas de faire de la r&d et d'avancer sur le sujet.
Les seuls qui connaissent précisément l'état des lieux de leurs capacités sont les agences de renseignements et évidemment nous n'en saurons jamais rien.
Pas certain que ce soit si simple sur le plan technique parce que pour "ré-ouvrir" les AS iraniens aux routes mondiales il faut des annonces BGP externes et internes et j'ai beaucoup de mal à envisager que ça ne se voit pas auprès de leurs différents opérateurs quand on sait le merdier que c'est de gérer ça correctement en temps normal, ou alors on pourrait imaginer qu'ils n'ouvrent que certains AS très ciblés (mais ça part du principe que les organisations cibles aient leurs propres AS ce qui est rarement le cas sauf si elles sont très grosses). Et tout cela en partant du principe qu'il n'y a pas de filtrage tiers par ailleurs.
LDLC particuliers a un bon service également mais qui hélas ne suffit pas à justifier l'écart de prix (j'avais noté +10/+20% quand même) surtout pour des composants dont les concurrents en face sont les grosses market place connues (cdiscount, amazon etc.) dont les prix sont plus bas.
978 commentaires
Le 10/12/2025 à 21h06
Modifié le 09/12/2025 à 20h31
Le 08/12/2025 à 20h25
Le 25/11/2025 à 14h07
Le 24/11/2025 à 17h35
politiques."
J'apprends donc que ni le gign ni les tueurs à gages ne sont efficaces.
Le 20/11/2025 à 08h06
Le 19/11/2025 à 18h34
1. oui chacun peut avoir le sien, d'où le : "mais personne n'a envie de redévelopper ses propres DNS de référence"
2. il y a certes 11 organisations mais elles sont administrativement coordonnées par l'ICANN, qui elle-même rend ses décisions en fonction de son conseil d'administration dont les membres sont issus de gros acteurs/référents techniques. On peut retourner le problème dans tous les sens mais il s'agit bien d'un SPOF en tant que tel. Pas un SPOF fragile type un état dans son coin (genre les US comme c'était le cas avant) ou un illuminé dans son coin, mais un SPOF quand même qui tient à la nature même d'avoir un accord mondial sur les ndd et leurs attributions
Modifié le 18/11/2025 à 15h13
A la limite on pourrait se dire mais pourquoi si peu d'acteurs pour chaque domaine ? La réponse est qu'en fait il y en a souvent plus que ce qu'on pense mais les plus intéressants commercialement sont peu nombreux et donc tous les DSI s'engouffrent dedans.
PS : et à ce rythme là on peut aller loin, quand on pense aux nombres de lib critiques utilisées partout qui sont à peine maintenues (xkcd 2347) ça donne le vertige
Le 24/10/2025 à 11h17
Pour les USA, que je connais bien, ce que tu dis est juste faux. Les armes ne sont absolument pas une religion, la plupart des états ont des lois assez dures à ce sujet et d'autres part le droit à s armer ne concerne que les armes et munitions légères, tout le reste (grenade, mitrailleuse, véhicules etc.) Est classé en tant que "destructive device" et est extrement compliqué à obtenir, interdit dans la plupart des états, sujet à autorisation administrative et contrôle annuel en plus d'un coût de procédure prohibitif. Au passage le non-respect des procédures ou le dépassement de délai t'envoie en prison quasiment automatiquement.
Le 24/10/2025 à 08h37
Si tu parles d'une armee au sens moderne avec un armement technique, non, tu peux avoir tout l'argent possible il faut que les voisins soient d'accord pour te laisser t'armer sinon ils risquent de te rendre visite assez vite.
Il a fondu un plomb mais son fric il ne pourra rien en faire de particulier.
Le 21/10/2025 à 21h46
L'implémentation connue sous Linux, infozip, n'est plus maintenue depuis 15 ans mais les distribs continuent de patcher les CVE tant le programme est indispensable.
On est au stade où l'implémentation 7zip (pour zip donc, je ne parle pas du format 7z) est meilleure que celle d'infozip, ce qui est quand même sacrément paradoxal.
Le format zip est vraiment excellent et excellemment bien pensé pour l'époque et à ce titre le format 7z n'a pas apporté grand chose par contre l'implémentation 7zip si (entre autres : support du multithread, ce qui est INDISPENSABLE aujourd'hui). De plus la spec est très bien rédigée, ça fait des années que je veux y redévelopper une implémentation from scratch pour linux mais c'est un taf à plein temps et personne ne me paierai pour les semaines à y passer malheureusement.
Le 20/10/2025 à 21h16
Le 18/10/2025 à 07h56
Le 17/10/2025 à 20h00
Entre le "flux" et le fichier vidéo final, comme le proposent ces sites, il y a un monde. Les vidéos streamées sont découpées en piste (vidéo, audio, metadata divers) elles-mêmes découpées en très courts morceaux dit "chunks". Le travail du lecteur est d'une part de réassembler l'ensemble et d'autre part de synchroniser les pistes.
Ces chunks peuvent être gardés en mémoire ou non, selon l'implémentation du lecteur.
Le 17/10/2025 à 13h20
Le 09/10/2025 à 14h44
Le 08/10/2025 à 10h50
Le 08/10/2025 à 10h27
Ça commence à faire pas mal d'années qu'on entend que Windows ne sera plus qu'un terminal utilisant le cloud MS basé sur un abonnement or je constate que nous n'y sommes pas du tout.
Le 20/09/2025 à 11h11
Le 12/09/2025 à 11h44
Ce n'est pas vraiment ça même si c'est la vision la plus propagée. Pour le commun des gens sur x86, Grub charge le noyau et l'initramfs en ram, mais l'initramfs n'est qu'une archive représentant un fs contenant effectivement le strict minimum requis (qq scripts, modules et confs + un init qui sert de point d'entrée aux scripts) pour pouvoir démarrer le système. Grub renseigne ensuite la zero page puis passe la main au noyau qui va lire la zero page, déduire qu'il y a une archive en mémoire, la décompresser, exécuter l'init s'y trouvant pour ensuite pouvoir monter le vrai root dans une partition temporaire, switcher et flusher le fs de l'initramfs qui ne sert plus à rien. Raison pour laquelle, par exemple, la gestion des partitions chiffrées est différente selon qu'il s'agit de root (inclus dans initramfs) ou autre (généré à la volée par les generator systemd cryptsetup), ce qui peut-être déroutant lors d'un debug. Mais dans tous les cas, le noyau prend bien le relai de grub dès le départ, il n'y a pas d'intermédiaire.
Après des façons de booter il y en a 150 possibles, on peut booter sans initramfs comme c'est le cas sur grossomodo tout ce qui n'est pas x86, d'ailleurs sur x86 aussi mais ça peut vite devenir compliqué (ordre de périphériques non garantis, pas de chiffrement, raid logiciel etc.), par multiboot (qui n'a jamais pris à part sur xen), par shim pour signer grub, etc.
Le 10/09/2025 à 09h37
Le 02/09/2025 à 08h38
Le 30/08/2025 à 06h50
Le 18/08/2025 à 13h25
Le 18/08/2025 à 11h22
Le 18/08/2025 à 03h58
Il faut imaginer que tu peux te trouver durablement dans un environnement où le réseau est écouté passivement avec un tap (réseau public, d'entreprise, enregistrement par un gouvernement etc.) ce que j'inclus dans la notion mitm mais effectivement ça ne peut pas protéger contre un mitm actif (proxy transparent avec réécriture tls).
Donc en résumé en PGP si ton terminal est saisi avec ta clé privée tous les échanges passés interceptés sont déchiffrables. En DH, whatsapp/signal, wireguard et sûrement d'autres, même avec la clé privée ce ne serait pas possible.
Le 17/08/2025 à 12h41
Tout cela dans un contexte mitm évidemment.
Modifié le 14/08/2025 à 19h44
Modifié le 14/08/2025 à 19h32
Il vaut mieux utiliser Signal ou tout équivalent pour ce genre de chose.
"Chacun doit comprendre comment ça fonctionne. Sans ca, nous serons toujours à la merci d'autrui en utilisant un produit "tout en un" et ses limites inhérente"
Bon alors si chacun doit comprendre tu élimines à peu près tout le marché de la communication numérique, et je ne vois pas comment ne pas utiliser un produit sans être "à la merci d'autrui" à moins que chacun développe sa propre implémentation.
"des messages postés dans une blockchain"
de quoi parles-tu ?
En ce qui concerne PGP pour le RCS/MMS j'aimerais bien que tu nous précises quelle implémentation le permet parce que je n'en ai jamais entendu parler (et c'est accessoirement complètement con comme approche).
Bref, tout cela nous montre bien qu'il vaut mieux arrêter le hakik.
Modifié le 11/08/2025 à 15h27
Modifié le 08/08/2025 à 19h36
Par ailleurs ce serait bien qu'ils re-étudient l'introduction d'I2P, c'est quand même plutôt la cible de ce genre de distrib.
Le 08/08/2025 à 19h33
Le 06/08/2025 à 14h12
Le 04/08/2025 à 14h22
Modifié le 29/07/2025 à 21h54
Les architectures micro-services sont inhérentes aux infras élastiques (aka cloud) et la combinaison des deux permet d'adapter finement la consommation de ressources en fonction de la charge, c'est tout. Personne n'a jamais dit que c'était particulièrement simple à architecturer.
Maintenant en ce qui concerne k8s, il faut faire le distingo entre le besoin réel du client et la branlette k8s que l'on retrouve sur les architectures. Il se trouve que je suis archi cloud publique (essentiellement aws, et on parle d'archi de boites du cac) et je passe mon temps à devoir re-concevoir des projets qui peuvent tourner très simplement sur ecs. Sauf que soit le commerce a décidé de vendre un truc de fou à un client qui n'y connaît rien, soit le client ne souhaite pas entendre parler d'autre chose parce qu'il a trop investi et enfin il y a les rares cas où k8s est difficilement remplaçable.
Modifié le 28/07/2025 à 21h39
Les certificats db dépendent exclusivement des OEM/ODM qui intègrent les SDKs phoenix/ami/insyde et rien ne les empêche de mettre les certificats qu'ils veulent. La seule condition de MS pour que le PC soit certifié est d'avoir au moins le leur de présent + SB activé par défaut, MS n'a jamais interdit que d'autres clés soient présentes sauf que les OEM/ODM ne veulent pas se compliquer la vie avec X clés à gérer (au moins 1/distrib majeure) qui ne serviront qu'à quelques geeks (dont je fais parti) dans des marchés de niche.
Par ailleurs les OEM/ODM sont libres de laisser l'utilisateur gérer le PK (et donc les KEK et les certificats db/dbx) ou de le verrouiller. Par exemple j'ai le plein contrôle sur mon uefi Asus (CM de 2023) et Insyde (PC clevo de 2020).
Par ailleurs, MS signe même un mini bootloader (exécutable "shim" qui embarque la clé publique de la distrib X permettant ensuite de valider la signature de grub pour le charger) afin que les RH/Debian/Fedora/etc. soient autonomes et donc puissent assurer la chaîne SB. Bon ce n'est pas gracieux de la part de MS, ils le font pour ne pas se mettre à dos différents acteurs mais sur le plan technique, absolument rien n'empêche les OEM/ODM de gérer d'autres clés sans perdre la certification MS. C'est à eux qu'il faut s'adresser pas à MS.
Le 28/07/2025 à 19h23
Modifié le 22/07/2025 à 09h56
J'ai toujours été surpris de voir à quel point les libristes (nb : j'en suis un) ne réalisent pas à quel point ce monde là repose sur le privé.
Je suis très reconnaissant de tout ce qu'a fait la FSF, des contributeurs travaillant sur leur temps perso au noyau Linux etc. mais c'est loin d'être suffisant pour créer un environnement fonctionnel aux standards actuels.
Le 20/07/2025 à 20h08
Le 18/07/2025 à 22h06
Le 18/07/2025 à 08h50
Le 09/07/2025 à 08h18
En tout cas c'est un outil excellent pour choisir un réseau selon son emplacement ou lieu de travail ou autre via la section "antennes et déploiements" qui indique tout ce qui est utile, il n'y a plus d'excuses désormais.
Le 26/06/2025 à 09h16
Modifié le 25/06/2025 à 19h06
Le 23/06/2025 à 15h44
Le 23/06/2025 à 13h39
Modifié le 23/06/2025 à 11h49
Les seuls qui connaissent précisément l'état des lieux de leurs capacités sont les agences de renseignements et évidemment nous n'en saurons jamais rien.
Le 23/06/2025 à 11h43
Et tout cela en partant du principe qu'il n'y a pas de filtrage tiers par ailleurs.
Le 13/06/2025 à 09h04
Le 13/06/2025 à 08h45