Le 17/04/2024 à 13h 08

C'est généralement réparti sur quelque heures pour éviter de surcharger les serveurs. Si tu vas dans le menu "Aide /A propos" tu peux déclencher la mise a jour immédiatement.

Le 15/04/2024 à 09h 22

J'arrive plus a retrouver les chiffre que j'avais. Mais j'ai retrouvé un récapitulatif inétréssant sur le site du conseil de l'union Européeene

On voit bien que les imports des USA (à 90% du gaz de schiste) ont été multipliées par 3, mais c'est vrai que le mix final reste plus équilibré que ce que j'avais en tête.

Le 15/04/2024 à 07h 47

C'est quand même a nuancer : on est passé d'une dépendance au gaz Russe à une dépendance aux gaz de schiste des USA. Ça parait certes moins risqué à court terme, mais il faudrait surtout réduire notre dépendance au gaz tout cours.

Le 13/04/2024 à 10h 31

Si tu parts du principe que l'utilisateur est responsable de la sécurité de ses paramètres mais qu'en même temps c'est l'implémentation qui fait foi et pas la documentation, en effet rien ne sera jamais une faille dans l'API.

Il n’empêche que, le fait que CreateProcess traite les arguments comme on traite une ligne de commande n'est ni le comportement auquel on s'attend, ni ce qui est documenté, et il en résulte une possibilité d'exploitation.

Dire si c'est une faille ou pas, c'est jouer sur les mots. En tout cas, ça en a les symptômes et ça devrait vraiment être corrigé, au minimum par une mise à jour de la documentation.

Le 13/04/2024 à 10h 05

Je comprend l'idée, mais je n'adhère pas vraiment au discours qui dit qu'on apporte plus d'attention à la sécurité quand on doit tout gérer, en tout cas c'est pas du tout ce que je constate dans la pratique.

Je suis d'autant moins convaincu que la philosophie de Rust contrairement à des langages comme Java, n'est pas d'automatiser les problématiques de sécurité pour les oublier, mais d'aider à les relever et à les prendre en charge, ce qui pousse au contraire à en prendre conscience. Rust m'a poussé a m’intéresser à la sécurité plutôt que l'inverse.

Je suis beaucoup plus conscient des problèmes de sécurité, y compris dans les autres langages, depuis que j'ai appris le Rust, et pas forcément que sur ce qui touche à la mémoire, car la communauté Rust ne tend pas vraiment à se reposer uniquement sur ce qu'offre le langage. Il y a notamment déjà pas mal d'outils qui permettent d'aller bien au delà des garanties mémoire du langage. De ce que j'ai pu constater, il y a beaucoup plus d'attention aux problématiques de sécurité en général dans les communautés Rust, que dans les communautés C et C++. C'est probablement pas pour rien que le problème a été identifié en Rust alors qu'il concerne bien d'autre langages dont certains depuis bien plus longtemps.

Le 13/04/2024 à 07h 51

Le problème c'est que CreateProcess à deux comportement différent suivant que le fichier qu'il exécute est un exécutable ou un fichier de commande et que le second cas n'est pas documenté.

Dans le premier cas les paramètre sont simplement passés comme arguments à l’exécutable, un simple échappement suffit, alors que dans le second cas les paramètre sont interprétés comme une ligne de commande ce qui n'est clairement pas ce qu'attendent les utilisateurs, et qui est difficilement échappable.

On pourrait au moins excuser ce comportement étrange s'il était documenté.

Le 12/04/2024 à 21h 38

Pour le coup le problème est aussi en C et C++. Rust en a hérité car il utilise la fonction CreateProcess de l'API Windows en C et C++. Et Rust considère que c'est un problème et l'a corrigé immédiatement alors que le problème va, semble-il, rester en l'état, au moins pour les langages Java, C et C++.

Donc même s'il n'est pas a l'abri de tous les problèmes, Rust reste clairement plus porté sur la sécurité que la majorité des langages.

Le 12/04/2024 à 21h 00

Le problème est plus compliqué que ça.

CreateProcess, quand il lance un exécutable (fichier exe) classique est correctement échappé. Le truc, c'est que si on lui fait exécuter un fichier de commandes windows (fichier bat ou cmd), il démarre en sous-main un interpréteur cmd.exe va traiter l'ensemble des paramètres comme une ligne dans un fichier de commande avec toutes les fonctionnalité associées beaucoup trop complexes pour un simple démarrage de script. Les règles d’échappement sont différentes, mais il y a aussi le fait que les variables d’environnement, mots clé et caractères spéciaux du langage batch sont traitées ...

