pasBill pasGates a écrit 16216 commentaires

J'ai vu plus bas 2-3 hypothèses que tu as données pour une solution.

Tu as évalué leur effet sur le fonctionnement interne d'Excel, les risques que ces changement poseent, sur ce que cela impliquerait potentiellement pour les utilisateurs existants et leur feuilles de calcul, … ?

Tu ne te rend visiblement pas compte que c'est un truc très sensible, à appréhender très soigneusement, parce que si ils se loupent, cela peut avoir de sérieuses conséquences vu l'utilisation énorme d'Excel par exemple chez les groupes financiers et autre.

Ensuite, ils ne veulent certainement pas compliquer l'expérience utilisateur pour tout le monde juste pour ce truc.

Bref, non, c'est loin d'être simple. Et tout cela, pour une infime minorité de gens.

Poses toi la question de combien de gens cela représente dans le monde d'Excel comparé à la population d'utilisateurs.

C'est très clairement une toute petite minorité.

Mais bien sûr qu'ils ont la qualité comme priorité mais la qualité c'est quoi ?

C'est répondre aux attentes des utilisateurs. Les utilisateurs veulent évidemment un produit stable, qui donne des résultats corrects, une UX agréable, des performances acceptables, un produit sûr, avoir les features qu'il faut, etc..

La qualité ce n'est pas résoudre des bugs qui n'affectent quasiment personne au détriment des choses ci dessus

La réalité est que comme partout ailleurs il y a plus de travail que de gens pour le faire, du nouveau boulot apparaît tout le temps, et il y a une priorité à mettre aux tâches.

La manière d'assigner une priorité aux tâches, comme partout, est liée à ce que les clients veulent, aux problèmes opérationnels, à la complexité et au risque des changements, etc…

La réalité est que ce truc est mineur, il m'emmerde quasiment personne. Le corriger présente un risque potentiel, et vu qu'il n'emmerde quasiment personne le bénéfice en retour du risque est négligeable pour la base utilisateur.

Tu appelles cela dette technique, oui effectivement, mais c'est loin d'être le seul problème dans cette catégorie et celui ci, comme expliqué au dessus, n'a vraiment pas la priorité.

Oh mais si seulement c'était si simple !

Les dates dans Excel sont utilisées par des centaines de millions d'utilisateurs.

Faire un changement amène toujours un risque de régression. Si Aujourd'hui ils essaient de faire ce changement ils prennent le risque d'affecter négativement ces millions d'utilisateurs. Pour quel bénéfice en retour ? Quasiment rien, 3 pekins à qui cela pose problème.

Oublie l'argent, d'un point de vue satisfaction du client corriger ce truc maintenant n'est absolument pas la bonne chose à faire.

En 2090 quand ce problème sera vraiment un problème pour une grande partie des utilisateurs la donné sera différente mais aujourd'hui cela n'a aucun sens.

Tout est question de priorité, que demandent les clients ?

Est-ce que c'est quelque chose que la plupart des client veulent, ou quelque chose qui les met en danger, etc… ? Non ? Alors est-ce vraiment si important aujourd'hui ou vaut il mieux mettre la priorité ailleurs ?

Une simple question de management de projet comme dans tout autre projet software. Si on te mettait comme project manager de Excel demain et que tu avais devant toi la liste de toutes les choses à faire, ce serait loin d'être la priorité.

En disons 2090, si Microsoft et Excel existent encore, ils se poseront autour d'une table et réfléchirons au meilleur moyen de gèrer le problème. Il y a plusieurs approches possible et selon la situation à ce moment ils regarderont quel genre de mode de compatibilité ils ont besoin.

Mais il n'y a aucun sens à discuter de ce problème aujourd'hui, il ne va affecter personne avant 70 ans.

Bref, Excel 2020, 2024 … 2088 n'auront aucun problème, et peut-être que 2092 aura quelque chose, ou pas, on n'en sait rien.

