votre avatar Abonné

BlackLightning

est avec nous depuis le 9 mai 2021 ❤️

Bio

KuroDenkoo@pm.me

871 commentaires

Le 21/05/2025 à 09h 10

Oui bien sûr toute la suite office peut être codée par un projet étudiant....

VLC a été fondé par des Centraliens, qui était selon les classements de kikimètre, la 3ème meilleur école d'ingé de France.

L'X étant la 1er, j'ose pas imaginer ce qu'ils peuvent faire...

Le 19/05/2025 à 18h 09

Je n'ai pas regardé tous les liens, mais rien que dans le premier, le mot Rust n'est cité à aucun moment. L'articule évoque des failles processeur (entre autre) et non des failles lié à un langage. Le C n'est pas plus épargné par ces failles liées à des attaques par canal auxiliaire, même s'il peut y avoir des stratégies d’atténuation. Ces stratégies d’atténuation (comme le parasitage des signaux analysés) ne sont pas lié à un langage.

Le deuxième lien ne fait pas plus référence au langage Rust. Je me suis arrêté là, car je vois pas en quoi ces attaques par canal auxiliaire assez connues sont liées particulièrement à Rust, d'autant que je vous ai cité une bibliothèque Rust qui annonce des bibliothèques en temps constant : https://github.com/RustCrypto/crypto-bigint. Après je n'ai pas étudié cette bibliothèque, mais le temps constant est bien évoqué dans la description du projet.

Edit : Rust est bien affecté par des attaques par canal auxiliaire, lorsque c'est le processeur qui n'arrive pas à faire des calculs en temps constant, mais dans ce cas le C/C++ est affecté tout autant, et dans les deux langages il peut y avoir des stratégies d’atténuation. Ma question est plutôt, existe-il des liens qui explicitent en quoi Rust est plus problématique par rapport à un autre langage sur ces questions ?

