But do you? You really only need to restart the processes using those packages. Technically, a kernel update (specifically security update, bug fixes may not be important) would only require a reboot.
However, I've often been in situations where I reboot anyhow, because rebooting means I'm 100% confident the old code is gone, whereas if I try to get clever and avoid the restart, I'm significantly less confident. Depending on how hard it is to validate the security bug, that can be a problem.
Plus, for much of the past 20 years for many computers, if you're going to restart all services, adding in the last step for rebooting doesn't add all that significantly to the downtime. Server-class hardware often have things that make that not true (stupid RAID cards), but for everything else you were often only adding, say, 25% for the actual reboot.
You don't need to be 100% confident the old code is gone - just 100% confident the old code is no longer exposed to the network - check your sockstat/netstat and call it a day.
It gets complicated when central libraries like glibc have to be updated.
I did this once with checkrestart on Debian Wheezy and I had to restart nearly everything except for the init process.
So in this case just restarting the system would have been faster and easier.
For lots of core stuff, you don't technically need to reboot, but you probably do need to go down to single user mode and come back up (consider upgrading glibc or openssl), and at that point you might as well reboot.
There actually might be a difference in favor of LP. LastPass knows, semantically, what encrypted password archives are, and can monitor for statistically unusual traffic related to an attacker downloading them.
Google has no no way to know, if 10k people are storing their encrypted keepassx archives in gdrive, and if those 10k archives are accessed in rapid succession, that it's an attack. It's lost in the noise of gdrive traffic.
That blade cuts both ways: the keepassx archives would be lost in the noise of all the other files on Google Drive/Dropbox/etc. On Lastpass, you know you're getting password archives. To me: advantage KeePass.
It depends on your threat model. If you are more afraid of the government than of a random script kiddie, the vastly bigger resources of Google do not matter as your (encrypted) database is just a NSL away.
And then the NSA is trying to crack it </tinfoil hat mode>
Well if I put on my tinfoil hat, then there is no protection from the NSA. So, now I'm only trying to protect my password/identity from criminal elements, I tend to side with Google as knowing what they are doing. It doesn't mean they will also be mistake free, but it is something they deal with and have been dealing with before LastPass was even an idea.
The point of using a locally-encrypted password database like KeePass is that you don't have to trust Google (or DropBox, or Microsoft). You trust the encryption instead.
While I understand what you're implying, you need to realize people depend on these devices. If they didn't exist, yes, people would find other ways (as they have in the past).
I find myself very good at picking up small examples of code. I think the real challenge in programming isn't learning how if statements, loops, arrays, etc. work but how to put them together to do what you want. This is the real challenge and I believe this is a combination of self-teaching (maybe experiences) and natural ability.