Personne ne va utiliser Office 2016 en 2100, si quelqu'un est encore en train d'utiliser Excel 2016 en 2095, il aura encore 5 ans pour s'occuper de gèrer le problème, et si Excel 2095 est un produit qui existe, il aura probablement un workaround pour gèrer cela.

Bref, comment faire une montagne d'un trou souris…

Bon, alors il faut déjà mettre une chose au clair : je parle de systèmes bien conçus et de logiciels bien intégrés. Genre des distributions avec des vrais paquets de qualité amateur.

Il est chouette ton dogme, mais quand tu es une boite de plusieurs milliers de postes utilisant les softs dont tu as besoin plutôt que uniquement les softs satisfaisant ta vision dogmatique, ben ta solution part à la poubelle.

Maintenant c'est sûr que si on parle de systèmes dépendant fortement de logiciels propriétaires de qualité professionnelle, on n'a aucun moyen d'être sûr de quoi que ce soit et le plus sûr est évidemment de redémarrer au moindre changement.

Ah ben oui, parce que les logiciels open source on le sait bien, ce n'est jamais de la merde en boite…

Un système qui est capable de démarrer des services pour obtenir un système qui fonctionne, est aussi capable de les redémarrer après une mise à jour. Ou du moins, peut l'être s'il a été conçu avec cette préoccupation. Bref, dire que redémarrer simplement les services concernés après une mise à jour, ce n'est pas fiable parce qu'on ne sait pas dans quel ordre les arrêter et les démarrer, c'est faux de manière générale.

Toi tu as du mal à comprendre que cela n'a rien à voir avec quel OS il s'agit, parce que Windows et Linux les 2 savent en théorie gérer les dépendences entre services, mais que plein de services installé à travers des applications venant de 235 sources diffèrentes ne vont pas forcèment suivre les règles, et que cela te plaise ou non ce cas doit être gèré.

Après, si c'est le gestionnaire de fichiers ou un autre outil qui fait partie de ce que tu appelles ton environnement de bureau qui a été mis à jour, aucune raison de se reloguer.

Non effectivement. Mais quand tu as un système de composants (genre COM our Corba) ou ton gestionnaire de fichiers se retrouve à être utilisé à travers RPC par plein d'autres softs ben cela devient soudainement compliqué de savoir quoi fermer et tu peux facilement te retrouver à devoir … tout fermer.

C'est pas pour rien que je te dis que c'est une problématique non trivial, il y a plein de cas à prendre en compte

les logiciels qui utilisent aussi ce fichier de configuration auront ce paquet dans leurs dépendances pures ou dans leurs recommandations ou suggestions.

C'est une belle théorie de croire que tous les softs vont avoir le format de package que tu désires et que leur manifeste va correctement inclure ce fichier, surtout si il est toujours présent sur les machines.

Peu importe, la solution existe et fonctionne très bien sur les systèmes qui l'utilisent. Il y a aussi des équivalents, de toute façon c'est un autre aspect du problème de l'ordre de démarrage des services en général, qui est déjà solutionné. Pas besoin de considérer ça comme un obstacle donc.

Si c'est un obstacle. Parce que l'objectif est d'avoir un système d'update qui met effectivement ta machine à jour et la protège plutôt qu'un système qui fait les choses à moitié.

Aurais-tu des détails techniques sur l'implémentation, en particulier le lien avec les fichiers sur le support de stockage qui doivent bien être modifiés aussi ?

https://techcommunity.microsoft.com/blog/windowsosplatform/hotpatching-on-windows/2959541

Après tout, si une mise à jour de ntpd apporte une configuration corrigée, le paquet qu'on vient de mettre à jour sait parfaitement quel est le service à redémarrer pour appliquer ce changement.

Tu connais tous les softs qui lisent cette configuration ? Non, tu fais une supposition ici qui est dangereuse.

Pour l'ordre de redémarrage, systemd fait ça très bien avec une belle gestion des dépendances.

Il est beau ton monde ou tous les softs utilisent systemd, mais c'est un monde imaginaire.

