Aujourd'hui à 12h 28

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

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

Hier à 15h 11

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

Aujourd'hui à 12h 10

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.

Hier à 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

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

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 .

[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

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

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

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

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

Le 20/04/2024 à 12h 21

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

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

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

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

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

+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

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

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

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.

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

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 )

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

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

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

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

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

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

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

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

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

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

Le 12/04/2024 à 17h 51

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

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

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

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

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

Le 12/04/2024 à 09h 29

Aussi il faut se mettre a la place de l'utilisateur lambda : l'OS pas maintenu sur le téléphone ne donnera lieu à aucune notification donc pas d’inquiétude, par contre pour Windows en plus des notification il y aura surement un passage au JT et différents sites d'actualités donc inquiétude.

Justement, c'est bien ça qui me chiffone. Microsoft est transparent et averti longtemps avant, et se prend plein de skud sur le sujet.

Par contre, si on met tout sous le tapis, personne n'en parle, même si les pratiques sont encore pire

Le 12/04/2024 à 08h 57

Il te suffit d'aller dans les paramètres > Windows Update > et de cliquer sur "Obtenir un bilan de santé du PC".

Tu auras toutes les démarches nécessaires ;)

Cela va te permettre d'ouvrir (ou d'installer avant si besoin) l'application de contrôle d'intégrité du PC. Tu as un encart qui correspond à Windows 11. Si tu cliques sur "Vérifier maintenant", tu sauras si ton PC est compatible ou pas, si non, pourquoi.

Le 12/04/2024 à 08h 51

Ou sinon, on reste sous Windows 10 sans support. C'est sur, c'est pas top d'un point de vue sécurité, mais c'est déjà ce qui est fait aujourd'hui avec les smartphones et personne ne s'en plaint. Donc, à mon avis, beaucoup le feront.

Surtout que la fin du support de signifie pas que cela ne fonctionnera plus du jour au lendemain. Quand on voit la durée de vie de XP, il y en a encore pour des années. Ce qui a vraiment "motivé" les derniers récalcitrants à changer, c'est les applications qui ne supportaient plus XP, à commencer par les navigateurs.

Vu la part de marché de Windows 10 sur Windows 11 actuellement (pour les Windows installés, grosso modo 70% de Win10 contre 30% de Win11), je vois plusieurs possibilité :
- Microsoft fait comme XP : la durée de vie a été étendue à plusieurs reprises
- Microsoft a continué de réaliser des mises à jour de sécurité lorsqu'il s'agissait de failles critiques (jusqu'en 2019 je crois) alors que le support de XP SP3 date de 2014 (date de support étendu !).
- Microsoft autorise l'installation de Win11 sur des PC "non compatible", en désactivant certaines fonctionnalités (comme celles requérants la présence d'un TPM)
- Microsoft ne fait rien. La part de Windows 10 restera tout simplement importante.

Après, les gens peuvent aussi réfléchir 2s. Sur les portables, c'est un point plus compliqué (je le concède), mais sur les tours, rajouter un module TPM à la carte mère est souvent possible pour un coût dérisoire (quelques dizaines d'€). Donc quand je lis que les entreprises devront changer leur parc informatique, c'est surtout que ces entreprises devraient changer d'équipe informatique. Sans compter le nombre d'équipement en réalité matériellement compatible, dont une fonctionnalité est désactivée dans l'UEFI (coucou le TPM).

Microsoft n'a pas changé les prérequis matériels depuis au moins Windows Vista (oui oui, Vista !). La migration d'une version à l'autre est gratuite depuis Windows 7. Des versions successives de Windows auront donc eu comme prérequis la même configuration matériel pendant près de 20 ans ! 20 ans, c'est trèèèèès long en informatique.

Ca me tue aujourd'hui de lire que Microsoft fait de l'obsolescence programmée avec Windows 11, alors que justement, de ce point de vue, c'est un des acteurs privés qui fait le plus d'effort à ce sujet, bien loin devant ses confrères des GAFAM comme Apple.

Enfin, les gens auront le choix, c'est aussi à eux de prendre leur responsabilité :
- continuer d'utiliser Windows 10, sans support donc
- installer un OS alternatif
- changer de matos

Donc non, Microsoft n'oblige pas a changé son matériel. Les utilisateurs ont juste un choix à faire. Mais est-ce qu'ils se posent la question alors que leur téléphone n'a pas reçu de mise à jour depuis 2 ans ?

Le 11/04/2024 à 14h 03

D'autres ne sont pas de cet avis apparemment. En résumé : baisse du nombre d'utilisateurs de 30% en 1 an. Pas certains que l'on puisse dire que ce réseau social se porte bien du coup.

Le 11/04/2024 à 11h 30

Toutes les fortes variations sur unknown sont en fait des Windows non reconnus.

On distingue que ChromeOS est aussi impacté par ces pics. Une baisse de Chrome OS se traduit souvent par une hausse de Unknown. Il y a souvent un pic correspondant avec Windows presque au même instant, mais parfois un peu décalé (ce qui rend très difficile toutes interprétations).

Il faudrait analyser les données brutes pour aller plus loin...

Le 11/04/2024 à 11h 23

Oui, je suis plutôt d'accord avec ta conclusion.

Maintenant, Windows, même si pas parfait, à un mécanisme de mise à jour plutôt bien rodé, dans le sens où si ça foire, il arrive à revenir tout seul dans une situation stable dans la grande majorité des cas. Ca fait même des années que je n'ai pas eu à "réparer" un Windows manuellement après une mise à jour en erreur (depuis Windows 7).

Sous Linux, je ne comptais plus les kernel panic (parce qu'il manquait un argument au boot par rapport au modèle du portable ou que le nom du périphérique de boot avait changé par exemple), au DE qui ne démarrait plus, quand ce n'était pas purement et simplement X/Wayland après une mise à jour. Bref, sous Linux, j'avais toujours un live CD dans un coin pour réparer ma bécane en cas de problème

Le 11/04/2024 à 11h 14

Avec un graphique comme ça, j'ai tendance à me dire que les crêtes sont simplement des erreurs dans la détermination des OS (surtout que c'est avec Unknown).

Il y a tellement de chose qui peuvent influencer la détermination de l'OS, a commencer par le UserAgent. Il suffit donc qu'il y ait une mise à jour d'un navigateur ou de l'OS pour générer ce genre de pic.

Le 11/04/2024 à 10h 37

Comme quoi on a tous des ressentis différents. Je suis aussi un adapte du ça marche, c'est stable, c'est cool. Du coup, c'est à cause de ça que je suis repassé sous Windows, après une nième mise à jour de Linux qui avait flingué ma machine, et j'avais la flemme de passer encore des heures à résoudre le problème.

Et si au début, ça m'a fait un peu bizarre de repasser à windows, j'ai bien moins de soucis à gérer avec les mises à jour depuis.

On est d'accord que ça me fait chier aussi les mises à jour imposées. Mais dans un sens, c'est pas plus mal, car c'est bien le genre de truc que je suis capable de dire plus tard, plus tard, plus tard et de remettre cela beaucoup trop longtemps.

Windows n'est pas parfait (loin de là), mais ça m'a fait gagner du temps.