Microsoft wil cumulatieve Windows 11-updates opdelen in kleinere 'checkpoints'

Microsoft gaat experimenteren met het uitbrengen van checkpoint cumulative updates in de 24H2-versie van Windows 11 en Windows Server 2025. Hierbij worden de updates opgedeeld in checkpoints en alleen de veranderingen ten opzichte van het vorige checkpoint geïnstalleerd.

Microsoft wil cumulatieve updates in het vervolg mogelijk in 'checkpoints' uitbrengen. Elk checkpoint bevat enkel de veranderingen die sinds het vorige checkpoint aan het besturingssysteem zijn aangebracht. Hierdoor moeten feature- en beveiligingsupdates kleiner zijn, wat tijd, bandbreedte en opslagruimte bespaart.

De maandelijkse updates bestaan hierdoor uit meerdere updatepakketten, namelijk één per checkpoint. Volgens het techbedrijf worden al deze checkpoints tijdens het installatieproces samengevoegd, waarbij alleen de content wordt geïnstalleerd die nog niet op het systeem aanwezig is.

Vanaf Windows 11-versie 21H2 installeert Microsoft bij iedere update alle wijzigingen die zijn aangebracht sinds de release van de initiële release-to-manufacturingversie. Door in plaats daarvan alleen naar het vorige checkpoint te kijken, zijn deze verschillen volgens Microsoft veel kleiner en sneller te installeren op pc's die al eerdere updates hebben ontvangen. De nieuwe Windows 11-previewversie voor het Dev Channel, 26120.1252, is de eerste update die op deze manier beschikbaar wordt gemaakt.

Reacties (47)

[IrBaboon79]

Hopelijk gaan we niet weer terug naar die grote aantallen kleine k*t-updates uit de win9x-server 2008 tijd...
of van die enkele kleintjes die dan er niet op willen omdat er iets anders mist...

Die cumulatieve pakketten zijn juist enorm praktisch als je een systeem hebt dat in vervelende 'IT managed' (niet dus) omgevingen zit en daardoor met moeite aan windows update te krijgen is: 1x zo'n dikke KB en dan misschien een paar kleine KBs uit de catalog trekken, erop kopieren en je bent redelijk bij...

[CAPSLOCK2000]

Voor en nadelen, als zo'n cummulatieve update mislukt zit je een soort limbo. Met kleine losse updates is makkelijker te pinpointen waar het fout gaat en is de kans groter dat andere, onafhankelijke, updates wel lukken.

[sfranken]

Maakt Windows geen automatisch herstelpunt meer vóór het installeren van (grote) updates? Dat was rond ~2008 (Vista) een van de punten die werd aangehaald bij de "Windows vs Linux" discussies op verschillende fora, dat was iets wat Windows wel had en de rest niet en werd beschouwd als een erg groot voordeel...

[IrBaboon79]

voor zover ik weet kan windows die dingen iig altijd terugrollen als ze falen; kost wel weer een reboot en duurt lang...

[sfranken]

Ja ik zou het al vreemd gevonden hebben als dat ineens niet meer kon. Vervelend dat het lang duurt, maar beter dan een complete herinstallatie moeten doen, toch?

[IrBaboon79]

Ach, een Re-install gaat bijna net zo snel tegenwoordig - 15min heb je een windows draaiend van scratch; zit je in het MS account eco systeem komen de applicaties al bijna weer vanzelf binnen inclusief de meeste settings, passwords,etc... 2-3 uur zit je toch al weer heel dicht in de buurt van hoe het was...

Alles wil tegenwoordig immers aan een cloud verbinden of een account opdringen...

[emansom]

Je bent blijven hangen in '96 systeembeheer. Appliances draai je in micro VMs en applicaties draai je in containers, waarvan de ISO (en OCI voor de container) al gebakken zijn door Packer en geconfigureerd middels SaltStack/Ansible.

Het duurt dan geen vijftien minuten. Slechts een paar seconden "van scratch".

