votre avatar Abonné

Uther

est avec nous depuis le 8 avril 2006 ❤️

1030 commentaires

Le 13/02/2025 à 11h 20

Je ne sais pas avec quoi tu compiles en C, mais GCC depuis un moment fait automatiquement cette hypothèse. ça fait un moment que je ne déclare plus mes pointeurs avec le mot clé restrict. D'ailleurs le code assembleur n'est absolument pas modifié.
La dernière fois que j'ai du mettre du restrict, c'était parce que le code servait de doc en même temps et que donc il fallait préciser ce point.

Donc en gros Rust interdit aliasing de pointeur.

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.

Le 13/02/2025 à 07h 01

Je pense que tu as compris où je voulais en venir avec la définition du coeur du noyau ;) Il est facile, à tout à chacun, d'utiliser le même terme pour parler de choses proches mais aux frontières différentes.

Qui plus est, attention avec la notion de wrapper. Un wrapper peut vite devenir plus qu'un wrapper. C'est plus que cela. Cela devient souvent a minima un adapteur.

En effet et les wrapper Rust ne font pas partie du sous-système DMA (dans /kernel/dma). Ils sont dans leur propre domaine(/rust)
Il faut comprendre que le sous-système ce n'est pas qu'une arborescence au sein de linux. Le /rust/kernel/dma fait, pour moi, parti du sous-système /kernel/dma. Ca n'a pas de sens de définir un sous-système sur la base d'un langage et non pas sur la base de la fonctionnalité/scope.
Il faut vraiment comprendre que ce wrapper n'est qu'une bibliothèque utilisée par les drivers Rust. ils pourraient tout a fait être dans le code des drivers, mais ça serait de la duplication inutile de code complexe.
Ah mais je comprends très bien, rassure toi (le dev, c'est mon métier, et les wrappers, j'en ai déjà fait plein !). Je sais aussi qu'un wrapper ne reste rarement qu'un wrapper, et peut vite devenir un adapteur. Et ici, dans le cadre d'un projet comme le noyau linux, c'est une des pires choses qui puissent arriver je pense, car tu peux avoir une interface en C qui soit ait évolué à la version n+1 tendu que la version en rust continu d'utiliser la version n, car le wrapper joue la glue nécessaire pour rendre compatible la version n avec la version n+1 (et devient donc un adapteur).

Maintenant, Linus a très bien résumé la situation je trouve. Et pour la dernière fois, l'intégration de Rust a été autorisée de manière très cadrée. Si cela ne plait pas à l'équipe de R4L, alors, comme je ne cesse de le répéter => fork, patch, etc.

Il faut comprendre que le sous-système ce n'est pas qu'une arborescence au sein de linux. Le /rust/kernel/dma fait, pour moi, parti du sous-système /kernel/dma. Ca n'a pas de sens de définir un sous-système sur la base d'un langage et non pas sur la base de la fonctionnalité/scope.
Sauf que comme je l'expliquais que ce soit du point de vu fonctionnel ou organisationnel le wrapper n'a pas a faire partie du scope DMA, et ça n'a jamais été cocidéré comme étant le cas pour tous les autres wrappers développés jusqu'a présent.

Si on considère que ce qui utilise l'API DMA fait partie du domine DMA, tous les drivers qui utilisent le DMA font partie du domaine DMA.
Maintenant, Linus a très bien résumé la situation je trouve. Et pour la dernière fois, l'intégration de Rust a été autorisée de manière très cadrée. Si cela ne plait pas à l'équipe de R4L, alors, comme je ne cesse de le répéter => fork, patch, etc.
Linus a surtout critiqué a raison la forme de la discussion. Il n'a, à ma connaissance, pas tranché le problème du point de vue technique.

Le 12/02/2025 à 22h 22

Je ne sais pas avec quoi tu compiles en C, mais GCC depuis un moment fait automatiquement cette hypothèse. ça fait un moment que je ne déclare plus mes pointeurs avec le mot clé restrict. D'ailleurs le code assembleur n'est absolument pas modifié.
La dernière fois que j'ai du mettre du restrict, c'était parce que le code servait de doc en même temps et que donc il fallait préciser ce point.

Donc en gros Rust interdit aliasing de pointeur.

Je serais curieux de voir des exemples réels. Si le mot clé restrict a été ajouté au langage, c'est justement parce que la norme du C interdit au compilateur de faire cette hypothèse, et qu'il fallait un moyen de le lui permettre.

Si GCC faisait vraiment ça, ça voudrait dire qu'il produirait des programmes carrément faux selon la norme.

Le 12/02/2025 à 07h 14

