[Desktop_architects] Shouldn't distros and ISVs ensure that security updates get deployed promptly?
Tim Bray
Tim.Bray at Sun.COM
Wed Feb 4 09:53:02 PST 2009
On Feb 4, 2009, at 9:28 AM, Dan Kegel wrote:
> Yes. Looking at this from a public health perspective,
> the goal is to keep reducing Linux's attackable cross-section.
> For now, it's probably ok if we let long-running instances of the
> old version of e.g. Konqueror keep running after the update,
> since most people do restart anyway after a day or two.
>
> Next year, who knows? Maybe suspend will be so good that nobody
> logs out normally, at which point the dialogs saying "please log out
> and log back in" might have to become more insistent.
Some points of information from the mac world which may be relevant:
Speaking of never logging out:
~/ 799> uptime
9:41 up 27 days, 20:32, 4 users, load averages: 0.47 0.48 0.52
This laptop goes back and forth to the office with me all the time,
and has been to California and back in those 27 days. I'm assuming
this kind of uptime will become typical on laptop Linux as suspend/
resume becomes more robust. (When this happens and video output
switching starts to Just Work, I'll switch off the Mac).
On the other hand, the mac browsers now all remember their tabs. So
killing them and restarting is no big deal. (Well, they forget where
the back button pointed).
Generally speaking the mac apps do a reasonable job on this. Most of
them remind you when there's an update. The good ones know about the
long-uptimes and don't wait for a restart to remind you, they just
check every so often.
Every user I know makes a judgment call. E.g. I'll update Adium (aka
pidgin) whenever it asks, but I never install Apple updates without
waiting a few days to let others be the guinea pigs. Apple stupidly
requires reboots for trivial updates, so theirs tend to wait longest.
Dan, I think Linus is right: there are going to be *very* few IT shops
where they'll let software providers do silent mandatory update. It's
a rare enough case that it hardly seems worthwhile building the
machinery to support.
-T
More information about the Desktop_architects
mailing list