I can't believe restarts are still a thing. We knew how to build OSes that can avoid this over 30 years ago. Many people claim that the Windows NT kernel is a pseudo microkernel, so it's probably all the user land cruft that's accumulated over the years. Hopefully they can clean that up and achieve true always-on functionality.
Its regularly astounding how few windows updates don't require a restart when most of my linux ones never do. The two filesystems act quite differently for locks, I know, but it is still a pain on windows.
I don't know how they'll get magic transparent updates when their model is to always require restarts.
>I don't know how they'll get magic transparent updates when their model is to always require restarts.
When the only thing stored locally is $HOME and everything runs on clusters on MS servers you will never know when the 'back end' reboots. The 'Future' is the same as the past but with updates.
You are (your smartphone) and will be running a dumb-terminal. Instead of one computer you are now using a very-large-cluster of servers. Each time you boot-up 'Your instance' may be a unique VM that gets spun-up in micro-seconds. When it's time for an update the patches can get all pushed out to the VM's and when you reconnect (i.e. wake from sleep-mode) you are now connected to an 'updated' VM with all the hard work happening on the backend.
This very of the future is really fucking COOL, and terrifying. It also pretty damn doable.
Interestingly, linux has ksplice despite being monolithic. To be fair I've never used it and I understand that it's fairly limited in what all can be patched without a reboot.
Random bit flips is a much longer time frame than we're currently seeing. Also, any services should be restartable at any time, so the only random bit flips that should matter are those in the kernel itself. The kernel data should be significantly smaller and so less likely to have a bit flipped.
If uptime and availability become a serious concern, then a partitioned system in which kernel data is in ECC memory while the remainder runs on cheaper non-ECC memory is possible as well.
I think you greatly underestimate a few things; one being the windows kernel size in memory, the other being the sheer volume of bit flips in high density memory.
A single 32GB SODIMM (as I have in my laptop, because it's a workstation laptop) see's roughly 12 bit-flips a month, these are correctable. This is pretty much in line with the 6-or-so bit flips I see on ECC memory inside servers (of which I have a few thousand, each having 32G modules spread over more area and enclosed in a heavy chassis, thus, less flips).
Bit flips are so common that it's even possible to have "double bit flips" in the same page, which is uncorrectable even with ECC.
So I think you grossly underestimate the percentage of bit flips, most are silent though (or attributed to bugs in software) so I understand you don't see it. If you had ECC memory you would.
My other point about Windows kernel being fairly large in terms of surface area is relatively self-evident, but I'll come back with some solid numbers, because those thousands of servers I was mentioning are all Windows.
EDIT:
As promised I checked the non-application memory usage of my fleet and the rounded value of Windows memory footprint by itself is 1.89GiB. FS Cache is also excluded.
> I think you greatly underestimate a few things; one being the windows kernel size in memory [...] As promised I checked the non-application memory usage of my fleet and the rounded value of Windows memory footprint by itself is 1.89GiB
That number is frankly absurd. No doubt it includes all sorts of things that shouldn't be included in a proper microkernel, which just goes to show to all those people that call the NT kernel a microkernel (or close to it), are full of it.
In principle, some book keeping memory for processes and the page tables are roughly all you need to live in kernel space.
Some things to note when talking about windows though; nearly their entire graphics stack lives in the kernel. They also have multiple environment subsystems running at the same time (POSIX, OS/2 and Win32) which, are running constantly and unavoidable, so I count them as kernel.
In addition they have things like the “security reference monitor” which resides entirely in the kernel.
It’s really apples to oranges, NT is truly heavy especially on server 2016 (which is where I grabbed the numbers)
I have comparatively fewer 2012r2 machines but I can aggregate the numbers for those too if you like.
And you hear stories about people being very afraid to reboot 30 year old mainframes / minis, so when moving buildings they are kept powered on, connected to ups...
Reboots are good because they test that your OS still works and you can make observations about which update broke what. They should be fast and painless though.
