/dev/null - Overig

Microsoft: waarom rebooten Windows computers zo vaak na updates?

11-06-2020, 08:09 door The FOSS, 46 reacties
Laatst bijgewerkt: 11-06-2020, 08:10
Verdere uitwerking van mijn post in het geblokkeerde topic https://www.security.nl/posting/660428#posting660510, naar aanleiding van kritiek hierop. Microsoft zelf stelt hierover het volgende:

Why you may be prompted to restart your computer after you install a security update on a Windows-based computer

After you install a security update, you may be prompted to restart your computer if one of the following conditions is true:

- The security update updates a DLL that is loaded in one or more processes that are required by Windows. The security update cannot be completed while the DLL is loaded. Therefore, the security update must stop the process that causes the DLL to be loaded. Stopping the process will unload the DLL that is required to complete the update. However, the process in which the DLL is loaded cannot be stopped while Windows is running. For example, the security update that is described in security bulletin MS04-011 updates many DLLs that are loaded in core operating system processes that cannot be stopped without shutting down Windows.
- The security update updates an .exe file that is currently running as a process that is required by Windows. The update cannot be completed while this process is running. However, you cannot force this process to stop unless you shut down Windows. For example, Csrss.exe is a required process in Windows.
-The security update updates a device driver that is currently being used and that is required by Windows. The update cannot be completed while this device driver is being used. However, you cannot unload this device driver unless you shut down Windows. For example, Disk.sys is a device driver that is required by Windows.
-The security update makes changes to the registry. These changes require that you restart your computer.
- The security update makes changes to registry entries that are read only when you start your computer.

https://support.microsoft.com/en-ca/help/887012/why-you-may-be-prompted-to-restart-your-computer-after-you-install-a-s

Kortom, het is dus inderdaad zoals ik al schreef: t.g.v. de brakke architectuur van Windows moet er steeds gereboot worden na updates.
Reacties (46)
11-06-2020, 08:42 door karma4
Door The FOSS: ….Kortom, het is dus inderdaad zoals ik al schreef: t.g.v. de brakke architectuur van Windows moet er steeds gereboot worden na updates.[/u]
Het zelfde verhaal kunnen aanhouden voor het FOSS gebeuren. Je ziet constant open source database open en bloot op het internet. Dat moet wel aan de brakke mentaliteit van FOSS liggen. Heelmaal gek op code niet op informatieveiligheid.
Geblokkeerd in een jaren 90 OS flaming komen ze geen steek verder maar veroorzaken wel steeds meer schade.
11-06-2020, 08:44 door linux4
Updaten van een Linux desktop distro gaat, net als bij Windows, tijdens je normale werkzaamheden door in de achtergrond. Maar als je Linux dan toch moet herstarten, wat enkel het geval is bij een kernel update of bij proprietary drivers updates, dan is die herstart net zo snel als een gewone herstart en hoef je niet te wachten op "Windows is working on updates... van 0 tot 100%...

Sinds ik deels thuis moet werken heb ik een W10 machine van de baas naast m'n privé Linux pc en ik moet zeggen dat W10 heel aardig draait tegenwoordig. Maar op het gebied van updaten zit het nog echt knullig in elkaar. Ook moet je updates van al je losse software pakketten in de gaten houden, bij Linux heb je één centraal systeem. Dit alles geldt ook voor Macs uiteraard.
11-06-2020, 08:47 door The FOSS - Bijgewerkt: 11-06-2020, 09:15
Door karma4:
Door The FOSS: ….Kortom, het is dus inderdaad zoals ik al schreef: t.g.v. de brakke architectuur van Windows moet er steeds gereboot worden na updates.[/u]
Het zelfde verhaal kunnen aanhouden voor het FOSS gebeuren. Je ziet constant open source database open en bloot op het internet. Dat moet wel aan de brakke mentaliteit van FOSS liggen. Heelmaal gek op code niet op informatieveiligheid.
Geblokkeerd in een jaren 90 OS flaming komen ze geen steek verder maar veroorzaken wel steeds meer schade.

Waar heb je het over? Ik geef je hierboven informatie die door Microsoft is gepubliceerd en jij komt met jouw oss-complottheorieën die nergens op gebaseerd zijn en waarover je niemand anders dan jou hoort. De conclusie moge duidelijk zijn. #nofurthercomment

De essentie van het probleem, die ook duidelijk de brakke architektuur van Windows demostreert is het volgende uit het Microsoft artikel:

Therefore, the security update must stop the process that causes the DLL to be loaded. Stopping the process will unload the DLL that is required to complete the update. However, the process in which the DLL is loaded cannot be stopped while Windows is running.

In tegenstelling tot de meer professionele besturingssystemen (zoals Linux, macOS) kan blijkbaar een proces dat updated DLL's gebruikt niet gestopt en opnieuw worden gestart als Windows draait. Met als gevolg dat hiervoor een reboot nodig is. Dat is een schrijnend probleem en dit zal Windows altijd in de weg staan bij gebruik als server OS. Maar ook op desktops is het erg vervelend. Met name als je voor de zoveelste keer je werk moet onderbreken door een reboot.
11-06-2020, 10:06 door [Account Verwijderd]
Ik ben een open source evangelist zoals Karma4 dat zo mooi weet te benoemen, maar ik vind dit een beetje zoeken.

Het update proces van Windows verdient niet de schoonheidsprijs en voor mij een van de redenen om destijds over te stappen naar Linux, maar om Windows hierom te diskwalificeren vind ik een brug te ver.

Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.

Belangrijkste is dat een OS na de updates verbetert, is (veiliger, gebruiksvriendelijker, stabieler, etc), dat rebooten is voor mij hinderlijk, maar ook niet meer dan dat.
11-06-2020, 10:10 door The FOSS - Bijgewerkt: 11-06-2020, 10:13
Door EnGeeX: Ik ben een open source evangelist zoals Karma4 dat zo mooi weet te benoemen, maar ik vind dit een beetje zoeken.

Het update proces van Windows verdient niet de schoonheidsprijs en voor mij een van de redenen om destijds over te stappen naar Linux, maar om Windows hierom te diskwalificeren vind ik een brug te ver.

Een server die moet rebooten bij elke update is niet werkbaar dus diskwalificatie van Windows voor toepassingen op servers ligt voor de hand. De Microsoft Windows adepten gaan nu iets roepen van patchdinsdag en inplannen van updates. Dat zijn allemaal workarounds om maar niet te willen inzien dat server reboots t.g.v. updates een Windows probleem zijn. En dat zoiets bij echte, meer professionele besturingssystemen helemaal niet aan de orde is.

Door EnGeeX: Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.

Voor een desktop is het irritant als je serieus, complex werk doet - waarvoor je een complexe omgeving op moet starten - dat het steeds onderbroken wordt door reboots. Maar voor lichte consumententoepassingen is het inderdaad geen probleem.
11-06-2020, 10:11 door Anoniem
Door linux4: Updaten van een Linux desktop distro gaat, net als bij Windows, tijdens je normale werkzaamheden door in de achtergrond. Maar als je Linux dan toch moet herstarten, wat enkel het geval is bij een kernel update of bij proprietary drivers updates, dan is die herstart net zo snel als een gewone herstart en hoef je niet te wachten op "Windows is working on updates... van 0 tot 100%...

Sinds ik deels thuis moet werken heb ik een W10 machine van de baas naast m'n privé Linux pc en ik moet zeggen dat W10 heel aardig draait tegenwoordig. Maar op het gebied van updaten zit het nog echt knullig in elkaar. Ook moet je updates van al je losse software pakketten in de gaten houden, bij Linux heb je één centraal systeem. Dit alles geldt ook voor Macs uiteraard.
Tijd om Fedora een te proberen dan.
11-06-2020, 10:25 door Ron625
Door karma4:
Het zelfde verhaal kunnen aanhouden voor het FOSS gebeuren. Je ziet constant open source database open en bloot op het internet. Dat moet wel aan de brakke mentaliteit van FOSS liggen.
Software heeft geen mentaliteit, dat is iets dat bij mensen thuis hoort.
Mogelijk bedoel je het beheer, maar dat staat los van een besturingssysteem.........
11-06-2020, 10:29 door Anoniem
Door The FOSS:
Door EnGeeX: Ik ben een open source evangelist zoals Karma4 dat zo mooi weet te benoemen, maar ik vind dit een beetje zoeken.

Het update proces van Windows verdient niet de schoonheidsprijs en voor mij een van de redenen om destijds over te stappen naar Linux, maar om Windows hierom te diskwalificeren vind ik een brug te ver.

Een server die moet rebooten bij elke update is niet werkbaar dus diskwalificatie van Windows voor toepassingen op servers ligt voor de hand. De Microsoft Windows adepten gaan nu iets roepen van patchdinsdag en inplannen van updates. Dat zijn allemaal workarounds om maar niet te willen inzien dat server reboots t.g.v. updates een Windows probleem zijn. En dat zoiets bij echte, meer professionele besturingssystemen helemaal niet aan de orde is.

