votre avatar Abonné

fdorin

est avec nous depuis le 26 mai 2017 ❤️

2777 commentaires

Le 29/04/2024 à 16h 18

Peut-être alors qu'il faudrait arrêter de leur proposer un tournevis pour planter des clous. (en l’occurrence, leur proposer une perceuse-laser-lance-missile pour planter des clous).

Peut-être qu'il faudrait arrêter de leur assurer à coup de gros plans de communication que c'est le futur de planter des clous avec des cotons-tiges nucléaires en mousse Bio.

Peut-être qu'il faudrait contraindre ces acteurs d'arrêter d'évacuer d'un revers de la main les dégâts collatéraux des technologies qu'ils créent. (ici la vie privée et le respect de la loi, mais les dégâts collatéraux des LLMs sont plus plus larges que ça).

Peut-être qu'il faudrait dire STFU aux OpenAI et consorts et reprendre la maîtrise de nos solutions techniques.

EDIT: clarity

OpenAI propose une brique. Quand des gens "ne sachant pas" utilise cette brique, ça donne NumeroBis comme architecte (cf. Astérix et Cléopatre). Est-ce vraiment de la faute de la brique ?

Dans ce cas, le discours que tu tiens, on peut le tenir sur plein d'objets de la vie courante :
- des voitures sont utilisées comme voitures bélier / faire des attentats => il faudrait que les constructeurs de voiture prennent leur responsabilité
- les couteaux : idem
- les médicaments pour les diabétiques détournées pour maigrir => c'est la faute des labo
- le protoxyde d'azote détourné en tant que drogue ? => c'est la faute de l'industrie culinaire
- ...

Attention, je ne dis pas qu'OpenAI est blanc comme neige (loin de là même). Notamment sur les jeux de données ayant servi pour les entrainements.

Je dis juste qu'il faut que chacun prenne ses responsabilités, et que lorsqu'un outil se comporte mal, ce n'est pas forcément la faute de l'outil, mais de celui qui s'en sert. Ce qui, pour moi, est le cas ici, car jamais OpenAI a dit que ChatGPT était une encyclopédie. Et OpenAI n'a cessé, depuis le début, de dire que ChatGPT pouvait dire des âneries.

Le 29/04/2024 à 15h 31

Exactement. Un LLM, c'est juste un pipotron extrêmement avancé.

Les hallucinations n'ont de réelles existences que pour la simple et bonne raison que certains s'en servent comme d'un moteur de recherche (par exemple, les jurisprudences hallucinées).

Quand les gens apprendrons à utiliser correctement leurs outils, ils arrêteront peut être de vouloir planter des clous avec un tournevis...

Le 29/04/2024 à 15h 08

Yes !! Je vais faire rapidement une appli avec MySQL. Mot de passe stockée en clair. HTTP uniquement, pas de HTTPS. Qui me suit ? J'ai besoin d'un investisseur :windu::D:copain:

Le 29/04/2024 à 14h 06

Je veux bien ta source, je n’ai pas le souvenir d’avoir particulièrement dit ça mais je peux me tromper.
Des changements il y en a eu énormément et sur une base quotidienne depuis la reprise du coup il va falloir m’expliquer la différence entre le bon et le mauvais changement.
Et du reste, j’ai aussi du mal à comprendre le principe du délai de prévenance.

il va falloir m’expliquer la différence entre le bon et le mauvais changement.
C'est comme le bon et le mauvais chasseur.

:humour::pastaper:

Le 29/04/2024 à 14h 04

Une amende ca se gère: contestation de la décision, renégociation du montant, paiement différé, etc.

C'est pas comme une interdiction à la TikTok, Huawei, Sputnik...
Là oui, ca serait surement dissuasif.

Mais faut pas rêver que l'UE bannisse un des fleurons de la tech US.

Une petite amende, ça se gère. Une amende d'un tel montant, ça s'évite.

Va expliquer ensuite aux actionnaires qu'il y a 40 Milliards de moins sur les bénéfices, et que la prochaine fois, ce sera peut être 80 ! :stress::mdr:

Le 29/04/2024 à 11h 57

J'ai du mal à comprendre la position d'Apple.
Pourtant c'est simple.

Il s'agit de lutter contre une perte de revenu induite par l'ouverture d'un écosystème fermé.
Lutter de toutes ses forces, le plus longtemps possible.

Avec l'IPhone, Apple s'est découvert une colossale source de revenus directs et indirects.
Je ne vois pas quelle autre source de revenus pourrait la remplacer.

Les critiques/amendes ne sont des effets secondaires qui seront gérés par les services concernés (communication, juridique...).

Si je me doute que les critiques ne sont pas dissuasives, les amendes dans le cadre du DMA le sont : jusqu'à 10% du CA mondial (qui peut monter à 20% en cas de récidive). Est-ce qu'Apple fait plus de bénéfices en Europe que 10% de son CA mondial ?

Par exemple, pour 2022, le CA annuel était de 394,3 milliards de dollars. Soit une amende pouvant aller jusqu'à 39,43 milliards de dollars juste pour l'Europe. Est-ce qu'Apple fait plus 40 milliards de bénéfice sur le sol européen ? Même si c'est le cas, ça doit commencer à piquer un peu quand même, et sans doute beaucoup plus qu'une "simple perte d'une part de marché".

Le 29/04/2024 à 08h 34

Or, l’un des points stipule qu’en cas d’achat sur un autre site depuis un lien dans une application, Apple a droit à 27 % de commission, si l’achat est réalisé dans les sept jours suivant l’appui sur « Continuer », quand l’App Store informe que le lien renvoie vers un site extérieur. Et puisque Apple considère que l’incitation vaut un lien direct, elle veut sa part du gâteau.
Apple interprète les choses comme cela l'arrange.

Quand il s'agit d'appliquer le DMA, c'est des "oui mais", avec des conditions tellement stricte que cela en devient quasiment impraticable. Exemple : téléchargement depuis un site web :
- oui mais il faut que l'application est plus de 1 millions de téléchargement durant l'année précédente et en Europe (puisque pour l'instant, c'est limité à l'Europe)
- oui mais il faut avoir souscrit au programme développeur depuis 2 ans minimum.

Pareil pour les stores alternatifs. C'est autorisé, mais avec des conditions telles qu'il est :
1) difficile pour un store de se monter
2) potentiellement très couteux de se tourner vers un store alternatif pour la distribution d'une application
3) Apple a toujours la main sur le blocage des applications

Et là, c'est "incitation" qui est décrit comme un lien direct. D'un point de vue juridique, un lien HTML n'a rien à voir avec une incitation.

J'ai du mal à comprendre la position d'Apple. Ils sont déjà sous le feu de nombreuses critiques de la part de l'Europe, mais aussi outre-Atlantique. Et là, il donne l'impression de donner le bâton pour se faire battre. A moins que cela ne soit un baroude d'honneur : se sachant perdu, ils vont tout faire pour faire durer les procès des années et des années et engranger un maximum de bénéfice durant cette période ?

Le 29/04/2024 à 08h 50

Non, Boulanger et Darty (de mémoire) en avaient fait les frais (pas une case à cocher, mais commentaires désobligeants). Et c'est quelque chose qu'on peut obtenir via le droit à la l'accès des données personnelles accordé par le RGPD. Le modèle que propose la CNIL mentionne les "éventuels champs commentaires".

Tout à fait. La CNIL a sanctionné ce type de commentaire par le passé. De mémoire aussi, c'était des commentaires plutôt négatif ("c'est un con", "cette personne a pété un boulon", etc.).

Par contre, elle autorise des commentaires, tant qu'ils sont objectifs et factuels.

