votre avatar Abonné

Uther

est avec nous depuis le 8 avril 2006 ❤️

Bio

Oups.
On dirait que quelqu'un ici aime garder ses petits secrets, comme si de par hasard il y avait quelque chose à cacher...
Désolé, ô lectrice de passage, cher lecteur égaré, pas de révélation sensationnelle pour le moment sur ce profil.
Repassez plus tard ?

961 commentaires

Hier à 00h 14

Je sais pas comment marche Grinder, mais je trouve étrange que des athlètes se fassent surprendre sur le site olympique et pas chez eux. A priori le risque de se faire identifier sur Grinder me parait encore plus grand dans leur pays, où ils sont plus connus.

Le 23/07/2024 à 10h 46

Pour le coup je suis même surpris que Linux ne concerne que 60%. Chez nous quasiment tous les services Azure utilisent Linux.

Le 22/07/2024 à 10h 25

C'est en effet assez surprenant pour Apple qui cultive les écosystèmes fermé particulièrement ces dernières années. Mais en même temps, ça peut se comprendre en tant qu'opposition a ses concurrents Google / Microsoft dont les AI sont des boites relativement noires.

Le 18/07/2024 à 16h 09

Clairement, ça parait bizarre de prendre autant de risque pour ce qui est probablement moins de 3 mois de salaire.

Le 18/07/2024 à 14h 38

Il n'y aura pas de successeur en tant que station en orbite basse terrestre regroupant la plupart des nation importante du spatial.

Il y n'a cependant jamais eu autant de projet de station en cours avec notamment :
- La Lunar Gateway : une station internationale plus petite mais en orbite Lunaire
- La Station Chinoise déjà en orbite qui devrait obtenir le soutien de quelque partenaires.
- Axiom Space (société américaine) prévoit de mettre en orbite une station privé
- Voyager Space prévoit aussi une station privée (construite par Airbus)

Le 13/07/2024 à 07h 18

Espérons que SpaceX contrôle mieux la désintégration des satellites Starlink que les Chinois. ne contrôlent le retour sur Terre de leurs déchets spatiaux.

Dans le cas présent, la majorité des satellites ne répond pas, donc niveau contrôle, on est totalement dans la situation des chinois avec leur station spatiale.

Heureusement les satellites Starlink sont bien plus légers et devraient se désintégrer bien mieux. De plus la situation est consécutive a un accident, ce qui est plutôt rare pour Falcon 9, alors que les Chinois sont coutumiers du fait

Le 09/07/2024 à 19h 29

Sais-tu pourquoi la NASA a choisi Ariane 5 en lieu et place de Falcon 9 (pourtant déjà là) ?

Ariane 5 est un lanceur dont la fiabilité est reconnue. Et avec un vol bien contrôlé, contrairement à celui de la Falcon.

Il y a plusieurs raisons :
- La précision des lancement d'Ariane 5 reste une référence.
- A l'époque ou a été pensé le projet, Les falcon 9 / Heavy étaient loin d'être une option envisageable.
- Même si entre temps, Space X était devenu viable, James Web ayant été conçu spécialement pour être replié au mieux sous la coiffe de Ariane 5 un changement de lanceur aurait posé beaucoup de soucis, pour quasiment aucun avantage.
- Le lancement par Ariane 5 est entièrement offert par l'ESA, c'est sa contribution au projet JWST.

Le 09/07/2024 à 07h 34

Ariane A62 et Ariane A64 n'existent pas encore... mais juste sur le papier ou dans des modèles de simulation numérique dans des ordinateurs... on verra demain...

En 2012, 2 sénateurs ont rendu un rapport sur le réutilisable. Le CNES et ArianeEspace se sont bien assis dessus. En 2019, Stéphane Israël, PDG d'ArianeEspace, un diplômé de... l'ENA avec ZERO bagage scientifique au passage, a enfin fait un mea culpa durant une conférence de presse: "on s'est sans doute trompé sur l'importance du réutilisable"

J'espère vraiment qu'Ariane 6 va décoller demain mais ce que je veux dire, c'est qu'en Europe, on s'est cru tellement plus forts et plus intelligents que tout le monde quand on était les leaders, et surtout vis-à-vis d'un programmeur informatique sud africain... Et maintenant ça fait mal, très très mal... surtout quand on a sûrement pléthore d'ingénieurs très talentueux en Europe... Je t'invite d'ailleurs à regarder sur YouTube les vidéos officielles des 4 lancements StarShip (environ 2min chacun) et surtout la fin quand le "public" applaudit...