Door EnGeeX: Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.

Voor een desktop is het irritant als je serieus, complex werk doet - waarvoor je een complexe omgeving op moet starten - dat het steeds onderbroken wordt door reboots. Maar voor lichte consumententoepassingen is het inderdaad geen probleem.

Ik beheer redelijk wat servers, die reboots maken mij niet zoveel uit.
Wij schedulen met SCCM de updates in de nacht, automatisch reboot volgt ook in de nacht, zodat de volgende ochtend alles in orde is.
We werken via (O)TAP straat, oftewel updaten via deze automatische schedules wordt eerst uitgevoerd op Test Servers, aantal dagen later op Acceptatie, aantal dagen later Productie...
Maar het mechanisme is geheel automatisch, wij ervaren hier weinig problemen mee. (Op een enkele servers/update na...)

Werkplekken hetzelfde, updates worden geinstalleerd en herstart wordt via SCCM onderdrukt, pas wanneer de eindgebruiker het uitkomt zal deze zijn systeem herstarten. (Uiteraard W10 Enterprise, niet mogelijk via W10 Home...)
Eventueel met een deadline van x-aantal dagen dat deze herstart alsnog wordt uitgevoerd.

Wij ervaren sinds W10 build 1803 eigenlijk weinig problemen met Updates/Upgrades... Build 1709 en lager zagen we wel af en toe vreemde problemen. (Maar is alweer 2 jaar geleden)
11-06-2020, 10:30 door Anoniem
Door The FOSS:

Kortom, het is dus inderdaad zoals ik al schreef: t.g.v. de brakke architectuur van Windows moet er steeds gereboot worden na updates.
Waarom is dit een brakke architectuur ? Er zijn keuzes gemaakt in de architectuur. Dat maakt het niet direct brak.