Ainsi, on peut dire :
- "client exigeant" à la place de client chiant, ce qui pourrait inciter à lui mettre un commercial avec de l'expérience et pas l'alternant qui vient d'arriver
- "risque de comportement agressif / violent" au lieu de "client a pété un plomb" pour mettre en face une personne de la carrure de Teddy Riner plutôt que celle plutôt fluette de Christophe Willem (sans aucun jugement vis-à-vis de ces deux personnes hein !)

Le 28/04/2024 à 20h 27

Bizarre je n'ai jamais eu edge repassant par défaut.
Ni one drive, ni le screen pour créer un compte qui repasse en boucle.

Je dois avoir de la chance je suppose.

On doit être deux à avoir de la chance alors. Je n'ai jamais eu Edge qui repassait en défaut, ni OneDrive qui proposait d'envoyer tous les docs perso. Pour la demande d'avoir un compte Microsoft, je ne peux pas dire, j'en ai un. Et la météo, ça fait belle lurette que c'est dégagé, et ce n'est jamais réapparu.

Le 27/04/2024 à 12h 10

D'après les news, c'est dans leur projet avec le nouveau Windows 12 avec l'obligation certainement d'avoir leur IA et cloud
https://www.01net.com/actualites/windows-12-sera-t-il-un-systeme-dexploitation-sur-abonnement.html

Cela rapport bien plus d'autant que peu de monde achètent son WIndows 140€. La plus part sont négociés avec le prix de la machine avec la vente lié. Malheureusement nous n'avons pas connaissance de la proportion.
Sinon il y a la vente OEM pour quelques euros qui trainent à droite et à gauche.

En imposant un abonnement, Microsoft s'assure un revenu constant et surtout une grande partie de ses clients (particulier, pro) vont suivre.
Je ne vois aucune raison que Microsoft n'aille pas dans ce sens, il y a peu de risque que les gens ailles voir si l'herbe est plus verte donc autant en profiter. Peu de pression des utilisateurs sur Microsoft pour lui faire changer d'avis.

Je vois mal Microsoft rendre l'utilisation de Windows payant au mois. Ce serait se tirer une énorme balle dans le pied.

Par contre, et l'article que tu cites va dans ce sens aussi, avoir un Windows gratuit de base avec des services payants (sans doute ceux lié à l'IA) ça oui. Et c'est loin d'être déconnant. L'IA, même si nous, en tant que simple utilisateur, on ne le voit pas, ça coûte cher. Et on est loin de tous utiliser ce genre de services. Combien de poste je vois rien qu'avec Cortana de désactivé ! Et activé ne signifie pas utilisé ;)

Mais Microsoft a tout intérêt à ce que Windows reste la plateforme dominante. Rendre la version de base payante serait une énorme erreur stratégique.
Je ne vois aucune raison que Microsoft n'aille pas dans ce sens, il y a peu de risque que les gens ailles voir si l'herbe est plus verte donc autant en profiter.
Tant qu'on ne touche pas les gens au porte monnaie, il y a peu de chance que les gens aillent voir ailleurs. Rendre un service gratuit* payant, cela ne sera pas là même. Cela sera une aubaine pour les solutions concurrentes, Chrome OS, Android et Linux en tête (je pense moins pour MacOS car cela nécessite de changer de machine ET d'avoir des moyens).

Et si Windows perd des parts de marché, l'un des problèmes rencontrés aujourd'hui par les alternatives, à savoir le support matériel (les fameux drivers), devra être pris plus en compte par les fabricants.

Si c'est le cas, alors les deux freins majeurs au manque d'adoption d'alternative (le support matériel, et l'effet réseau) sauteront, risquant de faire diminuer encore la part de marché.




* gratuit : il y a bien sûr le prix de la licence, mais très souvent, cette licence est incluse dans le prix à l'achat de la machine et est donc non visible par l'utilisateur, et presque indolore, surtout vu les tarifs préférentiels dont disposent les assembleurs.

Le 27/04/2024 à 12h 28

Il est vrai que sous Linux, il n'existe aucun service qui tourne en tant que root... :mdr:

Sinon, les imprimantes ne sont pas que des imprimantes réseaux. Il y a aussi les imprimantes branchées directement à la machine. Et là, quand tu imprimes un document, il faut bien que le service accède au document à imprimer, quelque soit l'utilisateur. Donc oui, SYSTEM à un sens.

De même que sous linux, les postfix, dovecot, etc. tourne en root car besoins d'accéder aux dossiers des utilisateurs et des services. De même que journald, le planificateur de tâches (cron), etc. Même CUPS (Common UNIX Printing System) , de mémoire, nécessite les droits root pour tourner. J'en déduis donc que Linux est n'a aucune sécurité ! :troll:

Le 26/04/2024 à 15h 11

La levée de bouclier des prisonniers à l'ego touché est rapide & violente.
Bon, en même temps, vu le ramassis de conneries et de platitudes sur un ton doctoral ... On est à deux doigts d'Asselineau version libriste, c'est pour donner le niveau.
à ces piles/pelles de merde technologique.
Tu as l'air d'avoir un peu de mal avec les solutions MS, ça doit faire quelques (dizaines d') années que ça a évolué. La formation continue c'est important, n'hésite pas à te remettre à jour. Et si tu n'as pas de CPF ou autre, tu apprendras plein de choses sur learn.microsoft.com :)

C'est effectivement mon avis : un ramassis de conneries dit sur un ton tellement péremptoire qu'il est inutile d'entamer toute discussion. D'ailleurs, on peut inverser Windows et Linux et on aurait exactement le même discours ^^

Du coup, j'ai opté pour la solution don't feed the troll :troll:

Le 26/04/2024 à 08h 44

On pourrait aussi se baser sur le referrer :
- si pas renseigné => téléchargement autorisé
- si renseigné et github => téléchargement autorisé
- si renseigné et pas github => téléchargement bloqué

Comme ce n'est pas un espace de stockage, il n'y a quasiment aucune raison valable d'avoir un accès direct au lien de téléchargement en dehors de github (ou gitlab)

On pourrait aussi limiter le téléchargement d'une pièce jointe au fait d'être logué sur la plateforme. Potentiellement, cela pourrait s'appliquer en fonction du type de fichier. Un fichier texte ne présente que très peu de risque comparé à un fichier .exe par exemple.

Le 25/04/2024 à 11h 33

Je crois que c'était de l'humour. En fait, non.

Mais en effet, il aurait mieux valu dire xénophobe que raciste.

Si c'était de l'humour, je ne l'ai pas perçu du tout.

Par contre, je persiste sur le côté raciste et non pas xénophobe. Je ne perçois pas seulement un rejet parce qu'il n'est pas européen, mais aussi du dénigrement (il n'y aurait pas le "petit programmeur", mais "entrepreneur" que je serais d'accord pour parler uniquement de xénophobie).

Le 25/04/2024 à 11h 29

euh en quoi c'est raciste de citer l'origine de la personne?
Concernant les prix difficiles de savoir car pas de sources ouvertes, les prix étant sacrément dopés par la NASA et l'armée américaine.

Citer l'origine d'une personne en soit n'est pas forcément raciste. Par contre, ne pas citer précisément la personne mais la désigner par son origine (ce qui n'a absolument aucune pertinence ici) et rajouter le qualificatif "petit" devant programmeur, pour moi, c'est raciste (sans compter le ton du reste du commentaire, qui précise bien que c'est la honte pour l'Europe).

