Microsoft a présenté il y a deux jours une amélioration importante à venir pour son processus de mise à jour sous Windows 11. À partir de la fin de l’année, le différentiel appliqué à certains correctifs mensuels sera plus fin. Avec à la clé, une réduction du temps d’installation et du poids des mises à jour.
Pour comprendre l’intérêt du changement annoncé le 15 juillet, revenons sur le fonctionnement des mises à jour mensuelles sur Windows 10 et 11.
Actuellement, Microsoft en déploie deux types. Les plus importantes, les correctifs de sécurité, sont publiées le deuxième mardi de chaque mois. Cette fréquence est la même depuis de nombreuses années. Elle a été mise en place pour donner aux entreprises un rythme clair et prévisible. Ces correctifs sont téléchargés et installés automatiquement, la machine devant après coup redémarrer. En entreprise, ils sont souvent gérés par un processus spécifique, permettant de planifier l’installation.
Viennent ensuite les mises à jour de « qualité ». Celles-ci ne sont plus liées directement à la sécurité, mais viennent corriger des bugs plus généraux. Ces mises à jour peuvent également contenir de nouvelles fonctionnalités. Bien qu’il y en ait pratiquement tous les mois, leur installation ne devient obligatoire qu’au bout de quelque temps.
Il faut ajouter un troisième type de mise à jour, nettement plus rare : les évolutions majeures. Elles sont annuelles ou semestrielles selon le système et les années. Pour Windows 11, la prochaine est la 24H2, dont le nom signifie « deuxième semestre 2024 ». Ces mises à jour modifient de larges pans du système et proposent de nombreuses nouveautés. Leur installation est optionnelle pendant un an, après quoi elles deviennent obligatoires. Elles se téléchargent et s’installent alors automatiquement. Sur une machine un peu ancienne, l’immobilisation de la machine peut prendre 10 à 20 min.
Le statut RTM et le calcul du différentiel
Depuis des années, les mises à jour de sécurité de Windows fonctionnent sur un mode cumulatif. Là où il fallait avant installer les correctifs mensuels comme autant de mises à jour séparées, Windows Update propose aujourd’hui une seule mise à jour contenant tout.
Ce « tout » est une accumulation de toutes les mises à jour rendues disponibles depuis la RTM de la dernière révision majeure du système. RTM, pour Release To Manufacture, est le statut d’une version signifiant qu’elle est prête pour distribution. C’est en général un équivalent à « version finale ». Il y a quelques subtilités, mais elles ne sont pas importantes dans le cas présent.
Pour donner un exemple simple, la version majeure en cours de Windows 11 est la 23H2. Quand des mises à jour mensuelles sont préparées, elles incluent tout ce qui est sorti depuis la RTM de cette version. Les téléchargements ont donc tendance à gonfler avec le temps. En revanche, le temps d’installation reste à peu près le même, car seule la partie effectivement absente de la machine est installée. Le reste est « inerte » et disparait après installation.
Vers des mises à jour « checkpoint »
On savait que Microsoft préparait depuis un certain temps un système plus souple. Le 15 juillet, l’entreprise a donc annoncé une importante modification qui arrivera avec la version majeure 24H2 et entrera en piste vers la fin de l’année.
L’éditeur y présente les points de contrôle, ou mises à jour « checkpoint ». L’objectif est simple : plutôt que d’attendre la RTM d’une version majeure pour établir une base de calcul, ces mises à jour établiront un nouveau point de contrôle. Il n’est manifestement pas prévu qu’elles soient présentes tous les mois, mais chacune consistera la base d’un nouveau calcul incrémentiel.
Le gros avantage est qu’elles viendront « casser » l’accumulation faite au fil des mois. Si vous recevez l’une de ces mises à jour, la mise à jour mensuelle suivant ne téléchargera et n’installera que le différentiel (delta) strictement nécessaire.
Les entreprises également concernées
Le delta étant calculé depuis le dernier point de contrôle et non plus depuis la dernière RTM, ce sont toutes les mises à jour qui seront plus légères à télécharger. Microsoft met donc en avant trois avantages : de plus petits téléchargements, une installation plus rapide et une charge moins importante pour les serveurs, qui n’auront plus à fusionner de trop grandes masses de données. Microsoft se permet d'indiquer au passage que ce fonctionnement est plus « durable ».
C’est également valable en entreprise, puisque le changement sera aussi présent dans Windows Server 2025. La prise en charge dans des services comme Windows Update for Business, Windows Autopatch et Windows Server Update Services (WSUS) sera automatique. Les administrateurs n’auront pas à modifier leurs réglages.
Pour les personnes testant les préversions de Windows 11, ces changements sont présents dans la dernière build (26120.1252) du canal Dev du programme Windows Insiders.
Commentaires (40)
#1
#1.1
Pourquoi faire simple quand on peut faire compliqué ! (et faire payé plein pot cette complexité inutile)
#1.2
#1.4
Si tu veux un vrai conccurent à Windows dans l'entreprise, ce serait FreeBSD, ou Readhat, ou Oracle ou Debian, pas "Linux"
#1.10
Pour moi, Windows n'a pas sa place. Il n'est pas stable (je connais pas un PC Windows qui ne doit pas rebooter au bout 3 semaines, ni qui maintient des perfs constantes dans le temps d'utilisation...). Sa seule stabilité, c'est sa rétro-compatibilité et son ABI & API. Mais c'est une force comme une faiblesse. Celà dit je concède que je me suis déjà écharpé avec Linux sur ce point.
La documentation est inférieure à celle de Linux. Exemple, tu cherches la doc pour mmap. J'ai besoin de parcourir plusieurs sous-liens pour trouver l'information de savoir si c'est du COW ou pas. Linux, un simple Ctrl-F et j'ai mon info. Et mieux, j'ai le code source pour répondre à mes interrogations.
En revanche, elle est accessible. Le ticket d'entrée pour la doc de Windows est nettement inférieure à celle de Linux.
Windows n'est pas sécure. Désolé mais le principe de kerckhoffs est pour moi strictement requis pour avoir confiance sinon c'est de la sécurité par obscurantisme. Et nous savons que c'est un échec.
Je pourrais aussi te parler des faibles performances du NTFS et du scheduler I/O du kernel. Pour un OS 2024 d'entreprise c'est assez risible. Ce qui le sauve, c'est la latance des SSD.
La question se pose également pour les autres schedulers et la capacité de Windows à gérer correctement du multiprocessing.
Je termine sur ceci. Windows sera un vrai OS quand il pourra gérer un supercalculateur du top-500. A defaut, pouvoir être aussi rapide qu'un Linux sur un benchmark du LINPACK. Même à code équivalent en asm, Windows reste significativement derrière (sur nos benchmark, ~10-15 % derrière du Linux [Fedora Workstation]).
#1.11
#1.3
Et le téléchargement "unique" n'a pas que des inconvénients :
- les téléchargements étant les mêmes pour tous, il est plus facile de mettre en place un cache / proxy / partage par peer / téléchargement offline
- le gestionnaire de paquets c'est bien pour gérer l'installation d'applications et leurs dépendances. Ici, ce n'est pas le cas, car les dépendances vont dépendre de la machine et énormément de sa configuration hardware (type de processeurs, cartes graphiques, bus, réseau, RAM, disque dur, etc.) avec une complexité, certes peut être pas insurmontable, mais plus grande que la gestion "statique" de dépendance des systèmes de gestion de paquets actuels.
- L'installation de la mise à jour se fait offline entre le moment où elle débute, et le moment où elle se termine. Avec un gestionnaire de paquets, ce n'est pas toujours le cas. On peut certes télécharger en amont les paquets à installer, mais un paquet peut ensuite avoir besoin de ressources complémentaires nécessitant une connexion internet que le gestionnaire de paquets ne pourra pas télécharger lui-même (c'est rare, mais ça arrive).
Je ne dis pas qu'un système différentiel ne présente pas d'avantages et que le système complet est exempts de défauts. Je dis juste que le système "complet" n'a pas que des défauts, et à aussi des avantages ;)
#1.7
Non, je ne connais pas gestionnaire de paquet Linux qui impose. En tout par Debian, Fedora, Ubuntu, Redhat entreprise / Centos, ArchLinux ce n'est pas le cas.
#1.8
Je ne pense pas que ce soit courant dans les paquets des dépôts officiels, mais dans les paquets d'applications hors dépôt, fait par des personnes qui ne sont pas des packagers, oui, ça arrive.
#1.9
*[...] le téléchargement "unique" n'a pas que des inconvénients :
- les téléchargements étant les mêmes pour tous, il est plus facile de mettre en place un cache / proxy / partage par peer / téléchargement offline [...]*
Le téléchargement incrémental ou différentiel n'est pas non plus incompatible avec le caching et le peering : au lieu d'héberger un gros fichier monolithique KB1234.msu, tu héberge son contenu. Il suffit d'héberger les fichiers à l'intérieur de l'archive, et tu héberge aussi le manifest qui contient les métadonnées requises (checksum, conditions d'installation ou pas, etc.)
En procédant comme ça, c'est facile de conserver du cache tout en augmentant la finesse de l'incrémental : toutes les machines téléchargent le manifest, puis ensuite seulement les fichiers unitaires requis.
Et rien n'empêche de concevoir un fetcher dédié pour demander à télécharger la mise à jour hors ligne (genre avec Microsoft Catalog.
#1.12
C'est totalement faux, tous les gestionnaires de paquets connaissent et chargent à l'avance le contenu (éventuellement en // d'un autre install pour gagner du temps). C'est comme ça que les distrib linux ont toujours fonctionné, et c'était absolument impératif à l'époque où les distrib arrivaient en DVD / CD. Sous windows c'est pas du tout le cas, pour beaucoup de soft tu charges en fait un installeur coquille vide qui à son tour va télécharger réellement le logiciel.
#1.13
Quand le téléchargement est dans un script en hook post-install, ton gestionnaire de paquet ne peut rien faire. Je suis d'accord pour dire que le paquet était mal foutu, mais c'est le paquet fourni par l'éditeur. Donc au bout d'un moment...
Par contre, je n'ai pas souvenir d'avoir eu le problème avec des dépôts officiels. C'était toujours des dépôts tiers.
#1.5
Et aussi pourquoi Windows n'a pas de netinstall pour le déploiement ? Bien plus pratique pour déployer rapidement des masters sans avoir à télécharger un iso régulièrement...
Après ce n'est pas tant le téléchargement qui pose souci (avec une connexion fibre c'est assez rapide) que le temps de l'installation lui-même qui est vraiment fou avec une machine récente.
un reboot (obligatoire...) met un temps de dingue à déployer les maj sur l'OS...
Historique des modifications :
Posté le 18/07/2024 à 08h11
Clair qu'on voit sacrément la différence de gestion des maj entre une Debian et un Windows, pour avoir un parc mixte...
Et aussi pourquoi Windows n'a pas de netinstall pour le déploiement ? Bien plus pratique pour déployer rapidement des masters sans avoir à refaire un iso régulièrement...
Après ce n'est pas tant le téléchargement qui pose souci (avec une connexion fibre c'est assez rapide) que le temps de l'installation lui-même qui est vraiment fou avec une machine récente.
un reboot (obligatoire...) met un temps de dingue à déployer les maj sur l'OS...
#1.6
#1.14
Le truc n'est même pas capable de découvrir ce qui est installé sur la machine,
winget ne connait que quelques softs, aucun pilote, pas même les màj de windows,
ça propose presque systématiquement des paquets obsolètes,
un grand nombre de paquets proposent ad vitam la même mise à jour parce qu'il est incapable de déterminer la version installée.
100% inutilisable ! (d'ailleurs MS ne communique plus trop sur cette daube depuis un moment)
Historique des modifications :
Posté le 23/07/2024 à 09h33
Tu n'as pas dû t'en servir pour écrire ça
Le truc n'est même pas capable de découvrir ce qui est installé sur la machine,
winget ne connait que quelques softs, aucun pilote, pas même les màj de windows,
ça propose presque systématiquement des paquets obsolètes,
un grand nombre de paquets propose ad vitam la même mise à jour parce qu'il est incapable de déterminer la version installée.
100% inutilisable ! (d'ailleurs MS ne communique plus trop sur cette daube depuis un moment)
#1.15
Si tu compares à 100% de features avec Apt pour Linux oui, c'est moins complet mais est-ce une bouse pour autant, non et comme d'hab', ce qui est excessif est insignifiant.
J'ai aucun des problèmes que tu cites dans la limite de l'utilisation de l'outil mais peut être que je sais comment et dans quel périmètre utiliser Winget et c'est je crois la même chose avec Apt.
Je te laisse te documenter.
Historique des modifications :
Posté le 24/07/2024 à 00h15
Tu ne dois pas trop savoir de quoi je parle pour dire ça.
et au vu de ta réponse c'est même pire.
Si tu compares à 100% de features avec Apt oui, c'est moins complet mais est-ce une bouse pour autant, non et comme d'hab', ce qui est excessif est insignifiant.
J'ai aucun des problèmes que tu cites dans la limite de l'utilisation de l'outil mais peut être que je sais comment et dans quel périmètre utiliser Winget et c'est je crois la même chose avec Apt.
Je te laisse te documenter.
#1.16
Tous étaient en retard de version dans winget, une fois installé au premier lancement chacun de ces softs proposaient leur propre mise à jour à l'exécution. Une fois la mise à jour faite depuis l'appli, winget oublie le soft et ne le propose plus du tout à l'upgrade.
winget ne gère même pas le propre store de Microsoft
tu ouvres le store Microsoft, il trouve pleins de màj que winget n'avait pas vu.
J'ai suivi tes conseils et me suis documenté :
- 991 bugs ouverts
- les 80 bugs uniquement sur la commande upgrade semblent confirmés mon ressenti
#1.17
Encore une fois Winget n'est pas parfait mais de là à le qualifier de bouse, c'est TON jugement de valeur mais c'est pas le mien dans MON périmètre d'utilisation.
Et en effet, plein de bug ouverts, ça signifie aussi qu'il est utilisé et que ses utilisateurs souhaitent leur faire évoluer. Est-ce que MS met l'emphase nécessaire? MS ne met jamais assez d'effort sur un tas de choses qui mériterait d'évoluer ( coucou Console)
Si tu penses que cet outil serait utile un peu à la manière d'Apt pour Linux, et qu'à ce titre le faire évoluer serait une bonne idée, pourquoi ne pas contribuer au Git de Winget?
Sinon, j'utilise aussi Chocolatey dans certains cas (ie: machines Windows clientes).
#1.20
#1.21
#1.18
Le nombre de bogue a un instant T ne donne absolument aucune information sur la (non) qualité d'un logiciel. Plus le nombre de bogues est grand, plus le logiciel est utilisé. C'est éventuellement la seule chose que l'on pourrait en déduire.
De plus, bogue dans ce contexte est inapproprié, c'est plutôt ticket qu'il faudrait employer. En effet, des demandes d'évolutions apparaissent aussi en tant que bogue. Et s'il y a des demandes d'évolutions, c'est que le logiciel est aussi utilisé.
Enfin, si le nombre de bogues ouvert reflétait la (non)qualité d'un logiciel, alors aptitude ne fait guère mieux que winget. Faut-il en conclure pour autant que c'est une daube ?
#1.19
Ce sont des problèmes majeurs qui rendent l'outil inutile, et ça fait 1an et demi que ces tickets sont ouverts sans prise en compte. (ça s'est plutôt un bon indicateur je trouve ;-)
Je pense que le qualitatif de daube est assez mérité.
Ce n'est pas un simple problème de métadata mal renseigné par les éditeurs tiers, Notepad (le nouveau), paint 3d produit Microsoft ne sont pas dispo !
#1.22
Juste sur les problèmes de version, pour aptitude (et je n'ai pas fait une recherche exhaustive) :
- Apt downloads arch all packages from wrong repo/checks wrong checksum
- apt-get install segfaults with certain repository configurations
- apt ignores versioned provides if non-matching version is installed via another dep
- [apt-get] build-dep can fail if policy selects candidate version that does not satisfy a versioned dependency
- apt-get autoclean keeps old versions when still provided by some source
- apt-get dumpavail does not print all versions
Donc en appliquant ta logique, je pense que le qualificatif de daube est mérité pour aptitude ;)
#2
Ce qu'il se passe avec SCCM, on fait une règle "package les dernières updates du mois pour w11 23h2", il met la dernière cumul et vire ce qui est obsolète depuis > 3 mois dans un package SCCM et les pc téléchargent tous le même package
là vu qu'on ne sait pas l'état des xxxxxpc (dont certains fraichement réinstallés donc RTM, d'autres éteints depuis 4 mois etc), s'il faut garder tous les KB différentiels, dans le même package SCCM "delta 1 mois, delta 3 mois, delta 3ans..."
Faire 1 package new par mois c'est ingérable en distribution sur une grosse infra, sans compter que certains sont superseed, mais si c'est plus du cumulatif, comment je reviens à l'état full patch depuis un RTM avec les updates qui sont purgées par SCCM
Historique des modifications :
Posté le 17/07/2024 à 17h39
Encore un truc à la c*n qui va plomber les admin SCCM, et conduire à des packages de 4TO, ou j'ai pas bien compris.
Ce qu'il se passe avec SCCM, on fait une règle "package les dernières updates du mois pour w11 23h2", il met la dernière cumul et vire ce qui est obsolète depuis > 3 mois dans un package SCCM et les pc téléchargent tous le même package
là vu qu'on ne sait pas l'état des xxxxxpc (dont certains fraichement réinstallés donc RTM, d'autres éteints depuis 4 mois etc), s'il faut garder tous les KB différentiels, dans le même package SCCM "delta 1 mois, delta 3 mois, delta 3ans..."
Faire 1 package new par mois c'est ingérable en distribution sur une grosse infra, sans compter que certains sont superseed, mais si c'est plus du cumulatif, comment je reviens à l'état full patch depuis un RTM avec les updates qui sont purgées par SCCM
#2.1
Ca ne change pas le repository des paquets.
Ce qui va exploser ton SCCM, ce sera la montée des paquets ARM en plus de X64 et x86 s'il t'en reste.
Pour les linuxiens, c'est comme si on ne récupérait pas tout un deb mais uniquement les fichiers différents. Ou si pour mettre à jour un snap on ne retéléchargeait que des morceaux.
#2.2
un kb de 725Mo dans le catalogue c'est 9.9 go dans sccm car ces boulets y ont intégré les features on demand (env 5.7+2.5go) dans tous les kb cumul intégrés dans sccm
extract de sccm sur le KB5040442
| fichier | taille |
|http://../.../public/featureondemand_3294af9937b733783476da837b21943dc160faaa.wim | 5747,73 |
| http://../.../public/edition_b7d4cae381a5971e5bf48a1246488c4e7861a0b0.wim | 2506,84 |
Historique des modifications :
Posté le 18/07/2024 à 08h51
j'ai vu les résultats dans sccm avec leur dernière invention il y a env 1 an
un kb de 725Mo dans le catalogue c'est 9.9 go dans sccm car ces boulets y ont intégré les features on demand (env 5.7+2go) dans tous les kb cumul intégrés dans sccm
extract de sccm sur le KB5040442
|http://../.../public/featureondemand_3294af9937b733783476da837b21943dc160faaa.wim | 5747,73 |
| http://../.../public/edition_b7d4cae381a5971e5bf48a1246488c4e7861a0b0.wim | 2506,84 |
Posté le 18/07/2024 à 08h52
j'ai vu les résultats dans sccm avec leur dernière invention il y a env 1 an
un kb de 725Mo dans le catalogue c'est 9.9 go dans sccm car ces boulets y ont intégré les features on demand (env 5.7+2.5go) dans tous les kb cumul intégrés dans sccm
extract de sccm sur le KB5040442
| fichier | taille |
|http://../.../public/featureondemand_3294af9937b733783476da837b21943dc160faaa.wim | 5747,73 |
| http://../.../public/edition_b7d4cae381a5971e5bf48a1246488c4e7861a0b0.wim | 2506,84 |
Posté le 18/07/2024 à 08h52
j'ai vu les résultats dans sccm avec leur dernière invention il y a env 1 an
un kb de 725Mo dans le catalogue c'est 9.9 go dans sccm car ces boulets y ont intégré les features on demand (env 5.7+2.5go) dans tous les kb cumul intégrés dans sccm
extract de sccm sur le KB5040442
| fichier | taille |
|http://../.../public/featureondemand_3294af9937b733783476da837b21943dc160faaa.wim | 5747,73 |
| http://../.../public/edition_b7d4cae381a5971e5bf48a1246488c4e7861a0b0.wim | 2506,84 |
#2.3
#2.4
#3
#3.1
Historique des modifications :
Posté le 17/07/2024 à 18h39
C'est déjà mieux que sur Android où le système des Pixels fait qu'il faut parfois 1H pour une mise à jour mensuelle de 20 Mo.
#4
#4.1
#4.2
le problème c'est que Windows, c'est plusieurs centaines de millions d'utilisateurs voire milliards. donc les problèmes ont plus de visibilité que Linux ou Mac qui sont loin derrière en terme de part de marché.
#4.3
Ça dépend comment tu comptes. Les estimations du nombre de machines Windows tournent autour de 1.4 milliard. Rien que chez Docker, on estime à 700 millions le nombre de déploiements, et Datadog estime le nombre de containers à 2.4 milliards dans le monde. Si on ajoute tous les serveurs hors containers, les OS embarqués de la plupart des box et routeurs (il y a aussi du *BSD dedans, certes), et les 3 milliards d'android qui, après tout, sont des Linux, la conclusion n'est pas si évidente que Windows est devant.
#4.4
- Un docker, tu n'utilises pas le gestionnaire de paquets pour le mettre à jour, tu mets à jour le conteneur via docker (autrement dit, tu télécharges une nouvelle image au lieu de mettre à jour celle déjà existante).
- l'embarqué a des spécificités propres. Idem, on ne fait pas de "apt update" (ou équivalent), mais en mettant à jour le firmware
- Android a un processus de mise à jour particulier qui n'a rien à voir avec ce que font les distributions linux classiques via leur gestionnaire de paquets.
Ensuite, les usages desktop / serveur sont très différents également, et n'ont pas les mêmes contraintes. Quand j'avais du Linux en desktop, les problèmes de mise à jour que je rencontrais était à 80% liés au système graphique (serveur graphique qui ne se lance pas, ouverture de session impossible ou qui plante, etc.), le reste du temps à du matériel qui se mettait à ne plus fonctionner correctement (souvent imprimante et/ou scanner). Problème qui ne se pose généralement pas pour le serveur ^^
Sur un serveur, tu as rarement une couche graphique (c'est possible, mais peu fréquent au final) et rarement des problèmes de compatibilités matériels (déjà, parce que le matériel connecté y est rare, et ensuite, les contrôleurs de disques durs, cartes réseaux, etc. sont choisis avec plus ou moins de soin par les hébergeurs pour fonctionner correctement sous du Linux).
#4.5
#4.6
Et même si les deux peuvent être fait par la même personne, cela n'empêche pas d'être deux processus complètement distincts avec des workflows normalement distincts. Un utilisateur (j'insiste bien sur le terme utilisateur) ne doit pas (ou en tout cas, ne devrait pas) mettre à jour son image docker en se connectant à celle-ci et en effectuant un apt-get update ou assimilé. C'est une très mauvaise utilisation qui va à l'encontre même de ce qu'est docker.
#4.8
#4.9
Avec Docker, on ne met pas à jour une image, on télécharge/crée une nouvelle image de la version à jour.
#4.7
Et si on compare, des windows server qui tombent c'est très très rare (et encore plus rare sur du windows server core).