Door The FOSS:
Een server die moet rebooten bij elke update is niet werkbaar dus diskwalificatie van Windows voor toepassingen op servers ligt voor de hand.
Complete onzin. Je hebt werkelijk weer geen idee waarover je praat.
Daarvoor heb je als eerste een change window waarin je onderhoud mag plegen.
Mocht je applicatie niet plag mag tijdens onderhoud, dan los je dat niet met een OS op, maar in je applicatie. (loadbalancing, clustering, stateless.

Dit doet mij denken aan een SLA afspraak over een domain controller en er was er 1 down wegens een hardware issue. Hele discussies gehad, want de SLA was niet gehaald, dat we 7 domain controllers hadden draaien op die site was niet van belang volgens de manager.

Komt weer op hetzelfde neer.

De Microsoft Windows adepten gaan nu iets roepen van patchdinsdag en inplannen van updates. Dat zijn allemaal workarounds om maar niet te willen inzien dat server reboots t.g.v. updates een Windows probleem zijn. En dat zoiets bij echte, meer professionele besturingssystemen helemaal niet aan de orde is.
Je bent weer aan het preken.

Je "professionele besturingssystemen" worden onderhouden in de zelfde change windows als de Windows servers en gebruiken de zelfde technieken om hoog beschikbaar te zijn bij de grote bedrijven.

Voor een desktop is het irritant als je serieus, complex werk doet - waarvoor je een complexe omgeving op moet starten - dat het steeds onderbroken wordt door reboots. Maar voor lichte consumententoepassingen is het inderdaad geen probleem.
Daar zijn allemaal gewoon afspraken voor gemaakt met de afdelingen.
Gewoon de juiste techniek en afspraken implementeren. Ik hoor maar heel weinig klachten hierover bij onze gebruikers. Communicatie is hierin gewoon belangrijk.

Je gebruikelijke onzin commentaar over lichte consumententoepassingen, laat al weer zien, dat jij gewoon geen enkel idee hebt, wat gebruikers nodig hebben om hun werkzaamheden te doen.

Voor de rest gewoon de gebruikelijke preken van onze predikant. Niets meer of minder.
11-06-2020, 10:31 door Anoniem
Door The FOSS:

Voor een desktop is het irritant als je serieus, complex werk doet - waarvoor je een complexe omgeving op moet starten - dat het steeds onderbroken wordt door reboots. Maar voor lichte consumententoepassingen is het inderdaad geen probleem.
Je geeft zelf aan een hekel te hebben aan de maandelijkse update. Hoe kom je dan op die stomme opmerking van steeds onderbroken te worden door gehoord. Werk jij dan alleen op patchday?
11-06-2020, 10:43 door Anoniem
Een eigenschap van POSIX-filesystemen is dat ze met inodes werken, datastructuren in het filesysteem die het bestand beschrijven en los staan van directory's. Via het directory-pad van een bestand wordt een inode geïdentificeerd, en het bestand dat wordt geopend is aan de inode gekoppeld, niet aan het directory-pad.

Het effect daarvan kan je zien als je bijvoorbeeld een grote download doet, zeg van een ISO-image. Je hebt een download-locatie gekozen en nog voor de download klaar is bedenk je dat je de download ergens anders wilt hebben. Je kan terwijl de download ongestoord doorloopt in een terminal met een mv-commando het bestand verplaatsen naar een andere directory in hetzelfde filesysteem. De download blijft ook op de nieuwe locatie toevoegen aan het bestand.

Een vergelijkbaar experiment is dit. Open drie terminalvensters. In een ervan monitor je het ruimtegebruik van je gemounte filesystemen:
watch -d df
In een tweede maak je een bestand aan dat alle beschikbare ruimte op gaat vreten in een filesysteem (tenzij je het afbreekt):
dd if=/dev/zero of=zero bs=1M
In de eerste terminal zie je dat het filesysteem waarop je dit doet geleidelijk minder ruimte heeft. In de derde terminal gooi je, terwijl het dd-commando doorloopt, het bestand weg:
rm zero
Dat lukt gewoon, terwijl het dd-commando door blijft lopen en geleidelijk aan meer schijfruimte wordt gebruikt. Maar als het dd-commando eindigt (wegens een vol filesysteem of omdat je het met CTRL+C afbreekt) komt opeens de gebruikte schijfruimte weer beschikbaar.

Wat gebeurde daar? De bestandsnaam "zero" was gekoppeld aan een inode, en dd werkte met die inode. Een inode blijft bestaan zolang die in gebruik is, hetzij via een of meer verwijzingen ernaar in de directorystructuur, hetzij vanuit processen die het bestand geopend hebben. "rm zero" gooide dus wel de directoryverwijzing weg maar niet de inode, die verdween pas toen dd hem niet meer geopend hield, toen pas werd die niet meer gebruikt. In feite gooit rm helemaal geen bestanden weg, het verwijdert alleen directory-entries, en het is aan het filesysteem om te bepalen of het bestand zelf wordt weggegooid (en dat gebeurt als er nul verwijzingen naar zijn).

Dit maakt dat op POSIX-systemen (Unix, Linux) software bijgewerkt kan worden terwijl die in gebruik is (want ook een executable of library die actief is levert een referentie naar een inode op). De naam in de directory waar die staat verwijst na de upgrade naar een nieuwe inode, maar processen die de oude in gebruik hebben lopen niet stuk op het verdwijnen van het oude bestand omdat de inode pas verdwijnt als die niet meer in gebruik is.

Linux heeft zo weinig reboots nodig omdat executables, libraries en andere bestanden die in gebruik zijn moeiteloos door nieuwe exemplaren kunnen worden vervangen. Het is na een upgrade wél nodig om processen die vervangen bestanden in gebruik hebben te herstarten, omdat die bestanden niet voor niets vervangen zijn en omdat er een (in de praktijk goed hanteerbaar) risico bestaat dat een oude versie van een executable na de upgrade een nieuwe versie van een library laadt waar die niet compatibel mee is. Bij bijvoorbeeld apache2 op Debian handelen de upgrade-scripts in het deb-pakket het af door de service voor de upgrade te stoppen en meteen erna weer te starten. Het pakket needrestart integreert een controle in het upgradeproces voor alle pakketten en biedt bij interactief gebruik een restart aan van alle services die met vervallen executables draaien, en geeft desktopgebruikers een notificatie van applicaties die een herstart nodig hebben.

Wat is er in Windows anders? Ik ben geen Windows-kenner, maar als ik het goed begrijp is in Windows een geopend bestand hard gekoppeld aan het directory-pad waarlangs het geopend is, en niet aan iets als een inode. Daardoor zijn bestanden ook op het niveau van een directory-pad gelockt, inclusief executables en libraries die aan lopende processen ten grondslag liggen, en is het vervangen van executables en libraries dus geblokkeerd. Een reboot is een botte-bijl-methode om in een klap alle bestanden die in gebruik zijn vrij te geven, en mijn indruk is dat dat is hoe in vroegere versies van Windows deze situatie werd afgehandeld. Daar is (alweer mijn indruk) verbetering in aangebracht, maar men is er niet los van gekomen op de manier waarop de semantiek van POSIX-filesystemen dat mogelijk maakt.

Waarom neemt men die semantiek dan niet over in Windows? Filesystemen zelf zijn geen belemmering, onder Linux gedragen FAT en NTFS zich net zo als POSIX-filesystemen in dit opzicht, de Linux-drivers ervoor kunnen dit duidelijk gewoon aan. Maar ik kan me voorstellen dat Windows zelf en Windows-applicaties gebaseerd zijn op de aanname dat file-locks op directorypadniveau geregeld worden en dat men dat om compatibiliteitsredenen niet zomaar kan veranderen.

Ook is het bij de POSIX-semantiek heel makkelijk om te beredeneren wat er allemaal fout kan gaan, en moet je het in de praktijk hebben meegemaakt om te beseffen hoe goed dat probleem in de praktijk ondervangen is en hoe soepel het werkt.

En dan zijn er natuurlijk configuraties waarin het verschil niet belangrijk is. Als een service geïmplementeerd is op meerdere servers die achter een load balancer zitten en je bij upgrades sowieso niet alle servers parallel bijwerkt maar ze een voor een offline haalt, bijwerkt en weer opstart, dan maakt het buiten het verschil in doorlooptijd geen donder uit of er nou wel of geen reboot bij nodig is.
11-06-2020, 10:46 door Anoniem
Net Ubunto moeten update'n. Reboot nodig...
11-06-2020, 10:47 door Anoniem
Zonder meteen weer in een FOSS discussie te schieten:
Het heeft te maken met een verschil in het ontwerp van de filesystemen in Windows en in Unix/Linux.
In Windows is een file keihard gekoppeld aan de filenaam. Als je een file wilt vervangen die open is dan moet je eerst
zorgen dat iedereen die file sluit. En als dat bijvoorbeeld een veelgebruikte DLL is dan is dat niet haalbaar zonder reboot.

In Unix (en daardoor ook in Linux) werkt dat anders. Een file is keihard gekoppeld aan iets wat men een "inode" noemt,
dat is het item waar alles in staat met betrekking tot de file, zoals de grootte, permissies, datum/tijd enzovoorts, maar NIET
de naam. Bepaalde files zijn "directories" en daarin staan filenamen, en daar staat een inode nummer bij.
Dus bijvoorbeeld in de directory /home/jijzelf staat een entry "mijnfile 1234" en dat betekent dat inode 1234 de inhoud
van mijnfile bevat.

Als een file eenmaal open is, dan houdt de kernel dit alleen bij dmv het inode nummer, dus niet met de naam.
Dit betekent een aantal dingen:

1. je kunt een open file gewoon deleten. de directory bevat de naam dan niet meer en je kunt hem niet meer via die
naam openen, maar processen die de file nog open hadden kunnen er nog gewoon mee werken (via het inode nummer).
2. je kunt een file vervangen door een andere door een nieuwe file te maken met een ander inode nummer en dan het
inode nummer in de directory te veranderen. processen die de file open hadden blijven de oude file gebruiken, en
processen die daarna die file openen krijgen de nieuwe file.

Dit mechanisme ontbreekt in Windows, daarom kan Windows nooit een file deleten die open is, en is het niet mogelijk
een file te veranderen zonder dat alle processen die die file open hebben dat "zien".
En je kunt natuurlijk niet een DLL of een .EXE die uitgevoerd wordt gaan overschrijven met een nieuwe versie waar
iets anders in staat, dan zal het programma crashen. Dus kan Windows dat alleen bij een reboot doen. De nieuwe
versie van de file wordt onder een tijdelijke naam gemaakt, en er wordt een lijst opgebouwd van "alle files die tijdens
een reboot vervangen moeten worden". Hij gaat dan bij de reboot al die oude files deleten en nieuwe renamen naar
de goede naam.

In Unix/Linux kan dat wel, maar je moet wel bedenken dat je dan die update in feite nog niet helemaal hebt doorgevoerd.
Bijvoorbeeld je update een DLL (shared library, .so file) dan krijgen nieuw gestarte programma's wel die nieuwe versie,
maar programma's die al draaiden die blijven de oude versie gebruiken. Is de update een critical security update in
een belangrijke veel gebruikte library, dan kun je beter toch maar rebooten.
(moderne Linux distributies kunnen wel een lijstje maken van processen die herstart moeten worden omdat ze de
oude versie nog open hebben, en zelfs dat herstarten automatisch doen, maar als zo'n process bijvoorbeeld je X
server is of alle shells ofzo dan komt het er op neer dat je net zo goed kunt rebooten)

Je moet wel bedenken dat dit mechanisme onderdeel is van het operating system en werkt per-file, en er dus geen
mechanisme is om te zorgen dat alles consistent is. Heb je een complex pakket wat bestaat uit allerlei subprogramma's
en shared libraries die bij sommige wel en andere niet gebruikt worden, of die zelfs dynamisch geladen worden op het
moment dat je een bepaalde functie uitvoert, dan kan het alsnog helemaal fout gaan als je een update uitvoert die
alles vervangt terwijl het programma draait waardoor een deel nog de oude versie is maar nieuw geladen zaken een
andere versie zijn. Die versies zijn wellicht onderling incompatible.

Een voorbeeld hiervan is Firefox. Als je dat update via het package management systeem van je distributie, terwijl
het programma open staat, en je gaat er dan verder mee werken dan zal het meestal even later (als je "iets nieuws"
doet) crashen. Doe je de update vanuit Firefox zelf, dan zal ie zichzelf herstarten om dit probleem te voorkomen.
11-06-2020, 10:49 door Anoniem
Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.
Hoelang duurt dan bij jou een update, bij mij toch zeker 15 minuten of meer, dit is wel de gewone versie voor huis
tuin keuken gebruik?
11-06-2020, 11:06 door Anoniem
Door EnGeeX: Ik ben een open source evangelist zoals Karma4 dat zo mooi weet te benoemen, maar ik vind dit een beetje zoeken.

Het update proces van Windows verdient niet de schoonheidsprijs en voor mij een van de redenen om destijds over te stappen naar Linux, maar om Windows hierom te diskwalificeren vind ik een brug te ver.

Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.

Belangrijkste is dat een OS na de updates verbetert, is (veiliger, gebruiksvriendelijker, stabieler, etc), dat rebooten is voor mij hinderlijk, maar ook niet meer dan dat.

ik begrijp je punt voor het huis tuin en keuken gebruik.

in een IT organisatie met servers is het echter andere koek.

we zien te veel en te vaak in de praktijk dat updates niet tijdig doorgevoerd worden en dat het gevolg een malware aanval is.

een deel van de problemen voor een IT dienst komen door de updates/patches van MS die 1) zorgvuldig getest moeten worden eerst, 2) bij uitrol een server dwingen te rebooten en tijdens de reboot soms een lange "update wordt geinstalleerd" procedure doorlopen met daarna weer een reboot en 3) patches komen maar eens in de maand als een hele grote all-or-nothing blob en dat geeft soms issues met hardware en andere software/drivers die functioneel nodig zijn op de servers.

dat heeft verder NIETS met oss / foss iod te maken en kan wel degelijk verbeterd worden vwb punten 1 en 3.
11-06-2020, 11:10 door Anoniem
Door The FOSS:
Een server die moet rebooten bij elke update is niet werkbaar dus diskwalificatie van Windows voor toepassingen op servers ligt voor de hand. De Microsoft Windows adepten gaan nu iets roepen van patchdinsdag en inplannen van updates. Dat zijn allemaal workarounds om maar niet te willen inzien dat server reboots t.g.v. updates een Windows probleem zijn. En dat zoiets bij echte, meer professionele besturingssystemen helemaal niet aan de orde is.

Jij noemt de andere OSsen professioneel, maar gebruikt daarvoor je persoonlijke waardes. Mag van mij, maar er zijn genoeg Windows servers in omloop.Hier geldt dat de wensen en behoeften je keuze bepalen. Bij die keuze moet je ook de specifieke eigenschappen bekijken (zoals het updaten) en daarnaar ontwerpen. Doe je dat en stem je alles daar op af, dan maakt het niet uit wat je kiest.

Door The FOSS:
Voor een desktop is het irritant als je serieus, complex werk doet - waarvoor je een complexe omgeving op moet starten - dat het steeds onderbroken wordt door reboots. Maar voor lichte consumententoepassingen is het inderdaad geen probleem.

Ook hier geldt dat je moet kijken naar de wensen en behoeften. Je kunt Windows zo instellen dat er pas wordt geüpdate als je er zelf voor kiest. Stel alles goed in, kies het juiste moment en dan is de onderbreking niet hinderlijk. Maar let wel, doe de update, anders haal je zelf de problemen op je dak. Het systeem van Microsoft is wat je krijgt en mits bewust gekozen, geen punt.
11-06-2020, 11:17 door Anoniem
Door Anoniem:
Door The FOSS:
Door EnGeeX: Ik ben een open source evangelist zoals Karma4 dat zo mooi weet te benoemen, maar ik vind dit een beetje zoeken.