Alors oui on peut dire que c'est un choix de fonctionnement de Windows et Rust doit s'adapter à la situation. C'est d'ailleurs ce que Rust a fait au final, là où Java a considéré que ce n'était pas son problème. Mais pour faire cela bien dès le début, encore aurait il fallu que ce comportement ait été correctement documenté. Or la documentation MSDN actuelle de CreateProcess ne dit rien de l'utilisation implicite de cmd.exe pour l'exécution des fichiers de commande, au contraire, elle propose de lancer cmd.exe manuellement.

Il est difficile de reprocher à Rust de ne pas avoir anticipé un comportement non documenté d'une API Windows dont les conséquence sur la sécurité avaient échappé a la plupart jusqu'à présent.

Le 05/04/2024 à 10h 23

En effet mais ça reste assez courant pour un lanceur. En général c'est le satellite lui même qui s'occupe de finaliser l'orbite.
C'est pour ça qu'il lui faudra un ravitaillement en orbite pour aller plus loin.

Le 17/03/2024 à 10h 49

Sur la version actuelle, au vu des données affichées sur les vidéo, il n'y a en effet pas beaucoup de marge de manœuvre. Mais en même temps il n'aurait fallu qu'une dizaine de secondes de poussé supplémentaire pour atteindre l'orbite, donc ça aurait été certainement possible même avec le peu d'ergol restant.

Si les nouveaux moteurs Raptor V3 tiennent leur promesse, ça devrait redonner de la marge au Starship.

Le 16/03/2024 à 16h 55

Après il y a plein de truc bien polluants dans le spatial, mais la carcasse d'un Starship qui retombe c'est vraiment anecdotique.
Le gros de la pollution entrainée par le Starship, c'est sa fabrication et ses émission de CO2 (et là aussi le plus gros étant du à la fabrication).

Le 16/03/2024 à 08h 10

Les métaux, surtout l'acier, c'est pas vraiment ce qui pollue le plus. Ça va juste rouiller lentement au fond de l'océan. Ça servira même de refuge à la faune marine, comme le font les épaves de bateau depuis des siècles.

En matière de produits chimiques une fusée n'est pas particulièrement plus chargée que la poubelle d'un français moyen. Les seuls produits chimiques qu'un Starship contient en masse, c'est du méthane, de l'oxygène et un peu d'azote. Le méthane et l'oxygène ayant brulé, il ne reste plus que de l'eau et du CO2. Quant à l'azote, autant dire que c'est pas un risque particulier vu que c'est 80% de ce que contient l'air que tu respires tous les jours.

Le 16/03/2024 à 07h 46

C'est les frottements de l'air qui on réduit la vitesse du booster.
Tu peux regarder la fin de la vidéo : il y a un schéma en bas à gauche qui indique les moteurs actifs. Tu verras que peu de temps avant le crash, les moteurs tentent de redémarrer, mais seuls quelques un y arrivent (sur les 13 prévus) et même ceux-là tombent en panne quasi immédiatement.

Le 15/03/2024 à 11h 32

C'est bien ce que je disais : il ne manquait que quelques secondes de poussée pour arriver à 28.000 km/h, ils auraient tout à fait pu le faire si leur but avait été de satelliser un Starship. Mais ils ont délibérément choisi de ne pas pousser jusque là, car une fois atteint cette vitesse, ils n'auraient certainement pas pu pousser en sens inverse pour décélérer et revenir sur Terre de manière contrôlée.

Un des buts principaux de la mission était de tester la rentrée dans l'atmosphère (et en effet c'était manifestement nécessaire). Ils ont donc choisi une trajectoire qui garantissait un retour.

Le 14/03/2024 à 20h 05

Sur le papier en effet, ça n'était pas une orbite complète. Mais c'est juste parce Space X a volontairement arrêté la poussée juste avant de l'atteindre, pour éviter de prendre le risque de se retrouver avec une bête de plusieurs milliers de tonnes potentiellement hors de contrôle. Car, si une fois en orbite, les moteurs ne redémarrent pas correctement, on risque de se trouver avec un Starship qui retombera on ne sait trop où et on ne sait trop quand.

Space X a bien fait la démonstration technique que le Starship est capable d'atteindre l'orbite basse, s'ils le souhaitent. Par contre, il leur reste à prouver qu'il peut en revenir.

Le 14/03/2024 à 16h 24