Ce sont tous les ingé. de SpaceX... Je sais que c'est naze d'être anti-vieux (j'ai déjà la quarantaine avancée) mais chez ArianeEspace, pas sûr d'avoir la même image de "public" et aussi enthousiaste.

Enorme gâchis !!

Pour résumer:

"ArianeEspace ou comment passer de leader mondial à looser total en moins de 20 ans"

Elon Musk avait dit il y a 2-3 ans dans la presse, grosso modo:

"Si ça n'a peté pas , c'est qu'on n'est pas allé au fond de la techno". En clair : "reculer les limites là où personne n'est encore allé". (les Trekkies reconnaitront)

En Europe c'est : "non non non, surtout pas de risque... ceinture & bretelles"
.

Pour être honnête, l'Europe n'est pas la seule a ne pas avoir cru au réutilisable. Après le semi-échec de la navette, Aucune agence ou même société n'y croyait vraiment à par Space X.

Avec son statut d'entreprise privé pilotée par seul un homme, en effet Space X à pu se permettre des choses que Ariane Espace ne pouvait tout simplement pas du fait de sa structure très dépendante des états.

Le 09/07/2024 à 06h 49

Après tant d'années, ça fait plaisir de voir que les nouveautés ne sont pas que sur le propulseur ou le réutilisable.

Réduire la masse et la consommation électrique c'est vraiment critique dans le spatial. Ça se fait en permanence depuis les débuts de la conquête spatiale, et on a jamais arrêté. C'est juste que c'est tellement trivial dans la conception d'engins spatiaux, que l'on en parle rarement en particulier, mais c'est un travail de fond.

Le 09/07/2024 à 06h 32

C'est en effet la limitation du LiFi : les obstacles peuvent couper la transmission. L'avantage d'une utilisation dans l'espace, qui est en énorme majorité constitué de vide, c'est que les obstacles entre un objet et l’atmosphère terrestre sont très rares et ne durent jamais trop longtemps.

Au niveau des nuages, ça pourrait éventuellement être un problème, mais si on peut se satisfaire de coupures ponctuelles, on doit pouvoir vivre avec.

Le 04/07/2024 à 11h 03

Par une tablette d'argile bien sur

Le 20/06/2024 à 12h 07

la source parle bel et bien de "Europe and Israel" (ils sont conscients que c'est pas en europe donc)

C'est comme pour les compétitions de foot, on a tendance a compter Israël avec les européens vu qu'ils ont du mal a s'intégrer avec leurs voisins.

Le 13/06/2024 à 11h 38

Après pour avoir une vision plus exacte, il faut voir plutôt la répartition par rapport à la diffusion d'information au global. Même pour les vraies information, il y a des comptes qui diffusent en masse.
Une grande partie de compte ne fait presque que le la consultation.

Le 06/06/2024 à 07h 12

A priori si le ship survit a son retour dans l’atmosphère (ce qui est certes loin d'être garanti). Il devrait aussi tenter un redressement pour atterrir dans l'eau en douceur et à la verticale.

Le 27/05/2024 à 14h 20

Il me semble que ça fait désormais partie des conventions internationnales de prévoir le désorbitage de satellites en fin de vie pour éviter la polution des orbites géostationnaires (entre autres) et limiter les risques de collisions avec des épaves

Une procédure de désorbitation est en effet prévue pour les satellites en orbite basse comme Kuiper et Starlink.

Pour les satellites en orbites géostationnaires, la désorbitation est souvent trop couteuse en carburant. En fin de vie, on les place plutôt sur des orbites cimetière.

Le 29/04/2024 à 10h 40

En effet, c'était le cas de la plupart des OS de l'époque.

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

Quelle était la part du gaz de schiste US dans l'approvisionnement de l'UE avant la guerre et quelle est-elle maintenant ?

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

On est d'accord sur un manque de documentation. Ce n'est pas pour rien que plusieurs équipes ont fait la même erreur.

Cela n'en constitue pas pour autant une faille dans l'API Windows.

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

La nuance de mon propos n'est pas de dire que X est mieux que Y. Mais de dire que X ou Y, peu importe, restons vigilants sur la sécurité et ne nous reposons pas sur des promesses, aussi avérées soient-elles.

D'où :

La sécurité IT ne repose pas sur une marque mais un ensemble de pratiques.


Choisir un langage apportant plus de sécurités fait donc parti de cet ensemble de pratiques. Auquel il faut ajouter la veille autour, et de ce qui est satellite. D'où mon exemple caricatural de "Linux c'est invulnérable aux malwares". Se reposer sur le discours de sécurité de Rust (que je n'ai jamais remis pas en cause, j'en suis incapable) est un risque en soit de réduire sa vigilance.

Exemple caricatural : le programme est plus sûr grace aux capacités du langage, tant mieux. Mais si la DB est exposée aux 4 vents, la sécurité est zéro pointé.

D'où, à nouveau :
La sécurité IT ne repose pas sur une marque mais un ensemble de pratiques.


Ma crainte au sujet du discours continu "Rust = plus sécurisé", c'est justement d'engendrer l'effet inverse.

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

Et pour le coup, si Windows ne fournit pas l'API pour éviter (car il s'agit de ça au final) de prendre les paramètres et de recréer une ligne de commande, alors oui Windows est responsable de la situation.


Ben non, pas d'accord. En quoi c'est une situation à éviter ? Ce sont des choix, différents (ce que je souligne depuis le début), et c'est de cette différence que vient le problème.

Et les deux ont aussi des différences en dehors du caractère d'échappement. Il est beaucoup plus simple avec l'approche de Windows de vérifier la taille max des arguments de la ligne de commande (alors que sous linux, il faut la reconstituer, sans oublier de compter les espaces !). Car oui, il y a une taille max !

De même, l'approche utilisée par Windows préserve les espaces. S'il y a besoin de 3 espaces entre deux arguments, c'est possible de le faire sous Windows, pas sous Linux.

Encore une fois, il n'y a pas une approche qui soit meilleure qu'une autre. Ce sont juste 2 approches différentes.

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

J'ai regardé l'article de blog cité pour plus de détails techniques.

Alors non, le problème ne vient pas de Windows. Le problème vient de la différence de comportement entre le monde Unix et le monde Windows (plus particulièrement, les caractères d'échappement à utiliser lors de la création d'un processus, où, sous Linux les spawn, popen, etc. utilise le backslash tandis que CreateProcess (l'API WIndows donc) utilise le caret (^).

Le fait que la même erreur ait été faite par plusieurs équipes distinctes dans plusieurs langages n'en fait pas un problème de Windows. Quand on appelle mal une API, il ne faut pas rejeter la faute sur l'API.

Des comportements Unix ont été calqués sur Windows, et après on vient dire que c'est de la faute de Windows. Le problème aurait tout aussi bien pu être dans l'autre sens, et là, personne n'aurait remis en cause Linux.

Comme expliqué dans l'article, on peut regretter que la communication soit axée sur Rust alors que la faille touche de nombreux langages. C'est juste que la faille a été découverte via Rust en premier.

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

Ce que je voulais dire c'est qu'une fois l'orbite atteinte, bah, pas beaucoup de possibilités de manoeuvre - changement d'orbite et autres. C'est plutôt embêtant pour un vaisseau de la taille du Starship...

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

En tout cas, comme le remarquait Hugo Lisoir sur un de ses lives précédents, le Starship arrive en orbite avec ses réservoirs à sec ! Ca ne laisse pas beaucoup de marge d'erreur ^_^;

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

On va pouvoir enfin ajouter une section « gestion des déchets des lanceurs durable » à leur site internet !

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

Le booster a bien rallumé les moteurs (puisqu’il a énormément réduit sa vitesse) mais il est arrivé au niveau de la mer à 1100kl/h.

Un peu comme pour les essaies de SN8, SN9, etc : quand ils essayaient d’atterrir avec juste un ou deux moteur, vitesse trop importante au sol et explosion. Quand ils ont refait le teste avec 3 moteurs, tout s’est bien passé !

Là, le booster n’avait que 3 moteurs, ils recommenceront sans doute avec 4 ou 5 pour réussir la prochaine fois.

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

Il n’était pas en orbite pour une bonne raison surtout : il faut atteindre 28.000km/h pour échapper à l’attraction terrestre et ils ont fait le test avec une vmax de 26.500km/h.

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

Il (ou ils ?) ont demandé l’inclusion dans le kernel linux…

Kernel linux = des milliards de périphériques à risque (serveurs linux, android, azure & co…)

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é.:yes:

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

Preum's ! :devil: Je t'avais laissé un délai raisonnable :fumer:

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

Tu peux très bien préciser l'état civil de la personne à la naissance par exemple, ça me parait + pertinent que de garder l'ancien nom comme titre de l'article wiki.

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

En effet. Mais comme toujours avec l'IA générative, l'essentiel est dans le prompt engineering. Si on veut en tirer le meilleur, il faut savoir comment le lui demander.

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

Pour le coup, vu la complexité des textes de loi, surtout dans le cas du fiscal, pour moi c'est un use case pertinent.

Dans le cas du travail législatif, l'obstruction parlementaire via le dépôt de très nombreux amendements (parfois pour une virgule dans un texte) est une technique rodée et utilisée peu importe l'affinité politique. Cette stratégie n'ayant que pour seul objectif de faire durer la session parlementaire et ralentir l'adoption d'un texte. C'est aussi un use case pertinent pour évaluer chaque amendement, surtout si jamais la tournure est tarabiscotée.

Ce serait d'ailleurs aussi un bon cas d'usage d'avoir un LLM qui résume les CGU inutilement longues, rédigées de manière à dissuader de les lire, ou d'une façon incompréhensible. Synthétiser, reformuler ou extraire de l'information dans un texte est une des finalités de ce genre d'outil justement.

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

Au moins Chrome ne tente pas d’être une app à tout faire… Edge par contre, plus le temps passe moins on a l’impression que c’est un navigateur.

Bon perso je suis sur Firefox alors :windu:

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

Quant au retour de la clé physique dont tu parles plus bas, tu parles de remettre des neiman dans tous les véhicules c'est bien ça ? :)


Tu peux verrouiller, déverrouiller et démarrer ta voiture lorsque ta télécommande n'a plus de batterie.

Généralement il y a une clé physique dans ta télécommande ou une puce passive.
Le sub-ghz c'est un confort mais ce n'est pas nécessaire.

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.
1 2 … 19 20