Het update proces van Windows verdient niet de schoonheidsprijs en voor mij een van de redenen om destijds over te stappen naar Linux, maar om Windows hierom te diskwalificeren vind ik een brug te ver.

Een server die moet rebooten bij elke update is niet werkbaar dus diskwalificatie van Windows voor toepassingen op servers ligt voor de hand. De Microsoft Windows adepten gaan nu iets roepen van patchdinsdag en inplannen van updates. Dat zijn allemaal workarounds om maar niet te willen inzien dat server reboots t.g.v. updates een Windows probleem zijn. En dat zoiets bij echte, meer professionele besturingssystemen helemaal niet aan de orde is.

Door EnGeeX: Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.

Voor een desktop is het irritant als je serieus, complex werk doet - waarvoor je een complexe omgeving op moet starten - dat het steeds onderbroken wordt door reboots. Maar voor lichte consumententoepassingen is het inderdaad geen probleem.

Ik beheer redelijk wat servers, die reboots maken mij niet zoveel uit.
Wij schedulen met SCCM de updates in de nacht, automatisch reboot volgt ook in de nacht, zodat de volgende ochtend alles in orde is.
We werken via (O)TAP straat, oftewel updaten via deze automatische schedules wordt eerst uitgevoerd op Test Servers, aantal dagen later op Acceptatie, aantal dagen later Productie...
Maar het mechanisme is geheel automatisch, wij ervaren hier weinig problemen mee. (Op een enkele servers/update na...)

Werkplekken hetzelfde, updates worden geinstalleerd en herstart wordt via SCCM onderdrukt, pas wanneer de eindgebruiker het uitkomt zal deze zijn systeem herstarten. (Uiteraard W10 Enterprise, niet mogelijk via W10 Home...)
Eventueel met een deadline van x-aantal dagen dat deze herstart alsnog wordt uitgevoerd.

Wij ervaren sinds W10 build 1803 eigenlijk weinig problemen met Updates/Upgrades... Build 1709 en lager zagen we wel af en toe vreemde problemen. (Maar is alweer 2 jaar geleden)

inderdaad als je een serieuze windows toko bent, dan moet je dat ook serieus allemaal inrichten en opzetten zoals hierboven gezegd wordt. ondanks dat, deze windows manier van doen om servers HA en met minimale downtime / interruptie aan te bieden, gaat dan wel gepaard met een grotere loggere IT organisatie waarbij veel meer dingen organisatorisch ook op orde moet gaan zijn.

ik denk dat sommige OSS-ers zoals FOSS uit een andere praktijk komen, die niet zalig makend is, maar vwb updates op hun systemen met veel minder geplan, organisatie en downtime etc. gepaard gaat. het is in de praktijk echt zo dat op bijv een RHEL systeem live kernel patches zijn en dat een update aan een service gewoon live kan gebeuren en hooguit een 'systemctl restart' nodig heeft en dat (omdat het een enterprise linux is) zullen updates niet nieuwe ongeteste features introduceren enzv. enzv. enzv.

wat je ook van OSS / Windows vindt, hierin verschillen de OSen zig duidelijk in en heeft dat een duidelijk impact op een grotere omgeving vwb het aantal beheerders en opzet van je organisatie. wat je daarbij dan 'profesioneel' noemt is dan ook subjectief en sterk afhankelijk van je achtergrond / ervaringen.
11-06-2020, 11:24 door Anoniem
Door Anoniem:
we zien te veel en te vaak in de praktijk dat updates niet tijdig doorgevoerd worden en dat het gevolg een malware aanval is.
Staat los van een OS.

een deel van de problemen voor een IT dienst komen door de updates/patches van MS die
De meeste problemen of punten zijn generiek en niet alleen voor MS.

1) zorgvuldig getest moeten worden eerst
Bij iedere patch wordt en moet dit gedaan worden.

[quite]2) bij uitrol een server dwingen te rebooten en tijdens de reboot soms een lange "update wordt geinstalleerd" procedure doorlopen met daarna weer een reboot en [/quote]Meerdere reboots? Das heel lang geleden dat ik daar last van had. En je hebt een change Window, hoe lang dan een patch duurt maakt niet direct uit.
En in zo'n change windows, daarin patchen we hondenren servers geautomatiseerd zonder enige problemen. Meerdere reboots echt niet nodig met de standaard Microsoft Patches.

3) patches komen maar eens in de maand als een hele grote all-or-nothing blob en dat geeft soms issues met hardware en andere software/drivers die functioneel nodig zijn op de servers.
De issues die gemeld worden, zijn voornamelijk op desktops en niet op servers, dus geld hier al niet echt voor. Daarnaast is het ook gewoon een onderdeel van je beheer, om firmware en drivers up to date te houden.
Ik kan mij niet herinneren dat server updates ooit problemen hebben gehad met drivers.

Maar voor applicaties, is het natuurlijk wel noodzaak om te checken of de applicaties moet nieuwe versies overweg kunnen. Ook dat staat los van een OS discussie.

dat heeft verder NIETS met oss / foss iod te maken en kan wel degelijk verbeterd worden vwb punten 1 en 3.
Valt ook wel mee. Meerdere reboots is tegenwoordig voor de standaard maandelijks updates zelden nodig.
En 3 staat los van een OS en is meer een applicatie probleem
11-06-2020, 11:34 door Anoniem
Je moet het probleem "na een Windows update moet je meestal rebooten" niet verwarren met het probleem
"Windows update is zo verschrikkelijk traaaaag". Dat zijn twee verschillende dingen. Het eerste heb ik al uitgelegd,
heeft te maken met het filesystem.
Het tweede heeft te maken met het feit dat in Windows het hele update proces wordt uitgevoerd als een transactie
die geheel op de disk geschreven moet zijn voor die gecommit wordt. Men gaat niet, zoals in Linux, in het wilde weg
files vervangen in de hoop dat het systeem niet halfweg crashed of de spanning uitvalt. De hele nieuwe status van
het systeem wordt net als in een goede database klaar gezet en in 1 keer (ondeelbaar) vervangen. Als het systeem
gedurende dat proces crashed en reboot, dan wordt de update in zijn geheel terug gedraaid als die nog niet helemaal
uitgevoerd was. Dit mechanisme (en de manier waarop het geimplementeerd is) is er de oorzaak van dat het installeren
van updates zo lang duurt. En je kunt het helaas ook niet uitzetten, zelfs niet als je zelf wel de gok wilt nemen.

Zou je een update bekijken en de handelingen die deze uiteindelijk uitvoert zelf met de hand doen (wat files copieren
en wellicht een registry key hier of daar) dan zou dat makkelijk 100 keer zo snel gaan. En dat zie je ook in Linux,
waar een dergelijk mechanisme niet gebruikt wordt. Maar realiseer je wel dat dit betekent dat als je systeem crashed
tijdens een update je in een toestand terecht komt die je handmatig en met de nodige expertise moet repareren.
(wel is het zo dat tegenwoordig meer Linux systemen werken met filesystems die snapshots kunnen maken, zoals
btrfs, en dan een snapshot maken voor de update en bij een crash aanbieden die snapshot terug te zetten. echter,
dit betreft dan het hele systeem, dus als je gedurende de update ook zelf dingen hebt gedaan raak je dat ook kwijt)

Verder is Windows Update erg traag in het bepalen wat er precies geupdate moet worden. Er is wel een lijst van welke
updates geinstalleerd zijn en het is simpel om de lijst op te halen van "welke updates zijn er" en die te diffen met
"welke updates zijn geinstalleerd" en degenen die niet geinstalleerd zijn te installeren. Ik heb dat jaren zo gedaan en
het gaat snel. Echter Microsoft Update doet dat niet zo, die haalt het niet op het level van update maar op het
level van bestand op, en gaat al die versies allemaal checken. Waarom, dat is me (gezien het transactionele karakter
van het installeren van updates) niet helemaal duidelijk. Het gevolg is in ieder geval dat "check of er updates nodig
zijn" ook heel lang kan duren, en het kost ook heel veel CPU.
11-06-2020, 11:37 door karma4 - Bijgewerkt: 11-06-2020, 12:03
Door Ron625: Software heeft geen mentaliteit, dat is iets dat bij mensen thuis hoort.
Mogelijk bedoel je het beheer, maar dat staat los van een besturingssysteem.........
Daar heb je gelijk in. Kijk je naar big data met server processen dan heb ik daar zeer droevige ervaringen in de afstemming tussen het gebruik, de veiligheid en functionaliteit en wat vanuit het OS geboden wordt.
De mentaliteit dat het os heilig en foutloos is zoals zij het neergezet en bedacht hebben.