Mais bref, pour en revenir au sujet, je maintiens que c'est vraiment dommage d'imposer un redémarrage pour tout type de mise à jour. Avec Windows, ça se comprend puisque le système d'exploitation a un défaut intrinsèque qui empêche de mettre à jour un fichier utilisé par un processus en cours d'exécution.

Mais ce n'est pas le cas… Tu peux faire tourner Windows et faire des updates sans redémarrer sous Windows sans problème : https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch

Pour atteindre l'objectif que tu cites il y a plusieurs méthodes, par exemple le hotpatching, qui est la méthode choisie par MS : https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates

Avec cela, plutôt que redémarrer chaque mois, c'est 4 fois par an. Avec le hotpatching tu ne te casse pas la tète à devoir redémarrer un processus, à devoir gèrer les processus dépendent de ce processus que tu redémarres, etc…

Bref, de nouveau, la méthode que tu cites n'est pas essentielle, il y a d'autres approches qui ont aussi leurs avantages.

Ça ne sert certainement pas à rien, et le fait d'imposer un redémarrage pour toute mise à jour du système est connu comme étant une vraie plaie. Ça a même inspiré des points de scénarios de films je crois.

Mais tu rèves, cela n'a rien de spécifique à Windows. C'est une architecture standard pour des applications desktops qui ont un service en arrière plan. Le client est fait spécifiquement pour tourner avec ce service et rien d'autre, sur une machine et c'est tout. Plein d'éditeurs ne se cassent pas les couilles à maintenir une ABI pour ce qui est au final 2 composants liés de manière très proche et qui ne concerne que eux et aucun autre client.

Ton idée que ces 2 doivent pouvoir être modifiés séparement est un dogme, qui ne repose sur pas grand chose de concrèt, tu ne prends pas du tout en compte les coûts de faire cela en comparaison du bénéfice que tu as en retour.

Ça ne sert certainement pas à rien, et le fait d'imposer un redémarrage pour toute mise à jour du système est connu comme étant une vraie plaie. Ça a même inspiré des points de scénarios de films je crois.

Je bosse depuis maintenant plus de 10 ans dans une boite qui est quasi exclusivement du Linux en tant que serveur, qui a sa propre distrib, des pontes de Linux employés içi, qui fait ses propres CPUs, etc… Bref, Linux, il n'y a pas grand monde sur cette planète qui le connait mieux qu'eux.

Tu crois qu'ils font quoi en ce qui concerne les updates ? Qu'ils s'amusent à aller regarder sur chaque machine quel processus arrèter et redémarrer et sont convaincu que cela marche sans problème ? On parle juste de quelque millions de systèmes hein, pas grand chose.

C'est un soupçon, pas forçément basé sur grand chose je te dirais.

Non.

Cela te montre quel soft doit redémarrer pour recharger une librairie parce qu'il regarde quel processus à chargé quelle librairie. Il ne va pas te montrer quel soft relancer pour qu'il recharge des changements de configuration par exemple, qui pourraient faire partie du patch de sécurité. Il ne te dit pas quels softs doivent aussi redémarrer parce qu'ils ont une dépendance non-manifeste à un soft que tu dois redémarrer à cause du patch.

C'est pas pour rien que je dis que ces trucs sont des gimmicks. J'ai quand même passé 13 ans dans le groupe qui faisait toutes les updates de Windows, c'est une problématique très compliquée, avec plein de cas à gérer.

Mais du tout non, parce que needrestart ne fait pas la moitié du boulot. Par exemple il ne prend pas en compte les patchs de sécurité qui ne correspondent qu'à une update d'une valeur de configuration et oû il faut redémarrer le soft pour que ce soit pris en compte.

Faut trouver ensuite l'ordre dans lequel redémarrer les softs, quels softs peuvent être arrété et quand, etc…

Ton petit cas particulier fait à la mano est impossible à généraliser au niveau d'un OS grand public avec des softs venant de plein d'horizons diffèrents.

