Les DSI et plein d'utilisateurs l'ont fait oui, mais il est évidemment beaucoup plus facile de se dire que non, cela évite de devoir de poser des questions sur le pourquoi des problèmes de Linux à décoller sur le desktop
Oh il y a certainement matière à critiquer certains aspects du système d'update, mon commentaire était plutôt destiné au reste du commentaire auquel je répondais
Je n'ai dit nulle part que c'est impossible à règler. Je te dit depuis le début que :
a) ce n'est pas aussi simple que tu le penses à règler
b) cela pose des risques à considèrer, à mitiger
c) cela ne se fait pas en 5 minutes
Et que ces paramètres là font que dans l'ordre des priorités, au vu du bénéfice à en tirer pour la population d'utilisateurs qui est très faible, ben ce n'est pas du tout en haut de la liste des priorités.
Tu insistes à croire qu'ils ne le font pas car ils s'en foutent, sans chercher à comprendre comment ils prennent leurs décisions, en croyant que tes 3 options imaginées en 5 minutes sont simples et pourraient vite être implémentées si seulement ils n'étaient pas des braneleurs et voulaient avoir un produit de qualité.
Je te le redis, si demain tu étais le project manager d'Excel, avec tous ces critères à gèrer, tu prendrais exactement la même décision qu'eux.
Mettre un warning que tout le monde voit (parce que tout le monde à peu près utilises des dates) c'est un problème ENORME , parce que quand tu parles de disons 300 million d'utilisateurs, ca te fait 3 millions de gens qui appellent le support, qui paniquent, … au minimum par exemple. Cela fera un certain nombre de gens qui choisiront la mauvaise option quand tu as un optin, etc…
Non vraiment, tu ne te rends pas compte de l'impact qu'un changement a sur des plateformes de cette taille. Excel n'est pas un soft qui change à vitesse grand V, et pour une bonne raison.
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.
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é.
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 ?
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.
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.
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.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à -1. Dernière modification le 04 mai 2025 à 16:08.
Les DSI et plein d'utilisateurs l'ont fait oui, mais il est évidemment beaucoup plus facile de se dire que non, cela évite de devoir de poser des questions sur le pourquoi des problèmes de Linux à décoller sur le desktop
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à -2.
Mais mon cher, évidemment que Windows n'est pas parfait, ne répond pas parfaitement aux demandes de tout le monde, etc…
Tout comme Linux, qui a ses propres problèmes.
Mais voilà, résultat final, le public visiblement préfère cette "bouse" à ton OS favori.
Sinon, je doutes fortement que Windows indexe les données d'un utilisateur dans une base accessible à tous les utilisateurs…
[^] # Re: Enfin !
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 1. Dernière modification le 30 avril 2025 à 14:26.
Ah mais qu'on se comprenne, les railleries ne sont absolument pas pour ceux qui se démènent, qui travaillent à combler les lacunes.
Elles sont pour ceux qui devant leur PC nous rappellent tous les ans que c'est l'année du desktop finalement.
Ce sont 2 groupes diffèrents.
[^] # Re: m$ c'est de la merde
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à -6.
C'est bon on a compris, tu as 13 ans et tu n'as aucune idée de ce qu'est un ordinateur ou un OS.
Reviens nous voir quand tu auras grandi
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 0.
Oh il y a certainement matière à critiquer certains aspects du système d'update, mon commentaire était plutôt destiné au reste du commentaire auquel je répondais
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à 0.
Je n'ai dit nulle part que c'est impossible à règler. Je te dit depuis le début que :
a) ce n'est pas aussi simple que tu le penses à règler
b) cela pose des risques à considèrer, à mitiger
c) cela ne se fait pas en 5 minutes
Et que ces paramètres là font que dans l'ordre des priorités, au vu du bénéfice à en tirer pour la population d'utilisateurs qui est très faible, ben ce n'est pas du tout en haut de la liste des priorités.
Tu insistes à croire qu'ils ne le font pas car ils s'en foutent, sans chercher à comprendre comment ils prennent leurs décisions, en croyant que tes 3 options imaginées en 5 minutes sont simples et pourraient vite être implémentées si seulement ils n'étaient pas des braneleurs et voulaient avoir un produit de qualité.
Je te le redis, si demain tu étais le project manager d'Excel, avec tous ces critères à gèrer, tu prendrais exactement la même décision qu'eux.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -2.
Mettre un warning que tout le monde voit (parce que tout le monde à peu près utilises des dates) c'est un problème ENORME , parce que quand tu parles de disons 300 million d'utilisateurs, ca te fait 3 millions de gens qui appellent le support, qui paniquent, … au minimum par exemple. Cela fera un certain nombre de gens qui choisiront la mauvaise option quand tu as un optin, etc…
Non vraiment, tu ne te rends pas compte de l'impact qu'un changement a sur des plateformes de cette taille. Excel n'est pas un soft qui change à vitesse grand V, et pour une bonne raison.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à -7.
Autre possibilité, qui est de loin la plus plausible: tu ne comprends rien à un système que tu critiques constamment.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -1.
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.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -3.
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é.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -5.
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
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -3.
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é.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -2.
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.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -1. Dernière modification le 25 avril 2025 à 18:06.
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é.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -2. Dernière modification le 25 avril 2025 à 17:43.
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.
[^] # Re: Volontaire ?
Posté par pasBill pasGates . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à -2.
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…
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 1.
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.
Ah ben oui, parce que les logiciels open source on le sait bien, ce n'est jamais de la merde en boite…
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é.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 2.
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
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 1.
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.
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é.
https://techcommunity.microsoft.com/blog/windowsosplatform/hotpatching-on-windows/2959541
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 2.
Tu connais tous les softs qui lisent cette configuration ? Non, tu fais une supposition ici qui est dangereuse.
Il est beau ton monde ou tous les softs utilisent systemd, mais c'est un monde imaginaire.
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
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 2.
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.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 2.
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.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 0.
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.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à -3.
C'est un soupçon, pas forçément basé sur grand chose je te dirais.
[^] # Re: Atomique ?
Posté par pasBill pasGates . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 3.
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.