Very slow booting and running and braindead OS's 1738
part of the micro-kernel genre ... core stuff was smallest unit possible and everything else was in parbreastioned address spaces.
For high-availability servers it has to be. You cannot move the root without a reboot. The root does not need to contain anything but a few other mounts, but it is...
the other was replicated kernels on replicated hardware ... basically do rolling restart.
similar, but different was loosely-coupled configurations (form of replication ... but also used for capacity) and migrate processes-applications across different processor complexes. this was done by some of the cp67-vm370 based commercial timesharing service bureaus
as they moved to world-wide, 7x24 operation in the early to mid-70s. particular pieces of hardware (including whole complexes) had to be taken out of service for periodic maintenance (but also applicable to kernal maintenance). recent post in this tread
i.e. from user-application standpoint using replicated systems (and things like process-workload migration) for masking system downtime-outage can be just as effective as making each individual component instantaneously restartable. this was also part of our ha-cmp product
Look again at the history of Feynman, Manley, and Metropolis. The war put a hiatus in their careers and they were just starting on their research lives when the red...
in the genre of parbreastioning and moving services out of the kernel ... post somewhat about contrast of moving SSL processing into the kernel ... vis-a-vis attempts at moving tcp-ip protocol stack out of the kernel in coyotos a parbreastioned, highly secure, capability based system
that traces its heritage back thru keykos and gnosis
in the early-mid 80s ... i had undertaken to move a large remaining component out of the vm370 kernel ... the "spool file system". the justification was that vm370 networking was dependent on spool file system and it was starting to represent a system thruput bottleneck for our hsdt project
I needed to improve the thruput by 10-100 times ... which required a significant restructuring. i figured that while i was at it, i would also move the processing out of the kernel. this was also somewhat improve the vm370 reboot time ... which was already pretty fast ... as the previous post (in this thread) also alludes to.
misc. past posts mentioning spool file system rewrite:
Very slow booting and running and braindead OS's 1739
Alt Folklore Computers from Newsgroups