Mais bien sur que si tu es un nerd et que tu fais cela depuis 20 ans, tu comprends tous ces détails, tu fais bien attention, au final tu peux, mais quand tu es Windows et tu as 1 milliard d'utilisateurs dont la plupart n'ont pas les connaissances, c'est un modèle ridicule qui ne sert à rien.

Idem en entreprise, quand tu as 1000 machines voire bien plus à gèrer, oû les machines ont des OS de versions diffèrentes, font tourner des softs diffèrents, ce modèle ne sert strictement à rien, c'est impossible à gèrer.

Bref, c'est un gimmick, en pratique pour un OS grand public c'est effectivement inutile.

Tu assumes ici que l'interface entre le serveur et le client est publique, hors si ces 2 sont toujours sur la même machine et ont pour but simplement de permettre la communication avec le service central il n'y a aucune raison d'avoir une ABI-API documentée, publique, … Avoir cela implique tout un effort de compatibilité ascendantes, support de vieilles versions, etc… qui est douloureux.

Je ne sais pas pour ta machine, mais sur Windows il est extrêmement commun de trouver un service en arrière plan et un client dans chaque compte utilisateur qui communiquent avec le service par named pipe ou autre. Le service n'a pas de connection réseau hors de la machine, la seule connectivité est pour ces clients locaux et l'application est un tout.

Il y a plusieurs updates installées chaque mois, fréquemment une du noyau. Qui à part un nerd comme toi va aller regarder les détails de chaque update, aller voir et vérifier 3 fois quels sont les softs à arréter, relancer, etc… et le faire à la mano ?

Personne, c'est douloureux, manuel, avec risque de se brouter, juste pour éviter un redémarrage. Bref, c'est un gimmick.

C'est d'une naiveté…

Il y a plein de systèmes client-serveur dans un OS (ex: un service en background dans son compte à lui et un client tournant en compte utilisateur qui fait office d'interface)

Il est fréquent que les 2 partagent les mêmes librairies. Un client, cela s'arrète et redémarre bien plus souvent qu'un serveur par contre d'habitude.

Tu installes ton update, en remplaceant un fichier que les 2 utilisent. Le service utilise la v1, si le client se relance entre les 2, le client utilisera la v2, ce qui pose potentiellement des problèmes selon les usages, ou alors il faut assurer une compatibilité de protocole, etc… ce qui est lourd à gérer et chiant.

Sans parler du fait que si tu installes ton fichier sans rien relancer, il n'est pas chargé en mémoire, l'ancien est toujours utilisé. T'as installé 3 mois d'updates sur ton serveur sans rien redémarrer c'est cool, en mémoire tu auras toujours le code vulnérable d'il y a 3 mois.

Bref, ton idée que l'approche Linux est clairement meilleure est naive, en pratique la différence est très faible car dans les 2 cas il faut stopper et redémarrer le code qui utilise les fichiers modifiés pour que l'update soit effective. Vu qu'il n'y a pas de moyen sur et simple pour automatiquement redémarrer tous les softs affectés, la pratique est de redémarrer les systèmes. Et c'est encore plus vrai vu la fréquence des updates de sécurité du noyau.

Cela fait 25 ans qu'on annonce que Linux arrive pour le grand public, ravi d'apprendre que cette fois ce sera la bonne, promis juré !

Tant qu'on est sur le sujet, la fusion comme source d'énergie inépuisable, c'est pour Jeudi c'est cela ?

Certainement, mais ils utilisent souvent des systèmes existants

Perso je te dirais que si tu regardes l'énorme majorité des utilisations de ces algos, c'est pour du HMAC ou du simple hachage.

Et là, plus c'est rapide, mieux c'est. Le scénario 'mot de passe' et essayer de bloquer les rainbow tables est en fait plutôt rare, parce que les gens ne s'inventent pas des systèmes d'authentification à base de mot de passe tous les jours, par contre ils écrivent du code qui signe et vérifie des signatures de fichiers, blobs, … fréquemment.