Dit klinkt niet echt als een goed idee. Dat scheelt wellicht tijd bij installeren, maar zo neem je wel het risico dat gebruikers online gaan zonder de juiste updates te hebben. Ook te lang uitstellen van updates brengt veel risico's met zich mee. Ik dacht dat Microsoft juist sinds een aantal jaren de veiliger richting op ging ...?

Misschien moet Microsoft (eindelijk) eens kijken naar waarom dat installeren van updates zoiets zwaars is. Ik heb ooit gekeken naar het stroomschema dat ze ergens online hadden staan met wat er allemaal bij kwam kijken en ik was aardig verbijsterd. Maar dat is misschien wel (deels) vervolgschade van het volgende.

Een reden (niet per se de enige) waarom updates op Windows zo omslachtig zijn is dat een lopend proces de bestanden (exe, dll's) van dat proces blokkeren in NTFS, die kunnen pas gewijzigd worden als die processen niet meer draaien en dan heb je al snel dat het proces pas bij een reboot afgerond kan worden. Zo heb ik dat althans ooit begrepen toen ik me er een keer een beetje in verdiepte.

Op Unix/Linux zit er een stapje tussen: de inode, een datastructuur per bestand op schijf. De directory-entry voor het exe- of dll-bestand (of welk bestand dan ook) verwijst naar een inode, en die inode is weliswaar geblokkeerd als het bestand in gebruik is bij een proces, maar de directory-entry niet, die kan omgehangen worden naar een nieuwe versie van het bestand. Daardoor blokkeren de lopende processen updates niet. De directory-entries gaan verwijzen naar de bijgewerkte bestanden, terwijl de lopende processen nog naar de inodes verwijzen van de oude versies die zij gebruiken. En een inode blijft bestaan zolang er een directory-entry óf een proces naar verwijst. Sluit het programma af en de schijfruimte die de oude inode in beslag neemt wordt automatisch vrijgegeven, dat is simpelweg de logica waarop POSIX-compliant filesystemen zijn gebouwd, een gegeven dus op Unix/Linux.

Alleen dat verschil al maakt dat updates op Linux een veel lichter proces zijn dan op Windows, er blokkeert van alles niet. Een update (of upgrade zoals het op Debian en afgeleiden heet) is simpelweg een kwestie van de bestanden uitpakken en op hun plaats zetten en eventuele scripts die als onderdeel van de upgrade zijn geleverd uitvoeren. In veruit de meeste gevallen stelt het qua doorlooptijd geen donder voor, en je kan configureren dat van lopende processen gecontroleerd wordt of ze een herstart nodig hebben.

En nou komt het gekke: op Linux werkt NTFS wat dit betreft net zo als andere filesystemen op Linux. Het is niet zo dat dat met NTFS een inherente onmogelijkheid is, de ntfs-3g-driver doet het gewoon, dus NTFS zelf zit dit qua datastructuren op schijf niet in de weg. Als ik het goed heb begrepen heeft NTFS qua schijforganisatie zelfs voor elk bestand een datastructuur die min of meer vergelijkbaar is met een inode.

Maar ik overzie niet wat voor consequenties het zou hebben om dit in Windows op een meer Unix-achtige manier te gaan doen. Wie weet zijn er wel allerlei dingen in Windows die uitgaan van de aanname dat die locks op het niveau van de bestandsnaam/directory-entry gebeuren, en zou het veel ingrijpender zijn om dit te veranderen dan je vanuit je leunstoel kan bedenken. Maar dat het in Linux kan met NTFS laat wel zien dat het geen fundamentele onmogelijkheid hoeft te zijn.

Als updates zo problematisch zijn voor gebruikers dat opties worden bedacht om eromheen te werken, dan zou in mijn ogen Microsoft zich eens ernstig moeten gaan afvragen wat die updates zo omslachtig maakt en of dat niet veel simpeler kan. In plaats van complexiteit toe te voegen, wat ze nu doen, zouden ze moeten kijken of er niet beter ergens complexiteit geëlimineerd kan worden. In dat update-proces in dit geval, en mogelijk in de manier waarop locks op bestanden werken.

Mooi dan kun je sneller starten met een nog grotere achterstand, en een grotere collectie zero days.

twee keer groter en een keer sneller in een zin dan moet het wel goed zijn.....

Windows heeft ook inodes alleen een andere naam. Dat is niet relevant.

linux locked niet en cached ALLE writes in memory. Dat levert andere issues op dat is het belangrijkste verschil.

Het is zegt maar nooit goed.
De klachten zijn namelijk dat tijdens installatie dit update proces te lang duurt... (ondanks dus "veiliger").
Maar door die klachten gaan ze het dus mogelijk maken dit over te slaan...
En ja dan zijn er weer andere mensen die klachten hebben dat het minder "veilig" is...

Oh, nou ik ga er altijd even voor zitten hoor. Maak er tijd voor. De hele bups in ene installeren op patchdinsdag. Ik vind het prima.