Le rallumage pour l’atterrissage des moteurs Raptor du Spaceship n'était de toute façon pas prévu pour ce vol. Elle devait faire un violent plat à la surface de la mer après avoir été freiné par l'entrée dans l'atmosphère.

Vu que la télémétrie transmise par Starlink et le système de transmission habituel de la NASA c'est arrêtée au même moment, il est fort probable qu'il se soit disloqué dans l’atmosphère et n'ai pas atteint de sol en entier.

A noter aussi un autre succès partiel concernant le booster qui a, cette fois ci, bien réussi son demi-tour. Mais dans la dernière partie du vol, il n'a pas réussi à bien se stabiliser, et n'a pas pu rallumer ses moteurs pour se poser en douceur.

Le 03/04/2024 à 08h 57

Pas besoin que ça soit dans le kernel Linux. Une backdoor dans OpenSSH touche déjà bien plus de machine intéressantes pour les pirates.
Quasiment tous ce qui permet le contrôle à distance par un technicien utilise OpenSSH aussi bien sous Linux, BSD, Mac et même possiblement Windows depuis quelques années. C'est à dire que presque tout serveurs et même une bonne partie des machines connectées auraient pu être compromis.

Le 20/03/2024 à 09h 53

En effet, j'ai utilisé le fantastique bouton "signaler une erreur", et ça a été corrigé.

Le 19/03/2024 à 10h 38

Si on se lance pas dans des projets nouveaux de temps en temps quitte à se planter et abandonner, on prend le risque de finir dépassé.

Mozilla a quand même quelques réussites à leur actifs et sont quand même autrement moins dispersés que Google.

Le 15/03/2024 à 17h 52

En même temps même sur les autres OS il n'utilisent pas leur propre moteur mais celui de Google (Blink).

Le 15/03/2024 à 17h 50

Ça y est aussi sur Firefox au moins.

Le 15/03/2024 à 08h 56

Ce qui est aussi certain, c'est que la plupart des gens ne savent pas que Brave a une politique "à la Adblock Plus" ou on ne bloque pas vraiment toutes les pubs et on se rémunère en prenant une commission sur celles qu'il laisse passer.
Le système de Brave est un peu plus tarabiscoté pour que ça soit moins flagrant, mais en gros l'idée c'est : on enlève les pubs existantes, on met nos propres pubs un peu plus discrètes, on récupère les sous à la place des exploitants des sites, et si Ils pensent à nous le demander gentiment, on leur en rendra une partie. Dans la vie réelle on appellerait ça du racket.

Le 25/02/2024 à 11h 12

J'aime beaucoup le dessin, par contre j'aurais plutôt mis une blouse blanche au chercheur plutôt qu'une cravate. Sans la légende, j'aurais cru que c'était un commercial.

Le 23/02/2024 à 08h 37

C'est exactement ce que je voulais dire. Il faut juste mentionner l'ancien prénom dans l'article, mais le titre et le contenu principal devraient utiliser le nouveau prénom. Une recherche de l'ancien nom devrait rediriger sur l'article avec le nouveau nom.

Le 23/02/2024 à 08h 32

Je pense pas que préciser le genre soit nécessaire, pour moi ce qui est vraiment important c'est l'ancien prénom, surtout si la personne a eu une activité notable avant sa transition, vu qu'il sera utilisé dans les sources.

Le 23/02/2024 à 08h 16

Je trouve en effet bizarre d’effacer totalement de l'article le prénom avant transition. L'ancien nom ne doit évidement pas être être utilisé pour faire référence à la personne dans l'article, mais il parait logique qu'il soit mentionné quelque part, particulièrement pour des personnes qui ont eu une activité notable avant leur transition vu qu'elles seront créditées avec leur ancien nom dans les sources historiques.

Le 16/02/2024 à 07h 56

C'est marrant, ce système sans compte, c'est ce que faisait Firefox Sync au début, mais ils sont passés a un système de compte classique car il se sont rendus compte que ce type de fonctionnement n'était pas naturel pour la plupart des utilisateurs

Le 15/02/2024 à 14h 55

En fonctionnant comme ça, le temps que Servo soit au niveau, Firefox serait mort depuis longtemps. C'est plus ou moins ce qui est arrivé à Netscape dont la réécriture du moteur a entrainé une trop longue stagnation et au final la mort. Recréer un moteur de zéro était déjà un pari dangereux à l'époque, de nos jours avec l'explosion de la complexité des techno web, ça serait juste du suicide, sauf pour des usages de niche très particuliers. Aucun navigateur qui vise une utilisation grand public ne peut se permettre de mettre en arrêt son évolution pendant des années.