Quand je lis juste cette phrase, "nous Européens, on est complètement à la ramasse et tout ça à cause d'un petit programmeur informatique d'Afrique du Sud...", ce que je comprends, peut être à tort, c'est que la grande Europe d'autrefois se fait mettre à mal par un gars d'un petit pays d'arriérés.

Sans entrer dans un wokisme quelconque, est-ce qu'on accepterait une phrase du genre "un petit programmeur homosexuel" ? ou "un petit programmeur musulman" ? ou même "un petit programmeur non-binaire" ? Non, tant cela n'a strictement rien à voir avec la choucroute.

Le 25/04/2024 à 10h 36

Je pense qu'il y a quelques erreurs dans tes chiffres.

Si j'en crois Wikipédia :
- 1er vol pour Falcon Heavy : 2018
- Nb de lancements pour le Falcon Heavy : 9
- 1er vol pour le Falcon 9 : 2010
- Nb de lancements / échec : 324 / 2

C'est important de ne pas tout mélanger, car la charge utile entre un Ariane 5 et un Falcon 9 par exemple, est du même ordre, alors que celle du Falcon Heavy est 3x plus importante. Le Falcon Heavy est grosso-modo un Falcon 9 avec 2 propulseurs d'appoints basés sur du Falcon 9 également.

Au niveau du coût du lancement, je retrouve grosso-modo ton chiffre pour ce qui est du Falcon 9. Par contre, pour le Falcon Heavy, on est plutôt de l'ordre de 100 millions de $.

A noter également qu'il n'y a pas que le poids ou le coût à prendre en considération, mais également les dimensions. Avec un diamètre de 5,4m, Ariane 5 (ou son successeur, qui a le même diamètre) était en mesure d'emporter des satellites qu'il n'est pas possible de mettre dans un lanceur Falcon9 ou un Falcon Heavy (3,6m de diamètre)

# Bref, en clair, nous Européens, on est complètement à la ramasse et tout ça à cause d'un petit programmeur informatique d'Afrique du Sud...

J'ai mis du temps avant de comprendre cette phrase, avant de me rappeler qu'Elon Musk, fondateur de Space X, vient d'Afrique du Sud. Je ne te félicite pas en tout cas pour cette attaque raciste gratuite :cartonrouge:.

[edit] J'ai du éditer plusieurs fois, il y a un gros bogue avec les citations, qui disparaissent tout simplement après rechargement de la page ! Du coup, j'ai changé en mettant un # pour introduire la citation.

Le 24/04/2024 à 15h 42

Ne pas oublier qu'ici, on parle de disque dur à destination de serveur. Leur utilisation n'a rien à voir avec un usage domestique ou bureautique.
Le disque est alimenté en quasi-permanence et est souvent sollicité aussi bien en lecture qu'en écriture.

Si je regarde juste pour mon expérience "personnelle" (dans le cadre de ma société) :
- j'ai déjà changé 2 disques de mon NAS. Il a 7 ans
- j'ai changé un disque de mon serveur dédié sur les 2. Il a 5 ans.

La moyenne de 4 à 5 ans ne me parait pas déconnant. D'autant plus qu'on peut avoir un disque dur qui présente des défaillances mais reste malgré tout "utilisable" (même si c'est jouer avec le feu ^^)

A titre strictement personnel, j'ai des disque dur qui ont 20 ans et qui tiennent encore le coup ;) Mais ils sont beaucoup moins sollicités.

[edit] Comme quoi, il suffit d'en parler pour que les problèmes arrivent ! Un des 4 disques dur de mon NAS a laché pas plus tard qu'aujourd'hui, après 43687h de fonctionnement, soit quasiment 5 ans. Disque changé, reconstruction en cours ^^

Temps estimé : environ 6h pour 5To (je suis en RAID6, qui supporte la perte de 2 disques, d'où le temps nécessaire)

Le 24/04/2024 à 14h 10

Pour l'ordre, ça dépend du type de courrier envoyé (au moins pour les médecins). En général même un simple signalement reçoit une réponse, et les plaintes, systématiquement.

Il y a longtemps (plus de 15 ans), ma compagne a l'époque avait envoyé une plainte à l'ordre des médecins devant un comportement anormal d'un praticien.

La seule réponse reçue, c'était un accusé réception, indiquant que le dossier allait être instruit, mais que le résultat de l'enquête, la décision, ainsi que les éventuelles sanctions, ne seraient pas communiqués.

Les choses ont peut être évoluées depuis (et dans ce cas, tant mieux).

Le 24/04/2024 à 08h 49

Je me pose une question : est-ce que la répression des fraudes fait un retour au consommateur qui fait un signalement ?

C'est un peu le problème que je constate aujourd'hui :
- les ordres des métiers (avocat, médecin, etc.) ne font jamais de retour, cela reste en interne
- les signalements pour les spam, fishing, etc. que ce soit par mail, SMS ou autre : aucun retour
- la CNIL fait un retour de ce que j'ai pu voir, mais il faut que le dossier soit traité et les délais peuvent être trèèès long (plusieurs années)

Du coup, en tant que citoyen, quand on fait un signalement, on a un peu l'impression que cela ne sert à rien, et donc n'incite pas réellement à le faire.

C'est peut être ma déformation de développeur, mais un retour utilisateur, c'est hyper important ! Quand un utilisateur me signale un problème, un bug, une erreur, il a toujours un retour, pour lui indiquer que c'est corrigé, ou que non, ce n'est pas un bogue, c'est une fonctionnalité :troll:. Ca permet de bien affiné le système et les utilisateurs se sentent réellement écoutés et considérés (et ça, ça change tout dans la relation avec eux !!)

Le 24/04/2024 à 09h 11

Ça me donne une idée : et si nous balancions ceux/celles qui changent leurs téléphones tout les 2 ans dans l’espace pour les obliger à payer pour les mises à jours logiciel et non pas pour de nouveaux équipements ?
:D

Pas en orbite alors. On risquerait vite d'avoir une "nuit permanente" :stress::mdr:

Le 24/04/2024 à 08h 36

Je tiens à faire remarquer la prouesse technique, à tous les niveaux, de cette mise à jour :
- la sonde est parti il y 47 ans. C'est donc du matériel datant de plus de 47 ans qu'il a fallu mettre à jour
- 47 ans en informatique, c'est la préhistoire. La RAM fait quelques ko, les calculateurs sont au plus cadencé à quelques Mhz
- 47 ans après, la sonde fonctionne encore. Il y a eu quelques avaries, mais il a toujours été possible de les contourner, ce qui montre une conception très bien pensée, avec de la redondance et de la reconfiguration à chaud
- transmettre des informations sur une telle distance, c'est loin d'être anodin. C'est pas du TCP/IP, il fallait gérer dès le début la correction d'erreur, les débits, la latence, etc. et cela revient à transmettre des informations outre atlantique en faisant des signaux avec une lampe de poche
- réussir à mettre à jour un système, à distance, sans savoir exactement ce qui se passe, c'est comme mettre à jour un PC dont l'écran reste noir. Je dis chapeau !!!

Quand je pense qu'aujourd'hui on a un truc à selfie dans la poche, bien plus petit et pourtant bien plus puissant, qui sert accessoirement à la téléphonie, que les constructeurs arrêtent de mettre à jour au bout de 2 ans, qui sont presque à jeter à la moindre défaillance ou lorsqu'ils deviennent "obsolètes", j'ai envie de dire à ces constructeurs : regardez Voyager I et prenez en de la graine.

Le 23/04/2024 à 11h 56

Je pense qu'il faut y comprendre en fait la quantization, qui consiste à réduire la précision pour diminuer la taille des modèles et la vitesse de calcul

Le 22/04/2024 à 17h 58

Je vais citer un grand philosophe à ce sujet :
Et pourquoi pas une laisse dans le cul ?
biiip John Spartan, vous avez une amende d'un demi-crédit pour infraction au code de moralité du langage

Le 22/04/2024 à 16h 36

Et encore, 10k parce que quelques curieux ont voulu voir le tweet original. On peut encore diviser par 10 (au moins !) le nombre de vue originelle à mon avis, s'il n'y avait pas eu cet effet Streisand ;)

[edit] reformulation car la première version manquait de clarté

Le 22/04/2024 à 10h 26

Lol.
ne confondons pas tout : ya des millions de voitures sur terre, de logements, or ceux ci ne valent pas des cacahuètes sous prétexte qu'il y ait masse de quantités. Pareil dans l'informatique : la valeur est faite par la qualité/quantité d'infos, mais aussi par leur rareté.
rien qu'en france, 77M de personnes. Pour que statistiquement une BDD vaut le coup, il faut :
a/ être un géant pour en toucher le plus possible
b/ disposer des infos spécifiques que les intéressés cherchent
c/ fuiter à la bonne date, càd après l'inscription de M Tartempion (sinon il sera pas dans la base)
d/ terminer en BDD gratuite après quelques années sur le net.

j'en connais deux qui touchent ce lot : linkedin, et facebook.
les deux ont fuit au début de la décénnie précédente. Ce qui n'empeche pas les milliers d'autres piratées, de presque rien valoir : trop petites pour avoir l'info qu'on cherche. Y'a juste La Poste Mobile qui complète avec une BDD récente pour la france, mais beaucoup trop maigre pour intéresser du monde.

Pourtant, quand on regarde : CMA CGM a été piraté en 2016 ou 2018, à l'heure de la "banalisation" du cannabis (euh du piratage), ce qui n'a pas empeché, malgré les millions perdus à la journée pour l'entreprise, de n'être une base de grande valeur, puisqu'elle n'intéresse personne. Or, si quelqu'un la diffusait, aucun doute qu'elle se revendrait bien plus cher : fiches de paies, etc, c'est surtout la diversité d'infos incluses qui fait la force du fichier ;)