Als je naar LDAP ID gid en de lopende processen kijkt dan is het schokkend dat een draaien systeem aangepast kan worden en pas na een herstart blijkt dat het niet meer draaiend te krijgen is. Dan kun je beter regelmatig herstarten om te weten dat er niets raars tussendoor uitgehaald is.

Een desktop, laptop kun je ook beter uitzetten als je het niet gebruikt. Remote beheer met onderhoud buiten kantoortijden kon ooit met desktops, Laptops met een byod moet je de serverside met virtual desktops oplossen.
Een andere reeks van beperkingen en mogelijkheden.

i]Door Anoniem:[/i]
1. je kunt een open file gewoon deleten. de directory bevat de naam dan niet meer en je kunt hem niet meer via die
naam openen, maar processen die de file nog open hadden kunnen er nog gewoon mee werken (via het inode nummer).
2. je kunt een file vervangen door een andere door een nieuwe file te maken met een ander inode nummer en dan het
inode nummer in de directory te veranderen. processen die de file open hadden blijven de oude file gebruiken, en
processen die daarna die file openen krijgen de nieuwe file.

Dit mechanisme ontbreekt in Windows, daarom kan Windows nooit een file deleten die open is, en is het niet mogelijk
een file te veranderen zonder dat alle processen die die file open hebben dat "zien".
Wat je beschrijft is locking (disp= old, new shr ja mainframe) en wat verder geëvolueerd is naar ACID in databases.
Als je het OS kent dan zijn er altijd basale (low level) IO methodieken die om de locking heen kunnen gaan.
Je bewering moet je omdraaien die ontwikkeling van een bescherming in Multi user gebruik heeft in Unix - Linux nooit plaats gevonden. https://en.wikipedia.org/wiki/File_locking

Nogal onhandig in race-conditions dat een bestand waar jij aan werkt door een ander meteen kwijt gemaakt wordt.
Jouw belangrijke updates verdwijnen ongemerkt. Dat gedrag maakt een Multi-user toepassing lastig.
Beter is het om een nieuwe bestand apart neer te zetten en de oude ook te bewaren. Als het mis gaat kun je nog terugrollen.

Stel nu eens dat een proces draait en dat deze regelmatig nieuwe processen inlaad, Krijg je ongemerkt een mix van oude en nieuwe code door elkaar. Het is de reden dat je software releasematig en getest vrij geeft, dat hoeft geen probleem te zijn.Het probleem ontstaat doordat het apart volledig testen op gewenste functies kostbaar gemaakt wordt.


Door Anoniem: …. Waarom, dat is me (gezien het transactionele karakter
van het installeren van updates) niet helemaal duidelijk. Het gevolg is in ieder geval dat "check of er updates nodig
zijn" ook heel lang kan duren, en het kost ook heel veel CPU.
Hier he ik we wat van.
Stel je hebt een complex van software in huis gehaald (server based) waarbij de leverancier vele variaties in combinaties naar zijn afnemers kan samenstellen, dan zit er niets anders op dan een complete lijst van wat er moet gebeuren zien samen te stellen. Het opstellen van zoiets leid snel tot een massale hoeveelheid van kleine datasets.
Massaal verwerken van grote hoeveelheden kleine datasets is gewoon traag.
Een database is niet voor niets bedacht, het vermijdt de IO voor het bijhouden van I-nodes dan wel file beschrijving.
Hoe vaak laat je het os de tijden modificatie/creatie/gebruik bijhouden? https://www.howtogeek.com/517098/linux-file-timestamps-explained-atime-mtime-and-ctime/
11-06-2020, 11:50 door Anoniem
Door EnGeeX: Omdat iets anders gebeurt, is het niet slecht of fout, maar slechts anders. Ik vind het hinderlijk hoe Microsoft haar updateproces regelt, maar het update-argument word door het gros van de mensen afgewimpeld als 'dan haal ik wel even een kopje koffie'. En eigenlijk hebben ze gelijk. Een probleem is vaak, maar zo groot als dat je het zelf maakt.
Individueel, ja. En masse ligt het anders. Dat zijn dan namelijk honderd miljoen kopjes koffie extra per update. Of hoeveel windows-desktops er ook in de wereld te vinden zijn. Honderd miljoen verloren kwartiertjes die even later met honderd miljoen kopjes koffie teveel honderd miljoen overhaast genomen en slechtdoordachte beslissingen opleveren.

Dit is een stukje hyperbool, natuurlijk, maar stel dat gemiddeld genomen tien euro aan productiviteit vervliegt per update per machine, dan is dat met deze (verzonnen) installed base een miljard euro verlies. Verborgen verlies, maar dat je het niet ziet wil niet zeggen dat het er niet is.

Ook precies hierom is het maatschappelijk gezien enorm duur om developers altijd de snelste desktop te geven: Dan moeten de gebruikers namelijk óók upgraden. Of als niet, dan raken ze structureel productiviteit kwijt omdat hun computer niet vooruit te branden is. Als je maar naar één computer kijkt, is developertijd duurder dan de computer over z'n afschrijving. Kijk je naar de hele installed base, dan is het al bij relatief weinig opschalen al omgekeerd.

Belangrijkste is dat een OS na de updates verbetert, is (veiliger, gebruiksvriendelijker, stabieler, etc), dat rebooten is voor mij hinderlijk, maar ook niet meer dan dat.
Je hebt geen enkele garantie op zelfs ook maar terugkomen na de reboot. Als het misgaat ben je makkelijk dagen kwijt om het weer recht te (laten) trekken. Niet alleen levert dat productiviteitsverlies op, maar laat ook zien dat het systeem onbetrouwbaar is. Het kan zomaar en zonder waarschuwing ophouden met werken. Dat kan je zelfs zomaar de wedstrijd kosten.*

Best kans dat de updates je computer zo sloom maken dat je al voor de volgende release de hardware moet vervangen. Ook daar zijn zelfs wel praktijkvoorbeelden van te vinden.

* https://www.zeit.de/sport/2015-03/basketball-paderborn-windows-update-abstieg of anders https://www.neowin.net/news/unexpected-windows-update-on-scoreboard-computer-delays-basketball-game/
11-06-2020, 12:12 door Bitje-scheef
Novell is het antwoord.
11-06-2020, 12:15 door The FOSS
Door Anoniem: ... Je gebruikelijke onzin commentaar over lichte consumententoepassingen, laat al weer zien, dat jij gewoon geen enkel idee hebt, wat gebruikers nodig hebben om hun werkzaamheden te doen.

Voor de rest gewoon de gebruikelijke preken van onze predikant. Niets meer of minder.

Ja, dat is lekker gemakkelijk! Noem het maar preken van 'onze' predikant. Wat nou 'onze'. Denk je dat je medestanders hebt die jouw denkbeelden volgen en dat dit een meerderheid is? Ik stel tegenover jouw 'onze' mijn 'onze'. De groeiende groep professionals die beseft dat al dat gedoe met die reboots en patchdinsdagen gewoon artefacten van het gebruikte besturingssysteem zijn. Om nog maar niet de spreken over de vatbaarheid voor malware en de algehele traagheid en verstrengeling van GUI en OS. Voor lichte consumententoepassingen maakt het niet uit. Voor professionele toepassingen zie je alleen Linux en macOS. Kijk maar eens om je heen op een softwareconferentie.
11-06-2020, 12:28 door Anoniem
Door Anoniem: Een voorbeeld hiervan is Firefox. Als je dat update via het package management systeem van je distributie, terwijl
het programma open staat, en je gaat er dan verder mee werken dan zal het meestal even later (als je "iets nieuws"
doet) crashen. Doe je de update vanuit Firefox zelf, dan zal ie zichzelf herstarten om dit probleem te voorkomen.
Anoniem 10:43 hier, leuk om te zien dat we parallel in andere woorden grotendeels hetzelfde hebben uitgelegd.

Ik draai Debian met een actuele Firefox die ik in mijn upgrade-scriptje rechtstreeks bij Mozilla download. Van die versie heb ik gemerkt dat die controleert of hij geüpdate is: hij crasht niet maar weigert na een upgrade nog nieuwe sites te openen (of waren het nieuwe tabs?), en biedt in plaats daarvan aan zichzelf te herstarten.
11-06-2020, 12:48 door [Account Verwijderd]
Mannen. Ik ga er van tussen. Het is onmogelijk om hier een normale discussie te voeren zonder dat het een strijd word.

@Karma; open source is niet eng, maar ander dan je prefereert.
@Foss: Windows is niet eng, maar anders dan je prefereert.

