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.

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.

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:


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.

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.

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.


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.

Tijd om Fedora een te proberen dan.

Software heeft geen mentaliteit, dat is iets dat bij mensen thuis hoort.
Mogelijk bedoel je het beheer, maar dat staat los van een besturingssysteem.........

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)

Waarom is dit een brakke architectuur ? Er zijn keuzes gemaakt in de architectuur. Dat maakt het niet direct brak.

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.

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.

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.

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?

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:
In een tweede maak je een bestand aan dat alle beschikbare ruimte op gaat vreten in een filesysteem (tenzij je het afbreekt):
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:
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.

Net Ubunto moeten update'n. Reboot nodig...

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.

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?

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.

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.


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.

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.

Staat los van een OS.

De meeste problemen of punten zijn generiek en niet alleen voor MS.

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.

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.

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

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.

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.

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.


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/

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.

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/

Novell is het antwoord.

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.

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.

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.

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.

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

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.

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.

Gebruikelijke onzin weer eens.

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.

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
.
Gebruikelijke onkunde. Gaan we maar niet op in.

Is ondertussen al een paar jaar geleden. Gaan we ook maar niet verder op in, oude koeien iedere keer ophalen.

En dan maar hopen dat alle applicaties dit gebruiken....... Anders kan je zomaar vulnerable zijn, terwijl je denkt gepatched te hebben.

Ik noem ook even iets met een consistency snaphot....

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. .

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.

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

Je moet wat als je thuis zit met een uitkering op de bank, ja dan ga je maar weer preken over open source evangelie.

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?

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.

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.

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.)

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.

Dat stond al in dat stuk wat je in zijn geheel gequote had.

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.

In ieder geval heb je het niet correct gelezen.

...

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

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.