et si ça perdait toute leur valeur, plus personne n'en récupérerait sur les plateformes concernées ;)

Il n'y a pas que les données personnelles.

Prenons l'exemple de Speedy, ou même du Slip Français (où pour le coup, on est sur que les commandes en cours ont été extraite).

Un pirate peut lancer une énorme vague de phishing, avec les vrai numéros de commande, les vrais montants, le détail des commandes, etc. et prétexter une facture impayée, un problème dans le prélèvement (le cas des 3x, 4x, 10x, etc sans frais) pour soutirer directement de l'argent aux victimes. Pas besoin de revendre les données. Et comme les informations sont justes (numéro de commande, détails, montant, etc.), il est difficile de prédire si un mail est légitime ou pas ([email protected] par exemple, ou un domaine exotique comme [email protected]).

Ce qui limite les dégâts, c'est que dans un tel contexte, les informations ont une durée de péremption plus ou moins courte.

Enfin voilà, tout ça pour dire que la revente des données n'est pas la seule source de revenus possible.

Le 22/04/2024 à 09h 12

Après avoir laisser des traces de pneu, les pirates passent la seconde !

Le 21/04/2024 à 09h 31

fdorin lui a cité il y a quelques temps et on en a ensuite discuté.

:smack:

Le 20/04/2024 à 12h 21

Le PDG d'une boite ne constitue donc pas une information officielle concernant ladite boite ?
Ben non, ce n'est pas une déclaration officielle. Ce n'est pas comme ça que ça marche. Et en plus c'est dans un contexte où il se défend de tweeter pour donner de l'importance à Twitter, il a tout intérêt à minimiser l'impact de ceux-ci.

La suite de son intervention :
So that’s, you know, if -- in this specific case, if I wanted to have it be -- receive a lot of distribution, I would have made it a primary tweet or a quoted tweet, which I did not.• It was simply a reply. The replies get 100 times less attention than a primary tweet. So this was certainly not any attempt to generate advertising revenue. In fact, generally advertisers will not want to advertise with content that is contentious
Comme dit dans la brève, "Il a par ailleurs déclaré « avoir potentiellement davantage contribué à affaiblir financièrement » le réseau social X, qu’il a racheté fin 2022, qu’à l’améliorer.". Est-ce le même passage ou pas, je ne sais pas.
Je t'ai littéralement donné la source exacte de la citation tronquée du huff traduite par next...
Quoi qu'il en soit, et tu peux dire que j'y vois ce que j'ai envie de voir, couplé avec des observations extérieurs et certains chiffres données par X même (baisse de 30% du nombre d'utilisateurs actifs en 1 an), c'est un aveu (ou semi-aveu en fonction du possible biais de traduction dont j'ai parlé plus haut) de la part du CEO de X. C'est quand même loin d'être rien.
Les chiffres sont ce qu'ils sont, mais ces paroles ci n'ont rien à voir avec la santé financière de Twitter. Il explique juste que ses tweet ont certainement été plus au détriment de la plateforme qu'à son avantage, encore une fois pour se défendre.

Ben non, ce n'est pas une déclaration officielle. Ce n'est pas comme ça que ça marche. Et en plus c'est dans un contexte où il se défend de tweeter pour donner de l'importance à Twitter, il a tout intérêt à minimiser l'impact de ceux-ci.
Je n'ai pas dit que c'était une déclaration officielle, mais une information officielle. Information officielle = information qui émane d'une source officielle. E. Musk, en tant que CTO de X constitue une source officielle.
Je t'ai littéralement donné la source exacte de la citation tronquée du huff traduite par next...
Je n'avais pas pris le temps de comparer avec l'article du Huffpost. C'est maintenant chose faite. Et effectivement, je confirme donc mes dire : la traduction induit à surinterpréter les propos de Musk. Je vais le signaler à la rédaction ;)

Le 19/04/2024 à 11h 26

Sur le principe du ragot, je suis d'accord. Mais je trouve ici que la brève va plus loin que le simple ragot. On a une information officielle (et pas simplement celle d'un observateur extérieur aussi sérieux soit-il) qui annonce clairement que suite au rachat par E. Musk de Twitter, Twitter s'est affaibli financièrement.
Ce n'est pas une information officielle, non. Ce n'est pas comme ça que ça marche.
Et le contexte dans lequel la phrase est sortie change tout le sens donné dans le titre :
Q. (BY MR. BANKSTON) Okay. So let’s go back to the question that we had, which was now that you’ve acquired the company, Twitter is no longer getting a free benefit. I mean, this benefits you as well, your engagement that you create for the company; is that correct?
A. Not necessarily. So I -- I believe my posting has really remained unchanged before and after the acquisition. The -- and going back to the sort of self-inflected wounds, the Kevlar shoes, I think there’s -- I’ve probably done -- I may have done more to financially impair the company than to help it, but certainly I -- I do not guide my posts by what is financially beneficial but what I believe is interesting or important or entertaining to the public.
Il parle de ses tweets. Il explique que ses tweet ont probablement un impact négatif sur Twitter. Il ne parle pas de la gestion de l'entreprise et de la santé financière globale.

