Linux 5.2 To Enable GCC 9's Live-Patching Option, Affecting Performance In Select Cases

[MaxToTheMax]

Also, I see live kernel patching as a basic desktop usability feature, not a server feature. If you have a mission critical server and you don't have a good plan for what to do while it's shut down, you're doing it wrong. Rebooting is far more of a hardship for desktop users than server users.

[Grogan]

This gives new meaning to distro dogfood. I can build my kernels however I want, including manual intervention for some unwanted options that are forced, but the poor sods that have to use distro kernels get a shit sandwich these days.

[jabl]

If I not mistaken, Canonical offers paid support for live patches. Lets see if they will let this free option on by default in future releases.

This new option just reduces the possibility that the compiler will create code that isn't able to be successfully live-patched. What Canonical wants to get paid for is not for enabling this option (likely they'll enable it by default, since their live-patching is against their default kernels, you don't have to run some special kernel with live-patching support), but rather for creating and maintaining these live-patches themselves and their supporting infra.

Consider that for a patch P, they'll have to create separate live-patches for all kernels X.Y.Z-N in their repo, and maybe even different versions depending on whether X.Y.Z-N is a pristine kernel or whether it has already has previous live-patches P1, P2, P3 applied to it. In the end you'll have quite many live-patches to keep track of and test.

[guidotrueb]

All this and we still don't have proper hibernate/resume support... =/

https://xkcd.com/619/

[Weasel]

Also, I see live kernel patching as a basic desktop usability feature, not a server feature. If you have a mission critical server and you don't have a good plan for what to do while it's shut down, you're doing it wrong. Rebooting is far more of a hardship for desktop users than server users.

Rebooting is trivial. If you find rebooting a pain, you're using your desktop wrong, period. Change your shitty ways.

Time to start compiling all kernels from now on, just to be safe from cancer.

[starshipeleven]

Realistically, to get everything back to how I had it so I can continue getting work done, rebooting takes about an hour, even though my boot time is only a few seconds.

No offence, but if you "need" to have hundreds of tabs open, a movie player and many editors and IDEs open at the same time to be productive you are probably deluding yourself.

[starshipeleven]

Also, I see live kernel patching as a basic desktop usability feature, not a server feature. If you have a mission critical server and you don't have a good plan for what to do while it's shut down, you're doing it wrong. Rebooting is far more of a hardship for desktop users than server users.

Bullshit, you are a very atypical desktop user, most people does not have hundreds of applications open.

What actually needs uptime and kernel patches without rebooting are servers where you can't just reboot the server whenever there is a critical kernel update as you have to plan the reboots months ahead to avoid disrupting the service.

Then you can use this feature wherever you feel like it, and none will stop you, but don't claim this bs please.

[MaxToTheMax]

No offence, but if you "need" to have hundreds of tabs open, a movie player and many editors and IDEs open at the same time to be productive you are probably deluding yourself.

None taken. But have you considered the possibility that what you consider "good practice" is just a workaround for technological limitations that could be solved with technology rather than accepted without question?

And yes, if I had to open everything from scratch at work every day, that's 20-60 fewer minutes a day for doing work.

[MaxToTheMax]

Bullshit, you are a very atypical desktop user, most people does not have hundreds of applications open.

What actually needs uptime and kernel patches without rebooting are servers where you can't just reboot the server whenever there is a critical kernel update as you have to plan the reboots months ahead to avoid disrupting the service.

Then you can use this feature wherever you feel like it, and none will stop you, but don't claim this bs please.

If your server really is that important, you should probably get two and reboot one at a time. When your PSU blows a capacitor, you'll need the backup anyway. Not that it's wrong to use live patching for this case, far from it. It's just less of a necessity, unless you're skimping on redundancy.

[dkasak]

All this and we still don't have proper hibernate/resume support... =/

It works great on systems with AMD GPUs. Intel has stability issues with resuming, and my last Intel-based laptop wouldn't resume from hibernation at all. nVidia used to be pretty hit-and-miss, though admittedly it's been over a decade since I made that mistake. So when you say "we" don't have proper support ... that's not really correct ... you just have to choose your hardware wisely.