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.
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,
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.
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.
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 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.
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.
Ç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.
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.
Ç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
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.
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.
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.
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.
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.
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
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.
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, ...
Le
28/08/2024 à
14h
06
Oui c'est le problème de base des LLM. Leur but premier n'est pas de donner une réponse exacte mais juste de produire du texte crédible. Quand les informations sont dans le jeu d'apprentissage, il y a de bonnes chance qu'elles ressortent, mais sinon, ça va mes inventer.
En utilisant aussi la novlangue consistant à ne plus parler d'explosion mais de désassemblage imprévu rapide (Rapid Unscheduled Disassembly)
A priori c'est pas nouveau, l'expression était déjà connue dans le domaine de l'aéronautique. C'est juste Musk qui l'a fait connaitre au grand public.
Le
23/08/2024 à
07h
37
Toujours aussi bons pour traiter ce genre d'infos chez France Info : elle n'a pas explosé au décollage, mais pendant un test, le décollage devait avoir lieu dans les semaines a venir, sans date précise. C'est d'ailleurs dans la dépêche Reuters citée par France Info...
"This was a test, and test campaigns are designed to identify issues prior to the next stage," a spokesman for SaxaVord said. "We will work with RFA to understand and learn from the causes and support them as they move forward to the next phase of their preparations." RFA said it was trying to gather information to resolve what happened following an "anomaly" during the test, one of a number of trials in the run-up to a launch."
Alors oui France info n'est pas ultra précis, mais d'un autre coté le communiqué minimise le problème.
Même si c'était un test, à quelques semaines du décollage, on ne s'attend pas vraiment à avoir un moteur qui explose. Ce genre de chose devrait être normalement détecté bien plus tôt, lors des essais statiques des moteurs.
Le
22/08/2024 à
10h
09
l’étage supérieur de la fusée aurait implosé « en partie à cause d'une erreur d’un employé, alors [que l'étage] était déplacé vers un hangar de stockage ».
Je me doute bien que c'est plus compliqué que ça, mais je peux pas m’ôter de la tête l'image de l'employé qui va voir son parton pour dire "Boss, je crois que j'ai fait une petite boulette en rangeant la fusée."
Dans l'article de Reporterre, la madame est dite "militante"... et peut-on considérer ce média comme absolument factuel en regardant le bas de page ? Parce que des fois, çà peut donner qu'on est "2 millions place de la République" alors qu'en fait il n'y avait que trois pelés et un tondu. :-/
Reporterre est connu pour être clairement "souple" avec les données et la façon dont il les présente.
Pas forcément. Le code source n'a probablement jamais fini dans un tiroir, le code des différents composant inclus dans Windows devant être recompilable, au minimum, pour permettre de supporter les nouvelles plateformes. Par contre il est possible qu'en terme de qualité du code, ça ne soit pas aux standards actuel et que Microsoft trouve que ça soit une bonne occasion et le refaire avec les API Windows modernes.
Sur ce genre de matériel le bootloader est généralement verrouillé pour ne permettre d'installer que des mises a jour signées. De plus c'est pas sur que Valve ait tous les drivers optimaux pour le Roge Ally sur Linux.
Alors oui le projet vise le C legacy, entre autre pour permettre d'utiliser des fonctionnalités plus modernes et faciliter la maintenance. Sur ce point C++ aurait en effet pu être une alternative valable.
Par contre, si on souhaite améliorer la sécurité de l'application lors de ses évolutions à l'avenir, et particulièrement la sécurité mémoire, le Rust est clairement un choix bien plus avisé que le C++. Le C++ moderne a beau fournir des nouveaux mécanismes de gestion mémoire, ils sont, comme en C, conditionnés à une bonne utilisation, là ou en Rust (hors code unsafe) il y a des mécanismes qui garantissent l'absence d'erreur mémoire et de data race.
Le
13/08/2024 à
09h
03
J'ai donné de bonnes raisons, ainsi que des sources, voir autre message.
Pourquoi vouloir interdire des langages ? mieux vaut laisser l'adoption se faire de façon naturelle, et ici PHP s'est imposé, grâce à ses qualités.
Je suis d'accord avec le fait que l'on ait besoin de langages selon les projets, c'est d'ailleurs la thèse que je défend : utiliser un langage par cas d'utilisation, et pas un langage polyvalent partout qui cherche à tout faire (python, java, etc)
Chez vous, vous faites ce que vous voulez, cela vous regarde si vous voulez produire du code avec plus de lignes de code à maintenir, et avec des technologies qui n'étaient pas adaptées à l'origine (javascript).
Le problème c'est que vos raisons, qu'elles soient bonnes ou non (et certaines ne le sont clairement pas), sont de toute façon trop personnelles pour permettre de décréter que certains langages ont le droit de se développer et d'autres ne l'ont pas.
Le site que vous donnez pour source a établi ses statistiques, en gros, à partir d'une détection automatique par domaine exposé au Web(ce qui exclut les intranet), quand c'est techniquement possible (pour beaucoup de backends le langage n'est pas détectable). Bref les CMS sont certainement surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dis pas que les chiffres sont faux, mais que c'est une vision partielle, clairement pas suffisante pour décréter qu'il faut sanctuariser un domaine avec un langage dédié.
Pourquoi vouloir interdire des langages ? mieux vaut laisser l'adoption se faire de façon naturelle, et ici PHP s'est imposé, grâce à ses qualités.
Vous êtes le seul ici qui veuille interdire des langages. Si PHP a eu le droit de prouver son intérêt dans les années 2000 alors que Perl faisait bien le boulot jusque là, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Je suis d'accord avec le fait que l'on ait besoin de langages selon les projets, c'est d'ailleurs la thèse que je défend : utiliser un langage par cas d'utilisation, et pas un langage polyvalent partout qui cherche à tout faire (python, java, etc)
Sauf que comme je l'ai dit au dessus, les cas d'utilisation sont très nombreux, d'une importance variable en fonction des projets, et pas toujours parfaitement démarqués. La séparation entre langages front, back et client lourd, correspond peut-être bien à votre approche quotidienne du développement, mais c'est terriblement réducteur. Il peut y avoir plein d'autres critères qui font qu'un langage à de l’intérêt pour un projet.
Chez vous, vous faites ce que vous voulez, cela vous regarde si vous voulez produire du code avec plus de lignes de code à maintenir, et avec des technologies qui n'étaient pas adaptées à l'origine (javascript).
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de choses en une ligne cause souvent des mauvaises surprises. Enfin, Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP n'était pas non plus adapté à autre chose que des petits sites persos à l'origine.
Le
11/08/2024 à
18h
42
PHP est dominant puisqu'il représente plus de 75% des backends, et qu'il est plus simple que ses compétiteurs, qui d'ailleurs cherchent à être polyvalent, assurant un avenir radieux au PHP.
J'ai dû mal me faire comprendre, je crois en la nécessité d'avoir un langage par cas d'utilisation. On ne fait pas de desktop avec un langage backend, et inversement. Utiliser JS pour le front et le back, c'est une expérience qui s'est soldée par un échec pour ma part. Nodejs n'a pas réussi et n'arrivera pas à remplacer PHP, fort heureusement.
Sauf que là vous décrétez les langages à conserver selon les critères qui vous plaisent, au moment ou ça vous arrange.
Si on avait interdit les langages qui ont déjà un concurrent installé qui répond au même cas d'utilisation, le PHP n'existerait pas : le Perl faisait le boulot longtemps avant que le PHP ne devienne utilisable pour autre chose qu'un site perso. Le C++ n'existerait pas non plus, vu qu'au final il ne couvre pas de domaine que le C ne puisse aussi couvrir.
Même la notion de cas d'utilisation est discutable, les frontières ne sont pas toujours parfaitement claires. Même à l’intérieur d'un même domaines comme le front, back, standalone, ou l'embarqué, suivant les projets on peut avoir des besoins différents en terme de rapidité d'exécution, rapidité de développement, facilité de maintenance, sécurité, capacité d'abstraction, outils de dev disponibles, ...
Je sais pas d'où vous sortez vos 75% de PHP. Peut-être que si vous comptez les sites WordPress et les pages Facebook, vous arrivez à ce chiffre, mais c'est des cas où il n'y a pas vraiment de développement en PHP à réaliser. En tout cas, chez nous, et dans la plupart des boites que je connais, plus personne ne développe quoique ce soit de nouveau en PHP depuis plusieurs années déjà, sauf pour bricoler un Wordpress. Le back-end se fait majoritairement en Java, C# ou JavaScript. On commence à avoir quelques expérimentations en Rust.
Le
10/08/2024 à
01h
20
On ne peut pas bâtir une société sur des bases qui ne font que changer. En 2024 c'est un soit disant manque de sécurité qui pousserait à réécrire tout le code de la planète, en 2050 ce sera quoi ? et en 2100 ? sommes nous vraiment si médiocre que l'on est incapable d'évoluer, condamné à stagner ?
Les changements sont nécessaires quand il y a un blocage, je n'en vois pas avec le c/c++.
PHP et JS sont parfaitement adaptés à leur domaine, et pour cause, ce sont les gagnants de la compétition pour ces cas d'utilisation. Flash, java, tout cela a échoué. Pareil pour les divers frameworks backend, VB.NET, et autres perl, aujourd'hui le web moderne c'est php et sql.
Depuis les débuts de l'informatique, il y a eu plusieurs langages qui cohabitent et ça ne l'a pas empêche d'évoluer bien au contraire. On ne va pas bien sur pas migrer tout le code C en Rust du jour au lendemain. Une migration ça a des coût qui sont a mettre en balance avec les bénéfices. Le but de l'outil que souhaite développer la DARPA vise justement a réduire ce coût.
Le JS malgré son coté peu adapté aux grosses applications, s'est imposé de par le fait qu'il n'y avait pas d'alternative native sur navigateur (ceci dit, avec le développement de WebAssembly, ça pourrait changer à l'avenir). Il c'est répandu ensuite coté backend, en bonne partie grâce aux gens qui, comme vous, préfèrent avoir un seul langage mal adapté que faire l'effort d'en apprendre plusieurs efficaces, mais aussi grâce à npm qui a permis de gérer facilement un écosystème complexe.
Quant a PHP, non seulement il n'a jamais été dominant, sauf dans les CMS, mais il est clairement sur la pente descendante.
Le
09/08/2024 à
14h
18
Changer de langage de programmation a des couts en terme de développement, de compatibilité et de maintenance (rien à voir avec une ceinture donc), et puisque le c/c++ ne disparaitra pas, rust ne fait qu'ajouter de la complexité à un monde déjà assez complexe, si le c/c++ est jugé comme pas assez safe, alors en ce qui me concerne il serait préférable de corriger ces problèmes.
Les langages de programmation bénéficient d'effets de mode, le ruby c'était moderne, le c c'est dépassé, python c'est l'avenir il faut l'apprendre à l'école, etc. Maintenant c'est rust est sécurisé. Quoi qu'on dise c'est ce que la mode veut bien nous faire croire, chose fausse bien sûr. Nous avons eu la chance côté back end d'avoir php qui a été capable de tenir la barre et de permettre un environnement globalement uniformisé, je n'aimerais pas que cela devienne la foire côté bas niveau.
Certes il ne faut pas changer de langage tous les 4 matins pour suivre la dernière mode, il faut mesurer clairement les avantage et les coût d'un changement. Perso le Ruby ne m'a jamais parru intéressant, contrairement au Rust. Mais d'un autre côté, refuser globalement le changement est un vrai problème.
Corriger C et C++, beaucoup ont essayé, mais soit le résultat était très partiel, pas pratique et/ou incompatible. Le résultat général est que ça ne peux pas vraiment se faire bien sans créer autant d'incompatibilités qu'avec un nouveau langage. C'était l'idée de base de Mozilla avant qu'il investisse dans Rust. ils auraient voulu sécuriser C++ mais ils se sont rendu compte que vu le nombre de changement que ça impliquait il était préférable de partir sur une nouvelle base.
PHP et JavaScript sont d'autre langage qui sont clairement une plaie due à leur héritage. Il sont passés de langage de script simple à des langages complets pas vraiment adaptés à leur usage actuel.
Le
07/08/2024 à
09h
30
Débattre sur l'utilisation de la ceinture ne correspond pas au sujet de changer de langage de programmation, pour passer d'un langage qui peut être sécurisé à un langage qui peut être sécurisé.
Je suis pas sur d'avoir bien compris ta phrase, mais la comparaison avec la ceinture de sécurité est plutôt valable.
Dans les deux cas, ça reviens à dire qu'une augmentation des mécaniques de sécurité entraine une baisse de la vigilance. Dans la pratique, ça n'est généralement pas ce que l'on constate. En tout cas ça n'est pas le cas de la ceinture et il ne semble pas non plus que ça soit le cas pour Rust.
Le
07/08/2024 à
09h
17
C'est quelque chose que j'avais déjà noté dans les communications autour de Rust. Personnellement, je n'ai pas le bagage pour m'en assurer ou comprendre derrière comment ça marche.
Mais ce qui m'inquiète, c'est qu'avec une comm' basée autour de "c'est un langage sécurisé", ça provoque l'effet inverse par aubaine et un nivellement par le bas de la vigilance. La technique ne se suffit pas à elle-même, il ne faut jamais l'oublier.
Je comprends l'idée mais dans la pratique c'est pas du tout ce que l'on constate. Il faut voir que la sécurité mémoire en Rust ne fonctionne pas comme en Java ou Go ou tout est caché derrière un Garbage Collector, en Rust le développeur est juste contraint de prouver au compilateur que son code ne pose pas de problème. Il reste très conscient de ce qu'il faut faire pour assurer la sécurité.
Dire que la sécurité de Rust pousserait à ne pas faire attention au code, ça revient (en très gros) à dire que la ceinture de sécurité pousserait à être imprudent sur la route. Dans la pratique ce n'est pas du tout ce que l'on constate. Au contraire, boucler sa ceinture est un rappel quotidien de l'importance de la sécurité.
Le
07/08/2024 à
08h
52
"Le problème existe toujours en C et C++ qui font directement appel à l'API problématique de Windows."
Oui et? On est ici dans du code applicatif et si c'est Mozilla qui a initié Rust ce n'est pas pour rien: Quand on fait de l'applicatif en frontal sur internet, cela a du sens. Pour le reste, si un API de l'OS pose pb c'est ici à Microsoft de faire le job, le rôle de l'appelant aidant potentiellement à contrarier l'exploitation mais c'est un emplâtre sur une jambe de bois.
Car pour du code noyau/modules, si c'est pour passer son temps à contourner les barrières d'un langage qui prétends résoudre le problème largement traité de la gestion mémoire, je dirais que pour le C++ l'affaire se discute mais que le C n'est pas délogé. Et je ne parle même pas de code de démarrage ou sur certaines architectures, virer le C serait un retour vers l'assembleur (au lieu d'en avoir besoin de quelques %).
Même pour de l'applicatif, un manque de maturité des chaînes de génération (et leur évolution encore rapide) pose des problèmes aux mainteneurs/distribution.
Pour le reste, si un API de l'OS pose pb c'est ici à Microsoft de faire le job, le rôle de l'appelant aidant potentiellement à contrarier l'exploitation mais c'est un emplâtre sur une jambe de bois.
La solution de fournie par Rust aurait pu être plus simple si Microsoft avait fourni une meilleure API, mais ce n'est pas un emplâtre sur jambe de bois : le problème n'est clairement plus exploitable en Rust contrairement a pas mal d'autre langages. On est d'accord que Microsoft aurait du faire quelque chose, il ne pouvait probablement pas changer l'API, car cela aurait pu causer des régressions, mais il aurait du au minimum documenter le problème, au mieux il aurait pu fournir une fonction alternative qui n'interprète pas les paramètres qu'on lui passe comme une commande batch.
Il est quand même important de noter que Rust évite de laisser des trous béant au prétexte que ça n'est pas son problème (jusqu'à une certaine limite quand même). L'approche de la sécurité est généralement bien plus sérieuse dans l’environnement Rust que C et C++.
Car pour du code noyau/modules, si c'est pour passer son temps à contourner les barrières d'un langage qui prétends résoudre le problème largement traité de la gestion mémoire, je dirais que pour le C++ l'affaire se discute mais que le C n'est pas délogé. Et je ne parle même pas de code de démarrage ou sur certaines architectures, virer le C serait un retour vers l'assembleur (au lieu d'en avoir besoin de quelques %).
En effet dans les cas ou la majorité du code aurait besoin d'être "unsafe" pour contourner les règles de sécurité du Rust, l'intérêt du Rust est discutable et autant utiliser un autre langage. Mais dans la pratique, ce genre de code est extrêmement rare. On a déjà quelques noyaux d'OS et des modules Linux fait en Rust, et il apparait que la très grande majorité du code n'a pas besoin des blocs "unsafe". En limitant la quantité de code exploitable on améliore grandement la sécurité.
Quand à la sécurité mémoire en C et C++, c'est en effet un problème beaucoup traité, mais absolument pas résolu. Le constat est a peu près le même dans toutes les sociétés qui maintiennent de grosses applications C et C++ surveillées : 2/3 des CVE sont dues a des erreurs mémoire.
Le
05/08/2024 à
18h
44
Je parle des articles à foison (notamment parus sur ce site) qui sont plus ou moins des annonces. Ex: "Microsoft nous dit qu'il va reprendre tout Windows en Rust"; "passke c'est sécure".
Sous entendu "mettez vous à Rust" ...histoire qu'on puisse faire pression sur les salaires. Une manœuvre parmi tant d'autres.
Ca colle le sticker "sécurité" alors que ce n'est pas censé être la seul chose d'un langage. Et il y en a pas mal des chose a regarder dans un langage.
Et il y a le syndrome "open BSD". Avant sa sortie de la première mouture, ca disait "tain c'est trop sécure". Moins de 15 jours après des gens on trouvé des failles et la grosse rigolade a commencé.
Rust n'y fait pas exception. Et le jour ou tu en a un qui trouve un super gros trou... Ca se passera comme dans l'Internet habituel... pas besoin d'expliquer la déferlante de commentaires de répéteurs lolesque.
Je n'émets pas de critique sur Rust lui même. Pour moi (à mon âge) c'est un énième. Il y a une approche et tant mieux si cela fonctionne.
Mais les schémas se reproduisent. A cause de problèmes plus humain et structurels (voire d'un niveau religieux) on a du mal à améliorer un dispositif existant. L'entrepreneur n'y est pas pour rien non plus (Oracle???). Ca finit par se comporter comme un pachyderme à force d'immobilisme.
Du coups avec l'impatience qui frustre; cela fait "poper" un nouveau venu (comme Rust) un peu naturellement. Parfois en faisant de pires bêtises qu'avant. Ca n'a pas l'air d'être le cas de Rust mais ne jurons de rien.
La formation aussi n'est pas en reste. C'est l'humain qui fait la bêtise de ne pas gérer les erreurs ou de bien contrôler ce qui rentre et sort de ses programmes faute d'y avoir été sensibilisé ou d'avoir un problème de comprenette. Rust ou pas.
Et pour me faire comprendre. Et si on prenait la com' Rust à l'envers pour voir ? S'il se focalise sur la sécurité, y a-t-il des domaines ou c'est pas vraiment au top (gestion de liste, hash et j'en passe)? Vois tu ?
Le problème c'est qu'à chaque tour on revient en arrière. C'est à dire que plus on fait de langages ou cadriciels (dont la plupart restent dans l'oubli) plus on s'éloigne de l'universalisme.
Je ne suis pas un zélote, toutefois on a besoin de bases solides (nos chers libs et fonctionnalités de base). Et bien malheureusement il y a un trop grand nombre de problèmes non adressés sur le plan global.
Le bon sens a du mal a émerger. A chaque article Rust on parle de sécurité. Le bon sens voudrait qu'on parle de tout. Même des gros défauts.
Et comme SEBGF le dis. Restons vigilant.
Sous entendu "mettez vous à Rust" ...histoire qu'on puisse faire pression sur les salaires. Une manœuvre parmi tant d'autres.
J'ai l'impression que beaucoup des gens qui râlent sur Rust le considèrent comme un langage de type Java ou Python. Ça reste un langage de bas niveau avec des considération et des postes similaires. Des comparaisons que j'avais vues, les salaires étaient de l'ordre du C voire plus élevés.
Rust n'y fait pas exception. Et le jour ou tu en a un qui trouve un super gros trou... Ca se passera comme dans l'Internet habituel... pas besoin d'expliquer la déferlante de commentaires de répéteurs lolesque.
Là encore j'ai vraiment l'impression que ça parle de Rust sans bien le comprendre. Rust n'est pas une technologie de sandbox dans laquelle des hackers auraient a chercher des trous mais un langage de programmation qui permet, entre autre, de cadrer la façon dont on manipule les pointeurs pour empêcher les erreurs mémoire. Il y a déjà des bugs connus qui permettraient à du code complètement tordu, de contourner le borrow checker, mais personne n'écrirait ce genre de code.
La formation aussi n'est pas en reste. C'est l'humain qui fait la bêtise de ne pas gérer les erreurs ou de bien contrôler ce qui rentre et sort de ses programmes faute d'y avoir été sensibilisé ou d'avoir un problème de comprenette. Rust ou pas.
La situation continue depuis depuis 50 ans y compris dans les endroits critiques particulièrement surveillés. Si la formation suffisait, on aurait pas 2/3 des vulnérabilités critique causées par des erreurs mémoire dans les base de code C et C++ les plus surveillées (Google, Windows, Linux, Oracle, Apple, ...). Les gens sont quand même relativement sensibilisé au problèmes du C depuis bien longtemps, particulièrement là ou la sécurité est importante, mais les humains, même les meilleurs et les bien formés sont faillibles.
Et pour me faire comprendre. Et si on prenait la com' Rust à l'envers pour voir ? S'il se focalise sur la sécurité, y a-t-il des domaines ou c'est pas vraiment au top (gestion de liste, hash et j'en passe)? Vois tu ?
En effet Rust n'est pas le meilleur langage pour tout et il ne prétend pas l'être. Aucun langage ne le peux. Typiquement si la sécurité et la fiabilité ne sont pas un soucis et que les restrictions imposées par Rust posent problème, je ne vais certainement pas te recommander le Rust. Zig peut être une solution intéressante si on veut garder les performances du C avec des fonctionnalité plus modernes et moins de contraintes que le Rust.
Le problème c'est qu'à chaque tour on revient en arrière. C'est à dire que plus on fait de langages ou cadriciels (dont la plupart restent dans l'oubli) plus on s'éloigne de l'universalisme.
Autant la multiplication a l'infini des outils pose soucis. L'universalisme dans les langages, c'est pas une bonne idée non plus.
Le
05/08/2024 à
14h
46
Le narratif autour de Rust c'est de dire que le langage aide à prévenir les erreurs mémoire, ce qui est globalement vrai, ça offre même pas mal de garanties au delà. Par contre, pas grand monde ne prétend que c'est magique et que ça éviterait de réfléchir à ce que l'on fait. Rust s'étant construit avec une préoccupation de la sécurité dès son origine, ces limites sont au contraire souvent bien plus prise en compte par l'écosystème qui tourne autour que dans les autres langages. Les limites de la sécurité fournie par le langages sont plutôt bien documentées.
Là où je vois très souvent un soucis vis a vis de la compréhension de la sécurité, c'est plus au niveau de la promotion du C++. J'ai très souvent entendu dire, y compris par des gens relativement expérimentés que l'utilisation des fonctionnalités post C11 suffit à résoudre les problèmes de sécurité, alors qu'on est vraiment très loin du compte.
L'exemple que tu cites est justement un bon exemple de l’intérêt de Rust pour la sécurité. La base du problème c'est le fonctionnement inattendu de la fonction CreateProcess de l'API (en C) de Windows dans un cas particulier qui permet une injection. La bibliothèque standard de Rust a fourni un échappement automatiquement quand ça a été découvert. Le problème existe toujours en C et C++ qui font directement appel à l'API problématique de Windows. Ça n'a pas fait l'objet de CVE car on considère que c'est l'utilisateur de l'API qui est censé s'assurer lui même de l'échappement. Dans la pratique c'est terriblement complexe à faire de manière exacte, mais à la limite on pourrait dire que c'est dans la tradition du C : l'utilisateur doit bien maitriser ses outils. Sauf que pour cela, encore faudrait il que la procédure pour bien utiliser la fonction CreateProcess vis à vis de ce risque d'exploitation soit documenté. A ma connaissance, le seul endroit où c'est bien documenté c'est sur le blog du découvreur du problème. Microsoft pas jugé nécessaire ne serais-ce que de mentionner le risque dans sa documentation officielle. Ça montre clairement que s'il y a un soucis de désintérêt de la sécurité, il n'est clairement pas a chercher du coté du Rust.
1012 commentaires
Dénonçant un manque d’investissement de Google, un développeur forke Flutter
30/10/2024
Le 30/10/2024 à 22h 52
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.
Raisonnement des IA génératives : les benchmarks nous désinforment
25/10/2024
Le 27/10/2024 à 09h 05
Le 25/10/2024 à 15h 02
Linus Torvalds en a « marre » du matériel buggé d’Intel et AMD
23/10/2024
Le 23/10/2024 à 11h 41
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,
Les satellites de Starlink sont « une menace pour les observations astronomiques »
21/10/2024
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.Mises à jour pour Firefox, en raison d’une faille de sécurité critique
10/10/2024
Le 10/10/2024 à 20h 15
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.
YouTube présente ses excuses pour la suppression accidentelle de chaines et contenus
07/10/2024
Le 08/10/2024 à 19h 26
Ç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.
[Édito] Intelligence artificielle, algorithm(iqu)es… comment nommer ce champ étrange ?
07/10/2024
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.
OpenAI obtient 4 milliards de dollars de crédit, s’ajoutant aux 6,6 milliards de sa levée de fonds
04/10/2024
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.
La Federal Aviation Administration réclame 633 009 dollars à SpaceX
18/09/2024
Le 18/09/2024 à 12h 31
Ariane 6 : la cause du raté de l’APU identifiée, un correctif en cours de test
16/09/2024
Le 17/09/2024 à 08h 42
Ou peut être en refroidissant d'avantage pour éviter le dépassement.La Maison-Blanche veut concilier IA et climat
13/09/2024
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.En 2023, les Américains ont consommé 100 exaoctets de data sur les réseaux mobiles
12/09/2024
Le 13/09/2024 à 10h 32
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 longeVirtualBox 7.1 modernise son interface et apporte diverses améliorations
12/09/2024
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.PlayStation 5 Pro : Sony officialise sa console avec un GPU plus puissant, à 800 euros
10/09/2024
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
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.
Frustrations et départ dans l’équipe Rust du noyau Linux
06/09/2024
Le 09/09/2024 à 12h 17
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
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
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
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.
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
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
Starliner de Boeing est bien revenue sur Terre sans encombre, à vide
09/09/2024
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.
Falcon 9 de SpaceX de nouveau clouée au sol par l’administration américaine
29/08/2024
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.
SpaceX de nouveau autorisée à voler, déjà deux lancements de Falcon 9
02/09/2024
Le 02/09/2024 à 08h 30
Pas vraiment étonnant comme décision, l'accident ayant au final peu de conséquences.Dix ans après le Gamergate, où en est-on ?
29/08/2024
Le 30/08/2024 à 06h 42
Le Brésil pourrait suspendre le réseau social X
29/08/2024
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é.Xavier Niel à l’Olympia le 18 septembre : entre autobiographie et références à Free
28/08/2024
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é !
Après une erreur à propos des élections américaines, Grok renvoie vers vote.gov
28/08/2024
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, ...Le 28/08/2024 à 14h 06
Oui c'est le problème de base des LLM. Leur but premier n'est pas de donner une réponse exacte mais juste de produire du texte crédible. Quand les informations sont dans le jeu d'apprentissage, il y a de bonnes chance qu'elles ressortent, mais sinon, ça va mes inventer.Blue Origin aurait perdu deux étages supérieurs de sa fusée réutilisable New Glenn
22/08/2024
Le 23/08/2024 à 10h 17
Le 23/08/2024 à 07h 37
Même si c'était un test, à quelques semaines du décollage, on ne s'attend pas vraiment à avoir un moteur qui explose. Ce genre de chose devrait être normalement détecté bien plus tôt, lors des essais statiques des moteurs.
Le 22/08/2024 à 10h 09
Je me doute bien que c'est plus compliqué que ça, mais je peux pas m’ôter de la tête l'image de l'employé qui va voir son parton pour dire "Boss, je crois que j'ai fait une petite boulette en rangeant la fusée."Datacenter : Meta abandonne les Pays-Bas pour s’installer en Espagne
21/08/2024
Le 21/08/2024 à 09h 48
Raspberry Pi 5 : 2 Go et stepping D0 pour baisser le prix à 50 dollars
19/08/2024
Le 20/08/2024 à 01h 54
Windows 11 : Microsoft abolit la limitation de 32 Go en FAT32, sous conditions
19/08/2024
Le 19/08/2024 à 10h 42
Pas forcément. Le code source n'a probablement jamais fini dans un tiroir, le code des différents composant inclus dans Windows devant être recompilable, au minimum, pour permettre de supporter les nouvelles plateformes.Par contre il est possible qu'en terme de qualité du code, ça ne soit pas aux standards actuel et que Microsoft trouve que ça soit une bonne occasion et le refaire avec les API Windows modernes.
Valve travaille sur le support de la ROG Ally avec son SteamOS
14/08/2024
Le 14/08/2024 à 19h 46
Sur ce genre de matériel le bootloader est généralement verrouillé pour ne permettre d'installer que des mises a jour signées.De plus c'est pas sur que Valve ait tous les drivers optimaux pour le Roge Ally sur Linux.
La DARPA veut traduire automatiquement le code C en Rust
05/08/2024
Le 13/08/2024 à 09h 54
Alors oui le projet vise le C legacy, entre autre pour permettre d'utiliser des fonctionnalités plus modernes et faciliter la maintenance. Sur ce point C++ aurait en effet pu être une alternative valable.Par contre, si on souhaite améliorer la sécurité de l'application lors de ses évolutions à l'avenir, et particulièrement la sécurité mémoire, le Rust est clairement un choix bien plus avisé que le C++. Le C++ moderne a beau fournir des nouveaux mécanismes de gestion mémoire, ils sont, comme en C, conditionnés à une bonne utilisation, là ou en Rust (hors code unsafe) il y a des mécanismes qui garantissent l'absence d'erreur mémoire et de data race.
Le 13/08/2024 à 09h 03
Le site que vous donnez pour source a établi ses statistiques, en gros, à partir d'une détection automatique par domaine exposé au Web(ce qui exclut les intranet), quand c'est techniquement possible (pour beaucoup de backends le langage n'est pas détectable). Bref les CMS sont certainement surreprésentés alors que c'est le type de site sur lequel on programme le moins. Je ne dis pas que les chiffres sont faux, mais que c'est une vision partielle, clairement pas suffisante pour décréter qu'il faut sanctuariser un domaine avec un langage dédié.
Vous êtes le seul ici qui veuille interdire des langages. Si PHP a eu le droit de prouver son intérêt dans les années 2000 alors que Perl faisait bien le boulot jusque là, pourquoi Rust n'aurait pas le droit de prouver son intérêt aujourd'hui.
Sauf que comme je l'ai dit au dessus, les cas d'utilisation sont très nombreux, d'une importance variable en fonction des projets, et pas toujours parfaitement démarqués. La séparation entre langages front, back et client lourd, correspond peut-être bien à votre approche quotidienne du développement, mais c'est terriblement réducteur. Il peut y avoir plein d'autres critères qui font qu'un langage à de l’intérêt pour un projet.
La maintenabilité d'un code ne se mesure absolument pas au nombre de lignes, c'est même souvent le contraire. Faire trop de choses en une ligne cause souvent des mauvaises surprises.
Enfin, Dieu sait que je n'ai pas envie de défendre JavaScript, mais le PHP n'était pas non plus adapté à autre chose que des petits sites persos à l'origine.
Le 11/08/2024 à 18h 42
Si on avait interdit les langages qui ont déjà un concurrent installé qui répond au même cas d'utilisation, le PHP n'existerait pas : le Perl faisait le boulot longtemps avant que le PHP ne devienne utilisable pour autre chose qu'un site perso. Le C++ n'existerait pas non plus, vu qu'au final il ne couvre pas de domaine que le C ne puisse aussi couvrir.
Même la notion de cas d'utilisation est discutable, les frontières ne sont pas toujours parfaitement claires. Même à l’intérieur d'un même domaines comme le front, back, standalone, ou l'embarqué, suivant les projets on peut avoir des besoins différents en terme de rapidité d'exécution, rapidité de développement, facilité de maintenance, sécurité, capacité d'abstraction, outils de dev disponibles, ...
Je sais pas d'où vous sortez vos 75% de PHP. Peut-être que si vous comptez les sites WordPress et les pages Facebook, vous arrivez à ce chiffre, mais c'est des cas où il n'y a pas vraiment de développement en PHP à réaliser.
En tout cas, chez nous, et dans la plupart des boites que je connais, plus personne ne développe quoique ce soit de nouveau en PHP depuis plusieurs années déjà, sauf pour bricoler un Wordpress. Le back-end se fait majoritairement en Java, C# ou JavaScript. On commence à avoir quelques expérimentations en Rust.
Le 10/08/2024 à 01h 20
Le JS malgré son coté peu adapté aux grosses applications, s'est imposé de par le fait qu'il n'y avait pas d'alternative native sur navigateur (ceci dit, avec le développement de WebAssembly, ça pourrait changer à l'avenir). Il c'est répandu ensuite coté backend, en bonne partie grâce aux gens qui, comme vous, préfèrent avoir un seul langage mal adapté que faire l'effort d'en apprendre plusieurs efficaces, mais aussi grâce à npm qui a permis de gérer facilement un écosystème complexe.
Quant a PHP, non seulement il n'a jamais été dominant, sauf dans les CMS, mais il est clairement sur la pente descendante.
Le 09/08/2024 à 14h 18
Corriger C et C++, beaucoup ont essayé, mais soit le résultat était très partiel, pas pratique et/ou incompatible. Le résultat général est que ça ne peux pas vraiment se faire bien sans créer autant d'incompatibilités qu'avec un nouveau langage.
C'était l'idée de base de Mozilla avant qu'il investisse dans Rust. ils auraient voulu sécuriser C++ mais ils se sont rendu compte que vu le nombre de changement que ça impliquait il était préférable de partir sur une nouvelle base.
PHP et JavaScript sont d'autre langage qui sont clairement une plaie due à leur héritage. Il sont passés de langage de script simple à des langages complets pas vraiment adaptés à leur usage actuel.
Le 07/08/2024 à 09h 30
Dans les deux cas, ça reviens à dire qu'une augmentation des mécaniques de sécurité entraine une baisse de la vigilance. Dans la pratique, ça n'est généralement pas ce que l'on constate. En tout cas ça n'est pas le cas de la ceinture et il ne semble pas non plus que ça soit le cas pour Rust.
Le 07/08/2024 à 09h 17
Dire que la sécurité de Rust pousserait à ne pas faire attention au code, ça revient (en très gros) à dire que la ceinture de sécurité pousserait à être imprudent sur la route. Dans la pratique ce n'est pas du tout ce que l'on constate. Au contraire, boucler sa ceinture est un rappel quotidien de l'importance de la sécurité.
Le 07/08/2024 à 08h 52
On est d'accord que Microsoft aurait du faire quelque chose, il ne pouvait probablement pas changer l'API, car cela aurait pu causer des régressions, mais il aurait du au minimum documenter le problème, au mieux il aurait pu fournir une fonction alternative qui n'interprète pas les paramètres qu'on lui passe comme une commande batch.
Il est quand même important de noter que Rust évite de laisser des trous béant au prétexte que ça n'est pas son problème (jusqu'à une certaine limite quand même). L'approche de la sécurité est généralement bien plus sérieuse dans l’environnement Rust que C et C++.
En effet dans les cas ou la majorité du code aurait besoin d'être "unsafe" pour contourner les règles de sécurité du Rust, l'intérêt du Rust est discutable et autant utiliser un autre langage. Mais dans la pratique, ce genre de code est extrêmement rare. On a déjà quelques noyaux d'OS et des modules Linux fait en Rust, et il apparait que la très grande majorité du code n'a pas besoin des blocs "unsafe". En limitant la quantité de code exploitable on améliore grandement la sécurité.
Quand à la sécurité mémoire en C et C++, c'est en effet un problème beaucoup traité, mais absolument pas résolu. Le constat est a peu près le même dans toutes les sociétés qui maintiennent de grosses applications C et C++ surveillées : 2/3 des CVE sont dues a des erreurs mémoire.
Le 05/08/2024 à 18h 44
Là encore j'ai vraiment l'impression que ça parle de Rust sans bien le comprendre. Rust n'est pas une technologie de sandbox dans laquelle des hackers auraient a chercher des trous mais un langage de programmation qui permet, entre autre, de cadrer la façon dont on manipule les pointeurs pour empêcher les erreurs mémoire. Il y a déjà des bugs connus qui permettraient à du code complètement tordu, de contourner le borrow checker, mais personne n'écrirait ce genre de code.
La situation continue depuis depuis 50 ans y compris dans les endroits critiques particulièrement surveillés. Si la formation suffisait, on aurait pas 2/3 des vulnérabilités critique causées par des erreurs mémoire dans les base de code C et C++ les plus surveillées (Google, Windows, Linux, Oracle, Apple, ...).
Les gens sont quand même relativement sensibilisé au problèmes du C depuis bien longtemps, particulièrement là ou la sécurité est importante, mais les humains, même les meilleurs et les bien formés sont faillibles.
En effet Rust n'est pas le meilleur langage pour tout et il ne prétend pas l'être. Aucun langage ne le peux.
Typiquement si la sécurité et la fiabilité ne sont pas un soucis et que les restrictions imposées par Rust posent problème, je ne vais certainement pas te recommander le Rust. Zig peut être une solution intéressante si on veut garder les performances du C avec des fonctionnalité plus modernes et moins de contraintes que le Rust.
Autant la multiplication a l'infini des outils pose soucis. L'universalisme dans les langages, c'est pas une bonne idée non plus.
Le 05/08/2024 à 14h 46
Le narratif autour de Rust c'est de dire que le langage aide à prévenir les erreurs mémoire, ce qui est globalement vrai, ça offre même pas mal de garanties au delà. Par contre, pas grand monde ne prétend que c'est magique et que ça éviterait de réfléchir à ce que l'on fait.Rust s'étant construit avec une préoccupation de la sécurité dès son origine, ces limites sont au contraire souvent bien plus prise en compte par l'écosystème qui tourne autour que dans les autres langages.
Les limites de la sécurité fournie par le langages sont plutôt bien documentées.
Là où je vois très souvent un soucis vis a vis de la compréhension de la sécurité, c'est plus au niveau de la promotion du C++. J'ai très souvent entendu dire, y compris par des gens relativement expérimentés que l'utilisation des fonctionnalités post C11 suffit à résoudre les problèmes de sécurité, alors qu'on est vraiment très loin du compte.
L'exemple que tu cites est justement un bon exemple de l’intérêt de Rust pour la sécurité. La base du problème c'est le fonctionnement inattendu de la fonction CreateProcess de l'API (en C) de Windows dans un cas particulier qui permet une injection. La bibliothèque standard de Rust a fourni un échappement automatiquement quand ça a été découvert.
Le problème existe toujours en C et C++ qui font directement appel à l'API problématique de Windows. Ça n'a pas fait l'objet de CVE car on considère que c'est l'utilisateur de l'API qui est censé s'assurer lui même de l'échappement. Dans la pratique c'est terriblement complexe à faire de manière exacte, mais à la limite on pourrait dire que c'est dans la tradition du C : l'utilisateur doit bien maitriser ses outils. Sauf que pour cela, encore faudrait il que la procédure pour bien utiliser la fonction CreateProcess vis à vis de ce risque d'exploitation soit documenté. A ma connaissance, le seul endroit où c'est bien documenté c'est sur le blog du découvreur du problème. Microsoft pas jugé nécessaire ne serais-ce que de mentionner le risque dans sa documentation officielle.
Ça montre clairement que s'il y a un soucis de désintérêt de la sécurité, il n'est clairement pas a chercher du coté du Rust.