Ce n'est pas une information officielle, non.
Le PDG d'une boite ne constitue donc pas une information officielle concernant ladite boite ?
Il parle de ses tweets. Il explique que ses tweet ont probablement un impact négatif sur Twitter. Il ne parle pas de la gestion de l'entreprise et de la santé financière globale.
Comme dit dans la brève, "Il a par ailleurs déclaré « avoir potentiellement davantage contribué à affaiblir financièrement » le réseau social X, qu’il a racheté fin 2022, qu’à l’améliorer.". Est-ce le même passage ou pas, je ne sais pas. Il est vrai que si c'est le cas, la traduction induit un biais menant le lecteur en erreur, dans la mesure où l'usage de "contribuer à" signifie qu'il a joué un rôle dans l'affaiblissement financier, et donc que l'affaiblissement est confirmé.

Quoi qu'il en soit, et tu peux dire que j'y vois ce que j'ai envie de voir, couplé avec des observations extérieurs et certains chiffres données par X même (baisse de 30% du nombre d'utilisateurs actifs en 1 an), c'est un aveu (ou semi-aveu en fonction du possible biais de traduction dont j'ai parlé plus haut) de la part du CEO de X. C'est quand même loin d'être rien.

Le 16/04/2024 à 11h 13

A la fois d'accord et pas d'accord.

Sur le principe du ragot, je suis d'accord. Mais je trouve ici que la brève va plus loin que le simple ragot. On a une information officielle (et pas simplement celle d'un observateur extérieur aussi sérieux soit-il) qui annonce clairement que suite au rachat par E. Musk de Twitter, Twitter s'est affaibli financièrement.

Il y en a encore qui pense que X se porte pour le mieux depuis le rachat. Là, cela va être difficile de prétendre le contraire, dans la mesure où c'est E. Musk lui-même qui avoue cet état de fait.

Le 19/04/2024 à 09h 25

Dans le même temps, c'est bien Facebook qui annonçait fièrement sur sa page d'accueil un message du genre "C'est gratuit et ça le restera toujours". Et avec toutes les casseroles qui montrent que Meta se moque complètement de la protection des données privées (Cambridge Analytica, etc.), il ne faut pas s'étonner si la législation évolue et je ne peux qu'approuver la position de Max Schrems.
Edit: faute d'orthographe corrigée.

Et le mantra de Google à ses débuts étaient... "don't be evil" ;)

Je me souviens parfaitement de Facebook annonçant que Facebook resterait gratuit. Mais il ne faut pas se leurrer. C'est une entreprise, et s'il y a une chose que Meta a su prouver jusqu'à aujourd'hui, c'était qu'elle était loin d'être philanthropique. Le jour où cela coutera plus à Meta de rester en Europe que d'en partir, l'annonce du "gratuit pour toujours" tombera vite dans les oubliettes.

Ce genre de promesse n'engage que celles et ceux qui y croient ;) (à moins que ce soit dans leur CGU, marqué comme un article irrévocable, mais j'avoue que j'ai la flemme de lire les CGU les plus longues et les plus incompréhensible du monde pour trouver ça !).

Le 18/04/2024 à 14h 12

Max Schrems, son président, affirme que « dans l'ensemble, Meta n'a plus le choix dans l'UE. Elle doit maintenant donner aux utilisateurs une véritable option oui/non pour la publicité personnalisée. Elle peut toujours facturer les sites pour le reach, s'engager dans la publicité contextuelle et d'autres activités similaires, mais le suivi des personnes à des fins publicitaires nécessite un "oui" clair de la part des utilisateurs ».
Meta dispose encore d'autres choix, comme :
- fermer purement et simplement Facebook en Europe ;
- rendre Facebook totalement payant en Europe.

Irréaliste diront certains. Pourtant, à force de tout faire (à tort ou à raison, là n'est pas la question) pour remettre en cause le modèle de rémunération actuel, le jour où la balance entre ce que coûte un utilisateur non payant (les serveurs, la modération, les espaces de stockages, les tuyaux, etc. ce n'est pas gratuit) et ce qu'il rapporte sera en la défaveur de Facebook, c'est bien ce qui pourrait arriver, car il faut bien garder en tête que la publicité non ciblée paye beaucoup moins que la publicité ciblée.

Le 19/04/2024 à 09h 10

Les archives de facturation sont, comme leur nom l'indique, des archives qui, après un temps donné, n'ont rien à faire dans la base de données du site web.
Si ce n'est pas fait par réduction de coût, il ne faut pas s'étonner de se faire voler son unique base interne.

L'archivage ne suppose absolument pas une séparation des données dans des base de données différentes. L'archivage consiste à marquer des données qui ne sont plus utiles pour un objectif précis, afin d'en restreindre l'accès et l'utilisation. Mais absolument pas à retirer de la base des données pour les mettre dans une autre (même si cela reste une possibilité).

Classiquement, on distingue 3 états de la donnée :
- en base active : les données sont encore utiles pour l'objectif fixé (par exemple, l'état d'une commande)
- archivage temporaire : les données ne sont plus utiles pour l'objectif fixé (par exemple, la commande est livrée depuis 1 mois). Toutefois, les données peuvent devoir être conservé pour la gestion des litiges, répondre à des obligations légales, etc.
- archivage définitif : il s'agit de données qui ne répondent plus à des enjeux légaux, contentieux, ... mais qui conservent une valeur "stratégique" pour l'entreprise. Depuis le RGPD, la conservation définitif de données à caractère personnelle est généralement impossible (je ne connais aucun cas où cela serait justifié, mais cela doit bien pouvoir se trouver).

Ces 3 états se distinguent par une accessibilité décroissante, mais absolument pas par une séparation physique du stockage (même si, une fois encore, cette séparation peut être mise en oeuvre).

Le 18/04/2024 à 08h 33

Pour les factures, si ce n'est pas de l'archivage probatoire (en PDF par exemple), c'est stocké dans les entêtes de facture, pas besoin du compte client pour ressortir ce type de documents. Heureusement d'ailleurs, car une modification du compte client entre 2 éditions modifierait la facture :non:

Mais je suis d'accord, ca ne me choque pas qu'un compte soit passé en inactif après 3 ans mais reste en BDD. Après en effet, reste la question de la minimisation, et dans les bonnes pratiques il faudrait faire des revues de comptes tous les ans (automatique ou pas).

Pour les factures, si ce n'est pas de l'archivage probatoire (en PDF par exemple), c'est stocké dans les entêtes de facture, pas besoin du compte client pour ressortir ce type de documents. Heureusement d'ailleurs, car une modification du compte client entre 2 éditions modifierait la facture :non:
On est d'accord ;) Mais pour répondre aux demandes d'accès imposées par le RGPD, c'est beaucoup plus simple pour l'entreprise de conserver le compte client que de ne conserver que les factures ;)

Le 17/04/2024 à 16h 44

Concernant la présence de personnes désinscrites, ce n'est pas forcément complètement déconnant, même si cela semble aller à l'encontre du RGPD.

Déjà, désinscrites ne signifie pas compte clôturé. On peut avoir un compte "actif" mais être désinscrit de toutes communications.

Ensuite, en tant qu'entreprise, le Slip Français se doit de conserver certains éléments, notamment tout ce qui à trait à la facturation pendant au moins 10 ans (c'est la loi). Que des informations comme les nom, prénom, adresse soient encore stockées n'est donc pas forcément étonnant. De même que le mail peut être utilisé pour répondre aux demandes d'accès aux données personnelles sans forcément avoir besoin de demander de pièces justificatives.

Donc même si certaines personnes n'ont pas eu de contact depuis 2018, si ces personnes avaient commandé sur le Slip Français, il est normal que le Slip Français ait encore des informations les concernant.

On peut bien sur s'interroger sur d'autres aspects, comme la minimisation des données, ou le fait que certains désinscrit se sont soudainement mis à recevoir de nouveau des sollicitations publicitaires, mais cela n'a rien à voir avec la fuite de données à proprement parler.

