[pjc50]

> What I expect it also means is that you'll get inconsistencies when doing inter-process communication, since they'll be using different libraries with potential mismatches.

In theory, but Linux systems tend to do very little IPC other than X11, pipelines, and IP-based communication, where the protocols tend to support running with different versions.

In practice you can achieve multi-year uptimes with systems until you get a mandatory kernel security update.

[majewsky]

How can you ave a multi-year uptime unless you willfully ignore kernel security updates? In this day and age, year-long uptimes are an anti-pattern (if only because you cannot be sure whether your services are actually reboot-safe).

[jschwartzi]

It's easy. You gather information about what the risks and hazards are for each vulnerability and then pragmatically decide whether there are any unacceptable risks after you mitigate with other layers of security.

It's a really common engineering task to do this and I'm not at all surprised that someone trying to maintain uptime would do so. Honestly it's more mature than updating every time because each change also introduces more potential for regression. If your goal is to run a stable system you want to avoid this unless the risk is outweighed.

[ams6110]

But with "yum check-update" or the equivalent apt-get incantation saying you have dozens of security updates every week or two, reading the release notes for all of them and deciding which ones can be skipped safely in your environment is too much work. Far easier to just apply all updates every two weeks or monthly or whatever your schedule is, and then reboot.

[tluyben2]

Fully agree here; a lot (most?) of patches and updates are simply not exploitable in the respective server use case, so why should I incur risk of downtime to apply it?

[cat199]

you willfully ignore kernel security updates.

If my system is closed to the public world, has a tiny amount of external services, and I am aware of the specific bug delta since system release and what mitigations may or may not be required, I can leave it running as long as I choose to accept the risk. Cute phrases like 'pattern' and 'anti-pattern' are rules of thumb, not absolute truths.

[bri3d]

Ksplice or KernelCare

[rkeene2]

Kernel Live Patching (KLP) has been in mainline since 4.4. I've used it to patch various flaws in my Linux distribution since rebooting the running cluster is more tedious.

[Valmar]

kexec?

[AnIdiotOnTheNet]

kexec doesn't keep your services running, it just allows the kernel to act as a bootloader for another kernel.

[mehrdadn]

X11 (or other window-related tooling) was exactly what I was thinking of actually, because every time I do a major Linux (Ubuntu) update I can't really launch programs and use my computer normally until I reboot. It always gets finicky and IPC mismatch is the best explanation I can think of.

[gnfurlong]

Are you sure this isn't more the Desktop Environment/Display Manager than X11? Or otherwise something to to with your use case?

I've primarily been using AwesomeWM for the last few years and occasionally XFCE (both on ArchLinux) and I cant recall ever experiencing what you describe.

[rleigh]

That's D-BUS being a terribly specified and poorly implemented mess. Everything underneath should be solid.

[mehrdadn]

I mean, OK, but if Windows's GUI (or PowerShell, or whatever) crashed or misbehaved upon update, would you be satisfied with "that's win32k/DWM/whatever being a poorly implemented mess; everything underneath should be solid"?

[rleigh]

No. D-BUS is a travesty and blight upon the Linux desktop, and with systemd, every Linux system. It's the most fragile and nasty IPC system I've encountered. There are several better alternatives implemented by competent people, so there's really no excuse for its many defects.

[andrewshadura]

Roger, I think we both know D-Bus has been rock stable at for the last 7 years, or possibly more, and Simon McVittie, its current maintainer, is a highly skilled and competent engineer.

While I find the situation different with systemd maintainers, whose communication style used to be questionable too often, and their software had some nasty bugs, I must admit that despite those problems they've also built software, which is nevertheless reliable, even though it took them a lot of time to come there.

This, honestly, is the most disappointing statement I read from you in the recent couple of years. And I'm saying this as a person who used to respect you a lot. I find your lack of respect together with the willingness to spread lies like this quite appalling.