Une grande partie de ce qui était particulièrement intéressant dans Servo a déjà été rapatrié dans Firefox, et c’était clairement ce qu'il fallait faire, même si pour la communication ça fait plus classe d'avoir un moteur tout neuf.

Le 15/02/2024 à 12h 05

Je sais pas si c'est toujours le cas, mais il me semble bien que les Freebox sont fournies gratuitement tout en restent bien propriété de Free.
Du coup a on vraiment intérêt de les démonter pour autre chose que la curiosité ? Et a on même le droit d'y remplacer quoique ce soit ?

Le 14/02/2024 à 19h 21

Sauf qu'un LLM n'est pas "intelligent" dans le sens oui il ne va pas trouver les détails particuliers qui ne lui ont pas été appris spécifiquement.

Même avec un bon prompt on ne couvrira pas toutes les subtilités possibles et si ça se développait,nul doute que les rédacteurs de CGU en tiendraient compte et spécialiseraient subtilement leur rédaction pour passer au travers.

Le 14/02/2024 à 18h 55

En effet une IA pour les CGU semble fort intéressante au premier abord, le problème c'est qu'il serait facile de glisser un petit détail essentiel qui sera perdu dans l'IA dans son résumé.

Le 14/02/2024 à 19h 12

Heu si clairement Chrome essaie d'être plus qu'un navigateur avec l'intégration des services Google et Chromecast, entre autre. Et même au niveau de la normalisation, il pousse des API techniques comme l'USB qui n'ont rien a faire dans un navigateur.

Le 13/02/2024 à 20h 17

Même sur ma Clio d'il y a plus de 15 ans, le verrouillage électronique empêchait de démarrer quand les piles de la télécommande étaient vides.

Le 08/02/2024 à 09h 31

Cool, j'ai hâte de pouvoir faire des gun fights entre Mickey et la Belle au bois dormant.

Le 02/02/2024 à 12h 01

Le soucis à l'époque, c'est justement qu'ils n'ont pas changé le système de numérotation alors qu'ils sont passés d'un système de sorties majeures non planifiées avec approximativement une version par an à un modèle de type agile avec des sorties toutes les 6 semaines.

Pour le coup s'ils étaient passés a une numérotation par date, ça aurait évité pas mal d'incompréhensions.

Le 30/01/2024 à 15h 15

Moi qui gardais un petit espoir que Free revienne sur ce qui a fait sa force sur le fixe, à savoir une offre claire et efficace, avec une box maison inspirée, autant dire que c'est foutu.

Sur le fixe, depuis la Freebox Delta, Free est en panne d'idée. Il a abandonné son segment tarifaire traditionnel en se prenant pour Apple mais il peine a fournir une valeur ajoutée qui justifie ce changement.

Au final Free fait exactement ce que je détestais chez Orange avec de l'inclusion de services tiers, et en cachant le prix réel sous des offres de réduction temporaire. Et au contraire, c'est Orange qui propose maintenant via Sosh des abonnements efficaces et sans fioritures.

Le 30/01/2024 à 08h 04

Ça n'a rien de surprenant : c'est compliqué de maintenir plusieurs versions différentes d'un logiciel surtout avec un changement si fondamental que le moteur de rendu d'un navigateur. Bien sur qu'ils aimeraient bien sur revenir à Gecko, mais si ce n'est possible qu'en Europe, en passant par des système d'installation alternatif pas facilement découvrable, ils ne pourront pas toucher pas grand monde a par quelques geeks motivés. Le coût n'est vaut pas la chandelle.

A priori les API web de iOS ne sont pas changées donc le navigateur interne restera webview. En théorie, une application européenne pourrait embarquer Gecko ou Blink mais ça obligerait a intégrer tout le navigateur dans le package de l'application le rendant inutilement lourd.

Le 25/01/2024 à 21h 51

C'est quand même triste de voir que Free a abandonné l'argument tarifaire alors que c'est ce qui les a fait connaître historiquement. Leur forfait bas de gamme maintenant deux fois plus cher que ce qui se fait chez la concurrence, hors période d'essai.
L'époque du forfait simple et efficace avec des outils maison léchés est terminée. Maintenant leurs commerciaux ne savent plus vanter que les abonnements Netflix et autre service tiers associés. Pour moi ce qui faudrait à Free c'est un retour aux source.

Le 17/01/2024 à 11h 17