Le 18/04/2024 à 10h 43

Personne n'impose rien à personne
Si. On m'impose de choisir un camp.

Le fameux "si t'es pas de notre coté, alors tu es de leur coté".
Spoiler: il y a des haineux dans les deux camps.

"Qu'on m'épargne d'avoir à choisir à un camp", comme disait JJGoldman.

+100000

C'est un peu le côté que je déplore aujourd'hui. "Si tu n'es pas avec nous, tu es contre nous". Les positions intermédiaires (du genre, je m'en fiche royalement) sont complètement passées sous silence.

Le 17/04/2024 à 10h 36

Il existe plusieurs types de trou noir. Celui au centre de la voie lactée n'est pas un trou noir stellaire, mais un trou noir supermassif.

Il est bien précisé que Gaia BH3 est le trou noir stellaire le plus massif jamais découvert dans la Voie Lactée ;)

Le 17/04/2024 à 10h 15

Attends, j'en rajoute une couche: leurs produits sont de très mauvaise qualité.

Avec mon épouse on a commandé en 2018 environ une vingtaine d'unités issus de gammes différentes, tout a fini à la poubelle en moins de 6 mois.

Le tissu se déchire, se troue, les élastiques cassent, les coutures s'effilochent...

C'est lamentable.

Tu prends le premier prix chez Carrefour, made in Bengladesh, c'est 10 fois mieux foutu.

Le Slip Français, c'est de l'argent, et maintenant des données, jetées par la fenêtre.

Je me demande bien ce que tu as pu commander, car je constate l'extrême inverse.

J'arrive à "user" certains de leur vêtement, mais :
- il me faut du temps
- je fais du sport avec (notamment de la course à pied, où il m'arrive de partir pendant 2h)

Chaussettes et boxer tiennent bien le choc. Il me fait plusieurs semaines d'utilisation intensive pour mettre à mal une paire de chaussette par exemple, alors que le premier prix chez Carrefour, c'était 3j. Les chaussettes ont tendances à se percer, et les boxer, ce sont les coutures qui ont tendance à lâcher.

T-shirt : en tondant, je me suis accroché à un barbelé de la clôture. Bilan : T-shirt intact, alors que ma première pensée était de gueuler car le T-shirt était neuf et je pensais qu'il était foutu.

Pantalon : rien à dire jusqu'à aujourd'hui. Cela fait plusieurs années que j'en ai certains, ils n'ont pas bougé d'un yota.

Le slip français, c'est peut être cher à l'achat, mais pour moi, c'est rentable sur le long terme tant j'achète moins de vêtements.

Le 15/04/2024 à 18h 17

C'est effectivement mal rédigé, mais sur le principe, il me semble que le principe de double-licence ne pose pas de problème.

La GPL interdit les restrictions, mais encore faut-il que tu possèdes une licence sous GPL du code source. Or, si tu prévois de mettre sur l'App Store, il ne t'octroie pas de licence GPL. Trolltech fait ça avec Qt depuis une éternité par exemple.

Il est effectivement possible de faire de la double licence (comme Qt que tu cites fort judicieusement).

Sauf que le choix de la licence à utiliser ne revient pas à l'auteur, mais à l'utilisateur :
- s'il peut distribuer son programme en respectant les termes de la licence GPL, il peut prendre la GPL ou la licence alternative, et l'auteur n'a rien à redire là-dessus
- s'il ne peut pas distribuer son programme en respectant les termes de la GPL, il ne dispose alors que de la solution de secours via le double-licensing.

Pour Qt, cela se traduit grosso modo par :
- si tu utilises Qt, que tu as apportés des modifications à la bibliothèque, alors soit ces modifications doivent être disponible en LGPL, soit tu dois acquérir la licence alternative
- si tu utilises Qt, que tu as apportés des modifications à la bibliothèque mais, que pour des raisons diverses, tu ne peux pas les rendre disponible en LGPL (utilisation d'une bibliothèque avec une licence incompatible avec la LGPL, code métier spécifique présentant une plus-value et devant resté confidentiel, etc.) alors tu dois acquérir une licence.

Le 15/04/2024 à 18h 00

Tu confirmes mon doute initial, tout comme le lien vers la fsf d'Oliverpool.

C'est une problématique similaire avec les nouvelles licences qui sont apparus pour les services utilisées massivement dans le cloud (MongoDB, Redis, Elastic Search, ...). Les nouvelles licences veulent dire (comme la SSPL), c'est du libre, sauf en cas d'utilisation en SAAS. Sauf qu'en réalité, ce n'est donc plus du libre.

Pour faire simple : une licence libre avec une clause "sauf si" dans le cadre de la jouissance d'une des 4 libertés fondamentales qui constitue le libre, n'est plus libre.

Le 15/04/2024 à 16h 59

Si le logiciel est libre, alors le fork doit fournir ses sources et mentionner le copyright de l'auteur original. Il semblerait ici que cela ne soit pas le cas.

Sinon l'affaire est juste un peu dégueulasse de la part du forker qui profite du travail d'autrui à peu de frais mais c'est effectivement la règle.

Maintenant je ne me fais pas trop de soucis pour Delta qui a déjà une bonne réputation chez les bidouilleurs et qui si il est autorisé sur l'App Store, y trouvera son petit succès.

Si le logiciel est libre, alors le fork doit fournir ses sources et mentionner le copyright de l'auteur original. Il semblerait ici que cela ne soit pas le cas.
Cela dépend des licences. Mais dans le cadre de la GPL v2 oui. Après, je n'ai pas d'iBidule pour aller vérifier (et de toute façon, l'application a été retirée).
Sinon l'affaire est juste un peu dégueulasse de la part du forker qui profite du travail d'autrui à peu de frais mais c'est effectivement la règle.
On est tout à fait d'accord. C'est d'ailleurs bien à cela que je réagissais quand je voyais que l'auteur n'en voulait pas au forkeur, mais à Apple.

C'est légal (si les conditions de la licence sont respectées comme la conservation du copyright), mais pas très moral...

Le 15/04/2024 à 16h 52

La citation complète est :

The GBA4iOS codebase is distributed under the GNU GPLv2 license. That being said, I explicitly give permission for anyone to use, modify, and distribute my original code for this project without fear of legal consequences — unless you plan to submit your app to Apple’s App Store, in which case written permission from me is explicitly required.
Et c'est là que les problèmes commencent ! Le texte en plus de celui que tu as cité est mal foutu.

1) il commence par autoriser ce que la GPL V2 autorise déjà : utilisation, modification et distribution.

2) il met une limite à la distribution sur l'Apple App Store qui est d'avoir son autorisation écrite.

Mais la GPL V2 est plus permissive que cette restriction et il a dit que son code était distribué sous GPL V2. Donc sa restriction est en contradiction avec la première phrase. Cette restriction me semble inefficace. Elle l'aurait été s'il avait faite dans la même phrase et encore, je n'en suis pas sûr. Voilà ce que c'est quand un développeur, lycéen qui plus est, joue avec les licences logicielles, il se plante.

Cette restriction me semble inefficace. Elle l'aurait été s'il avait faite dans la même phrase et encore, je n'en suis pas sûr.
Même pas. La GPL interdit toute restriction, sous quelque forme que ce soit, dans la distribution. On a donc :
- soit le code est sous GPL, et il n'est pas possible de restreindre la diffusion (sa limitation ne tient donc pas)
- soit la diffusion est restreinte, mais son code ne sera pas sous GPL (ni même une quelconque licence libre).

Les deux sont purement et simplement incompatibles. Tout au mieux, on pourrait dire qu'il fait un dérivé non libre de la GPL (et encore, pas sur que cela plaise à la FSF de dire cela :francais:)

Le 15/04/2024 à 14h 53

Le développeur s’est fendu d’un message sur Threads : « Apparemment, Apple a approuvé une contrefaçon de GBA4iOS – le prédécesseur de Delta que j'ai créé au lycée – dans l'App Store. Je n'ai donné à personne la permission de le faire, et pourtant il est maintenant en tête des classements (bien qu'il soit rempli de publicités et de suivi) ».
Il a ajouté qu’il n’était pas en colère contre le développeur, mais bien contre Apple : « Je suis furieux qu'Apple ait pris le temps de modifier les règles de l'App Store pour autoriser les émulateurs, et qu'elle ait ensuite approuvé une copie de ma propre application, alors que j'étais prêt à la lancer ».
Plusieurs choses (punaise, voilà que je défends Apple maintenant...) :
- Apple a approuvé une contrefaçon de GBA4IOS : impossible de parler de contrefaçon. Le logiciel est libre (sous GPLv2) et le nom a été changé.
- Je n'ai donné à personne la permission de le faire : et si, en mettant le logiciel sous licence libre, chaque utilisateur peut le redistribuer comme il l'entend. Un utilisateur n'a AUCUNE permission à demander à l'auteur (sinon, le logiciel ne serait pas libre)
- est-ce à Apple de vérifier si, pour chaque application Open Source, le titulaire des droits (dans la limite de ce que cela peut bien signifier) a pour objectif ou non la publication d'un application pour vérifier si un fork soumis doit être accepté ou non ? Pour moi, non.