Est-ce que Rust plus problématique que le C ? Dans l'absolue oui car il n'est pas possible créer des librairies en Rust pour figer le code. Ainsi, si je produis une crate pour un chiffrement sensible, je ne dispose d'aucune garanti que le code généré ne vas pas changer, suite par exemple à une MaJ du compilateur (e.g., modification d'un cmov avec jmp). Sur ce point, le C est légèrement plus robuste car on peut, dans une certaine mesure, figé des choses en disant au compilo "Touche pas à ça petit con".
L'autre défaut à mon sens, c'est que l'inclusion d'asm en Rust n'apporte aucune garanti à ma connaissance que le compilateur ne va pas modifier l'ordre des instructions, en C tu peux garantir ceci.
En pratique, la seule façon d'être robuste (en Rust comme en C) et d'utiliser une lib "de confiance" (comme tu l'as mentionné dans ton précédent poste).

Le défaut majeure de Rust est cette manie à vouloir tout réécrire. Très bien, si ça fait plaisir à des personnes de coder en Rust et de moderniser de vieilles choses en C/C++, allez-y. Mais vouloir reprogrammer du chiffrement en Rust (comme AES), c'est prendre un risque si jamais c'est mal fait.

Si tu couples avec l'effet NPM de Rust et ses crates, tu arrives à quelque chose où des implémentations cryptographiques vulnérables vont se retrouver cacher au fin fond d'un empilement de crate pour des services exposés sur le Web. C'est pas comme si on n'avait pas le retour d'expérience avec NPM ou Pip.

Mitigons ce point par le fait que les algorithmes de chiffrements modernes (i.e, plus récent qu'AES) tel que Chacha20 sont conçus pour éviter une partie des défauts de l'AES et de ce type d'attaque, car les LUT n'existent plus dans le design et repose que sur des opérations que l'on sait produire en temps constant.


Concernant les liens et les sources, tu as les trois papiers (mais tu as déjà capté l'idée) et le reste n'est que de la logique qui a déjà été éprouvé avec le C (cf. RSA et l'exponentiation modulaire).


Conclusion de mon point. Si je dois utiliser du chiffrement en Rust (e.g. AES) , je chercherai idéalement une lib de référence (e.g., standard ou certification FIPS). A défaut quelque chose qui s'appuie sur des librairies éprouvées dans d'autres langages. Dans le pire des cas, une implémentation reposant uniquement sur l'usage des instructions AES-NI. Tout le reste, en dehors d'un projet perso sans conséquence, je ne voudrais même pas l'inclure.


Ultime conclusion: Rust est un langage "memery safe" (même s'il y a des limites) contrairement au C ou C++. Mais Rust et le C ne sont pas langages "constant time".

Le 19/05/2025 à 15h 20

"En cryptographie Rust sera très dangereux à utiliser car il ne peut garantir l’exécution en temps constant des instructions processeurs."
Je ne trouve pas de sources qui confirme ce que vous dites. Je comprend que la gestion mémoire sous-jacente en Rust peut faire varier la vitesse d'exécution et donc poser des problèmes d'exécution en temps constants, là où en C, il faut expliciter la gestion dynamique de la mémoire, mais de ce que j'ai lu, il semble possible de développer des algos en temps constant en Rust, vu que les bibliothèques de CryptoRust notamment celle ci, le proposent. Sachant que de toute façon il est peu recommandé d'implémenter ses propres bibliothèques liées au chiffrement, que ce soit en Rust ou en C/C++ ou dans n'importe quel langage, il n'y a pas vraiment de moment où a besoin de faire très attention sur le temps constant dès lors qu'on utilise une bibliothèque éprouvée. Même pour comparer deux "mot de passe" ou "token", ne suffirait-il pas d'utiliser une fonction "officielle" pour le faire ?

De plus, si vous voulez développer votre propres fonction, j'ai trouvé cette bibliothèque Rust qui teste si votre exécution est bien en temps constant : https://github.com/rozbb/dudect-bencher

Avez vous un lien qui explique en quoi se serait un problème indépassable ?

John Kelsey, Bruce Schneier, David Wagner, and Chris Hall. Side channel cryptanalysis of product ciphers.Journal of Computer Security, 8(2-3):141–158, 2000.

21. Paul C. Kocher. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In
Advances in Cryptology – CRYPTO 96, volume 1109 of LNCS, pages 104–113. Springer, 1996.

22. Robert Könighofer. A fast and cache-timing resistant implementation of the AES. In Tal Malkin, editor,CT-RSA, volume 4964 of Lecture Notes in Computer Science, pages 187–202. Springer, 2008.

Parmi quelques exemples en tête.


ça n'a rien à voir avec la manière dont Rust ou le C gère la mémoire à la fin tout est un pointeur (même en Rust). ça a avoir avec la conversion du Rust/C en assembleur.

Et prouver qu'un code est en temps constant ne se fait pas avec dudect-bencher. Il manque des fonctionnalités essentielles pour quelque chose d'aussi sérieux que de la cryptographie.

Le 17/05/2025 à 16h 23

Mon propos n'était pas que le sondage StackOverflow était pertinent, mais plus que TIOBE ne l'est pas plus, en tout cas pas sur l'aspect niche ou pas, ou même sur la comparaison de la progression des langages Python et Rust à 10 ans.

Pour le jeux vidéo, où verrais-tu l'usage de Rust ?
Coté moteur il a une bonne place à jouer par exemple. Bevy-engine me semble prometteur, notamment par son architecture, ses designs techniques (sa gestion ECS avec les systems).
Mais également coté éditeur de contenu, Rust me parait très pertinent car il permet de faciliter la création et surtout la maintenance de grosses applications complexe.
Par contre il faudra du temps, justement parce que ce sont de grosses applications, avec une dépendance à tout un écosystème (librairie de GUI pour l’éditeur, physique pour les moteurs de jeux), donc il faut aussi que l'écosystème migre (par l'utilisation d'alternative), ou au minimum se rende compatible avec Rust.
Embark-studios par exemple mise beaucoup sur Rust, avec un certain nombre de projet écrit en Rust publié en opensource.

Pour le jeux vidéo nous verrons à l'usage. Mais on trouve bien des moteurs en Go, en C# alors pourquoi pas en Rust.

Le 17/05/2025 à 16h 22

Mais ne pas faire de C++ moderne, sauf cas particulier, est idiot ! C'est comme utiliser de l'essence au plomb alors qu'il y a mieux.
Mais ne pas faire du Rust, sauf cas particulier, est idiot ! C'est comme utiliser de l'essence au plomb alors qu'il y a mieux.
:D
La qualité d'un code ne dépend pas d'un langage mais du développeur.
Bien sûr, j'ai aussi vu du code Rust pas très jolie, et pas hyper robuste.
En revanche qu'on se sente plus à l'aise avec Rust ou le C++ pour faire un code de qualité, c'est plus une question de goût et de couleur.
Pas seulement, Rust (et sont écosystème) apporte plus d'outils pour aider à faire du code de qualité.
Mais c'est logique, c'est "le but" de Rust, et il est plus récent, il profite des expériences précédentes.
Oui comme en C++ avec le concept du RAII. Alors certes, on n'a pas les mêmes garanti que Rust à la compilation, mais on les a à l’exécution.
Et ça fait une importante différence, car à l'exécution, c'est plus compliqué à tester, et parfois difficile d'être certain que c'est bien testé.

"Pas seulement, Rust (et sont écosystème) apporte plus d'outils pour aider à faire du code de qualité."

Comme en C++ où il existe une multitude d'outils. Le Rust a l'avantage d'avoir compris que ce genre d'outils sont nécessaire à avoir dans un langage plus récent.

"Et ça fait une importante différence, car à l'exécution, c'est plus compliqué à tester, et parfois difficile d'être certain que c'est bien testé."

C'est bien vrai, mais un peu de nuance sur ce point. Les sécurités de Rust sur les accès mémoires sont partiels. Une vrai vérification est un problème NP-hard et là Rust aurait un temps de compilation mésosphérique. Le borrow-checker couvre les cas les plus courants et normalement, si on ne fait pas de saloperies, ça marche dans 100% des cas. Mais le système de vérification peut-être mis en échec et ça seul un test réel pourra permettre de le détecter.

Et là, il est très naturel dans un code C++ sérieux (qu'importe pro ou sérieux) d'avoir des checks mémoires forts sur la stack ou sur la heap lors des phases de dev et de tests. Est-ce plus naturel de faire tourner un valgrind avec Rust qu'avec du C++ ? Je ne sais pas pour ma part mais pour les codes Rust qui font du unsafe ou FFI, je n'ai pas souvenir d'un projet sur Github d'importance utilisant ce genre de vérifications.

Le 17/05/2025 à 15h 15

Ok pour la façon dont tu compare.
Je ne suis personnellement pas convaincu par leur pertinence pour comparer l’expension de Python et Rust.
Par exemple :

Le faible classement dans l'index TIOBE, et le fait que le C/C++ domine toujours depuis 10 ans alors que Rust peine encore à prendre la place.
Dans l'autre sens, lors des sondages Stack Overflow, Rust est souvent mis en avant. Je cite :
Pourtant, c’est Rust que les répondants admirent le plus. En effet, près de 85 % des développeurs l’ayant utilisé, ont déclaré qu’ils veulent continuer à s’en servir, contre 58 % pour JavaScript et 66 % pour Python.
Je ne pense pas qu'il serait autant plébiscité des développeurs l'ayant essayé si c'était un langage qui vise une niche (ce qui était le propos de départ).
Tu parlais du Rust dans le jeu vidéo. Je ne l'ai pas vu détrôner significativement le C++ dans ce domaine. En revanche, j'ai vu Python faire office d'alternative à Lua.
Je ne pense pas que ça soit une comparaison pertinente. C++ est utilisé pour la partie moteur, qui est d'une certaine façon la fondation technique d'un jeu, ce sur quoi s'appuie tout le reste. C'est plusieurs millions de lignes de code.
Alors que Lua et Python sont plutôt utilisés pour les parties scripting. Donc des bases de code beaucoup plus petite, et qui sont plus différentes d'un jeu à l’autre.

Comparer Rust SO avec TIOBE ne renseigne pas sur la même information. TIOBE fonctionne sur "Le nombre de pages web retournées par les principaux moteurs de recherche lorsqu'on leur soumet le nom du langage de programmation". Donc clairement à l'échelle du Web, on parle moins de Rust que des autres langages, pourtant personne ne nie que Rust à le vent en poupe.

Pour SO, comparer Rust, Javascript et Python me laisse dubitatif sur les questions posés. bref, ce genre de sondages a la même valeur que "80 % des sympatisants d'un parti politique sont pour Mr X à la tête du parti". Et pourtant Mr X se prendre une branlée aux élections présidentielles.

Pour le jeux vidéo, où verrais-tu l'usage de Rust ?

Le 17/05/2025 à 15h 05

Effectivement on utilisait du "vieux C++", les choses ont évolué en C++. Mais pas toutes les bases de codes, tout le monde n'a pas envie de faire du C++ moderne, et n'est pas obligé.
C'est une des raisons pour laquelle je préfère Rust, il y a une contrainte de "qualité de code" supérieur.
Quand je dois utiliser du code externe (une librairie par exemple), c'est plus facile d'avoir confiance dans le code (sa qualité, sa fiabilité). Et je dirais aussi, plus facile de "vérifier" si le code est de qualité.

C'est quoi le rapport entre un pointeur et Arc, Mutex et autres ? On mélange des choux et des carottes là, non ?
Le rapport que je fais, c'est que dans les deux cas c'est le moyen d’accéder à une allocation mémoire.
Si le C++ moderne incite à ne plus utiliser directement les pointeurs, c'est encore possible, et très présent dans les bases de code historique.
En Rust (non Unsafe) il n'y a pas de pointeur, une allocation mémoire est encapsulé dans un objet qui contraint (et explicite) la façon dont on pourra accéder à la donnée (modification ou pas, multi-thread ou pas).

*"Effectivement on utilisait du "vieux C++", les choses ont évolué en C++. Mais pas toutes les bases de codes, tout le monde n'a pas envie de faire du C++ moderne, et n'est pas obligé.
C'est une des raisons pour laquelle je préfère Rust, il y a une contrainte de "qualité de code" supérieur."*

Mais ne pas faire de C++ moderne, sauf cas particulier, est idiot ! C'est comme utiliser de l'essence au plomb alors qu'il y a mieux.
La qualité d'un code ne dépend pas d'un langage mais du développeur. En revanche qu'on se sente plus à l'aise avec Rust ou le C++ pour faire un code de qualité, c'est plus une question de goût et de couleur.

La qualité d'un code ne présume absolument pas de sa fiabilité. Voici un bon exemple : https://github.com/RustCrypto/block-ciphers. Autant de dire qu'utiliser ce code dans autre chose qu'un projet de hobbyiste, c'est prendre des gros risques.
Pourquoi ? Car Rust ne peut pas garantir l'execution en temps constant ni l'assembleur produit.
Ce qui fait la confiance d'une libraire, ce n'est pas uniquement la qualité de son code. J'ai bien plus confiance dans BLAS que dans n'importe quelle code, quand bien même Rust garanti l'absence de bug mémoire dans son implémentation.


*"Le rapport que je fais, c'est que dans les deux cas c'est le moyen d’accéder à une allocation mémoire.
Si le C++ moderne incite à ne plus utiliser directement les pointeurs, c'est encore possible, et très présent dans les bases de code historique."*

Je reformule ma question. En quoi un Mutex est un access à la mémoire ? Sémantiquement ça ne fait pas de sens.

"En Rust (non Unsafe) il n'y a pas de pointeur, une allocation mémoire est encapsulé dans un objet qui contraint (et explicite) la façon dont on pourra accéder à la donnée (modification ou pas, multi-thread ou pas"

Oui comme en C++ avec le concept du RAII. Alors certes, on n'a pas les même garanti que Rust à la compilation, mais on les a à l'execution.

Le vieux C++ doit disparaître des codes et surtout de l'enseignement de la programmation aux nouvelles générations. Le vieux C++ est révolu et ne doit perdurer que les endroits où les MaJ d'un code n'est pas simple et sans conséquence.

Le 17/05/2025 à 13h 41

Je ne trouve pas que Rust ne vise qu'une niche, au contraire il vise à être une option pertinente (mais pas la seule) dans à peut-près tous les domaines (en dehors des usages ou la compilation est un problème, type "scripting dynamique" par exemple).
Aujourd'hui, je sais qu'il prend place notamment dans les noyaux (windows, linux), en cybersécurité dans les outils de protection réseaux, dans les backend d'application web, dans des applications client (Un certain nombre d'application Gnome, le client Dropbox), dans l'embarqué, dans le jeux-vidéo (même si timidement pour l'instant), dans les applications web client (avec WASM). Donc je n'appellerais pas ça une niche.

Et sur quoi tu te bases pour dire que Rust est nettement moins répandu que Python ?
Nettement moins sur quel critère ? Le nombre de développeur ? Le nombre de programme écrit ? Le nombre de personne qui utilise des programmes écrit dans le langage ?
Et les époques sont différentes, les langages n'ont pas du tout le même objectif, donc je ne vois pas trop comment une comparaison de popularité ou d’expansion pourrais être pertinente.

" (en dehors des usages ou la compilation est un problème, type "scripting dynamique" par exemple)."

En dehors du HPC, de toute approche parallèle plus complexe qu'un fork-join, de la crytographie, du jeux vidéos... Rust est très bon là où la sécurité mémoire est critique (e.g, équipement réseau, pare-feu, noyau...). Mais si la sécurité mémoire n'est pas une priorité, Rust devient moins utile/interessant comme solutions.

"Et sur quoi tu te bases pour dire que Rust est nettement moins répandu que Python ?"

La faible migration de projet vers Rust (les offres en C++ sont largement supérieure à Rust en France). Le faible classement dans l'index TIOBE, et le fait que le C/C++ domine toujours depuis 10 ans alors que Rust peine encore à prendre la place.
Quand Python est arrivée, en 10 ans il a pris la place de Matlab, IDL et consort dans les milieux académiques et industrielle. Matlab est encore enseigné dans les écoles d'ingénieurs au coté de Python mais de plus en plus de prof. passe à Python. Idem pour les universités.
Quand à Rust, bah il commence à sortir le bout de son nez.

Tu parlais du Rust dans le jeu vidéo. Je ne l'ai pas vu détroner significativement le C++ dans ce domaine. En revanche, j'ai vu Python faire office d'alternative à Lua.

Le 17/05/2025 à 13h 29

De mon coté, je pense que Rust à de bons atouts pour se répandre à peu près partout.

Venant du C/C++, avant d'apprendre le Rust, j'arrivais assez bien à lire le langage, au moins aussi facilement que du JavaScript ou du Python. Bien sur quand on veut comprendre vraiment comment est construit un programme (y compris le design/l'architecture), il faut apprendre le langage.

Je suis utilisateur de logiciel libre avec une démarche de contributeur. Malgré une envie de participer notamment quand je rencontrais des bugs, ou j'avais envie d'une petite fonctionnalité supplémentaire je crois que je n'ai jamais réussi à participer à des programmes en C ou C++.
Alors qu'avec Rust j'ai pu le faire sur plusieurs projets, et des projets totalement différent. Une fois une base minimum du langage appris, je trouve la charge mentale pour lire le code, le comprendre et le modifier nettement plus faible.
Contexte: j'ai plus de 13ans d'expérience professionnel en programmation C/C++ et environ 3 ans en Rust (pas à temps plein).

Je trouve le code Rust plus facile à lire, car beaucoup plus explicite. L'exemple qui me vient en premier est les pointeurs en C/C++ vs Rc, RefCell, Arc, Mutex, RwLock en Rust.
En Rust le type indique l'intension et les contraintes lié à une allocation mémoire, alors qu'en C/C++ on a juste un pointeur.

Concernant l'inclusion de Rust dans le noyau Linux, effectivement ce n'est pas simple et c'est normal que ça créé des problèmes. Mais je pense que si ça été accepté par Linus, c'est parce que les avantages sont importants.

"En Rust le type indique l'intension et les contraintes lié à une allocation mémoire, alors qu'en C/C++ on a juste un pointeur."

Et par curiosité, quelle version du C++ tu utilises ? Parce que je suis d'accord pour le "vieux C++". Mais ce n'est plus le cas avec le C++ moderne. Les pointeurs ne sont plus censé se trimballer seul maintenant, et surtout, sauf cas particulier, on en a rarement besoin.

Ah oui, mélanger la notion de pointeur en C avec celle du C++, c'est pas comparable. Le pointeur C et C++ sont sémantiquement la même chose, mais la manière de les utiliser à largement changer.

"L'exemple qui me vient en premier est les pointeurs en C/C++ vs Rc, RefCell, Arc, Mutex, RwLock en Rust."

C'est quoi le rapport entre un pointeur et Arc, Mutex et autres ? On mélange des choux et des carottes là, non ?

Le 17/05/2025 à 11h 36

Plutôt d'accord avec toi.

Je rajouterai des éléments qui font que, pour moi, Rust restera un langage assez cloisonné dans ses usages.

Déjà, la syntaxe. On a beau avoir de l'expérience et connaitre plus ou moins un certain nombre de langage, il est très difficile de lire et comprendre un tant soit peu du code Rust sans aucune connaissance du langage. Et ce n'est pas un langage facile. Il vient avec de nombreuses "contraintes" qui sont le pendant de la sécurité de la gestion de la mémoire. Tous les développeurs ne sont pas près à faire ça. Il suffit de voir encore tous ceux qui préfèrent faire du javascript au lieu du typescript !! (purtant, la marche technique me semble beaucoup moins haute)

De plus, il existe déjà des langages beaucoup plus sûr que le C, mais sans avoir le même modèle que le Rust. Je pense à l'Ada notamment. Pourtant, l'Ada n'a pas percé non plus, sauf dans des zones de niches. Et ça fait plus de 40 qu'il existe et qu'il évolue ! (Ada83, Ada95, Ada2005, Ada2012 et Ada2023)

Ensuite, et là c'est un avis strictement personnel, j'ai trouvé que l'API manquait un peu de cohérence et de clarté. Et avec cargo, on peut vite se retrouver avec le syndrome NPM : 1 dépendance en rajoute 50.

Enfin, je n'ai rien contre Rust pour de nouveaux projets. Mais inclure Rust dans des projets déjà existant comme le noyau Linux, c'est le meilleur moyen, à mon sens, de créer des problèmes. L'homogénéité au sein d'un projet, notamment un projet de cet envergure, devrait être la priorité. Le débogage pourra être extrêmement pénible, car il faudra à la fois avoir des connaissance sur le fonctionnement du noyau, en C et en Rust (et des connaissances plus ou moins poussées). L'attrait pour de nouveaux contributeur pourrait aussi en pâtir, tant la marche technique peut sembler élevée pour contribuer.

En face avec toi sur tout ces points

Sur la syntaxe je pense que c'est l'héritage de OCalm et de la programmation fonctionnelle plus que des contraintes mémoires liés aux borrow-checker.

Pour le noyaux linux, il est difficile de comprendre le choix de Linus. Certains parlent de pressions venant des GAFAMS (réduction des coûts car à terme nombres de dev Rust > nombres de dev C ou des enjeux en lien avec les licences GPL/MIT). Linus semblait parlé du fait qu'attiré de nouveaux dev en C était difficile est que Rust allait faciliter la chose.
Je suis sceptique, car au delà de C et du Rust, le dev système c'est plus une affaire d'élements très bas-niveau que d'un langage de programmation.
Mais je suis d'accord, Rust dans l'intégration du noyau risque de poser des soucis (c'est déjà le cas) car le modèle mémoire du noyau Linux n'est pas celui de Rust. (et la même logique s'applique pour tous les aspects en lien avec l'execution parallèle (threads, asynchrone, mulitprocessing...)).
A mon sens, il aurait était plus intéressant pour le noyau de faire évoluer son langage C.
Pour le Rust comme kernel, il y a le projet RedOx.

Le 17/05/2025 à 10h 57

Au passage, quelqu'un aurait une source d'information sur OVHCloud et Rust, en particulier pour les services HP ?
Le seul truc que je trouve, c'est du VPS pour jouer à un jeu vidéo.

Et j'ai bien la source, mais j'ai tellement l'impression de lire un billet bullshit mi-marketing mi-IA que je doute même de la véracité de l'information dans le lien donné par Next.

Le 17/05/2025 à 10h 55

Il [G. Hoare] définit Rust comme un outil « permettant de construire d’autres infrastructures : protocoles réseau, serveurs web, équilibreurs de charge, systèmes de télémétrie, bases de données, codecs, cryptographie, systèmes de fichiers, systèmes d’exploitation, machines virtuelles, interpréteurs, etc., etc. ».

En cryptographie Rust sera très dangereux à utiliser car il ne peut garantir l’exécution en temps constant des instructions processeurs.

Je comprends que son auteur veut le voir partout, mais Rust ne vise qu'une niche d'application. Et la preuve en 10 ans d'existence Rust est nettement moins répandu que Python ne l'a été. Non pas qu'il est inutile, mais qu'ils visent une niche, qui représente des cas d'usages assez spécifique.

Le 17/05/2025 à 10h 45

Les langages basé sur la preuve formelle vont en ce sens. Mais c'est souvent complexe à mettre en oeuvre et ça demande beaucoup de puissance de calculs. En ce ce sens, tu t'en sers pour les choses très critiques (e.g., sécurité des personnes, cryptographie...).

Ensuite, il se pose une autre question qui est de l’exécution. Tu as un langage safe, cool. Mais est-ce que ton processeur sera safe à l'execution ?

Rust en ce sens apporte une possibilité de se protéger d'un certains nombres de vulnérabilités en ayant trouvé un compromis entre temps de compilation et "preuve que c'est safe".

Le 07/05/2025 à 09h 51

Je suis d'accord, il faudrait des garants financiers en charge de contrôler les projets et recadrer rapidement si nécessaire. Si le projet échoue, les garants remboursent.

Mais je pense qu'il y a un autre problème, et ça me coûte de le dire car c'est pas vraiment aligné avec mes valeurs.
Je le vois bien dans la boite où je bosse depuis quelques années. Mais des projets de plusieurs dizaine de personne ne tiennent qu'au savoir et à la vision d'une seule. Et cette seule personne peut avoir gagné du crédit sur un projet et être mauvais sur un second.
La méthode américaine du "t'es le meilleur ou je te remplaces" permet d'avoir, in fine, des gens techniques très bons très souvent. Là où ici (je reste vague, car ce n'est pas forcément franco-français), on va plutôt être sur le principe de Peter (seuil d'incompétence).
Pour moi, il faut savoir récompenser grassement la réussite d'un projet complexe afin de pousser à la créativité.

Elon Musk est un bon exemple. Il est extrêmement compétent techniquement par rapport à ses "fonctions" chez Tesla (PDG) et SpaceX (proprio), et on voit comment ça avance sur le plan technique. Il est capable de trancher sur des décisions de façon rapide et pertinente, car il est garant du budget ET de la réussi du projet.
Même au niveau politique, Trump lui a demandé de faire de la merde, on ne peut pas lui retirer qu'il a fait de la merde avec efficacité.
Dans le reste du monde, les dirigeants des grosses boites sont avant tout des politiciens qui ne comprennent rien à ce que leur boite fabrique et vend, et n'ont pas de vision réellement long terme.

La différence fondamentale avec les US que tu présentes se résume à des différences de mentalités.

Au US, la prise de risque est normal et culturellement assumé. ça fait parti de "leur ADN" en quelque sorte. En outre, au US ils savent qu'ils ont besoin de gens compétents pour faire tourner leur système. Le système du "t'est le meilleur ou tu meurs" s'inscrit aussi dans la logique US basé sur la loi du plus fort (physiquement, militairement, économiquement...).

En France, la prise de risque n'est pas valorisé et on est plus "prudent" que les US. L'autre différence majeure est qu'au US tu peux évoluer dans ta carrière en restant un tech. En France, tu ne peux finir que manager.


Pour la direction des grosses boîtes (comme celle du CAC40), oui c'est plus des politiciens mais ils évoluent dans un environnement ou ne pas avoir ces compétences est létal. Néanmoins, ces PDG semblent mieux gérer leur boîte que Macron ne gère le budget de la France et de son image.

Le 06/05/2025 à 22h 29

On a les outils, on a les compétences, on a le savoir-faire, il ne manque plus qu'une vision à long terme et une réelle volonté politique, un budget solide et un développement carré, pas juste filer le marché aux copains ou à des entreprises fantômes qui vont faire du sale boulot et se graisser la patte au passage en surfacturant, comme souvent avec les commandes publiques.

Si c'est une offre publique faite par l'Etat ça passera par des ESN parce qu'il faut pas s'attendre à mieux de nos dirigeants actuelle. Et que logiquement, les ESN feront un gros lobby pour avoir les marchés (ce qui est logique).

En réalité ça me dérange pas, si et seulement si les échecs seront lourdement sanctionnés. Si c'est pour donner de l'argent publique et faire un Louvois (ou équivalent) mais encaisser le butin alors autant garder MS. Entre la peste et le choléra, avec le dernier on est sur de mourir dans ses excréments.

Le 06/05/2025 à 18h 40

Pour que Microsoft prenne la parole de cette manière et avec ce message, c'est qu'il commence à craindre que l'UE envisage sérieusement de commencer à se détourner de leur solution.

Je doute que Microsoft s'appuie sur du vent, donc il semblerait que les hautes instances de l'UE envisage réellement de réduire leur soumission à MS. Interessant.

Le 07/05/2025 à 09h 43

"les salaires assez faibles au regard de ce qu’ils touchent au US"

Ben vasy vivre aux US, le grand rêve américain.
Ou pas...

On sent quand même le côté râleur FR dans vos comms.

Déjà le côté équitable : équité de quoi ? d'un salaire ? mais versus quoi ?
grade ? compétence ? investissement personnel ?

Ensuite ça connoterait presque une préférence nationale, sans vouloir vous offenser :
Pourquoi devrait-on privilégier un expat avec le mal du pays ou un terreau national consanguin ?

PS: je ne dis pas qu'on n'a pas un orchestre avec tous les instruments dans la news, mais jsute vos comms, ...
:-D

J'ai vécu au US et je faisais de la recherche. Et si j'y suis pas resté, c'est parce que j'étais pas compatible avec la mentalité

Je n'envie absolument pas les US. Mais je reconnais que la gestion de leur centre de recherche et nettement meilleur qu'en France. C'est pas une question de cerveaux, c'est une question d'organisation des administrations, qui a le bon mérite de ne pas changer à chaque ministre.hom
Je te résume, au US tu passes 1 mois à préparer tes dossiers pour demander tes budgets. Les règles varient peu entre les années et les formats de soumission sont largement partagées par les différentes administrations. En France... Il suffit que tu mettes un nouveau ministre pour que ça change tout, au point que des chercheurs font plus d'administratifs que de recherche.

Pour la question de la préférence nationale, faut vraiment n'avoir jamais connu la Recherche française pour balancer des inepties pareils ! Les docteurs français sont très appréciés à l'étranger car ils sont bosseurs, bons et savent s'intégrer dans un nouveau pays. (Clairement l'opposé de l'image qu'on imagine).
Pour rappel, nos impôts payent la formation des chercheurs de l'école primaire à l'université. Alors oui, autant récupéré notre investissement surtout s'ils ne sont pas mauvais.
Pour compléter @WarMachine dans son poste a bien décrit la situation actuelle.

Le coté raleur du com' vient du fait qu'avant de faire venir des chercheurs étrangers et de les accueillir dans des conditions moins bonnes que dans leur pays, on pourrait déjà s'occuper des nôtres et de notre Recherche.

Le 06/05/2025 à 18h 46

Je pige que dalle à toute leur com'.

On annonce de l'argent pour les chercheurs US, mais on envisage de taper dans le budget de la recherche pour 2026. On cherche à faire venir des checheurs américains, alors qu'on a déjà un vivier en France et, par extension en Europe. Je comprends rien à la logique à part celle de vouloir faire tourner des éoliennes en brassant du vent.

Et très sincèrement, les chercheurs US vont vite déchanter de la vie à la Française dans les milieux de recherches. La branlette administrative en tête, la recherche de budget à x instances et les salaires assez faibles au regard de ce qu’ils touchent au US...

Le 05/05/2025 à 21h 33

Tu l'as surement noté, mais même pas besoin de l'ED pour vendre le pays. Regarde nos gouvernants.

Le 05/05/2025 à 21h 32

Il manque plus que les conflits armés entre eux...

Le 04/05/2025 à 12h 18

À ma connaissance AMD ne se démarque pas négativement d'Intel question fiabilité et stabilité, Donc si je dois établir des SLA, un RTO ou un RPO pour une plateforme Intel ou AMD, je ne vais pas faire de différence. D'un point de vue stabilité et résilience d'une solution, il y a tellement d'autres aspects à considérer que le cpu.

Maintenant il est vrai qu'on pourrait aussi regarder la stabilité des performances suite à des mises à jour du microcode pour des vulnérabilités au niveau des cpu's. Ces dernières années j'ai l'impression qu'Intel n'a pas impressionné positivement en la matière. Mais AMD n'est pas forcément à l'abri d'une opportunité de décevoir.

En principe, si tu gères un système sensible tu ne fais pas les maj du micro-codes sur tes machines de prods sans avoir vérifié avant les impacts possibles au regard des risques encourus.

Le 04/05/2025 à 12h 17

La CPU pas le seul point mais ca fait en parti. J'ai la même question qui m'est posée sur chaque architecture avec une "nouveauté".
Quel est le recul et/ou le feedback que je peux donner sur le plan fiabilité sur ce "nouveau" composant surtout s'il est critique?
Si ma réponse est "peu ou aucune", et si le marché cible prévoit des pénalités SLA, la position de l'intégrateur sera invariablement celle de privilégier l'expérience fiabilité à la performance brut sauf à considérer un véritable gain qui pourra se traduire sur un coût global sensiblement diminué.

Donc oui les intégrateurs sont conservateurs parce qu'ils doivent gérer des risques financiers..

Maintenant comme tu sembles bien connaitre AMD, peut être as-tu des statistiques à faire valoir?

Les CPUs sont des composants fiables, en dehors de problèmes d'alimentations via des VRM (lié à des problèmes de la CM, de la mauvaise gestion énergétique...) les CPU n'ont pas raison de lâchés comme ça. Et si c'est le cas, c'est un problème du constructeur/fondeur.

Mais de toute façon, les nouveautés ne font pas parti des éléments critiques car il faut un minimum de recul. Déjà pour le hobbyiste prendre le dernier processeur sur le marché fraichement sorti n'est pas recommandé. Alors pour un pro, qui plus est avec des SLA, c'est joué à la roulette russe avec plus d'une balle dans le barillet.

Sans plus de détails, difficile de faire valoir plus AMD ou Intel. Juste qu'AMD a réussi avec Zen à prendre la tête, et que maintenant ne pas considéré AMD dans un choix technique est une idiotie.
D'ailleurs de nombreux supercalculateurs reposent sur de l'AMD (le dernier en date est Frontier le plus puissant au monde actuellement) alors qu'avant Intel dominait ce marché. Preuve d'un changement qui n'est pas anodin.

Après, comme l'a mentionné @ragoutoutou il y a d'autres choses en prendre en considération que le CPU pour la fiabilité.

Le 30/04/2025 à 19h 36

Je vais te donner une raison qui est la mienne. Dans ma boite (on est éditeur de logiciel), nous réalisons des tests sur des matériels avec nos logiciels dont l'objectif est de produire des requis matériels pour permettre un dimensionnement approprié en fonction du cas d'usage. Cela comprends, serveur, clients et inclus technologies du réseau et du stockage. Nous ne vendons pas de matériels.
Ces test monopolisent une équipe assez importante et nous imposent de coller au marché du matériel. A date, nous ne faisons qu'une seule plateforme: Intel. Nous n'avons objectivement pas la taille de doubler cette équipe pour porter les tests sur AMD (parce que nous devrions maintenir les tests Intel quand même..) et sais tu pourquoi il n'y pas de débat sur le sujet?
Parce qu'il n'y a pas de demande de la part de nos clients.

Je vais donc te retourner ton, argument d'autorité:
" il n'y a plus pas vraiment de raison fonctionnelle de prendre AMD plutôt qu'Intel".

ça ne marche que si les clients sont compétents pour comprendre les enjeux associées et les gains.

AMD surpasse Intel pour du calculs. Si ton logiciel n'est pas orienté calculs/simulations lourdes, qu'il ne demande pas un IPC de malade ou autres alors oui Intel ou AMD le client s'en fiche car il ne voit que le sticker.

Le 26/04/2025 à 18h 33

Nous verrons bien mais je vois une grande différence entre Intel et AMD sur le marché serveur: la disponibilité, le support et la fiabilité.
Il faudra qu'AMD convainc sur ces 3 axes pour percer et cela prend du temps.
Maintenant, il est bon d'avoir 2 fabricants en concurrences pour dynamiser ce marché.

Pour compléter @ragoutoutou, si tu regardes les offres d'OVH sur du bare-metal on trouve plus d'AMD que d'Intel. Par contre, il n'y a que 3 familles Zen de CPU AMD contre 5 pour Intel. En revanche les modèles d'Intel me laisse penser à juste un effet de renouvellement des stocks et de réutilisation de plus vieilles architectures.

Le 26/04/2025 à 15h 50

On ne va pas se plaindre quand même. Il a fallu trouver des solutions quand les CPUs, on eut consommé des stéroïdes. Le cache n'est pas une mauvaise chose.
Les CPU auraient pu devenir multi-coeurs bien avant et les RAM pouvaient être multicanal aussi.
L'augmentation drastique des fréquences qui a eu lieu à l'époque des Pentium 3 n'était pas la seule voie possible pour augmenter les performances. C'est cette augmentation déraisonnable des fréquences qui a causé l'apparition de pipelines à 50 étages, l'apparition des bidouilles à l'origine de bon nombre de failles actuelles et la course en avant de la taille et du nombre des caches.

Et puis le problème des performances n'est pas lié qu'au processeur, les développeurs ont une grande responsabilité dans le fait que, malgré l'augmentation considérable des performances, les services rendus se dégradent https://fr.wikipedia.org/wiki/Loi_de_Wirth
Oui et non. Dans l'absolu, c'est suffisant (source, destination, accumulateur / compteur). Moins confortable (comme l'était un 68k) mais suffisant. D'où le cache. Il peut éventuellement servir d'extension pour les registres. Pour peu qu'on sache le faire ou que le langage utilisé le permette (les structures en Cpp par ex).
Suffisant, oui puisque cela fonctionne mais cela engendre beaucoup de déplacements de données pour libérer les registres spécialisés, via la pile ou via la mémoire. Si on fait des statistiques sur le type d'instructions utilisées dans un programme, on peut séparer les instructions en deux catégories:
- les instructions productives : calculs, tests, rotations..
- les instructions non productives : déplacements de données, saut inconditionnels, sauvegarde et restauration de contexte.

Si on compare le taux d'instruction non productives pour le même algorithme implémenté dans deux jeux d'instructions, on peut comparer l'efficience de l'architecture et à ce jeux, le x86 est très mal placé face aux ARM par exemple mais plus globalement face aux processeurs ayant des registres plus nombreux et moins spécialisés.

Sauf que ton raisonne pour les registres n'est valide que pour du calcul ne faisant pas appel aux unités flottantes. Si on prends l'x86-64 avec l'AVX-512 on se trouve à 32 registres de 512 bits contre 32 registres 128-bits pour l'ARM v8.

En revanche, on a 31 GP registres pour l'ARM v8 et 16 pour l'x86-64 (32 si on considère l'APX, mais ce n'est pas encore courant).

Néanmoins augmenter les registres implique que les compilateurs sachent les utiliser (et les dev aussi). Et même avec plus de registres, ce n'est pas toutes les implémentations d'algorithmes qui peuvent les utiliser.


Par contre mesure l'efficience d'une architecture en comparant des registres ça me paraît pas suffisant, tu préfères pas mesurer/estimer l'IPC dans ce cas ? Car le jeux d'instructions c'est une chose mais ça ne fait pas tout.

Le 26/04/2025 à 15h 21

L'écart délirants entre la vitesse des cœurs et les bus externes est aussi un problème de physique. Intel a bien des défauts avec leur x86, mais certaines choses sont lié à l'évolution des technologies.
Si on met de côté le problème de l'architecture déficiente des x86, il y a bien d'autres problèmes en effet.

Je dirais plus que c'est une fuite en avant dont la responsabilité est partagée à 50% entre les développeurs qui ne veulent pas se remettre en question (et certainement leurs donneurs d'ordre qui ne veulent pas les former à ces changements), et les fondeurs qui continuaient de mettre en avant la performance des cœurs unitaires.

Il aurait fallu multiplier les cœurs depuis longtemps au lieu de les surcadencer aux prix d'une consommation que j’évaluerai à au moins 300% (consommation dynamique liée au carré de la fréquence et une fréquence deux fois trop grande en moyenne selon moi). Mais cela implique de rendre les traitements parallélisables donc d'adapter les manières de développer.

Si, au lieu de continuer sans cesse de baser les évolution quasi exclusivement sur la vitesse des cœurs, les architectures étaient devenues plus multi-cœur comme maintenant, cette évolution aurait démarrée plus tôt. Avec un énorme gain sur les consommations électriques.

La fuite en avant me parait manquer d'acteur. Je pense que les fondeurs ne créeent plus le besoin mais ce sont les usages qui le font. Augmenter le nombres de coeurs n'est pas aussi simple que d'augmenter la fréquence du processeur, ça implique plus de transistors, des mécanismes de synchronisation et de la communication au niveau du CPU. Au niveau des OS, ça demande savoir gérer correctement ce point, et même de nos jours (Linux y compris) il y a encore des bugs ou des failles de sécurités.
Niveau application, (or avènement du cloud) les besoins sont concentrées dans certains domaines de niches (calculs d'ingénieries, recherches académiques). L'IA, les jeux vidéos dépendent bien plus des GPUs (et c'est aussi vrai pour certains calculs indu.). Bref ce n'est pas majorité.
Et enfin, écrire un code en parallèle efficace (et sans trop de bug) n'est toujours pas une tâche facile. Même si certains langages offrent des accès simplifiées (e.g., Python, Rust) dès que ça devient un élément critique ils faut revenir des langages plus pratiques (e.g., C++). Sauf que comme tu le mentionnes les donneurs d'ordres ont, pour leur majorité, rien à carrer de ces choses là.


Par contre la consommation électrique des coeurs je ne sais pas si vrai que ça. Quand tu compares un CPU ARM (e.g., Ampère) avec de l'x86, oui l'efficacité énergétique par coeur est plus prononcé chez ARM que l'x86. Mais à lors que tu tires dessus à fond (simulations numériques), l'écart se réduit entre les deux.

Selon moi, si tu souhaites baisser la consommation énergétique de ces bestioles, je verrais plutôt une simplification de l'architecture et notamment du front-end des CPU. Beaucoup de transistors sont alloués aux décodages des instructions (sur l'x86), aux optimisations internes, à la détection de boucles.... Vu la puissance d'un CPU à leur actuelle en terme de puissance brutes, on pourrait s'appuyer plus sur les compilateurs (et les développeurs) pour optimiser les codes en amonts et ainsi réduire significativement le nombres de transitors.

Mais là encore, ça ne marchera pas en réalité car si tu économises du transitors, ils seront remis ailleurs (plus de coeurs ? plus d'unités de calculs ?). Ensuite ça demande d'avoir des développeurs formés à l’optimisation et des donneurs d'ordres conscient de ces enjeux. En fait, ça demande aussi bien aux producteurs, qu'aux utilisateurs de revoir leur lien avec l'informatique dans nos sociétés. Et ça c'est pas gagné du tout.

Le 25/04/2025 à 11h 49

L'écart délirants entre la vitesse des coeurs et les bus externes est aussi un problème de physique. Intel a bien des défauts avec leur x86, mais certaines choses sont lié à l'évolution des technologies.

Le faible nombres de registres est un problème mais il y a aussi une responsabilité des dev. Oui Intel a bien conscience de ce problème puisque l'APX vise à augmenter drastiquement ce point. Seulement ça ne sert rien d'augmenter ce nombre de registre si les compilateurs (et les développeurs) ne savent pas les exploiter dans leur code. Actuellement, GCC dispose d'une option permettant d'améliorer l'usage de ses registres, mais elle est peu utilisé en pratique (d'après les nombreux Makefile que j'ai vu passé dans ma vie). Clang ne dispose pas de cette option est à du mal à exploiter correctement cette possibilité.
MSVC a une option de mémoire mais qui de compétent utilise une merde pareil ?


L'x86 n'est pas fait pour faire de l'IA pour les raisons que tu as expliqué et c'est la raison de la présence de circuit plus spécialisé (e.g., Ryzen AI). Bien qu'on puisse entraîner et inférer un NN, c'est plus pour "fun" ou du debug ou R&D de prototype qu'autres choses (et encore il faut de l'AVX-512 de mémoire).

Cette annonce est dirigé vers les marchés, les actionnaires et la presse mainstream. En aucun cas, elle vise les technophiles.

Le 28/04/2025 à 10h 43

Python est un langage interprété. En revanche, des modules Python (e.g., numpy, scipy, PyTorch...) peuvent être écrit en Python ou non (et dans ce cas il y a un binding à faire).

La raison évidente est pour l'aspect performance (exploitation plus efficace du processeurs, meilleure gestion de la mémoire...).

Le 26/04/2025 à 15h 23

Pareil, c'est une surprise. Mais au moins ça fait du bien de voir que ce genre de politicien existe.

Le 26/04/2025 à 14h 55

A noter que c'est System76 qui supervise le dev principale avec des devs payés à temps plein. ça n'éparpille pas forcément les ressources de l'open-source.

Ensuite, celui est développé en Rust donc il y a un intérêt à voir ce que Rust va permettre de faire sur ce genre de segment. En outre, la hype étant sur porté sur Rust il y a également un bon vivier de contributeurs possibles.

Le 26/04/2025 à 14h 52

Mais c'est une conséquence du public cible. Linux, c'est principalement le monde des serveurs et des geeks. Bien qu'on puisse utiliser Linux sans faire de la ligne de commande, dès que tu dois configurer, créer des comptes, règler le pare-feu... La ligne de commande s'avère un outil très puissant, et à titre personnel bien au-delà des interfaces graphiques.

En revanche, Windows & MacOS eux pour vendre doivent se mettre à la porter de leur utilisateurs. Et l'ergonomie des IHM est la seule chose que les utilisateurs lambdas vont voir de ces OS. Linux s'en fout car il vise avant tout un autre public. Néanmoins si Linux veut se rendre accessible, ce genre de travail est nécessaire.

Le 23/04/2025 à 10h 52

Parce qu'en terme de durée de vie et consommation énergétique, l'idéal c'est de ne pas dépasser 50% de la puissance maximale d'une alimentation. 🙂
En outre, je veux un peu de réserve, si un jour je décide d'overclocker le CPU (ce qui est loin d'être nécessaire aujourd'hui, j'ai tout passé en mode éco et undervolté).
En outre, l'Antec 400w date de 2013 et a servir pour un AMD C60 de longues années puis un Intel N100, elle a des loupés avec la nouvelle configuration, j'ai des pertes de gpu à pleine charge et le ventilateur s'excite comme un dingue dès qu'il est sollicité.
L'alimentation RM850x, peu sollicitée même à pleine charge de l'ensemble de la config, restera silencieuse, et est beaucoup plus qualitative/stable en comparaison pour assurer la longevité d'un matos autrement plus cher, et compatible avec la mise/sortie en/de veille rapide, qui me sera fort utile pour le NAS, ne souhaitant qu'il soit actif qu'à partir du moment où un équipement local ou distant essaie de le joindre.

Sinon pour répondre côté nvidia, on peut soit directement lier n'importe quelle carte PCIE (ou périphérique en géneral, même USB, SATA, etc...) à une vm, soit la diviser (vgpu) en plusieurs cartes.

@Burn2 et @bingo.crepuscule : Ok merci. Je vais réessayer, mes derniers essais furent des échecs.

Le 22/04/2025 à 21h 22

Hé bien tu n'est pas le seul, j'avais anticipé la possibilité de soucis, je suis content d'avoir fait du DiY et été sur du standard, avec Proxmox... J'ai tous les usages, des services, home assistant, SMB, VM pour cloud gaming... Et ça roule. 🤗
Bon évidemment, ça a demandé un peu d'investissement... :

-Ancien boîtier Bitfenix prodigy (Mini ITX)
-Carte mère ASRock B650I Lightning (Mini ITX)
-CPU Ryzen 9 7900 (12 coeurs / 24 Threads)
-32Go de DDR5 6000Mhz CL30
-GPU GTX 1660Ti OC (pour du 1080P) [Ils peuvent toujours se brosser pour que j'achète du neuf, vu le prix délirant des gpu désormais. Ça fait tourner FF7 rebirth en 60fps quasiment tout à fond avec optiscaler, là, c'est dire, ça m'est largement suffisant...)
+
-GPU GTX 1650 pour les enfants (deux vm pour les usages familiaux donc, accessible via Sunshine/Moonlight) branchée sur le second slot NVME derrière la carte mère, via un adaptateur Occulink)
-Adaptateur NVME => x6 SATA III (pour les disques durs)
-Alimentation Antec Neo 400, qui trop juste et vieille, sera bientôt remplacée par une Alimentation Corsaire RM850x.

Avec ça, plus de prise de tête, du standard, hautement configurable si nécessaire mais simple d'accès, conteneurs et VM faciles à exporter/cloner.
Côté VM, sur les OS, c'est CachyOS, SteamOS, Home Assistant, et Windows 11 selon les besoins/tests. Il faudrait que j'essaie Android aussi.

À noter qu'une des vm avec la GTX 1650 est accessible physique, j'ai lié un dongle uniyfing de logitech à un couple clavier/souris, relié à un écran/projecteur, et ça roule comme un pc présent physiquement.

Pour le reste, pour que tout fonctionne niveau résolution/sortie pour les gpu avec le streaming sunshine/moonlight, il faut des dongles simulant la présence d'un écran à brancher sur HDMI, ça coûte quelques euros sur aliexpress, jusqu'en 4K 120Hz.

Deux petites questions, tu passes d'une alim de 400 W à 850W ? Pourquoi un gap aussi grand ?

Promox permet de faire "virtualiser" des GPUs Nvidia ?

Le 23/04/2025 à 10h 43

...hmmmm... le genre de réponse qui me donne l'impression que mon message précédent n'a pas été lu...

c'est un fait qu'ils dominent le centre de calcule, mon propos est que la désinvolture pour le marché gaming pourrait faire tache d'huile et menacer leur position sur ce marché. Il ne faut pas s'imaginer que des entreprises modernes et agiles se laissent longtemps coincer chez un fournisseur qui met leur existence en danger.

J'ai bien lu ton précédent message. Mon point est de dire que même si Nvidia font les "cons", ils ont quand même un lead technologique réel sur le hardware. Ce n'est pas aussi simple de que de passer de Intel à AMD pour les CPU.

Quand à ta dernière phrase, Pourtant c'est qu'on observe avec les boites modernes qui utilisent u MS pour leur R&D ou encore de l'Intel pour leur machine de calcul. Penser que les acteurs soit rationnels dans leur décision n'est valable que dans des modèles d'économie totalement déconnecté de la réalité.

Le 22/04/2025 à 21h 26

Oui enfin, sur le secteur "entreprise" Nvidia domine également. Niveau GPU, AMD pourrait rivaliser mais CUDA est bien implémenté et difficile de faire aussi bien (HIP est assez méconnu, et OpenACC ne permet pas de pousser le GPU à fond, OPenCL est trop geek et ChatGPT connait bien CUDA).

Le 19/04/2025 à 14h 59

La grande majorité des gens n'en ont rien à cirer. Ils ne veulent pas changer de système. Ils veulent de l'IA, du pratique, etc. et ne pas changer leurs habitudes

Je vais en choquer certains ici : Linux n'est pas encore prêt pour le grand public. Et je me demande s'il le sera un jour, tant la philosophie derrière est différente (et je précise que j'apprécie Linux et l'utilise au quotidien).

Pour commencer, le choix de Windows est simple : on prend la version préinstallée sur le PC.
Pour Linux, c'est la jungle .

Ensuite, Linux une des forces, mais qui fait aussi une de ses faiblesses, c'est la tendance au monde Linux à changer certaines choses qui marchent (je ne dis pas que c'est fait sans raison, c'est juste un constat).

Dernièrement, c'est le passage a Wayland qui est plus ou moins douloureux (moins si on n'a pas de Nvidia, plus si c'est le cas). Mais nvidia ou pas, on trouve encore de nombreux rapports de bogues de tel ou tel application qui ne marche pas (ou mal) à cause de ça. Il n'est pas rare d'avoir des bogues, de devoir revenir en arrière, etc.

Sans compter que l'installation de programme hors des dépôts officiels de la distribution peut vite devenir un bordel sans nom.

Tant qu'il faudra un minimum de compétence en informatique pour la gestion de Linux (ou avoir quelqu'un avec ces connaissances dans son entourage proche), je vois très mal linux se répandre sur le Desktop, quelle que soit les décisions prisent par MS pour ses produits.

Bien je sois d'accord avec toi, il y a un point qui peut changer la donne : Linux en entreprise.

Si jamais les conneries de Microsoft finissent par poser problèmes ou la géopolitique de Trump (rêvons un instant que l'UE se sortent les doigts du tréfonds de son incompétence en IT et ose frapper les US où ça fait mal... les services numériques US), il est pas impossible que partiellement commence un processus de migration de Windows -> Linux, et que ce processus finissent pas toucher les Michus. Si ces même Michus (pas de jaloux, Mme & Mr) finissent pas utiliser du Linux, ils finiront éventuellement par l'utiliser dans leur usage quotidien, au profil d'avoir la même chose au travail et à la maison pour ne pas être trop perturbé.

Alors oui, je considère ça comme extrêmement peu probable tant les GAFAM ont parasité les entreprises, les institutions et les centres de formations de nos "élites".

Le 05/04/2025 à 15h 59

Pour l’anecdote nous avons aussi un datacentre - moji 1 - qui fonctionne sans clim.
200kw de puissance consommée en permanence, c’est un petit dc, 72 baies, PUE de 1.1, groupe gaz de ville et supercaps, on chauffe tous nos locaux avec - le top du top en termes d’environnement.
Complément de frais en adiabatique quand l’air extérieur dépasse les 27 degrés, on consomme environ 150 m cubes d’eau par an (soit la conso d’un individu).

Si tu veux recycler de la chaleur ça fait joli sur le papier on y réfléchit pour moji 2 mais il faut tellement d’énergie pour passer de 35 degrés en air à 70-80 degrés liquide que ce n’est pas très rentable, et ça n’a de sens environnemental qu’avec une électricité fortement décarbonnée et que si tu effaces du fossile et pas du géothermique.
En dlc ou immersion le rendement est plus intéressant mais c’est pas simple en collocation - et pas facile non plus sur son propre parc de serveurs au demeurant.

L'air a deux défauts pour le refroidissement, il est un mauvais conducteur et n'offre pas de changement de phase "naturellement".

Pour le recyclage de la chaleur, quid des solutions basé sur une interface liquide-liquide ou gaz-liquide ?

Le 03/04/2025 à 18h 57

Je ne comprends pas quelque chose. Comment Anubis peut être une contre-mesure ? S'il repose sur une preuve de travail (si j'ai bien compris le code c'est du calcul récursif de SHA) en quoi ça limite les crawlers ?

De ma compréhension, le crawlers pourrait bien effectuer cette opération mais à part ralentir la pression sur le site je ne vois pas trop ce que ça peut changer, pusique in fine les données se feront quand même aspirer. Si il y a peu de crawlers ok ça peut aider mais si le nombres devient conséquent ça ne va pas forcément changer grand-chose, non ?

Le 01/04/2025 à 20h 44

Il y a plusieurs représentations des nombres en cobol.
Les comp-1 et comp-2 sont des formats à virgule flottante sur 4 et 8 octets. Mais on les utilise rarement, historiquement on leur préfère le format comp-3 qui est aussi compris nativement par le processeur, il stocke le nombre en BCD (Binary Coded Decimal) qui a l'avantage d'être lisible directement en hexadécimal :
(0102030C)comp-3 = + 102030 (le dernier caractère C indique un nombre positif, D négatif)
(1234567D)comp-3 = - 1234567

J'avais oublié cette histoire de BCD :roll:

Merci pour le rappel.

Le 01/04/2025 à 20h 43

Pourquoi voudrais-tu utiliser des flottants, avec des erreurs d'arrondi à chaque étape, pour gérer du pognon ?

Parce que tant que ça augmente mon solde, ça me va :D

Blague à part, ce n'était pas le sens de ma question. Ma question porte sur comment le compilateur Cobol gère les nombres décimaux en langage machine par pure curiosité.

Le 01/04/2025 à 19h 00

Petite question. Étant donné que Cobol n'utilise pas les nombres flottants et ne peut donc pas avoir accès aux unités flottantes des CPU modernes, comment est-ce gérer au niveau langage machine ?

Les mainframes disposent de CPUs avec des unités spécialisées à ce type de calcul ? Ou bien le compilateur COBOL contient ce qu'il faut pour ce genre de calculs à la manière des libraires type MPC ?

Le 31/03/2025 à 22h 40

Est-ce que nos politiques connaissent vraiment les oeuvres de Miyazaki-sensei ?

J'ai vraiment du mal à croire que les plus jeunes comme Attal ou Thevenin serait capable de disserter sur princesse Mononoke, le tombeau des lucioles ou encore mon voisin Totoro ?

Eux, les politiques, qui ont passé un temps fou à déféquer sur les D&D, les mangas qui portent la violence chez nos jeunes, ne serait probablement pas foutu de faire la différence entre Bleach ou One Piece, un FMA et une oeuvre de Miyazaki. Alors là je pige pas le message.
Surtout qu'en vrai, s'ils pensent vraiment s'adresser à une génération qui a connu ces œuvres, ils devraient savoir qu'ils ont aussi bien raconter des conneries à cette même génération.

Et puis sérieusement, c'est moi qui passe trop de temps à regarder des animés ou bien certains font vraiment photo d'un personnage mort ? Sérieusement, la photo d'Ensemble/Horizon me donne l'impression de voir les candidats au survival game dans Mirrai Nikki (heureusement qu'ils ne le connaissent pas celui-là) lors des openings/ending.



Sinon, sur un ton plus lié à cette manie produit par Altman est son manque d'affection et de sens dans sa la vie (si j'en crois sa story-teller),
vous trouvez pas que ces ersatz ne semble provenir que du Voyage de Chiriho ou de mon voisin Totoro ?
Par exemple, aucune femmes politiques ni de près ni de loin ne semble faire penser au coup de crayon de Mononoke. Ils sont tous enfantins et candides. Pourtant les oeuvres de Miyazaki-sensei, c'est loin d'être l'édulcoration à la Disney.

Le 31/03/2025 à 15h 08

Pour ceux qui ne connaissent pas les services offerts par un noyau/OS.

Il s'agit de pouvoir faire communiquer/travailler entre eux des processus/tâches ou threads d'un même processus.
Dans le lien mis par hwti, on parle de sémaphores, de mutex et d'évènements.
Les 2 premiers évitent que des ressources/données soient utilisées "en même temps" par 2 entités logicielles avec pour but de protéger des erreurs du type : a lit une donnée puis b lit la même donnée, a fait un calcul sur cette donnée et écrit le résultat en mémoire, b fait un autre calcul (ou le même) et l'écrit lui aussi en mémoire. On a donc écrasé la valeur modifiée par a.
Si par exemple, a et b font -1 sur la donnée, on passe de donnée à donnée-1 au lieu de donnée-2 si l'on avait protégé l'accès à la donnée.

Pour les événements, je n'arrive pas à trouver de page Wikipédia, les termes que je recherche me font tomber sur des événements (salons ou autres) informatiques ou sur de la programmation événementielle, ce qui n'est pas ça non plus au niveau d'un OS.
Mais en gros, ça permet à un processus d'attendre un événement avant de continuer son traitement et à l'OS ou d'autres processus de générer cet événement.

Les évenements sont, dans le cas ce driver, un sémaphore binaire permettant de représenter un système à deux états concernant les conditions de reset.

Le sémaphore binaire n'est qu'un cas particulier de sémaphore.

Le 21/03/2025 à 19h 08

C'est pas que ça ne choque personne. C'est que Microsoft a une excellente stratégie commerciale et qu'il n'y a pas d'alternatives viables pour les décideurs (oui, pour le public de Next on sait qu'il y a largement des alternatives).

Et puis Microsoft offre une sécurité, celle du parapluie de responsabilité. "C'est pas moi chef, c'est la faute de Microsoft/Les autres font la même chose..." Et l'administration française adore le "pas de vague".
ça n'encoure pas l'innovation ni la recherche d'alternative.

Le 20/03/2025 à 22h 46

Effectivement, rien en FP32/64.. dommage.

D'après le document fourni pour GB300 NVL72, le FP64/ FP64 Tensor core est à 100 TFlops.

Soit + 17% plus performant qu'une RTX 5090 en FP32.

Pour comparer ça aux Top 500, Disons qu'il faut ~ 25 GB300 NVL72 pour avoir la même puissance que le dernier supercalculateur du Top 500 de Novembre 2024 (Marlyn).

En comparaison si on prends HPC6, le supercalculateur européen le plus puissant (Italie) on est à ~ 6060 de ces bestioles.

Le 20/03/2025 à 22h 13

Je ne sais pas quel est le taux de contrôle, mais je me dis qu'un douanier ne doit pas perdre son temps à vérifier l'historique mail de tous les péquenots qui se présentent.
Ce chercheur a quand même du être ciblé en amont pour une raison X ou Y.

L'accès au territoire US pour un ressortissant français nécessite de remplir un formulaire quelques jours avant le départ. Et dessus, il est demander sa profession et son employeur. C'est clairement pas difficile pour eux de cibler des personnes.

Si on rajoute le possible renseignements, je doute de la qualité de l'aléa.

Le 20/03/2025 à 22h 10

Avec quel argent ?

Nous aussi en France nous avons des cerveaux ! Si la France est prête à accueillir des chercheurs US, j'espère qu'elle sera aussi prête à concéder à faire des efforts pour embaucher ses propres docteurs qui file soit à l'étranger soit dans le privé.

Le gap de la Recherche française peut se combler, non pas avec des chercheurs US, mais avec une politique stable de longue durée, du financement publique correctement investis, la valorisation des brevets, et une politique de gestion compatible avec la notion de Recherche Scientifique Publique, et un coup de tronçonneuse pour se déparasiter la bestiole. Après ça, on pourra commencer à parler de faire venir des chercheurs US.

Le 18/03/2025 à 18h 37

Peine perdu. Ni Van der Layen, ni Macron (pour la France) n'a la volonté de faire un bras de fer avec les US. (voir HDH et l'EN).

ça finira lettre morte et soumission à Trump et son administration.

Le 13/02/2025 à 18h 58

C'est moi où j'ai l'impression qu'on "vend la France" comme un site pour installer des datacenters s'en faire fi des conséquences ?

Le 13/02/2025 à 18h 56

J'ai fait un petit exemple rapide : https://godbolt.org/z/dn1Kn89e9
Rust est bien par défaut plus optimal. Il faut rajouter restrict au paramètre 'a' pour que le C génère le même code que Rust.

Je confirme ton exemple, cependant j'ai repris les codes où j'avais de l'aliasing et pourquoi je t'ai affirmé plus haut que GCC avait changé.

C'est ma faute, en substance je compile toujours avec l'option -frename-registers qui n'empêche pas l'aliasing mais qui fait que GCC "découple". Si tu reprends ton exemple du haut en C et que tu rajoutes cette option, tu verras que les deux variables sont chargés dans des registres différents puis additionner. ça n'a pas choqué au début car j'ai toujours retenu que l'aliasing fait mov, add , mov. ça reste vrai qu'il y a aliasing et que le processeur fait deux load au lieu d'un, mais en pratique les deux codes s’exécuteront de la manière sur le processeur.

Dans le cas de Rust, les deux additions ne pourront s'effectuer qu'une fois que l'instruction mov sera retiré. Dans le cas du C, les deux instructions moves seront executés ensemble, puis au cycle suivant les deux instructions add. Finalement, il faudra bien 2 cycles d'horloge au deux codes pour arriver au même résultat.

D'où le fait que je ne voyais pas la différence car finalement il faut le même nombre d'horloge pour arriver à ce résultat.
1 2 … 17 18