Dit was de laatste, ik ga mijn account verwijderen. Reddit is een beschaafder en nuttiger platform dan dit forum.
11-06-2020, 13:50 door souplost
Dat er nog windows servers in omloop zijn komt waarschijnlijk omdat de gebruikte applicatie windows only is. Dat gemeentes in Nederland o.a. Oracle op een Linux server draaien zegt wel wat. Het is op zich opvallend want de grote dienstverleners zijn allemaal rond windows gebouwd. Edoch zelfs Microsoft heeft haar vlaggenschip MSSQL naar Linux geport. Beheerders gebruiken dat niet alleen omdat de performance hoger is, of niet vatbaar is voor al die windows malware, maar ook omdat een reboot niet per definitie noodzakelijk is. Een database opnieuw opstarten kan lang duren en wie heeft er niet meegemaakt dat windows cifs shares er opeens niet meer zijn. Relinking van databases zit men ook niet op te wachten. Vandaar dat er tools (ksplice, livepatch etc) zijn waardoor een reboot niet nodig is. V.b. https://www.oracle.com/technical-resources/articles/linux/ksplice-update-tour.html.

Een reboot is een instabiele situatie naar hopelijk een nieuwe stabiele situatie. Dat is altijd een vervelend risco met als gevolg dat velen te laat patchen met als resultaat veel malware ellende met een schade die inmiddels in de miljarden moet lopen.
Zelfs een kritieke patch wordt bij grote windowsdienstverleners pas na een maand geïnstalleerd, want procedure, terwijl we weten dat het soms op een weekend aankomt.

Wie heeft er niet meegemaakt dat een windowsserver na een antivirus update niet meer opkwam. Daarom gebruikt het windowsoligopolie ook dure OTAP straten en clusters van van alles en nog wat. Gaat de een down blijkt de ander het niet over te nemen. Daarnaast is niet alles horizontaal schaalbaar zoals Ceph. Op papier werkt het allemaal en kan het lekker worden verkocht. In de praktijk vliegen ze er omstebeurt uit omdat ze de prestaties niet waarmaken.

Het is ook nog niet zo lang geleden dat gamers ontzettend over de zeik gingen omdat hun win10 systeem ging rebooten terwijl hun game al 12 uur aan de gang was. Windows beheerders hebben er mee leren leven en wensen geen commentaar verbeteringen te horen bljikt ook hier weer op security.nl zodat de discussie op slot kan worden gegooid.