Je serai Riley Testut, je serai bien en colère contre l'auteur du fork, et pas contre Apple. Son projet est effectivement parasité, et la présence de publicités et de trackers dans la version distribuée plaide pour une action plutôt volontaire voire malsaine et non pas pour un acte de quelqu'un d'un peu trop passionné ne pensant pas à mal.


Voilà, sinon, un point de détail : le dépôt actif semble être celui sur bitbucket. Celui sur github est archivé.

Le 15/04/2024 à 11h 38

En fait, ce n'est pas un LLM à 1 bit, c'est une variante d'un LLM à 1 bit. La valeur ternaire se retrouve encodée sur 1,58 bits, d'où le nom. On peut retrouver l'article sur arxiv.org (en anglais).

Le 15/04/2024 à 09h 42

Pour être plus précis, le standard derrière s'appelle Posix (et pas GNU C). Sauf que l'API Windows existe 1985, POSIX depuis 1988. Windows ne respecte donc pas un standard qui n'existait tout simplement pas l'époque des premières versions du système d'exploitation.
Ce que tu dis n'est pas possible le noyau NT n'existe que depuis juillet 1993 et ne se base justement pas sur DOS, par contre, il gare une certaines compatibilités, mais les applications Ms-DOS/Windows de l'époque ne fonctionne pas sous Windows NT.

En quoi n'est-ce pas possible ? Un changement majeur niveau noyau n'implique pas forcément un changement des API exposés.

Le changement de noyau NT reflétait surtout une modification profonde de la manière de communiquer avec le matériel. De manière très simpliste (car c'est loin d'être le seul changement mais sans doute le plus significatif), avant NT, les drivers pouvaient accéder directement au matériel (en by-passant complètement le noyau donc), ce qui n'est plus le cas avec NT.

Winapi, première version, date du 20 novembre 1985 d'après Wikipédia et existait bien avant le noyau NT.

Il ne faut pas confondre le noyau (qui gère entre autre le matériel) des API exposés pour les programmes.

Le 13/04/2024 à 10h 08

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

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.

Le 13/04/2024 à 00h 59

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.
Parce que tu fournis une ligne de commande à analyser (parser) plutôt que de fournir le résultat de cette analyse ? Résultat que tu connais car au final, d'un point de vue programme tu connais les paramètres du programme que tu appelles.
Cela passe pour un shell, où l'utilisateur entre des commandes, mais pas pour des APIs bas niveau.

Et je ne vois pas le souci d'espaces dans la façon Linux : tu passes juste un tableau de chaîne de caractères (terminées par le caractère NUL). Le fait de vérifier la taille max de l'ensemble n'est pas plus coûteux : vu la différence de temps de lancement entre Linux et Windows (plus lent), ce n'est certainement pas ça le plus coûteux !
Encore une fois, il n'y a pas une approche qui soit meilleure qu'une autre. Ce sont juste 2 approches différentes.
Si justement : dans le cas présent, il s'agit d’exécuter un programme depuis un autre programme avec les paramètres connus.