J'ai du mal a comprendre pourquoi les bindings Rust devraient être considérés comme faisant partie du cœur de Linux
Je pense que beaucoup d'incompréhension viens justement de là (que ce soit entre nous ou au niveau du projet Linux lui-même) : quelle définition donne t-on au coeur du noyau ? Si c'est tout ce qui n'est pas un driver, alors oui, un wrapper fait parti du coeur. Si c'est tout ce qui est utilisable par un driver, un wrapper fait aussi parti du coeur. Si c'est le code C, non le wrapper ne fait pas parti du coeur.
Sauf que cette règle n'a jamais existé, c'est juste l'idée trouvé par Christoph Hellwig pour refuser le patch sans admettre que c'était un soucis pour faire des drivers en Rust
Pourtant, c'est dans les règles : chaque sous-système fait comme il le souhaite. Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected.
Le vrai soucis, c'est que le ton c'est envenimé des deux coté :
- Christoph Hellwig a levé des objection sans prendre en compte les choix fait lors de l'introduction de Rust dans le noyau et de manière de plus en plus véhémente alors que les gens du projet Rust for Linux lui expliquaient les effort qu'il faisaient pour garantir un impact minimal.
- Hector Martin de son coté à essayé de pousser sur les réseaux sociaux pour prendre à partie la communauté et Linux Torvalds ce qui a agavé la situation.
Comme je le disais plus haut, chaque sous-système fait comme il le souhaite vis-à-vis de Rust (et c'est R4L qui le rappel !). Je comprends la frustration des développeurs Rust, mais ils veulent un peu le beurre (Rust) et l'argent du beurre (au sein du noyau linux).

Encore une fois, le noyau Linux existe depuis 3 décennies maintenant. 3 décennies de code C. Même des portions écrites en assembleur (généralement, pour des raisons d'optimisations) sont réécrites en C pour plus de maintenabilité et de portabilité.

Intégrer un nouveau langage dans un projet de 30 ans d'âge, c'est tout sauf anodin, et cela ne doit pas se faire n'importe comment. Le comportement d'Hectore Martin a jouer les pleureuses sur les réseaux sociaux est très loin de faire avancer le débat, et ne pourra, au contraire, que le cristaliser.

Christoph Hellwig refuse peut être le patch un peu brutalement, mais il le dit lui-même : pas de code rust pour ce sous-système (et c'est une règle tout à fait applicable comme le rappel R4L).

Une fois encore, si la politique d'intégration de Rust au sein du noyau pose problème, libre à l'équipe de R4L de forker le noyau et/ou de le fournir sous forme de patch (c'est faisable, grsecurity le faisait très bien par le passé). Ils auront moins de soucis de gouvernance, pourront faire les choix qu'ils veulent, mais auront plus de boulot de maintenance.

quelle définition donne t-on au coeur du noyau ? Si c'est tout ce qui n'est pas un driver, alors oui, un wrapper fait parti du coeur.
Cette définition par dichotomie est difficilement applicable. En regardant le code source de Linux on voit bien qu'il y a plein de choses qui ne sont manifestement ni le cœur ni les drivers.
Si c'est tout ce qui est utilisable par un driver.
Là on est dans la définition ad-hoc sur un point trop spécifique. Ça n'a pas vraiment de sens où on va devoir classer la lib C dans le noyau, vu quelle est utilisée par les drivers en tant que bibliothèque au même titre que les wrapper.
Si c'est le code C, non le wrapper ne fait pas parti du coeur.
La encore c'est trop spécifique pour avoir un sens.
Rien n’empêcherai techniquement d'utiliser du Rust dans des sous-systèmes qui font manifestement partie du cœur d'un OS comme le scheduler par exemple. Ça ne deviendrait pas des drivers pour autant.
Et pire encore : les drivers en C deviendraient le noyau :mad2:
Pourtant, c'est dans les règles : chaque sous-système fait comme il le souhaite.
En effet et les wrapper Rust ne font pas partie du sous-système DMA (dans /kernel/dma). Ils sont dans leur propre domaine(/rust). Les retirer n'aurait aucun impact sur le code DMA, juste sur les drivers Rust qui l'utilisent

Il faut vraiment comprendre que ce wrapper n'est qu'une bibliothèque utilisée par les drivers Rust. ils pourraient tout a fait être dans le code des drivers, mais ça serait de la duplication inutile de code complexe.

Le 11/02/2025 à 22h 23

Encore une fois le patch ne touche pas au cœur, c'est juste une interface pour les drivers Rust, qui utilise l'API C existante.
Si. Le patch créé une couche supplémentaire entre les drivers et le coeur en C. Ce n'est plus un driver.
A partir du moment où on a décidé qu'on permettait les drivers en Rust, le problème de la maintenance est inévitable. Refuser une API Rust commune pour le DMA ne résout rien : le code d’adaptation à l'API C va juste se retrouver dupliqué dans chaque driver et résoudre les impacts d'une évolution de l'API C sera encore plus complexe.
Un changement d'API au niveau C peut provoquer des problèmes de compilation pour certains drivers Rust. Avec cette modification, un changement d'API au niveau C peut provoquer des problèmes de compilations pour TOUS les drivers Rust.
Et c'est bien le cas. Encore une fois le projet Rust for Linux crée juste des wrapper Rust pour permettre au drivers Rust de s'interfacer plus naturellement avec le code C du coeur du noyau. Il ne le modifie pas directement.
Comme je le disais, la création de cette interface, c'est ajouter un coeur Rust au coeur C.
Le wrapper permet au contraire d'établir une frontière claire entre le Rust du driver d'un coté, et le C du coeur de l'autre coté.
En créant une interface Rust qui devient, de facto, une partie du coeur.

Je comprends parfaitement les motivations des développeurs Rust. Je comprends aussi parfaitement les motivations des développeurs & mainteneurs du noyau qui préfère le C.

Actuellement, il y a des règles qui ont été établies. Le Rust est autorisé pour les drivers. Point barre. Il n'a pas été autorisé pour autre chose. C'est une des raisons pour lesquels le patch a été refusé. Le code est dans un drvier ? non => patch refusé.

On peut espérer que le patch et son refus ouvre des discussions et surtout une prise de décision consensuelle sur ce qui est, ou n'est pas, autorisé au sein du noyau Linux.

Et encore une fois, si l'équipe R4L n'est pas contente de la direction prise, libre a elle de forker le noyau pour intégrer les modifications comme elles le souhaitent. Ainsi, aucune maintenance supplémentaire pour l'équipe "historique" du noyau.

A partir du moment où l'équipe R4L souhaite rester dans le giron du projet Linux, c'est à elle de se conformer aux règles qui ont été établies.

Si. Le patch créé une couche supplémentaire entre les drivers et le coeur en C. Ce n'est plus un driver.
La couche d'abstraction est là depuis le début du projet Rust for Linux et c'est sa mission majeure. C'est le mode de fonctionnement qui a été validé et qui est en place depuis 3 ans. La couche d'abstraction était là avant les premiers drivers Rust. Ce patch l'étend juste pour prendre en charge le DMA.

Les drivers et le noyau font partie du code Linux (entre autre). Il n'y aurait pas de sens à mettre ailleurs la couche qui s'intercale entre les deux.
Un changement d'API au niveau C peut provoquer des problèmes de compilation pour certains drivers Rust. Avec cette modification, un changement d'API au niveau C peut provoquer des problèmes de compilations pour TOUS les drivers Rust.
Qu'ils soient écrits en Rust ou en C, les drivers n'ont pas de raison d'être impactés la modification d'une API qu'ils n'utilisent pas. Le wrapper n'y change rien.
En créant une interface Rust qui devient, de facto, une partie du coeur.
J'ai du mal a comprendre pourquoi les bindings Rust devraient être considérés comme faisant partie du cœur de Linux :
- D'un point de vue technique, ils ne permettent pas d'interagir plus que les drivers C avec les différents composants du noyau. Ils passent par les mêmes API.
- D'un point de vue organisationnel, ils sont dans le répertoire "rust" à la racine du projet, les drivers sont dans le répertoire "driver" et le cœur du noyau est dans le répertoire "kernel". Il n'y a actuellement aucun code Rust en dehors des bindings et des drivers Rust.
Actuellement, il y a des règles qui ont été établies. Le Rust est autorisé pour les drivers. Point barre. Il n'a pas été autorisé pour autre chose. C'est une des raisons pour lesquels le patch a été refusé. Le code est dans un drvier ? non => patch refusé.
Sauf que cette règle n'a jamais existé, c'est juste l'idée trouvé par Christoph Hellwig pour refuser le patch sans admettre que c'était un soucis pour faire des drivers en Rust. La couche d’abstraction à toujours été le maillon essentiel de l'intégration du code Rust dans Linux. La refuser c'est justement aller contre le fonctionnement défini.
On peut espérer que le patch et son refus ouvre des discussions et surtout une prise de décision consensuelle sur ce qui est, ou n'est pas, autorisé au sein du noyau Linux.
Ce point là a été décidé avant même le début du projet, ça n'est pas un problème.

Le vrai soucis, c'est que le ton c'est envenimé des deux coté :
- Christoph Hellwig a levé des objection sans prendre en compte les choix fait lors de l'introduction de Rust dans le noyau et de manière de plus en plus véhémente alors que les gens du projet Rust for Linux lui expliquaient les effort qu'il faisaient pour garantir un impact minimal.
- Hector Martin de son coté à essayé de pousser sur les réseaux sociaux pour prendre à partie la communauté et Linux Torvalds ce qui a agavé la situation.

Le 11/02/2025 à 22h 10

Quelles sont les optimisations difficiles en C que permettent les règles d'ownership ?

Par exemple Rust interdit qu'il y ait en même temps, sur une même variable, deux références mutables (en termes C, deux pointeurs non constants) . Le compilateur peut s'en servir pour optimiser, alors qu'en C il faut déclarer manuellement les pointeurs 'restrict' pour promettre au compilateur que les pointeurs sont uniques, ce que presque personne ne prend la peine de faire en pratique.

D'ailleurs quand Rust a activé cette optimisation, ça a permis de détecter des bugs dans la gestion du noalias de LLVM, et par conséquence dans l’implémentation de "restrict" de clang. Ces bugs étaient là depuis des années mais on ne s'en était pas rendu compte avant car "restrict" est très peu utilisée en C, alors qu'il est utilisée implicitement partout en Rust.

Le 11/02/2025 à 13h 24

Le refus de Christoph Hellwig est très très mal argumenté, étant donné qu'il a déjà été décidé que l'on allait accepter des drivers en Rust dans le noyau.
Il a été décidé d'autorisé les drivers en Rust, pas le coeur du noyau (les bus de communications, le DMA, etc.). Nuance.
L'interface étant maintenue à part par le groupe Rust for Linux, et pas directement dans le sous-domaine DMA. Dupliquer cette interface dans chaque driver poserait beaucoup de problème et ne résout rien.
C'est là où tu te trompes. Une des forces (et des faiblesses !) du noyau linux, est que son API interne peut changer à tout moment. Quand c'est le cas, l'équipe qui a fait la modification reporte la modification sur les drivers impactés lorsque c'est possible. C'est actuellement faisable car quasiment tout le code de Linux est en C.

Demain, si l'équipe en charge du DMA décide de changer son API, non seulement il faut mettre à jour tous les drivers écrit en C, mais il faut aussi :
- mettre à jour le wrapper Rust
- mettre à jour les drivers écrit en Rust.

Il faut donc des compétences en Rust. Compétences que tout le monde n'a pas.

Sans compter qu'en cas de problème avec un driver DMA avec un driver rust, il faudra trouver si le problème vient du code DMA en C ou du Wrapper en Rust.

On peut ne pas être d'accord. Cloisonner l'usage de Rust aux "drivers" terminaux me semble une sage décision, d'autant plus dans un projet legacy où le cross language apporte de la complexité supplémentaire et où certains paradigmes de programmation sont très différents.

Comme le dit Linus, le système actuel n'est pas parfait mais à fait ses preuves. Autoriser le R4L a gérer ça et intégrer du code Rust pour le coeur du noyau, c'est ouvrir une boite de Pandore en l'état actuel des choses.

Le cloisonnement par driver a aussi un avantage relativement simple : en cas de besoin (absence de mainteneur compétent en Rust par exemple), on peut plus ou moins facilement réécrire le driver en question en C, sans trop d'impacts sur le reste du système.

Si aujourd'hui on autorise un wrapper Rust dans le coeur de Linux, demain ce sera du code Rust dans le coeur de Linux.

Une fois encore, on peut ne pas être d'accord avec la stratégie. Maintenant, il ne faut pas oublier que Linux est un logiciel libre, sous GPL-v2. Libre à l'équipe R4L de faire un fork pour intégrer directement ses wrappers s'il le souhaite. L'équipe de maintenance du noyau ne pourra rien dire. Grsecurity le faisait (fait ?) depuis fort longtemps par exemple.

Linux a des règles, qui peuvent paraitre rigides, mais c'est sans doute aussi grâce à ces règles que le noyau a pu se développer ainsi et perdurer pendant presque 30 ans.

Il a été décidé d'autorisé les drivers en Rust, pas le coeur du noyau (les bus de communications, le DMA, etc.). Nuance.
Encore une fois le patch ne touche pas au cœur, c'est juste une interface pour les drivers Rust, qui utilise l'API C existante.
Demain, si l'équipe en charge du DMA décide de changer son API, non seulement il faut mettre à jour tous les drivers écrit en C, mais il faut aussi : mettre à jour le wrapper Rust, mettre à jour les drivers écrit en Rust.
A partir du moment où on a décidé qu'on permettait les drivers en Rust, le problème de la maintenance est inévitable. Refuser une API Rust commune pour le DMA ne résout rien : le code d’adaptation à l'API C va juste se retrouver dupliqué dans chaque driver et résoudre les impacts d'une évolution de l'API C sera encore plus complexe.

Pour limiter le poids sur les mainteneurs actuels qui ne connaissent que le C que le projet Rust for Linux c'est engagé a mettre a jour l'API et les drivers Rust en cas de changement dans l'API C.
Cloisonner l'usage de Rust aux "drivers" terminaux me semble une sage décision, d'autant plus dans un projet legacy où le cross language apporte de la complexité supplémentaire et où certains paradigmes de programmation sont très différents.
Et c'est bien le cas. Encore une fois le projet Rust for Linux crée juste des wrapper Rust pour permettre au drivers Rust de s'interfacer plus naturellement avec le code C du coeur du noyau. Il ne le modifie pas directement.
Si aujourd'hui on autorise un wrapper Rust dans le coeur de Linux, demain ce sera du code Rust dans le coeur de Linux.
Le wrapper permet au contraire d'établir une frontière claire entre le Rust du driver d'un coté, et le C du coeur de l'autre coté.

Le 11/02/2025 à 09h 50

Le refus de Christoph Hellwig est très très mal argumenté, étant donné qu'il a déjà été décidé que l'on allait accepter des drivers en Rust dans le noyau.
Yes, interfaces to the DMA API should stay in readable C code and not in weird bindings so that it reminds greppable and maintainable.
Les interface pour les drivers écrits en C restent en C, mais c'est normal que les drivers écrits en Rust aient une interface écrite en Rust tant qu'elle est maintenue à part et n'a pas d'impact sur le code C sous-jacent.
S'il grep le code qu'il maintient, il n'est pas impacté.
If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
L'interface étant maintenue à part par le groupe Rust for Linux, et pas directement dans le sous-domaine DMA. Dupliquer cette interface dans chaque driver poserait beaucoup de problème et ne résout rien.

Le 11/02/2025 à 09h 35

Il faut sortir du mythe du C qui permet de prédire ce qui sera compilé. Les compilateurs modernes font énormément d'optimisation qui font que plus grand monde a part des experts n'est capable de prédire les opcodes générés pour tout code non trivial. La seule chose qui est vraiment prévisible c'est l'arrangement mémoire, et c'est également le cas en Rust si on le souhaite.

Rust a des performances comparables au C, parfois meilleur, parfois en dessous, globalement au même niveau. Les règles d'ownership permettent notamment certaines optimisations difficiles en C.

Le 11/02/2025 à 09h 17

Parce que les PR demandent des changements dans des sous-systèmes existants... donc du code C en maintenance (par des gatekeepers :).
L'idéal pour Rust serait la création d'un tout nouveau sous-système écrit from-scratch en Rust.
Mais c'est pas tous les jours que Linux a besoin d'un nouveau sous-système :)

Et puis faut bien avouer que Rust... Comment dire...
C'est légèrement chiant comme syntaxe et frustrant en terme de limitations quand tu viens du C.

Perso j'ai découvert Zig et je ne veux pas retourner à Rust.
Ca me fait le même effet que TypeScript vs Javascript.

Parce que les PR demandent des changements dans des sous-systèmes existants... donc du code C en maintenance (par des gatekeepers :).
En l’occurrence non.
Le patch en question était juste une abstraction de l'API C pour le DMA pour permettre aux drivers Rust d'y accéder avec une interface adaptée au langage. Ca n'avait aucun impact sur le code existant.
L'idéal pour Rust serait la création d'un tout nouveau sous-système écrit from-scratch en Rust. Mais c'est pas tous les jours que Linux a besoin d'un nouveau sous-système :)
En l’occurrence ça arrive souvent pour les drivers et ça tombe bien c'est le premier objectif du projet Rust for Linux : pouvoir faire des drivers en Rust. C'est pour cela qu'il mettent en place une API en Rust pour accéder au sous-systèmes existants
Et puis faut bien avouer que Rust... Comment dire... C'est légèrement chiant comme syntaxe et frustrant en terme de limitations quand tu viens du C.
Pour ce qui est de la syntaxe Rust, je suppose que tu ne t'y est pas trop attardé trop longtemps. Ça m'a fait ça aussi au début, mais quand on a pris l'habitude, c'est la syntaxe du C qui parait bizarre.
Quant au limitation, il n'y en a pas vraiment. Certaines choses potentiellement dangereuses sont justes plus complexes a réaliser, mais c'est volontaire car il vaut mieux être sur de ne pas les faire par erreur.

Le 11/02/2025 à 09h 06

En fait le patch à l'origine du drama ne mélangeait pas C et Rust. C'était une abstraction en Rust qui se branchait au code C existant sans rien y modifier. Et les personnes en charge de Rust for Linux ont bien précisées qu'elles se chargeaient elles même de maintenir ce code si un changement dans le code du DMA en C cassait son fonctionnement.
Sur ce point je donne raison à Hector Martin : Christoph Hellwig n'avais pas de bonne raison de s'opposer. Dans la mesure ou il a été acté que l'on voulait pouvoir faire des drivers en Rust, c'est la meilleure méthode avec le moins d'impact possible sur les développement en C. Si on suit ses préconisations en s'opposant a tout code Rust même bien séparé du code C existant, c'est juste rendre impossible le projet Rust for Linux.

Ceci dit je rejoint Linus Torvald sur la critique de la manière dont Hector Martin c'est exprimée sur les réseaux sociaux, pour pousser Linus à prendre parti, plutôt que de le joindre directement, ce qui a jeté inutilement de l'huile sur le feu.

Le 21/01/2025 à 01h 44

Premier échec sur 6 vols, ce lanceur a volé plus souvent en 6 mois alors qu'il est en test. Ariane6 est en phase commerciale et il faut 2 mois pour préparer un lancement !

Une Facon9 tous les 3 jours et Vega-C n'est pas sorti des soins intensifs. Si le vol suivant présente la moindre défaillance, c'est la fin de ce lanceur.

Désolé mais ça me rend triste de voir autant d'argent, de personnes impliquées, pour ça. Tous les discours des politiques ne remplacent la réalité : l'Europe est un nain pour l'accès à l'Espace, alors qu'on a parmi les meilleurs technologies et chercheurs.

C'est difficile de parler d'échec ou de succès dans le cas du Starship, surtout en comparaison à Ariane 6. Certes le programme Starship a généralement rempli la plupart de ses objectifs lors des vols et a globalement fait mieux à chaque OTF (vol de test orbital), mais le Starship est encore un projet en cours d'évolution qui n'a pas encore atteint l'orbite. Et il devra encore beaucoup évoluer pour remplir correctement ses objectifs une fois qu'il l'aura atteinte.

Le 21/01/2025 à 01h 21

Autant ce que fait Space X avec les Starship est impressionnant, la comparaison avec Ariane 6 n'a pas de sens car aucun des sept prototype lancés pour le moment n'a rien déployé sur orbite, quand Ariane 6 a dès sont premier vol réussi a déployer correctement la majorité de sa charge utile.
Les Starship sont encore des prototypes développés de manière très différente. Il y a beaucoup de lancements, mais on sait qu'ils sont encore loin de l'objectif final.

La où la comparaison fait plus mal c'est vis a vis de la Falcon 9 qui réalise plusieurs lancement par semaine.

Le 12/01/2025 à 11h 48

En grande partie oui

Le 10/01/2025 à 02h 13

C'est probablement pas près d'arriver vu que la fonctionnalité a été volontairement retirée du navigateur il y a un moment déjà.

Le 08/01/2025 à 10h 14

Dans ce contexte, elle pourrait utiliser la suspension des enquêtes contre les géants numériques comme un levier de négociation.
Ce qui serait complètement idiot, en suspendant l’enquête avant de commencer les négociations, on affaiblit au contraire la puissance du levier.

Le 24/12/2024 à 14h 30

Le problème c'est que y'a pas un seul fabricant pour rattraper l'autre dans les imprimantes, au moins pour le grand public. J'ai l'impression que c'est un peu mieux pour le professionnel mais je connais pas trop.

Le 16/12/2024 à 10h 46

La question que je me pose, c'est est-ce qu'il y a moyen de faire une correction manuelle, du script. Pour le coup, je ne ferais pas confiance a une traduction automatique, mais pour des langues que je maitrise assez pour relire le script, ça me partait une excellente fonctionnalité.

Le 30/10/2024 à 22h 52

Open Office.

Après le rachat de Sun par Oracle, il n’avançait plus. Il y a eu le fork LibreOffice, avec le succès que l'on connait.

En effet, mais là je suis pas sur que ça puisse être reproductible pour Flutter.

LibreOffice était une décision coordonée d'une grosse partie des contributeurs suite au quasi abandon du projet par Sun puis Oracle. Là, ça à l'air d'être une personne qui part seule, alors qu'il reste une équipe conséquente active chez Google.

Le 27/10/2024 à 09h 05

Genre : utiliser un agenda ?

Oui mais intégré au site.

Le 25/10/2024 à 15h 02

Je sais bien. Mais dans 4 semaines, je vais oublier de le partager sur mes réseaux :p

Il faudrait une fonctionalité pour ça : marquer un article a partager plus tard.

Le 23/10/2024 à 11h 41

Après ce qu'a l'air de dire Linus c'est que ça va trop loin pour des cas quasiment impossibles à exploiter, parce qu'il y a maintenant tellement de recherche en sécurité qu'il y a toujours quelqu'un pour tomber sur le moindre truc pas parfait, dire que ça va être un problème et forcer tout le monde à surréagir. Il semble dire qu'il ne veut plus pourrir le code de Linux pour des cas comme ça.

Après, autant au niveau du noyau que des compilateurs, ces "pourrissements" doivent rester optionnels. On ne devrait les activer qu'à la fois pour les processeurs concernés dans une application à risque dans une situation à risque. Il ne faut pas les activer sans réfléchir et râler ensuite parce que ça se traîne.

Et le gars qui a besoin en même temps de performances et de sécurité maximale, il n'a qu'à pas prendre un CPU foireux et voilà, ou découper son traitement en une partie performante et une partie sécurisée, sur 2 machines différentes si besoin.

Après, autant au niveau du noyau que des compilateurs, ces "pourrissements" doivent rester optionnels.
Certes mais même si ça reste optionnel, ça rajoute de la complexité a développer, tester et maintenir.
Et le gars qui a besoin en même temps de performances et de sécurité maximale, il n'a qu'à pas prendre un CPU foireux et voilà,
Sauf qu'au moment ou tu achètes, tu ne sais généralement pas encore que le CPU est foireux. Et si tu as investi beaucoup tu ne vas certainement pas le jeter,

Le 21/10/2024 à 17h 10

Ils ont déjà amélioré la pollution lumineuse entre les Starlink V1 et 1.5, il n'est pas exclus qu'ils fassent de même pour la polution radio des Starlink V2.

Le 10/10/2024 à 20h 15

Ou bien rust ne sauve pas de grand chose!

Bien que Firefox soit une des applications existantes qui contient le plus de Rust, il contient toujours pour le moment plus de code en C++ qu'en Rust.

Les "use after free" sont normalement impossibles en Rust, sauf à mal utiliser du code "unsafe". Le but du code unsafe étant évidement d'être réduit au minimum pour limiter les risques.

Le 08/10/2024 à 19h 26

Bah oui, si tu ne fais aucune promotion pour les plates-formes alternatives tu ne risques pas d'attirer les gens.

Et oui, certes, tant que globalement une plate-forme est inconnue du grand public, tu ne peux espérer qu'un taux de conversion ridicule de ton public à toi (genre 1% à 5% selon le degré de "fan-itude").

Est-ce une raison pour rester pieds et poings liés à ton fournisseur actuel ? Non.
Si tout le monde cultive son baobab dans la main en attendant que les autres fassent le taff de promotion d'alternatives à sa place, rien n'avancera jamais.

À chacun de se sortir les doigts et faire SA part du taff, quitte à aussi bousculer ses "collègues" ou concurrents gentiment pour les inciter à s'y mettre aussi.

En parallèle, une lettre commune aux instances législatives pour mettre en avant le poids économique (ridiculement petit mais grandissant) et culturel (déjà plus conséquent) de la création de contenu sur Youtube pour proposer l'adoption de mesures de protection dans la loi serait autrement plus compliquée mais également très efficace sur le long terme.

Je joue pas a distribuer les bons points, bien sur que la diversité ferait du bien, et que ça serait bien que les vidéaste agissent pour ça. Mais dans la pratique on ne peut pas espérer qu'il le fassent eux même : ils ne le peuvent pas s'ils veulent que leurs vidéos soient vues.

Ça leur fait une belle jambe si ce qui peut éventuellement assurer le long terme est probablement fatal à court terme. Quand on est dans un domaine aussi concurrentiel que les vidéos web, on ne peut juste pas faire autrement que d'être sur les médias qui donnent de la visibilité ou on disparaît derrière ceux qui le font.

Le 08/10/2024 à 06h 11

Bien avant le coté clé en main, il y a surtout le problème de visibilité. Si les gens vont sur YouTube, c'est avant tout parce que c'est là qu'est le public.

Avoir des sources alternatives ne sert a rien si elles ne sont pas visitées. La plupart de ceux qui avaient choisi de diffuser sur plusieurs média différents en sont revenus car la complexité n'en valait pas la peine au vu du nombre de vue anecdotique sur les services alternatifs.

Le 08/10/2024 à 06h 37

Le problème, c'est que débattre quand on est pas d'accord sur le sens des mots qu'on utilise, c'est un bon moyen de finir avec un dialogue de sourds.

Le 08/10/2024 à 06h 34

Pour le coup je trouve au contraire que "algorithme" ou "heuristique" sont de très mauvais choix quand on parle de Machine Learning car ces termes font traditionnellement référence a des procédures bien définies avec un résultat prédictible, même s'il n'est pas forcément optimal.

Certes, l'apprentissage suit un algorithme défini, mais le programme exécuté au final suit une logique que l'on est incapable d'expliquer précisément.

Le 04/10/2024 à 15h 32

On disait ça de Facebook et ils ont bien fini par avoir un modèle commercial viable.
Pour autant, je ne parierais pas mes économies sur le fait que c'est ce qui va arriver pour OpenAI.

Le 18/09/2024 à 12h 31

Ça fait quand même un peu plus que le coût de 9 lancements FALCON 9 ou plus de 6 lancements de Falcon Heavy.
Édit : je ne sais plus compter ! Il a raison, c'est très peu.

Il doit y avoir un problème d'unité. Ça fait plutôt 1% du coût d'une Falcon 9, ce qui me parait quand même significatif à défaut d'être cher.

Le 17/09/2024 à 08h 42

Ou peut être en refroidissant d'avantage pour éviter le dépassement.

Le 14/09/2024 à 07h 15

Ils n'ont rien fait pour le Bitcoin, je vois pas comment il feraient quelque chose dont les perspective paraissent bien plus intéressantes.

Le 13/09/2024 à 10h 32

M'enfin, ils auraient pu utiliser 100 EB au lieu de 100 T MB. Ce n'est pas comme s'il n'y avait pas une norme internationale de notation des préfixes d'unités avec des symboles distincts. :byebye:

Ça oui c'est une grosse connerie.
Je parlais juste de l'échelle courte (million, billon, trillon, quadrillon, quitilion,...) qui est quand même plus simple que les (million, milliard, billon, bilard, trillon, ...)

Le 12/09/2024 à 14h 59

Alors on peux leur reprocher beaucoup de chose sur les unités, particulièrement les unités impériales, mais l'échelle courte est quand même plus pratique que l'échelle longe

Le 12/09/2024 à 14h 40

Pas mal d'applications on un délai variable pour éviter de surcharger les serveurs en faisant toute les mises à jour en même temps et pour pouvoir faire marche arrière sans impacter trop de monde si les premiers à a mettre a jour remontent un problème vraiment gênant.

Le 11/09/2024 à 07h 43

En même temps la solution pour augmenter les FPS et la résolution est sensiblement la même : un meilleur GPU.

Le 11/09/2024 à 05h 42

Je dirais comme argument, sauf erreur de ma part :
- la viabilité sur plus long terme. Les éditeurs de jeux sont obligés de se plier aux exigences techniques de la console à contrario du PC
- cela prends pas de place, fais peut être bien moins de bruit
- pls simple à lancer, il y a juste à allumer et à charger le jeu

Pour la viabilité à long terme, c'est même quand même contestable. La génération PS5 à déjà 4 ans d'age. Choisir une console Pro, c'est prendre une console qui durera moité moins longtemps qu'une console classique. Parce qu'il faut pas se leurrer quelqu'un qui attache autant d'importance aux performances pour payer ce prix ne gardera pas sa console longtemps à la sortie de la PS6.

Microsoft a fait un choix moins marketing, mais en fin de compte plus logique en proposant sa version Haute performance dès le début de la génération.

Le 09/09/2024 à 12h 17

D'accord, merci pour les précisions (oui, je sais, je me répète).

J'avoue que je ne suis pas Rust au jour le jour, donc c'est pas toujours évident d'avoir toutes les informations ^^

Théoriquement elle pourrait forcer le projet a changer de nom et de logo mais c'est tout. Elle ne peut notamment pas imposer le développement de certaines fonctionnalités, ou imposer des personnes dans les groupes de travail du projet.
En pratique, la fondation peut quand même faire sacrément pression : vous acceptez ça, ou on vous interdit dorénavant d'utiliser le logo, la marque, et les noms de domaines associés.

De son côté, elle peut forker le projet (il est libre), et faire ensuite évoluer sa marque Rust et le langage associé comme bon lui semble (et d'appeler le langage Rust).
Comme elle n'est pas propriétaire du code, elle ne peut pas non plus changer les licence du code.
Je ne sais pas si elle est propriétaire ou pas (d'ailleurs, y a-t-il un propriétaire) ? Par contre, elle peut changer la licence. Si je me souviens bien, Rust est sous licence MIT, qui autorise le relicensing tant qu'on conserve les attributions.

En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que de l'administratif, et n'a pas les moyens humains de soutenir un tel projet. Il faudrait qu'une partie substantielle des équipes actuelles la soutienne dans la démarche.
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.

Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.

Mais enfin, là on est dans la fiction improbable, le mandat de la fondation est de soutenir le projet Rust.

Le 09/09/2024 à 11h 12

D'accord, je comprends mieux ce que tu veux dire. Merci pour tes précisions ;)

La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Pas tout à fait vrai. La Fondation Rust, si j'ai bien suivi, dispose justement des marques et nom de domaines associés. Elle en est donc propriétaire, légalement parlant.

Mais j'ai bien compris que le côté décisionnel est géré par une équipe (la Rust Team Core existe-elle toujours du coup ?) plus ou moins indépendante vis-à-vis de l'évolution du langage lui-même.

La fondation est propriétaire de la marque, mais pas du projet. Théoriquement elle pourrait forcer le projet a changer de nom et de logo mais c'est tout. Elle ne peut notamment pas imposer le développement de certaines fonctionnalités, ou imposer des personnes dans les groupes de travail du projet. Comme elle n'est pas propriétaire du code, elle ne peut pas non plus changer les licence du code.

Le projet Rust est organisée en différentes team qui gèrent chacune certains aspect du langage (langage,compilateur, lib, doc, ...), la team Core gérant les aspect généraux. l’évolution du langage en lui même est plutôt géré par la Team Language

Le 09/09/2024 à 10h 37

Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla (contrairement a son projet jumeau Servo), car ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Je réagis la dessus, car je n'ai pas la même vision que toi.

L'indépendance de Rust est récente. La fondation Rust a été créé il y a un peu plus de 3 ans en 2021.

Pour Servo, pour recadrer, j'ai cru comprendre que nombre de contributeur de Rust faisait tout simplement parti de l'équipe en charge du développement de Servo. Donc Servo abandonné, c'était une bonne partie de contributeurs à Rust qui tombait. Et ça, c'était en 2020 (donc avant la création de la fondation Rust).
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Tant que le développeur originel du driver est là, pas de souci. Le jour où il part, s'il y a un bogue à corriger dans un driver, il faut un développeur qui connaisse Rust. Idem, les contributions externes, il faudra connaitre Rust. Aujourd'hui, vu le ratio des dev qui connaisse C par rapport à ceux qui connaisse Rust, ça peut être un véritable frein à la maintenance d'un driver.

Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un supporter du projet, certes vital au début, en faisant contribuer certains de ses salariés et en fournissant l'infrastructure du projet. Au fur et a mesure, d'autres sociétés ont apporté des contributeurs payés et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal supporter de Rust. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.

La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.

Le 09/09/2024 à 09h 12

Pour ma part, je vois ça comme une guerre d'ego... de la part de l'équipe de Rust.

Rust gagne en popularité, et le noyau Linux aurait certainement à gagner à inclure du Rust. Je ne dis pas le contraire.

Maintenant, il faut se replacer dans le contexte : Linux est un projet qui a 33 ans, qui est constitué de millions de lignes de code, et jusqu'à présent est écrit quasiment exclusivement en C, avec quelques morceaux d'assembleur propre à chaque architecture quand il n'est pas possible de faire autrement.

Rust, bien que présentant des avantages, a aussi des défauts. Le langage dans sa forme actuelle est encore jeune, sa popularité est récente, il a failli tomber après l'abandon par Mozilla en 2020. Il s'est plus ou moins stabilisé ces dernières années.

Sa courbe d'apprentissage n'est pas simple et nécessite un véritable investissement. Le noyau Linux, de part sa nature, nécessite aussi un véritable investissement pour y aller. Pour l'instant, il n'est qu'en C (ou quasiment). Si demain, il faut connaitre à fond et le C et le Rust, cela risque d'en rebuter plus d'un.

Le problème, pour moi, n'est pas tant de décider d'avoir du C ou du Rust, mais de faire cohabiter les deux, avec les soucis que cela peut engendrer. Une base de code, avec un seul langage, c'est quand même bien plus pratique. Comme il y a déjà des millions de lignes de code en C dans le noyau, le C à forcément un avantage certains de ce point de vue.

J'entends certains des arguments avancés par "l'équipe Rust". Mais j'ai l'impression aussi parfois qu'ils font une montagne d'un non-événement et parce que ce qui est présent actuellement ne permet pas à Rust de fonctionner correctement doit être changé (cf. les propos d'Asahi Lina).

Elle interprète ce refus comme des bâtons mis dans les roues de l'équipe Rust, alors qu'il peut très bien s'agir de conserver un comportement et un style de code homogène à travers l'ensemble des drivers. Car un changement, aussi mineur soit-il, quand il y a 50 drivers qui en dépendent, peut facilement créer des incompatibilités ou des effets de bords non prévus dans certains d'entre eux.

Vue la criticité du projet, il me parait plus que normal de ne pas sauter sur l'effet de mode du moment.

Rust, bien que présentant des avantages, a aussi des défauts. Le langage dans sa forme actuelle est encore jeune, sa popularité est récente, il a failli tomber après l'abandon par Mozilla en 2020. Il s'est plus ou moins stabilisé ces dernières années.
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla (contrairement a son projet jumeau Servo), car ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Le problème, pour moi, n'est pas tant de décider d'avoir du C ou du Rust, mais de faire cohabiter les deux, avec les soucis que cela peut engendrer. Une base de code, avec un seul langage, c'est quand même bien plus pratique. Comme il y a déjà des millions de lignes de code en C dans le noyau, le C à forcément un avantage certains de ce point de vue.
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Mais j'ai l'impression aussi parfois qu'ils font une montagne d'un non-événement et parce que ce qui est présent actuellement ne permet pas à Rust de fonctionner correctement doit être changé (cf. les propos d'Asahi Lina).
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique, y compris pour les autres drivers si j'ai bien compris.
J'ai l'impression qu'elle se plaint plus du ton des échanges que de la décision qui, comme tu le dis peut se justifier d'un point de vue risque de régression.

Le 08/09/2024 à 07h 47

C'est vrai et c'est actuellement ce qui est fait. Mais c'est uniquement valable si Rust ne reste qu'un wrapper du kernel, et ne mets pas à profit certains de ses avantages pour des fonctions bas-niveau du kernel plus sensible (e.g., FS, scheduler, IPC...). à l'heure actuelle sous Linux.
Mais dans ce cas, pourquoi s'embêter à maintenir deux langage ensemble si l'un des n'est qu'un wrapper ? J'en vois pas l’intérêt, et qui plus Rust est a une courbe d'apprentissage assez raide par rapport à du C.

Par contre, et c'est un scénario qui va arriver dans le futur si Rust reste, quid des fonctions codés en Rust vont devoir se brancher avec du C durant la migration de pans du kernel de C-> Rust ?

Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.

Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera pas avant de très très longues années, si jamais ça arrive, D'ici à ce que la question de généraliser l'usage de Rust se pose, Rust aura probablement déjà une API stable (il y a des travaux en cours).

Je pense qu'une grosse partie des problèmes actuels viennent de cette incompréhension. Le projet Rust for Linux n'a pas assez communiqué sur la limitation du scope de Rust. Certains ont eu l'impression que le but du projet était de tout réécrire en Rust.

Le 07/09/2024 à 22h 15

Rust a 10 ans passés. Il est maintenant mûr, il a montré de très grandes qualités native sur la sécu, le multitâche, les perfs et la conso de ressources.


Non, Rust n'est pas mur. Son ABI n'est pas encore très stable dans le temps et il évolue encore trop vite pour parler de maturité. Pour faire des codes qui vont être oublié dans le user-space, pourquoi pas. Mais pour un kernel (je parle pas des drivers), Rust va demander une plus grande maintenance de par ses futures évolutions.

Sur la sécu mémoires uniquement, Rust est en effet assez novateur.

Pour la partie perf, en monocoeur Rust est moins bon que le C compilé avec GCC en raison de LLVM, idem pour la partie conso des ressources. Mais ça reste à la marge en général. Par contre niveau du temps de compilation assez délirants pour être devant être mur.
Pour le multitâche, Rust est pas mal pour de la mémoire distribuée, il ne fait guère mieux que le C. Mais en mémoire partagées, sa manie de tout copier ou de mettre des verrous partout le rendent moins rapide que le C.


Par contre rust implémente certains concepts comme le parallélisme et le SIMD via des librairies de base et la syntaxe normale, pour le C c'est franchement de l'extension et ça sent bon la verrue depuis toujours par exemple.

Vrai question. Tu trouves le parallélisme sous Rust plus facile ? Déjà que la syntaxe de Rust est son plus gros défaut (à ce niveau même l'API de Windows est plus lisible) mais pour piger le calcul parallèle en Rust c'est juste infect. Trop verbeux, trop syntaxe inutilement cryptique. Pour le SIMD en Rust, c'est la même chose en plus de nécessiter de l'unsafe et devoir écrire de l'assembleur haut-niveau.
Alors, le parallélisme en C, ça peut vite devenir dégeu. Je suis d'accord. Mais le SIMD en C, non c'est clairement plus lisible qu'en Rust.
Et pour les deux, les libraires sont natives (i.e., fournit avec le compilateur).

Non, Rust n'est pas mur. Son ABI n'est pas encore très stable dans le temps.
Dans le contexte de Rust for Linux, l'ABI n'est pas un problème. en effet le code Rust devant interagir avec du C, il utilisera l'ABI C qui est stable.

Le 09/09/2024 à 09h 41

Même financièrement, s'il y avait eu perte des astronautes, les répercussions auraient été énormes sur les programmes spatiaux à venir, ce qui au final aurait sans doute couté bien plus cher que l'envoi d'une nouvelle capsule. Il suffit de voir ce qui est arrivé à la navette.

Pour Boeing ça aurait été une vraie catastrophe. Au point où ils en sont un demi-succès, c'est déjà pas mal.

Le 02/09/2024 à 08h 37

Bien évidement qu'il va y avoir une analyse par Space X qui a tout interet à ce que ça ne se reproduise pas.

Pour ce qui est du besoin d’enquête de la FAA avec interdiction de vol, c'est plus discutable car la situation est quand même différente d'un accident d'avion. Il ne s'agit que d'un échec d’atterrissage d'un appareil vide. Aucune vie n'est menacée et la chute en la mer du premier étage est la norme pour toutes les fusée en dehors de la Falcon 9.

Le 02/09/2024 à 08h 30

Pas vraiment étonnant comme décision, l'accident ayant au final peu de conséquences.

Le 30/08/2024 à 06h 42

Je comprend le côté cliché, mais en même temps, incarner un personnage "moyen", c'est bof quoi, je préfère un personnage exceptionnel, tant par sa puissance, que par sa beauté :p

Après sur les MMO, c'est différents, mais sur FF14, j'ai que des persos féminins :transpi:

Qu'on ne soit pas tenté par des persos moche, ça ce comprend. Mais les canons de beautés sont quand même plus variés que ce qui est proposé dans la plupart des jeux.

Le 29/08/2024 à 11h 01

Autant je trouve légitime la demande, le délai de 24 heures me parait difficilement tenable pour nommer sérieusement quelqu'un a un poste si exposé.

Le 28/08/2024 à 18h 38

Qu'est ce qu'il est fort Xavier Niel !
Il arrive à ce que des gens payent pour venir écouter sa publicité !

Le 28/08/2024 à 15h 10

En fait le soucis c'est que les élection fédérales sont synchronisée avec les élection locales pour limiter le nombre de déplacements aux urnes. Quand on va voter aux USA, on vote pour plusieurs chose à la fois : grands électeurs du président, juges, gouverneurs, ...