[IrBaboon79]

Ik doelde op een thuis herinstallatie - ga ik al die moeite niet voor doen (laatste keer is pakweg 3 jaar geleden toen ik een nieuwe pc heb gebouwd…) en eerlijk gezegd is een schone install ook wel prettig

Op werk: cliënt images uitrollen doet de afdeling IT maar via hun procedures. Niet mijn werk.

[Reactie gewijzigd door IrBaboon79 op 22 juli 2024 13:24]

[Venator]

Goed punt, m.i. een golfbeweging door de jaren heen:

• Kleine updates --> oh wel grote aantallen, veel overhead met installeren etc. -->
• Grote updates --> oh we hebben niet overal genoeg bandbreedte om snel te patchen -->
• Insert technology xyz voor bandwidth harvesting, differential updating, streaming updates etc. -->
• Misschien toch maar weer kleinere pakketten -->
• Fastforward 5 jaar als de gemiddelde internet snelheid 20% hoger ligt -->
• Grotere updatepaketten

Ik denk dat het pas weer veranderd als de daadwerkelijke core van het OS aangepakt wordt, qua opbouw en aanbrengen van lagen van security in het OS, zodat je soortement van microcode updates kan toepassen/streamen voor de meeste zaken.

[the_stickie]

Dat golfgevoel klopt wel, maar er zijn gedurende de jaren ook heel wat belangrijke wijzigingen geweest in Windows en de update-infrastructuur. Wat er werkelijk gebeurt bij een update is enorm veranderd.

[tvtech]

Hoewel het nog steeds regelmatig problemen geeft en retetraag is. Sommige dingen veranderen niet

[emansom]

Ah, atomische updates en software in pakketbronnen met delta diffs?

Wat een innovatief concept! Als er enkel een besturingssysteem was wat dit al dertig jaar geleden had geimplementeerd, dan was de wereld een stuk verder.

[Yde]

Ik moet toch even denken aan VAX/VMS van Digital Equipment Corporation uit de jaren 80/90

[pepsiblik]

Zoals @Loller1 al stelt deed Microsoft dit al eerder. Ze hadden dus een reden om er vanaf te stappen. Dus atomische updates etc, is misschien ook niet altijd het beste.

[andru123]

De reden was waarschijnlijk een nieuwe ontwikkelaar/architect met 1 jaar ervaring, ter vervanging van de ontslagen 30-jarige veteranen. Nu moet het wiel opnieuw worden uitgevonden.
Dit gebeurt bij elke groot bedrijf trouwens.

[Loller1]

Nee, de reden was dat het oude systeem toeliet dat gebruikers beveiligingsupdates konden cherry-picken met als gevolg dat iedere Windows installatie steeds verder en verder afdreef van de standaard (aka "volledig gepatched"). Door over te stappen op cumulative updates had iedereen altijd dezelfde versie (vandaar ook dat vanaf Windows 10 de delta van de OS versie omhoog gaat naarmate dat je updates installeerde, terwijl die in Windows 7 en lager altijd hetzelfde bleef tot je een SP installeerde omdat het daar een onzinnig gegeven was) en was er altijd maar 1 configuratie van Windows die getest moest worden: de laatste. Niet alleen dat, maar alle updates combineren maakt ook dat - zeker na enkele jaren - het instellen van een nieuw systeem nog altijd vlot verloopt want je hebt maar 1 update om te installeren in plaats van 250+, maar ook het maandelijkse update proces gaat gewoon veel sneller op die manier.

[FBI1988]

Ik hoor enig sarcasme..

[[Bc]-=VorteX=-]

Ik ben heel benieuwd of dit goed gaat werken in de praktijk, want de aangedragen punten van minder bandbreedte en storage zijn prima, maar Microsoft heeft niet per se de beste trackrecord als het gaat om incrementele updates en alles dan goed stabiel houden. Bij elke update moet alles kloppen, ongeacht of het de voorlaatste of twintig versies geleden was die je update, dat brengt wel heel wat complexiteit met zich mee qua updateproces en -logica aan de developer's kant, volgens mij.

