Livepatching applies selected Linux kernel fixes while the system remains operational. This enables administrators to fix critical kernel vulnerabilities without service interruption and reboots, which is especially important for servers, cloud instances, industrial systems, and remote edge devices where downtime is costly or risky.
Canonical also emphasizes that Livepatch does not eliminate the need for reboots. It only reduces urgent, unscheduled reboots between planned maintenance windows, but regular reboots are still required to fully adopt new kernel versions and clear system state.
One more thing that needs to be made clear is that Livepatch is not intended for typical desktop users.
Will it eventually come to the desktop user? Would you welcome it?
I can only conceive of this being used for livepatch of Security issues, where a new-found vulnerability categorically cannot be allowed to persist beyond the point of detection.
IMHO, I would think that anything else should not be allowed to be classified as such, forcing proper planning and testing prior to deployment.
In financial institutions where I have used both Sun Solaris and Red Hat Enterprise Linux, I doubt that they would trust a mechanism like this; instead they had multiple server farms, multiple sites, and they would conduct most of the updates OUTSIDE of regular business hours, but some services were available somewhere across the globe 24x7x365, so staged maintenance and updates were deployed without disruptions. With the multiple sites, even hurricanes and other natural disasters were minimized, if not eliminated completely; definitely the most expensive, sophisticated, and fortress-based server environment I’ve ever seen. Another financial services firm that was a spin-off of an automobile financing arm that later became a bank, financial lending and financial services firm had a decent approach, not quite as severe or “ideal”, but they had plenty of redundancy too, and multi-site operations too.