In Linux is alles een file. In Windows een object, daarom is het NT filesysteem ook zo traag (probeer eens een folder te openen met paar duizend files). Waarom je in windows bijna altijd moet rebooten en een Unix systeem niet, is hier boven netjes uitgelegd. Een rpm distro geeft met (# needs-restarting ) aan welke processen gerestart of gereload moeten worden of waarom een reboot nodig is (# needs-restarting -r )
De genoemde windowshandicap zorgt er trouwens ook voor dat het backuppen van windows files een probleem is. Er moeten allerlei trucs (zoals Shadow Copy) worden uitgehaald om het op te lossen en levert dus een extra risico op.
11-06-2020, 14:23 door souplost - Bijgewerkt: 11-06-2020, 14:26
Door Bitje-scheef: Novell is het antwoord.
Het was goed dat ze eigenaar van de USL UNIX code bleken te zijn.
Weer zo'n techneuten bedrijf met superieure producten dat het niet tegen MS marketing kon opboxen.
Ook te lang bij IPX blijven hangen.
Deze is na 12 jaar nog steeds waar: https://www.youtube.com/watch?v=g45YkIVF4n0
Dit is ook uitgekomen mede dankzij Novell en IBM: https://www.youtube.com/watch?v=x7ozaFbqg00
11-06-2020, 14:38 door Anoniem
Door souplost: Dat er nog windows servers in omloop zijn komt waarschijnlijk omdat de gebruikte applicatie windows only is. Dat gemeentes in Nederland o.a. Oracle op een Linux server draaien zegt wel wat. Het is op zich opvallend want de grote dienstverleners zijn allemaal rond windows gebouwd. Edoch zelfs Microsoft heeft haar vlaggenschip MSSQL naar Linux geport.
Das toch niet zo vreemd? Gewoon de complete Oracle Stack gebruiken, volledig ondersteund door 1 leverancier. Vrij standaard oplossing en implementatie.
Als je de logica daar niet van in kan zien, tja.... Dat kan wat verklaren.

gebruiken dat niet alleen omdat de performance hoger is, of niet vatbaar is voor al die windows malware, maar ook omdat een reboot niet per definitie noodzakelijk is. Een database opnieuw opstarten kan lang duren en wie heeft er niet meegemaakt dat windows cifs shares er opeens niet meer zijn.
Er draaien maar heel weinig databases van een SMB share (CIFS is trouwens een hele legacy naam, is dat toevallig je laatste ervaring met Windows?). Ik heb trouwens nog nergens een MSSQL Database op Linux productie zien draaien. Ze zullen er vast wel zijn. Maar ik ben ze nog niet tegen gekomen. Gewoon Windows gebruiken, eventueel in een always on cluster. Werkt gewoon goed, stabiel en snel.

Een reboot is een instabiele situatie naar hopelijk een nieuwe stabiele situatie. Dat is altijd een vervelend risco met als gevolg dat velen te laat patchen met als resultaat veel malware ellende met een schade die inmiddels in de miljarden moet lopen.
Gebruikelijke onzin weer eens.

Zelfs een kritieke patch wordt bij grote windowsdienstverleners pas na een maand geïnstalleerd, want procedure, terwijl we weten dat het soms op een weekend aankomt.
Bij een goede architectuur, segmentatie en implementatie maakt het meestal niet eens direct uit. Servers zijn alleen toegankelijk op de benodigde poorten. Afgezien de applicatie patches natuurlijk.
Dat dit meestal niet gedaan wordt, ligt niet aan Microsoft of een andere levernacier.

Wie heeft er niet meegemaakt dat een windowsserver na een antivirus update niet meer opkwam.
Is al weer een tijdje geleden, maar is een mogelijkheid. Updates komen daar eventueel meerdere keren per dag uit. Deze kun je natuurlijk eventueel eerst aan een test groep deployen
.
Daarom gebruikt het windowsoligopolie ook dure OTAP straten en clusters van van alles en nog wat. Gaat de een down blijkt de ander het niet over te nemen. Daarnaast is niet alles horizontaal schaalbaar zoals Ceph. Op papier werkt het allemaal en kan het lekker worden verkocht. In de praktijk vliegen ze er omstebeurt uit omdat ze de prestaties niet waarmaken.
Gebruikelijke onkunde. Gaan we maar niet op in.

Het is ook nog niet zo lang geleden dat gamers ontzettend over de zeik gingen omdat hun win10 systeem ging rebooten terwijl hun game al 12 uur aan de gang was. Windows beheerders hebben er mee leren leven en wensen geen commentaar verbeteringen te horen bljikt ook hier weer op security.nl zodat de discussie op slot kan worden gegooid.
Is ondertussen al een paar jaar geleden. Gaan we ook maar niet verder op in, oude koeien iedere keer ophalen.

In Linux is alles een file. In Windows een object, daarom is het NT filesysteem ook zo traag (probeer eens een folder te openen met paar duizend files). Waarom je in windows bijna altijd moet rebooten en een Unix systeem niet, is hier boven netjes uitgelegd. Een rpm distro geeft met (# needs-restarting ) aan welke processen gerestart of gereload moeten worden of waarom een reboot nodig is (# needs-restarting -r )
En dan maar hopen dat alle applicaties dit gebruiken....... Anders kan je zomaar vulnerable zijn, terwijl je denkt gepatched te hebben.


De genoemde windowshandicap zorgt er trouwens ook voor dat het backuppen van windows files een probleem is. Er moeten allerlei trucs (zoals Shadow Copy) worden uitgehaald om het op te lossen en levert dus een extra risico op.
Ik noem ook even iets met een consistency snaphot....
11-06-2020, 14:42 door karma4
Door souplost:
Door Bitje-scheef: Novell is het antwoord.
Het was goed dat ze eigenaar van de USL UNIX code bleken te zijn.
Eerder een bedrijf dat niet naar de pijpen va IBM danste https://nl.wikipedia.org/wiki/Novell
SMB V1 was niet voor niets van IBM (lan managers). Leuk om te lezen de hele historie van verkoop en rechten Unix en Suse. Die had ik nog niet zo gevolgd. .

… In Linux is alles een file. In Windows een object, daarom is het NT filesysteem ook zo traag (probeer eens een folder te openen met paar duizend files). …
Onder Linux knalt het hele zaakje onderuit als je het probeert. Krijg je voor je het weet het advies om het bij Windows te laten.
Klinkt raar maar het gebruik is groot geworden met een boel endpoints die allemaal veel kleine bestandjes gebruiken.
Zet het in een netwerk met clusters en het blijft nog overeind ook. Een onmogelijkheid in de andere wereld.
11-06-2020, 14:56 door souplost
Door karma4:
Door souplost:
Door Bitje-scheef: Novell is het antwoord.
Het was goed dat ze eigenaar van de USL UNIX code bleken te zijn.
Eerder een bedrijf dat niet naar de pijpen va IBM danste https://nl.wikipedia.org/wiki/Novell
SMB V1 was niet voor niets van IBM (lan managers). Leuk om te lezen de hele historie van verkoop en rechten Unix en Suse. Die had ik nog niet zo gevolgd. .

… In Linux is alles een file. In Windows een object, daarom is het NT filesysteem ook zo traag (probeer eens een folder te openen met paar duizend files). …
Onder Linux knalt het hele zaakje onderuit als je het probeert. Krijg je voor je het weet het advies om het bij Windows te laten.
Klinkt raar maar het gebruik is groot geworden met een boel endpoints die allemaal veel kleine bestandjes gebruiken.
Zet het in een netwerk met clusters en het blijft nog overeind ook. Een onmogelijkheid in de andere wereld.
karma4 die altijd ontkent iets met windows te maken te hebben springt onmiddellijk in de bres. Zie ook zijn onzinnige race-conditions opmerkingen. Hoe geloofwaardig is dat?
Dat windows reboot altijd noodzakelijk is komt doordat files gelocked zijn. Ga nu niet proberen te vertellen dat dat nu ineens een voordeel is. Als je onder Linux filelocking wil hebben kan dat op verschillende manieren.
11-06-2020, 15:16 door Anoniem
Door souplost: Dat er nog windows servers in omloop zijn komt waarschijnlijk omdat de gebruikte applicatie windows only is. Dat gemeentes in Nederland o.a. Oracle op een Linux server draaien zegt wel wat. Het is op zich opvallend want de grote dienstverleners zijn allemaal rond windows gebouwd. Edoch zelfs Microsoft heeft haar vlaggenschip MSSQL naar Linux geport. Beheerders gebruiken dat niet alleen omdat de performance hoger is, of niet vatbaar is voor al die windows malware, maar ook omdat een reboot niet per definitie noodzakelijk is. Een database opnieuw opstarten kan lang duren en wie heeft er niet meegemaakt dat windows cifs shares er opeens niet meer zijn. Relinking van databases zit men ook niet op te wachten. Vandaar dat er tools (ksplice, livepatch etc) zijn waardoor een reboot niet nodig is. V.b. https://www.oracle.com/technical-resources/articles/linux/ksplice-update-tour.html.

Een reboot is een instabiele situatie naar hopelijk een nieuwe stabiele situatie. Dat is altijd een vervelend risco met als gevolg dat velen te laat patchen met als resultaat veel malware ellende met een schade die inmiddels in de miljarden moet lopen.
Zelfs een kritieke patch wordt bij grote windowsdienstverleners pas na een maand geïnstalleerd, want procedure, terwijl we weten dat het soms op een weekend aankomt.

Wie heeft er niet meegemaakt dat een windowsserver na een antivirus update niet meer opkwam. Daarom gebruikt het windowsoligopolie ook dure OTAP straten en clusters van van alles en nog wat. Gaat de een down blijkt de ander het niet over te nemen. Daarnaast is niet alles horizontaal schaalbaar zoals Ceph. Op papier werkt het allemaal en kan het lekker worden verkocht. In de praktijk vliegen ze er omstebeurt uit omdat ze de prestaties niet waarmaken.

Het is ook nog niet zo lang geleden dat gamers ontzettend over de zeik gingen omdat hun win10 systeem ging rebooten terwijl hun game al 12 uur aan de gang was. Windows beheerders hebben er mee leren leven en wensen geen commentaar verbeteringen te horen bljikt ook hier weer op security.nl zodat de discussie op slot kan worden gegooid.

In Linux is alles een file. In Windows een object, daarom is het NT filesysteem ook zo traag (probeer eens een folder te openen met paar duizend files). Waarom je in windows bijna altijd moet rebooten en een Unix systeem niet, is hier boven netjes uitgelegd. Een rpm distro geeft met (# needs-restarting ) aan welke processen gerestart of gereload moeten worden of waarom een reboot nodig is (# needs-restarting -r )
De genoemde windowshandicap zorgt er trouwens ook voor dat het backuppen van windows files een probleem is. Er moeten allerlei trucs (zoals Shadow Copy) worden uitgehaald om het op te lossen en levert dus een extra risico op.

Uit ervaring:
OTAP heeft niet alleen met techniek te maken.
OTAP is vaak een eis van een klant.

Wij hebben ook Linux systemen in OTAP en clusters staan... (kan een eis zijn, los of het OS dit nodig zou hebben of nooit zou rebooten)

Wij hebben een klant die verplicht validatie moet uitvoeren op zijn systemen en processen om aan bepaalde certificeringen te voldoen...
Maakt het onderliggende operating systeem of geinstalleerde applicatie niet uit, moet gewoon gebeuren en goed gepland worden.

Bv. De klant controleert of bij een aanpassing op het systeem dezelfde input voor dezelfde output zorgt na de werkzaamheden.

Voorbeeld in dit proces:
https://nl.wikipedia.org/wiki/Good_manufacturing_practice
11-06-2020, 15:46 door A.J.
Je moet wat als je thuis zit met een uitkering op de bank, ja dan ga je maar weer preken over open source evangelie.
11-06-2020, 15:51 door Anoniem
Door karma4:
… In Linux is alles een file. In Windows een object, daarom is het NT filesysteem ook zo traag (probeer eens een folder te openen met paar duizend files). …
Onder Linux knalt het hele zaakje onderuit als je het probeert.
Hoe het zit onder Windows weet ik niet maar met Linux kan ik dit soort uitspraken heel simpel verifiëren. Ik heb een directory aangemaakt met daarin hardlinks naar bestanden in mijn homedirectory. Dat leverde 285.378 bestanden op met daarin 749 GB, alles in één platte directory.

Daar had bestandsbeheerprogramma thunar even werk aan: het duurde 1,5 minuut voor het de lijst met bestanden liet zien. Daarna was de performance van thunar wat schokkerig (maar niet van andere programma's), ongetwijfeld omdat thunar op de achtergrond thumbnails van de bestanden maakt en dat is natuurlijk geen kleinigheid, daarvoor moeten al die bestanden ook nog eens gelezen worden. Maar het werkte, ik kon bladeren, bestanden openen, geen enkel probleem.

Dus ik heb het onder Linux geprobeerd met heel wat meer dan een paar duizend files en er knalde helemaal niets onderuit.

Waar baseerde jij je uitspraak op?
11-06-2020, 15:55 door Anoniem
Door Anoniem: Je moet het probleem "na een Windows update moet je meestal rebooten" niet verwarren met het probleem
"Windows update is zo verschrikkelijk traaaaag". Dat zijn twee verschillende dingen. Het eerste heb ik al uitgelegd,
heeft te maken met het filesystem.
Het tweede heeft te maken met het feit dat in Windows het hele update proces wordt uitgevoerd als een transactie
die geheel op de disk geschreven moet zijn voor die gecommit wordt. Men gaat niet, zoals in Linux, in het wilde weg
files vervangen in de hoop dat het systeem niet halfweg crashed of de spanning uitvalt. De hele nieuwe status van
het systeem wordt net als in een goede database klaar gezet en in 1 keer (ondeelbaar) vervangen. Als het systeem
gedurende dat proces crashed en reboot, dan wordt de update in zijn geheel terug gedraaid als die nog niet helemaal
uitgevoerd was. Dit mechanisme (en de manier waarop het geimplementeerd is) is er de oorzaak van dat het installeren
van updates zo lang duurt. En je kunt het helaas ook niet uitzetten, zelfs niet als je zelf wel de gok wilt nemen.

Zou je een update bekijken en de handelingen die deze uiteindelijk uitvoert zelf met de hand doen (wat files copieren
en wellicht een registry key hier of daar) dan zou dat makkelijk 100 keer zo snel gaan. En dat zie je ook in Linux,
waar een dergelijk mechanisme niet gebruikt wordt. Maar realiseer je wel dat dit betekent dat als je systeem crashed
tijdens een update je in een toestand terecht komt die je handmatig en met de nodige expertise moet repareren.
(wel is het zo dat tegenwoordig meer Linux systemen werken met filesystems die snapshots kunnen maken, zoals
btrfs, en dan een snapshot maken voor de update en bij een crash aanbieden die snapshot terug te zetten. echter,
dit betreft dan het hele systeem, dus als je gedurende de update ook zelf dingen hebt gedaan raak je dat ook kwijt)

Verder is Windows Update erg traag in het bepalen wat er precies geupdate moet worden. Er is wel een lijst van welke
updates geinstalleerd zijn en het is simpel om de lijst op te halen van "welke updates zijn er" en die te diffen met
"welke updates zijn geinstalleerd" en degenen die niet geinstalleerd zijn te installeren. Ik heb dat jaren zo gedaan en
het gaat snel. Echter Microsoft Update doet dat niet zo, die haalt het niet op het level van update maar op het
level van bestand op, en gaat al die versies allemaal checken. Waarom, dat is me (gezien het transactionele karakter
van het installeren van updates) niet helemaal duidelijk. Het gevolg is in ieder geval dat "check of er updates nodig
zijn" ook heel lang kan duren, en het kost ook heel veel CPU.

op SuSE SLES gaat dat anders. daar wordt bijv btrfs/lvm gebruikt en een snapshot van '/' gemaakt voordat updates doorgevoerd worden:

https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-snapper.html

los daarvan, mijn persoonlijke ervaring van 20j met RHEL, CentOS en voorgangers; een 'yum update' kun je vrij onschuldig gewoon runnen op een live systeem als je puur gebruik maakt van de officele repos (en anders protections/priorities aan hebt staan). je kun daarna KIEZEN of je wel of geen reboot doet, of je wel of geen service herstart. de reboot kan ook nog eens een warme reboot zijn via kexec:

https://blogs.oracle.com/linux/reboot-faster-with-kexec


kortom, de informatie hierboven is niet geheel correct.
11-06-2020, 15:56 door [Account Verwijderd]
Mijn ervaring met zowel Linux als Windows is dat het 'installeren' van updates lang kan duren en niet altijd stabiel is. De manier waarop Linux ook applicaties kan updaten en je niet gelijk vast zit aan een Microsoft account is wel veruit superieur aan Windows en de Windows app store. Het voordeel van live patching lijkt mij redelijk niche. Wanneer je updates stabiel en snel kan uitvoeren zie ik absoluut geen probleem, ook niet met een eventuele verplichte reboot. Als je dat wel hebt, moet je even bedenken wat je gaat doen als de stroom een keer uitvalt.

Verder heb ik nog weinig mensen gehoord over Google's (Chromebook en Android) aanpak met A/B partities. De stabiliteit van atomic updates met dezelfde snelheid als een normale reboot. 'Updaten' gaat in de achtergrond waarna je met een simpele reboot over bent naar de nieuwe versie. Mocht er iets mis gaan kan er altijd teruggeschakeld worden naar de vorige versie, zonder dat hier al je bestanden zijn overgeschreven.

Door Anoniem:Tijd om Fedora een te proberen dan.
Fedora Silverblue bedoel je? Applicatie updates (Flatpak) hebben geen reboot nodig. OS updates (OSTree, atomic updates) wel, echter is dat even snel als een normale reboot (i.t.t. Windows 'updates installeren'). Vergeet boven dien niet dat je de meeste commandline tools in een Toolbox (Podman) installeert, waardoor je je eigen systeem dus niet hoeft te updaten of rebooten. (Ja het is een beetje flauw. Fedora Workstation/Server maakt inderdaad gebruik van een 'updates installeren' proces om te voorkomen dat het bestanden gaat overschrijven in lopende processen wanneer dit in de achtergrond gedaan zou worden.)
11-06-2020, 16:06 door Anoniem
Door Ron625:
Door karma4:
Het zelfde verhaal kunnen aanhouden voor het FOSS gebeuren. Je ziet constant open source database open en bloot op het internet. Dat moet wel aan de brakke mentaliteit van FOSS liggen.
Software heeft geen mentaliteit, dat is iets dat bij mensen thuis hoort.
Mogelijk bedoel je het beheer, maar dat staat los van een besturingssysteem.........

right: ik ben een beheerder van GEEN compjoeter en GEEN besturingssysteem. oh jeej wat heb ik veel werk.

kortom beheer staat niet LOS van een besturingssysteem, maar wat je probeert te vertellen is dat onafhankelijk van welk bestuuringssysteem je gebruikt, er beheer nodig zal zijn. tegelijkertijd opent de juiste formulering en de juiste logica de deur naar de volgende redenatie stap: het kan dus soms makkelijker of moeilijker beheren zijn afhankelijk van het bestuuringssysteem en de omstandigheden.

zo jammer die onzorgvuldigheden steeds... zal wel een bepaalde beheers mentaliteit zijn die ik vaker proef bij ITers.
11-06-2020, 18:10 door Anoniem
Door Anoniem:
op SuSE SLES gaat dat anders. daar wordt bijv btrfs/lvm gebruikt en een snapshot van '/' gemaakt voordat updates doorgevoerd worden:
Dat stond al in dat stuk wat je in zijn geheel gequote had.


los daarvan, mijn persoonlijke ervaring van 20j met RHEL, CentOS en voorgangers; een 'yum update' kun je vrij onschuldig gewoon runnen op een live systeem
Je gaat niet in op wat er gebeurt als tijdens die update het systeem crashed. Dat maak je niet vaak mee natuurlijk, maar
als Microsoft rekening moet houden met alle miljarden gebruikers dan gebeurt het daar vast wel een keer en dan is zo'n
gebruiker nog hulpelozer dan de gemiddelde Linux gebruiker.

kortom, de informatie hierboven is niet geheel correct.
In ieder geval heb je het niet correct gelezen.
11-06-2020, 19:35 door The FOSS - Bijgewerkt: 11-06-2020, 20:01
...
11-06-2020, 19:35 door karma4 - Bijgewerkt: 11-06-2020, 19:46
Door Anoniem: ..
Dus ik heb het onder Linux geprobeerd met heel wat meer dan een paar duizend files en er knalde helemaal niets onderuit.
Waar baseerde jij je uitspraak op?
ext4 gaat rond de 32000 bestandjes langzaam aan plat, fysiek opgeslagen (xml) schrijvend, niet zomaar lezen.
Je gaat met schrijven druk geven op de system cache en de io balancer.
Bij 250.000 gaat de zipper plat.
File io met een open/close per record update gaat tergend langzaam als de striping tekort schiet. Ik zag de Mtime constant veranderen terwijl ik een enkele update al open/close verwacht had.
Iostat en lsblk laten het euvel zien als je de moeit neemt om het te volgen, rw informatie gemiddele block grootte. doorvoer snel dalend. Doe het wel met meerdere gelijksoortige processen tegelijkertijd ik had er als een single process op een machine nog niets in de gaten. Het ging fout toen er meer tegelijkertijd ging.

Dit soort verhalen:
https://serverfault.com/questions/787887/ext4-usage-and-performance
https://access.redhat.com/solutions/472273
http://www.brendangregg.com/blog/2016-10-06/linux-bcc-ext4dist-ext4slower.html
11-06-2020, 19:37 door The FOSS
[Verwijderd door moderator]
11-06-2020, 19:42 door karma4
[Verwijderd door moderator]
11-06-2020, 19:57 door The FOSS - Bijgewerkt: 11-06-2020, 20:02
[Verwijderd door moderator]
11-06-2020, 21:16 door The FOSS
Door karma4:
Door Anoniem: ..
Dus ik heb het onder Linux geprobeerd met heel wat meer dan een paar duizend files en er knalde helemaal niets onderuit.
Waar baseerde jij je uitspraak op?
ext4 gaat rond de 32000 bestandjes langzaam aan plat, fysiek opgeslagen (xml) schrijvend, niet zomaar lezen.
Je gaat met schrijven druk geven op de system cache en de io balancer.
Bij 250.000 gaat de zipper plat.
File io met een open/close per record update gaat tergend langzaam als de striping tekort schiet. Ik zag de Mtime constant veranderen terwijl ik een enkele update al open/close verwacht had.
Iostat en lsblk laten het euvel zien als je de moeit neemt om het te volgen, rw informatie gemiddele block grootte. doorvoer snel dalend. Doe het wel met meerdere gelijksoortige processen tegelijkertijd ik had er als een single process op een machine nog niets in de gaten. Het ging fout toen er meer tegelijkertijd ging.

Dit soort verhalen:
https://serverfault.com/questions/787887/ext4-usage-and-performance
https://access.redhat.com/solutions/472273
http://www.brendangregg.com/blog/2016-10-06/linux-bcc-ext4dist-ext4slower.html

Dat zijn edge cases voor een bestandssysteem dat mijlenver boven NTFS uitsteekt. Kortom: in de door jou aangedragen voorbeelden of vergelijkbare edge cases zou NTFS al lang de geest hebben gegeven.

https://medium.com/@emmettgb/ext4-vs-ntfs-6dbb79807006
11-06-2020, 21:25 door souplost
[Verwijderd door moderator]
11-06-2020, 21:50 door souplost - Bijgewerkt: 11-06-2020, 21:51
Zoals altijd bagatelliseren de windows architecten hier de windows problemen en in dit geval de reboots. Daarom zal het ook nooit wat worden en gaat het alleen maar bergafwaarts, gezien het afnemende aandeel op Azure ook.
Een reboot introduceert geen extra risico en er is toch een patch window. Alsof het allemaal geen geld kost. Dat Oracle altijd op een Linux server wordt geïnstalleerd ondanks dat Windows wordt gesupport wordt weggewuifd als een logische stackoplossing.
Het zal nog wel een tijdje duren voor de windows architecten ontslagen worden. Toenemende patchwindows, telemetrie privacy schendingen en criminelen afkopen om bestanden te decrypten is nog niet genoeg.
12-06-2020, 07:50 door karma4
[Verwijderd door moderator]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.