D'une part, la façon de faire de WIndows introduit des problèmes d'analyses vu que les règles sont difficiles à utiliser (je dis ça d'expérience de batch), pas documentée sur la doc de CreateProcess (pas trouvé sur la page de lien ou d’explication), d'autre part ça introduit des failles de sécurité du fait de cette complexité et de cas limites (notamment sur les caractères ").

Or, il s'agit bien de ça : Rust a une faille critique à cause de cette façon de faire qui nécessite un travail compliqué, mal compris et pour rien

Parce que tu fournis une ligne de commande à analyser (parser) plutôt que de fournir le résultat de cette analyse ? Résultat que tu connais car au final, d'un point de vue programme tu connais les paramètres du programme que tu appelles.
Cela passe pour un shell, où l'utilisateur entre des commandes, mais pas pour des APIs bas niveau.

La question est de savoir si les paramètres du ligne de commande sont nécessaires au système d'exploitation ou pas. La réponse est non. L'OS à juste besoin de savoir le programme à lancer, et les paramètres à passer, mais n'a pas à connaitre la structure des paramètres (tableau ou ligne).

Sous Linux, le choix a été fait d'organiser les paramètres sous forme de tableau. Sous Windows, c'est une chaine de caractère. Les deux sont tout à fait viable et ont de subtiles différences.
Et je ne vois pas le souci d'espaces dans la façon Linux : tu passes juste un tableau de chaîne de caractères (terminées par le caractère NUL). Le fait de vérifier la taille max de l'ensemble n'est pas plus coûteux : vu la différence de temps de lancement entre Linux et Windows (plus lent), ce n'est certainement pas ça le plus coûteux !
Je ne parlais de la complexité en terme de temps de calcul, mais de la complexité d'avoir un algorithme correcte. Et j'avoue ne pas trop voir en quoi le temps de lancement vient jouer un rôle ici. On parle des paramètres des programmes. Cela n'a strictement rien à voir.
D'une part, la façon de faire de WIndows introduit des problèmes d'analyses vu que les règles sont difficiles à utiliser (je dis ça d'expérience de batch),
Jusqu'au jour où on va se rendre compte que linux a en fait potentiellement le même problème, car quand un script est exécuté, l'interpréteur est déterminé via le shell bang. Chaque interpréteur peut avoir des règles d'échappements différents. Du coup, là aussi, on accusera Windows ?
Or, il s'agit bien de ça : Rust a une faille critique à cause de cette façon de faire qui nécessite un travail compliqué, mal compris et pour rien
Pas pour rien non. Quand les systèmes sont différents, il faut bien palier les différences. C'est le rôle du pattern adapteur ou d'un wrapper en programmation. Mais parfois c'est compliqué oui. Comme ici.

Le 13/04/2024 à 00h 19

Le problème est que l'API Windows est fondamentalement limitée et ne permet pas de passer une liste d'arguments à un programme, uniquement une chaîne de caractères qui sera "la commande", ce qui implique tout un tas de problèmes.

Oui Rust, Java & co doivent trouver une manière correcte pour contourner cette limitation de Windows. Mais pas seulement, c'est a peu près certain qu'on trouve dans le monde des dizaines de milliers de failles à cause de cette limitation problématique et difficilement compatible avec la manière dont la fonction main est spécifiée dans la plupart des langages (les argument sont une liste de string, pas une string)

Encore une fois, il n'y a pas une approche qui soit meilleure qu'une autre.
Si, il y a une approche correcte, qui maintient la sémantique de la liste d'arguments sur toute la ligne, de la commande ou du script jusqu'à la fonction main du programme, et une approche fondamentalement problématique et qui encourage les failles de sécurité, mais qui marchotte à peu près avec des hacks et des contournements.

Le fait que les langages de programmation aient repris cette sémantique indique bien que tout le monde considère ça comme la manière correcte de faire. Je ne connais aucun langage qui ait choisi de prendre ses arguments comme une seule grande chaîne de caractères au lieu d'une liste.

Oui Rust, Java & co doivent trouver une manière correcte pour contourner cette limitation de Windows. Mais pas seulement, c'est a peu près certain qu'on trouve dans le monde des dizaines de milliers de failles à cause de cette limitation problématique et difficilement compatible avec la manière dont la fonction main est spécifiée dans la plupart des langages (les argument sont une liste de string, pas une string)
Quitte à me répéter, les premières versions de l'API Windows sont sorties avant pas mal de standardisation, dont celle du C (dont le premier standard remonte à 89 rappelons le). Si les points d'entrées ont été mis à jour depuis et que Windows accepte aussi le point d'entrée actuellement répandue (autrement dit, la fonction main), beaucoup des choix techniques de l'époque ont perduré pour des raisons de compatibilité (car oui, Windows possède une API extrêmement stable, contrairement à ce que l'on trouve dans les environnements Linux). Mais pareil, il n'y a pas de solution quoi meilleure que l'autre Les deux ont des avantages et des inconvénients.

Et une fois encore, ce n'est pas une limitation de Windows. C'est une problématique entre un environnement POSIX et un non POSIX. C'est radicalement différent.
Si, il y a une approche correcte, qui maintient la sémantique de la liste d'arguments sur toute la ligne, de la commande ou du script jusqu'à la fonction main du programme, et une approche fondamentalement problématique et qui encourage les failles de sécurité, mais qui marchotte à peu près avec des hacks et des contournements.
Sérieusement ? Appeler ce qui relève d'un adapteur ou d'un wrapper un hack ? Sinon, certains langage n'avaient pas la notion de tableau d'arguments, mais bien d'une ligne : BASIC, Fortran à partir de 2003 (bon, qui propose les deux approchent :p), mais qui n'avait aucun mécanisme standard avant. Il me semble que COBOL permet les deux aussi. Et je suis loin de connaitre tous les langages.

Le problème est que tu considères la sémantique de la liste d'arguments comme allant de soi et étant une obligation aujourd'hui. Même si c'est très répandu, c'est loin d'être toujours le cas.
Le fait que les langages de programmation aient repris cette sémantique indique bien que tout le monde considère ça comme la manière correcte la plus pratique de faire.
Ma correction.

Sinon, cette faille est du même acabit qu'une injection SQL qui serait exploitable car le connecteur à la base de données, sensé protéger via l'utilisation de requêtes paramétrées, fait mal son boulot. Est-ce qu'on dit pour autant que ce sont les SGBD qui sont troués ? Ou les API qui sont mal utilisées ?

Le 12/04/2024 à 21h 46

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.
Vraiment ? L'argument serait valide pour un petit nombre de personnes, ou sur un langage unique.
Ce n'est pas le cas ici.

Le standard sur lequel s'appuie Rust est celui de GNU C, pas "Linux" (qui est un noyau). Rien de bien nouveau, et qui à défaut d'être une norme, est un standard d'interopérabilité.
Qui plus, un vieux standard : on ne parle pas de dernière fraîcheur.

La vieillerie cmd.exe contient une manière très particulière (comme personne d'autre) de fonctionner, et ce depuis donc bien trop longtemps.
Une n-ème démonstration que l'habitude de M$ de produire du non-standard crée un/des risque(s) pour les utilisateurs de leurs produits.

Les langages doivent donc adopter un comportement particulier pour ce système d'exploitation particulier. D'aucuns dirait que c'est bien le système d'exploitation le problème.

Cf. https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

Le standard sur lequel s'appuie Rust est celui de GNU C, pas "Linux" (qui est un noyau). Rien de bien nouveau, et qui à défaut d'être une norme, est un standard d'interopérabilité.
Qui plus, un vieux standard : on ne parle pas de dernière fraîcheur.

Pour être plus précis, le standard derrière s'appelle Posix (et pas GNU C). Sauf que l'API Windows existe 1985, POSIX depuis 1988. Windows ne respecte donc pas un standard qui n'existait tout simplement pas l'époque des premières versions du système d'exploitation.
Les langages doivent donc adopter un comportement particulier pour ce système d'exploitation particulier. D'aucuns dirait que c'est bien le système d'exploitation le problème.
C'est le principe de la bibliothèque standard de chaque langage. Quand tu as un langage dont l'API est proche de Posix, c'est plus simple à développer sur un système Posix que sur un système non Posix.

Le fait que plusieurs personnes se sont cassées les dents et qu'il y ait une faille à ce sujet aujourd'hui montre 2 choses :
- écrire une implémentation d'une API standard, ce n'est pas quelque chose de trivial
- un manque de documentation de l'API Windows.

Mais cela ne signifie pas que l'API présent une faille comme beaucoup le pense.

Le problème aujourd'hui touche uniquement Windows car :
- les systèmes à base de Linux (distribution classique, Android, etc.) respectent plus ou moins le standard POSIX
- les BSD respectent plus ou moins POSIX
- MacOS (basé sur BSD) respect plus ou moins POSIX

En fait, Windows est le seul système d'exploitation "grand publique" qui ne soit pas Posix de nos jours.
Une n-ème démonstration que l'habitude de M$ de produire du non-standard crée un/des risque(s) pour les utilisateurs de leurs produits
Comme dit plus haut, le standard n'existait pas à l'époque des premières versions de Windows.

Le 12/04/2024 à 21h 25

Pour avoir eu un souci similaire en Java (plus exactement une issue reportée par un outil de sécurité), c'est surtout qu'il y a une différence fondamentale entre Windows et Linux : en C, tu as des commandes comme execvp dont la signature passe par un tableau de paramètres.

Mais CreateProcess fonctionne différemment : learn.microsoft.com Microsoft

[in, out, optional] lpCommandLine
The command line to be executed.
The maximum length of this string is 32,767 characters, including the Unicode terminating null character. If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters.
On passe une ligne de commande - pas un exécutable et ses paramètres - , ce qui introduit tout un tas de problèmes :

- celui des espaces
- celui des caractères spéciaux, qui t'en qu'à faire sont différents de Windows à Linux
- ... une limite de 32767 caractères

Pour reprendre Java, et je suppose que Rust fait pareil, on utilise bien des tableaux dans le code du langage : github.com GitHub

Côté Windows, on voit que Java recalcule une ligne de commande : github.com GitHub

Côté Linux c'est (bien) différent : on passe des tableaux, que des tableaux, rien que des tableaux avec la seule contrainte du caractère NUL en fin de chaîne.

- github.com GitHub
- github.com GitHub

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.

(si les liens ci-dessus référencent Java 21, ça existe depuis au moins Java 8, donc ce problème Windows qui concerne Rust, Java, etc.... est là depuis au moins 2013 :))

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.