Windows Update kräver sex uppkopplade timmar för att få ut uppdateringar

Kompilera med statisk länkning om vi pratar ports så är problemet ur världen.

FreeBSD program som ingår i FreeBSD(alltså inte ports) är kompilerade på samma vis, så behöver t.ex. SSH demonen uppdateras så det just bara den som kommer att få startas om. Behöver Syslog uppdateras så är det enbart bara den som startas om. Samma med NTP o.s.v.

Men visst, börjar man trycka in lösningar(t.ex. via pkg) som man själv inte kompilerar ifrån ports och där väljer statisk kompilering så lär det bli ett antal beroende. Jag har inte märkt att statisk kompilering äter utrymme så jag ser inte det som ett problem.

Men om man nu länkar saker statiskt så blir ju följden bara att det inte räcker med att starta om tjänsterna/applikationerna utan att du även behöver kompilera om dem (eller åtminstone göra om länkningssteget för dem) OCH starta om dem när något bibliotek de använder har uppdaterats.

Det går att stänga av det där, alltså den där rutan att den tipsar om ett online konto mm
På engelska ligger det under Settings -> System -> Notifications & actions -> Sedann bockrutan där det står "Suggest ways I can finish setting up my device to get the most out of Window" så ska du itne få upp den mer, om det är det jag tänker på

Alltså.. jag känner inte igen mig alls, min upplevelse av windows 10/11 är klockren! Noll problem och allt flyter bara på.

Kör även Linux och det är också trevligt, dock så stöter jag ofta på att det behövs lite "avancerad problemlösning" men det är jag medveten om, det är priset man får betala för frihet 😁

Kom precis på att jag visst har ett problem i windows men det är Razers mjukvara Synapse som orsakar att musen kopplar ifrån, störande som attan så om någon har en lösning på det problemet så tas det tacksamt emot

Det jag har haft fokus på är att FreeBSD inte behöver startas om för att något program/tjänst behöver uppdateras.

Om man kompilerar in biblioteken eller knyter sig till dom motsvarande en DLL i Windows, så är resultatet detsamma, man måste alltid starta om programmet för att det nya skall läsas in i minnet. Kör man FreeBSD så är det sysadmin som gör valet, skall jag använda färdig kompilerade filer för min plattform, eller behöver jag göra en ändring i något befintligt och detta finns i FreeBSD eller i ports så blir det alltid en kompilering, men det är bara den första kompileringen som tar tid.

Och vill man undvika delade bibliotek så är statisk länkning vid kompilering svaret.
Var gång man kompilerar något ur ports med make så kommer den även att kompilera ihop nya bibliotek om den känner att behovet finns där. Men om man ändrar det så att delade bibliotek skall länkas statisk så slipper man problemet med att andra program drabbas utav nertid p.g.a. ett program som skall uppdateras.

Och sedan så är där ingen garanti för att dom klarar av det nya biblioteket(om man inte kör statiskt), så måste även dom uppdateras trots att man inte har den avsikten.

I alla läge jag varit med om så fungerar saker felfritt på målplattformen när man kör med statisk kompilering eftersom allt är packat och klart och inga biblioteksavvikelser sker. Ville köra en grej på ESXi 5.0U1 och då slutade det med statisk kompilering eftersom ordinarie mak inte löste uppgiften, men det beror på min okunskap då detta var CentOS(äldre version som fungerade som kompileringsmiljö för ESXi 5.0U1) som jag gjorde något motsvarande på och då har FreeBSD inte haft något med saken att göra.

Vill Du byta ut ett program mot en annan version så får Du stänga ner programmet, byta ut inblandade nykompilerade filer, köra igång programmet.

Men jämfört med Windows så är det som dag och natt. Windows kräver i princip att hela maskinen startas om, och gärna flera gånger.

Jag hör vad du säger, men jag tror fortfarande att vi inte till fullo pratar om samma sak.

Min poäng i ett nötskal:
Om du t.ex. installerat uppdateringar som lagt dit ett nytt libssl.so i /usr/lib (eller var det nu må ligga) som lagar ett säkerhetshål så fortsätter ju alla befintliga processer att köra den gamla koden.
Dvs, det avslutande steget i uppdateringsprocessen är att antingen reda ut vilka processer som berörs på något sätt av de uppdateringar som installerats och starta om dessa (vilket kan bli en krävande övning i verkligheten, beror på situationen) eller att boota om (har åtminstone fördelen att det är enkelt att genomföra korrekt).

En stor skillnad är ju just att detta helt nödvändiga avslutande steg ofta är implicit och lämnas som en övning för systemadministratören att lösa bäst de vill. Och det är där jag menar att det känns som en grov förenkling om man påstår att "det går så snabbt och enkelt och jag behöver typ aldrig starta om".

Det ger en möjlighet till att själva välja vilka program som skall startas om, i vilken ordning samt vid vilken tidpunkt. Jag segmenterar själv så att en VM har sällan mer än en huvuduppgift vilket underlättar(vilket program skall startas om när?).