On va dire qu'ils avancent bien plus vite que le SLS, mais même si les progrès sont impressionnants, le Starship n'a pas encore tout a fait validé l'orbite basse terrestre, là ou le SLS a déjà réalisé une orbite d'injection trans-lunaire.

Pour arriver sur la Lune le Starship doit même au point le ravitaillement en vol, se qui pour le coup reste une sacrée inconnue

Le 17/01/2024 à 10h 55

Malheureusement non, Space X est connu pour garder pas mal d'informations secrètes. Et même ce qu'elle partage avec la NASA est généralement sous le coup du secret industriel.

C'est toute la différence avec la NASA qui publie tout ce qu'elle fait directement, car c'est une agence d'état.

Le 13/01/2024 à 19h 31

De ce que j'ai compris, ce n'est pas obligatoire, même si tout est fait pour y pousser. Mais j'avoue que je n'ai jamais testé.

Le 05/01/2024 à 09h 28

Je l'ai pas testé personnellement, mais de ce que j'ai compris, ce n'est plus aussi verrouillé qu'avant et il y a la possibilité de l'utiliser comme un Linux plutôt classique non ?

Le 11/01/2024 à 09h 37

Bien sûr, on peut toujours transitionner d'un noyau vers un autre en passant par l'intermédiaire d'une couche de compatibilité, mais on est plus dans le simple changement de langage : je doute que ce dont parlait Refhi.

Et je doute encore plus que l'on puisse se permettre ça sur Linux actuellement. Il y aurait beaucoup trop de problèmes de compatibilité. Pour faire ça sur un produit si établi, il faut être une entité forte comme Apple ou Microsoft. Sur du libre ça conduirait fatalement à des forks et un risque de fragmentation de l'écosystème.

D'ailleurs, même Microsoft a abandonné son expérimentation de remplacement du noyau NT de Windows, de peur de déstabiliser son écosystème.

Le 11/01/2024 à 04h 43

Tout à fait. Mais là on est dans le cadre du projet personnel. Il n'a pas forcément à apporter une révolution. Il peut tout a fait disparaitre comme la très grande majorité des projets du genre. Ce genre de projet sert quand même à confirmer l'efficacité de Rust pour ce genre de tâche, même si on s'en doutait un peu vu de ses caractéristiques, c'est intéressant d'avoir des retour pratiques.

En effet Moturus OS a une bien meilleure valeur ajoutée. Redox OS d'un autre coté à aussi l’intérêt de miser sur une architecture micro-kernel et de proposer une alternative au traditionnel UNIX.

Le 10/01/2024 à 17h 38

Après on est jamais à l’abri qu'un petit projet plaise et arrive a fédérer une communauté grandissante jusqu’à intéresser les professionnels. C'est ce qui est arrivé à Linux qui à la base n'était qu'un petit projet sans ambition comparé à Hurd qui envisageait de devenir la référence de l'écosystème GNU.

Beaucoup de projet resteront discrets et oubliés, c'est la dure loi de la sélection naturelle logicielle. 😊

Le 10/01/2024 à 17h 32

C'est peu probable! Maestro est un noyau UNIX like mais, à première vue, ne vise pas à être 100% compatible avec Linux. Si un jour on faisait une migration de Linux en Rust, ce qui est de toute façon déjà peu probable, il faudrait que le code du nouveau noyau ait une API et un comportement 100% compatible.

Le 10/01/2024 à 17h 20

Il ne s'agit pas encore de réécrire cœur du noyau en Rust, juste de permettre de contribuer en développant des modules (donc principalement des drivers) en Rust.

Le 21/12/2023 à 15h 28

Il faut espérer. Pour le moment il y a juste eu une décision juridique en se sens pour plusieurs autre qui sont allées dans le sens d'Apple. On est pas a l’abri d'un appel qui annule cette décision.

Et même si le sideloading est autorisé il est probable que rien ne changera pour les règles de l'Apps Strore, et je suis pas sur que grand monde osera se passer de l'Apps Store tout comme pas grand monde n'ose se passer du Play Store sur Android.

Le 21/12/2023 à 09h 06

Malheureusement c'est plus compliqué sur iOS car Apple interdit sur l'App Store les navigateurs qui n'utilisent pas le moteur web maison. Du coup Firefox iOS se retrouve avec un moteur imposé qu'il lui est impossible de personnaliser directement.

Le 21/12/2023 à 09h 12

Uranus est la seule planète du système solaire à avoir un axe de rotation quasiment horizontal alors que les autres sont quasiment verticaux.

Edit: grillé (seconde position)