Door Neb Poorten: En dan al die reboots die Windows nodig heeft omdat het besturingssysteem een grote spaghetti van niet voldoende ontkoppelde onderdelen is.
Alleen al uit de verschillende manieren waarop Windows en *nix file locking regelen kan dit voor een belangrijk deel verklaard worden.
In Windows gebeurt dat op het niveau van het directory-pad/filenaam en in *nix op het niveau van een inode, de datastructuur die de file op schijf beschrijf waar in Posix-filesystemen een directory-entry naar verwijst. Daardoor is het in *nix mogelijk een bestand te hernoemen, te verplaatsen of te verwijderen zonder dat een proces dat het in gebruik heeft daar last van heeft, dat blijft gewoon het bestand zien tot het ermee klaar is. Het is alleen maar een verwijzing naar het eigenlijke bestand (de inode) die vervalt of verandeer, de inode zelf vervalt pas als er geen verwijzingen naar zijn én het bestand niet meer in gebruik is.
In beide werelden is een executable/shared library/dll gelockt zolang het in gebruik is bij een proces, maar door de verschillende niveaus waarop de lock is geregeld is het in Windows niet en in *nix wel mogelijk om de directory-entry naar een nieuwe versie van het bestand te laten verwijzen. Het effect is dat *nix upgrades mogelijk maakt terwijl executables en libraries in gebruik zijn, terwijl Windows dat blokkeert. En dan heb je in veel gevallen een reboot nodig.
Dat betekent wel dat op *nix een proces op basis van verouderde software na een upgrade kan bljven doorlopen, nog steeds op basis van de vervallen versie. Dat wordt in Linux deels afgevangen door de upgrade-scripts die onderdeel van pakketten zijn een herstart te laten forceren (apache2 bijvoorbeeld zal herstart worden bij een upgrade). Maar een nieuwe versie van bijvoorbeeld de standaard C-library zal apache2 niet doen herstarten, en desktop-applicaties worden ook niet automatisch herstart (wat je ook niet zou willen). De programma's checkrestart (Debian, onderdeel van pakket debian-goodies) en needrestart (ook andere Linux-smaken, apart pakket) ondervangen dat, die laten na een upgrade zien welke processen herstart moeten worden.
De *nix-benadering is flexibeler en minder tijdrovend maar je moet als gebruiker/beheerder wel beter snappen hoe het in elkaar steekt om te kunnen garanderen dat je lopende systeem ook echt de nieuwe software gebruikt; de Windows-benadering is daardoor vermoedelijk meer foolproof. Mijn voorkeur? Duidelijk de *nix-benadering. Het is namelijk in prinicipe mogelijk om op basis daarvan een systeem te bouwen dat net als bij Windows afdwingt dat alle software die herstart moet worden ook herstart wordt, maar omgekeerd is het op basis van de Windows-benadering principieel onmogelijk om een systeem te bouwen dat dat niet afdwingt. De benadering waarmee je meer kanten op kan is in mijn ogen superieur.
Een aardig detail is dat op Linux de drivers voor NTFS en zelfs FAT prima in staat zijn om de *nix-manier van locking toe te passen. NTFS heeft nog structuren die op inodes lijken, FAT heeft die niet. Het is dus meer een kwestie van hoe het besturingssysteem met filesystemen omgaat dan van hoe de filesystemen zelf gestructureerd zijn.
Ik spreek niet tegen dat Windows (maar bijvoorbeeld ook KDE) een sterke indruk wekt dat alles aan alles hangt. Dat komt denk ik enerzijds voort uit een neiging om geïntegreerde produkten aan de gebruiker voor te willen zetten en bij commerciële partijen als Microsoft ongetwijfeld ook omdat kunstmatig gecreëerde afhankelijkheden een manier zijn om meer aan een klant te verkopen. Maar dat wil niet zeggen dat de software intern spaghetti is, want naast belangen op gebied van presentatie en verkoop heeft men dat spul ook nog te onderhouden. Ook bij Microsoft weten ze echt wel dat sterke cohesie en smalle koppelingen een voorwaarde voor een onderhoudbaar geheel zijn.