[sfranken]

Microsoft kan bij de concullega's van Red Hat / Fedora gaan kijken, die doen dit al ~30 jaar zo..

[Loller1]

...of ze kijken gewoon naar hoe ze het deden in Windows 8.1 en eerder. Dit is ook voor Microsoft totaal geen nieuw concept hoor...

[Splorky]

Als ik zie hoe moelijk het was om een dark mode in te bouwen denk ik dat oude kennis niet op de juiste plek zit, in XP kon je naar halterlust de hele UI stylen in de meest walgelijke kleur combinaties. Nu wordt er bijna gejuicht als het eindelijk mogelijk is om één extra thema te hebben die darkmode genoemd wordt, waarbij alle contact menus consistent mee kleuren.

[Prince]

Ik ben meer een Debian/Ubuntu/Alpine man, maar was oprecht niet op de hoogte dat YUM of DNF met delta's werkte. Hoog tijd om nog eens naar de alternatieve distro's te kijken.
YUM deed dit sowieso niet dacht ik; dat was het volledige package per versie die binnengehaald werd. van DNF heb ik geen flauw idee.

[sfranken]

yum en dnf beheren hetzelfde. De overgang naar delta-rpm's word vanuit de repo gedaan, dus is onafhankelijk van yum of dnf (nu is yum een symlink naar dnf, dus meh). Deze verandering is gedaan toen dit nog logisch was, maar er zijn plannen om dit stop te zetten in Fedora 41+

[houthakker]

2 Vragen die bij me opkomen:
- heeft dit effect op rollbacks ?
- aantal keer rebooten blijft gelijk ?

[Snotvis]

Even uit de losse pols, dus neem het met een korreltje zout:

In principe zou je een diff-check kunnen uitvoeren tussen de nieuwe versie en de oude(re) versie waar je naar terug wil. Dan zou je alleen wijzigingen terug hoeven te zetten en klaar zijn. De vraag is alleen in hoeverre nieuwe/andere variabelen roet in het eten kunnen gooien (bijv. 2 variabelen worden gecombineerd in nieuwe versie, wat gebeurt er dan met terugzetten/ als je 'null' invoert).

Van uitgaand dat de policies etc. applied moeten worden, zou je nog steeds moeten rebooten. Mogelijk kan alles in één keer, waardoor je met een enkele reboot klaar bent. Worst case moet je elke versie toepassen, wat betekent dat 3 updates ook 3 reboots worden (al lijkt me dat sterk).

[Prince]

Rollback werkt op basis van snapshots van de systeembestanden.
Dit heeft enkel invloed op de informatie die doorgestuurd wordt.

Simpel gezegd; stel dat je een executable hebt van 100MB en er komt met spoed een nieuwe versie uit omdat er ergens staat "laat me je tets zien" ipv "laat je me test zien". Vroeger werd er 100MB doorgestuurd; nu enkel een filenaam, offset en string 'st'; een paar bytes dus.

Al de rest blijft hetzelfde.

Ook is het eenvoudiger voor hen om een bepaald onderdeel op bepaalde systemen terug te rollen. Dit is goed voor die situaties waarin bepaalde configs problemen gaven. zo kunnen ze enkel de foute code terugrollen, maar de meeste security fixes wel behouden.

[Centauriprime]

Ook handig voor de LTSC versies. Misschien met terugwerkende kracht ook daar inbouwen. Juist die LTSC versies staan op plekken met kleine update windows en beperkte bandbreedte.

[CAPSLOCK2000]

