Ltrlg a écrit 9 commentaires

… plus une requête SQL erronée et des déploiements en prod sans tests (suffisants).

… et probablement quelques autres détails plus mineurs, vu que la liste de remédiation inclut des points non discutés.

En effet, l’article parle ici d’une autre permission dont l’usage est détourné :

I’ll conclude this post with a tiny example from Zepto. They ask for READ_SMS permission. You can deny it, but it’s mandatory if you sign up for Zepto Postpaid.

[…]

The point is when any app gets permissions like READ_SMS, as users, we have no visibility over when or what it’s accessing.

Si je lis bien, ils ont démontré qu’une simulation algorithmique n’est pas possible pour un modèle donné de notre réalité. Modèle par essence imparfait. Et, dans ces hypothèses hyper-spéculatives de méta-monde, la possibilité d’une simulation non-algorithmique ne peut pas vraiment être écartée (quoi que cela veuille dire). Bon, apparemment ils ne sont pas d’accord sur ce deuxième point (« Any simulation is inherently algorithmic »), mais leur formulation exclue l’usage de systèmes analogues du champ des simulations, ce qui me semble discutable.

Ce qu’ils ont démontré, c’est donc surtout notre incapacité à simuler ledit modèle notre réalité, ce qui est en soi un résultat important, mais aurait probablement fait un moins bon titre ?

Ce document ne semble mentionne pas de « triggers » (du moins sous ce nom) comme indiqué par le PP. Vu l’age qu’il a et son statut RC, ce ne serait pas très étonnant que la révision en cours d’écriture ajoute des exigences.

Cela dit, cette version vise déjà « l'envoi systématique et sécurisé dans Mon espace santé […] des documents de santé communiqués au patient » (certes avec la « non opposition [sic] du patient »), j’aimerais bien savoir ce qui peut faire fuiter plus de données.

L’ABI par défaut est instable. Et c’est plutôt bien, une ABI stable par défaut étant plus un inconvénient qu’un avantage pour un langage avec des génériques monomorphisés comme le Rust ou le C++ (le C++ permet de pré-monomorphiser pour contourner le problème, mais c’est limité et il faut y avoir pensé).

Cependant, on peut volontairement passer à une ABI stable via repr(C)/extern "C" (par exemple). Je n’ai pas vérifié, mais RfL étant une surcouche d’une API écrite en C, ils en utilisent probablement beaucoup à l’interface. C’est possiblement un peu plus de travail, mais ce n’est pas fondamentalement différent des restrictions à l’ajout de champs dans une struct exposée en C : une API n’a une ABI stable que si elle a été pensée pour.

Il existe toutefois un risque sur l’ABI lié au fait que GCC et LLVM ne sont pas toujours parfaitement d’accord et que mixer des objets en provenance des deux est risqué, les différences ne générant généralement aucun avertissement au moment de la liaison.

Il doit bien y avoirs des adorateurs du crabe qui passent sur le site; si ils ont des réponses…

J’ai cru comprendre que c’est une partie du problème : les mainteneurs sont accusés de faire partie d’une religion/secte qui veut imposer sa vision du monde au noyau, alors qu’eux s’estiment plutôt dans une optique d’élargissement des possibilités.

Un projet lancé trop tôt car Rust évolue encore […]

Quasiment tous les langages intéressants évoluent encore (à diverses vitesses) du fait des découvertes/inventions dans cette discipline si jeune qu’est l’informatique. Le formuler ainsi évite de détailler les potentiels problèmes sous-jacents : stabilité (Rust la garantit officiellement, la pratique est parfois plus compliquée, mais rarement, pas trop un problème pour RfL), maturité en fonctionnalités (RfL nécessite actuellement des features instables, ce qui est un problème ; RfL n’utilise pas l’écosystème Cargo, qui n’est donc pas un problème dans ce contexte).

L’historique montré dans Marie France est celui de Lucie Castets, avec une majuscule.

Lucie castets, avec une minuscule, avait 1. une erreur de typo dans le titre, 2. un contenu presque sans information (littéralement « Candidate proposée par le NFP pour le poste de 1er ministre »), 3. contournait une protection mise en place sur la version sans typo. Ça justifie raisonnablement une suppression.

Pour l’article sans typo, la troisième suppression ne se justifiait pas en immédiate à mon avis (un bandeau d’admissibilité + jugement différé aurait été plus pertinent), l’article contenant un début d’information (ce n’était pas le cas pour les deux premières suppressions).

Casser la compatibilité pour les pilotes plus souvent que pour les utilisateurs est explicitement prévu par les auteurs : Note: Semver Exempt API. Il faudra voir comment cette possibilité est utilisée, mais les pilotes tiers ne semblent pas une préoccupation des développeurs de sqlx (ce qui est compréhensible vus leurs objectifs, mais dommage pour les plus petits SGBD).

C’est à ma connaissance le premier changement de syntaxe de Javascript depuis belle lurette ; je dirais au moins 15 ans.

Alors, en regardant la ligne 6 (ES 2015, probablement la plus grosse évolution du JS – il y a 8 ans) de ce tableau :

Modules, classes, portée lexicale au niveau des blocs, itérateurs et générateurs, promesses pour la programmation asynchrone, patrons de destructuration, optimisation des appels terminaux, nouvelles structures de données (tableaux associatifs, ensembles, tableaux binaires), support de caractères Unicode supplémentaires dans les chaînes de caractères et les expressions rationnelles, possibilité d'étendre les structures de données prédéfinies.

En gras ce qui contient des modification de syntaxe, de mémoire.

Plus la ligne ES 2016 (7 ans) :

Mots-clés async/await, opérateur d'exponentiation, nouvelle méthode pour les prototypes de tableaux.

Plus récemment, le tableau est un peu vide mais en contient d’autres (plus mineures, certes).

[Edit] + gras sur « portée lexicale… », aka let/const.