atzanteol@sh.itjust.works
on 20 Sep 05:03
nextcollapse
This is already possible with kpatch, ksplice, etc. This new thing seems more like a hypervisor of sorts? Or maybe a next level docker where containers could package their own kernel?
kuberoot@discuss.tchncs.de
on 20 Sep 10:13
collapse
In-memory kernel patching is complicated, AFAIK only select distributions support it, right? If kernel hotswap is successfully implemented this way, it should allow switching between arbitrary kernels at runtime without extra work or setup.
Of course, that’s a pretty big “if”, but a simple unified system sounds like a great thing. And of course there’s more to this than swapping kernels.
Not necessarily, maybe the main kernel has to keep running so you won’t be able to hot swap that (haven’t read the thing yet). In any case we’ve had updates without reboot for a while for a while, but it’s a pain to set up, there’s even a song about it youtu.be/SYRlTISvjww
That’s kind of hilarious. At first we had VMs to run entirely separate operating systems. Then we had Containers to separate everything except the kernel. And now we might get separation for just the kernel.
Well, there’s a separate technology stack for virtualization. So, it would be similar in effect, but the way you get there is different, and it’s possible that it performs better or worse for certain scenarios.
fruitycoder@sh.itjust.works
on 20 Sep 20:32
collapse
Ok now i just need a wrapper for it so that k8s can load to the side loaded kernel as a virtual(?) node.
Crazy cool to think we can load procs on tuned kernels on demand like that. You could also have an container runtime spec for it if you wanted a kernel per pod kind of deployment (more niche to me though).
threaded - newest
Full system updates without a reboot? Sign me up.
This truly is God’s country
Keep you imaginary sky daddy out of here, thank you
<img alt="" src="https://lemmy.world/pictrs/image/fb764b98-f29d-421f-99c7-7f628a01217f.jpeg">
Just a figure of speech 😉
Also sounds like we can run multiple kernels at once during normal operations, to isolate processes.
So, could I run a second kernel for, say, Docker to use? Isolate those containers away from the host system kernel?
Linux subsystem for linux
You know the very first thing someone is going to do is run Linux in Linux in Linux.
I thought the first would be Doom :(
This is already possible with kpatch, ksplice, etc. This new thing seems more like a hypervisor of sorts? Or maybe a next level docker where containers could package their own kernel?
In-memory kernel patching is complicated, AFAIK only select distributions support it, right? If kernel hotswap is successfully implemented this way, it should allow switching between arbitrary kernels at runtime without extra work or setup.
Of course, that’s a pretty big “if”, but a simple unified system sounds like a great thing. And of course there’s more to this than swapping kernels.
Not necessarily, maybe the main kernel has to keep running so you won’t be able to hot swap that (haven’t read the thing yet). In any case we’ve had updates without reboot for a while for a while, but it’s a pain to set up, there’s even a song about it youtu.be/SYRlTISvjww
What the fuck this is the best idea ever
In a weird way this makes Linux a microkernel. They’re “macro” but isolated and cooperative. Coolest patch set I’ve read about in a while.
That’s kind of hilarious. At first we had VMs to run entirely separate operating systems. Then we had Containers to separate everything except the kernel. And now we might get separation for just the kernel.
If I have a container with an isolated kernel, is it just a VM?
Well, there’s a separate technology stack for virtualization. So, it would be similar in effect, but the way you get there is different, and it’s possible that it performs better or worse for certain scenarios.
Ok now i just need a wrapper for it so that k8s can load to the side loaded kernel as a virtual(?) node.
Crazy cool to think we can load procs on tuned kernels on demand like that. You could also have an container runtime spec for it if you wanted a kernel per pod kind of deployment (more niche to me though).