but that's where it becomes more serious: when basic functions of the system fail, silently. when you can't even reboot without a terminal, because the reboot dialog crashes

as more and more official things can/need to be done online, it will only get to be a bigger risk. I don't think it's low even today.

Usually you would only need to reboot if you want to use the new kernel right away after an update.

and the new version of all the software that is still running with the old version.

For most of the programs, you don't even need to restart them if they're already running.

~~how? won't they keep being the old version?~~

However, if you restart them they will run as the newer updated version.

oh, yeah, we agree on that. but my point is that in my experience, a lot of software gets very confused if some libs it would use or resource files have changed after they were started. often that's also the reason why holding back a package's version makes trouble over time (because certain other packages can't be updated either), or same with using custom repos that have a different release schedule or maybe are not even in sync with your distro

rest assured, the 300 MB common social network apps with ever increasing storage and memory usage and decreasing functionality won't be marked appropriately

But an adversary could easily use a bad usb when they have physical access to the computer and glitter nail polish doesn't detect that. I guess that this is why nail polish isn't sufficient on its own and why we need also either trenchboor or Heads.

it would be interesting to know how much does usbguard protect against this. of course you also need to do something to limit booting from usb, but how effective is usbguard in practice?
what is the risk of sticks that tries to compromise the machine through kernel driver vulnerabilities?
is it possible that it compromises some other firmware on the machine (like the EC in laptops)?
or that it takes advantage of some hardware design failure?

Personally I've only heard about Heads so far, but I think this is an interesting topic. Could you give us a short explanation about why is SRTM not enough, and what is a better way?

Timeshift is explicitly designed to do that easily and automatically

by consuming much more space. but you're right, I did not think about it

Backup before upgrade is a weird thing to cram into a file system.

I agree, but these are not really backups, but snapshots, which are stored more efficiently, without duplicating data. of course it does not replace an off site backup, but I think it has its use cases.

Not completely but kind of, all those poweroff, reboot etc. tied to systemd, though I believe this is mostly related to polkit run out of time.

that's right, but as I remember the error was talking about being unable to launch that KDE-specufic countdown overlay. journalctl has shown such an error for every time I tried to stop the session in any of the ways.

Normally updates don't change a thing on Linux since the system runs on RAM.

that's not how I understand the system is working. could you elaborate?

I've learned this lesson with my Android phone a few years ago. There it was actually about sqlite databases of a system app (contacts I think?), but this can happen with other formats too. Worst is if it doesn't just error out, but tries to work with "garbage", because it'll possibly take much more time to debug it, or even realize that your data is corrupt.

will that also restore your data? what happens when a program updates its database structure with the update, and the old version you restore won't understand it anymore?

Maybe you have random powerloss?

who doesn't? even if rarely, but it just happens

being able to revert a failed upgrade by restoring a snapshot is not a power user need but a very basic feature for everyday users who do not want to debug every little problem that can go wrong, but just want to use their computer.

ext4 does not allow that.

we need to consume the rich. There's no other way