Back in the early 1990s, when I was working on Sun’s Unix boxes, it was routine for them to be up for multiple years at a time. A reboot was a big event.
Now here we are in 2017, and every single update to the Linux kernel — of which there are several every week — requests a reboot.
As I write, my Ubuntu 14.04 LTS box is running Linux 4.4.0-72. The update process just downloaded Linux 4.4.0-75, and now it’s asking to restart. Linux is more than 25 years old; yet it still can’t install a new sub-patch-level release of the kernel without rebooting? Clearly there can be no API changes between 4.4.0-72 and 4.4.0-75, so why can’t it just slip the new kernel into place without a reboot?
To be clear: I’m not saying that doing this is trivial; I am saying that after 25 years of development, I am amazed no-one’s taken it on. How much time is wasted rebooting millions of Linux boxes every other day, and re-establishing the working environment (window layout, files loaded into the editor, etc.)? This seems like a problem worth solving.
Perhaps part of the problem here is cultural: Windows has taught people that you expect to have to reboot your computer every day. Most Linux users have come to the light side from Windows, and have brought that expectation with them. It seems normal to them.
But it’s not. Or, at least, it shouldn’t be.
(Yes, part of the reason the Suns stayed up for years was that kernel updates were amazingly rare. Seamless kernel upgrade was a problem that didn’t need to be solved then. But it’s a problem that needs to be solved now.)
Two responses on Twitter to the stream of tweets that became this post:
- Tony McMahon points out that there is a thing called Livepatch.
- Alex Stapleton says that Ubuntu offers kpatch rebootless upgrades.
Very interesting — I will follow these up. (And I will be be asking myself, as I do so, why there are two solutions instead of one, and why this behaviour is not the default.)