Het komt allemaal maar complex over. Is het niet handiger om over te gaan op een "echte" package manager zoals bekend uit de LInux wereld? Dan verdwijnen alle problemen die hier opgelost worden vanzelf. Je systeem rekent zelf uit welke updates er nodig zijn en download precies paketten en zorgt dat dingen in de juiste volgorde geinstalleerd worden en waar nodig herstart of herladen. Er is wel wat overhead per pakket, in bytes en installatietijd, maar ik krijg de indruk dat het netto nog steeds efficienter werkt.

Een leuk bijkomend voordeel is dat moderne Linux-installaties niet beginnen met een basis-versie te installeren en die dan te updaten. Omdat er met losse pakketten wordt gewerkt zal het systeem gewoon direct de nieuwste versie van internet downloaden en installeren. Dat scheelt tijd, bandbreedte en vervuiling van je systeem.

[ShadLink]

Dus kan je dan na een clean install eerst 2 uur iets anders gaan doen omdat Windows alle checkpoints binnen gaat zitten halen. Lekker handig.

Waarom maakt MS het niet super makkelijk om gewoon een ISO te dowmloaden van de laatste RTM + alle updates sinds. Dan ben je gewoon in 1x klaar.

[Reactie gewijzigd door ShadLink op 22 juli 2024 13:24]

[Visgek82]

Dat doen ze al? Je krijgt met de media creation tool de nieuwste versie binnen voor zover MIcrosoft die uitgestuurd heeft.

[ShadLink]

Nu krijg je de laatste RTM versie, die wordt jaarlijks bijgewerkt. Maar ik bedoel dat als je de ISO download ook de maandelijkse updates automatisch gedownload worden. Die zitten er nu niet in.

[Z80]

En wat is dat anders dan nu?
Nu wordt er 1 groot pakket in 1 keer binnen gehaald. Straks het zelfde pakket in stukjes.
De eerste update zal net zo lang duren. Daarna, als alles goed gaat, een stuk sneller.

[ShadLink]

Het zou idd niet uit moeten maken, maar MS kennende... zit je straks 10x te herstarten omdat na elke deelupdate Windows opnieuw gestart moet worden.

[Hell-Slave]

Wat ik altijd grappig vindt is dat Windows updaten altijd zo Godsgruwelijk lang moet duren, m'n hardware wordt steeds sneller maar Windows updaten duurt nog altijd 30-60 minuten.
Terwijl in Linux updaten een kwestie van minuten is.
Kan iemand het uitleggen waarom Windows zo langzaam is met updaten? (serieuze vraag)

[Cees7964]

Bij mij duren ze niet meer dan 10 minuten tot hooguit een kwartier, vaak zelfs nog korter

[CivLord]

Bij Windows gebeurt het meeste, zoals downloaden en installeren op de achtergrond. Het enige dat je er van merkt is dat je op het Windows Update scherm de voortgang in procenten ziet. Misschien dat dat bij Linux ook op de achtergrond gebeurt, maar dat je er daar pas iets van ziet/ merkt wanneer dat alles al gebeurt is.

[Hell-Slave]

Heeft u weleens met Linux gewerkt?
Linux doet bij mij niks op de achtergrond en updaten gaat snel kwestie van minuten.
In tegenstelling tot Windows waar een geforceerde update veel langer duurt.
Er is duidelijk een verschil in update snelheid, misschien dat de Windows code complex is of vervuilt is met legacy rommel.

[grimlock]

Wow, en dan kijk ik even naar de "scene" van de tachtiger jaren die illegale releases uitbracht. Komt dit niet heel erg bekend voor? Echt revolutionair Microsoft!

[anzaya]

Ik kan het verband niet echt leggen..

[Invoke]

Hoe gaat dit werken als je losse updates wil aanvinken en anderen achter wil houden dan? Of blijft dat voor de 'optional' updates. En wordt het steeds opnieuw opstarten?

Overigens op een van mijn machines het probleem dat als windows update zich ongewenst gerepareerd heeft het vervolgens updates binnenhaalt waarbij na uitpakken amper/geen vrije schijfruimte over is zodat er weer een rollback is of erger, ook zo geniaal.