Le dimanche 03 novembre 2013 à 14:23 +0100, Kevin Kofler a écrit :
Michael Scherer wrote:
> When statistics cost you money, yeah, I think that's important to take
> them in account. Maybe your employer do not care about this, but I
> strongly suspect mine does, and I strongly suspect that most companies
> do care about this as well.
Company computers should get updated only by the sysadmins (which AFAIK is
how it works at his company, him being the CTO, sysadmin and lead developer
in one person), or by automated scripts running as root (which is how it's
done at my university, there's an autoupdate script running at bootup).
Users have no business updating company-managed computers.
You would delighted to know that not everybody do like this. We prefer
let the employees decide when the time to update is right, due for
exemple factor like "having to leave the office soon", or "being at a
customers site without much network connectivity", etc, etc.
As i say, we mostly have a fleet of laptop, and of course, the situation
would be different if this was a set of workstation, but alas, this is
not the case.
> Not to mention that basically, what you suggest is that the
> bypass users explicit requests to shutdown, and that doesn't sound like
> a improvement to me ( and again, I say that also because that's what we
> tried at work, and this didn't work that well ).
Yet this is exactly how PackageKit deals with this for online updates.
Then I think this must be changed. And in fact, that's maybe why this is
> However, since you didn't explained at all what are the
issues you are
> facing with the new approach, and since you have only explained how you
> are doing on your 20 servers ( which is totally unrelated to the
> question of desktops, BTW, and which would still be usable at your
> convenience on anything you maintain ), I am quite sceptic on your whole
The issues are that:
* updates require 2 reboots,
as long as this is automated, this is a technical detail. People seeing
2 times the bios do not really matter. Granted, this is annoying to have
to enter your encryption password twice if you use luks, but I wonder if
kexec cannot help on that part.
* you cannot use what you upgraded before doing the reboots,
and so ? If the upgrade is the reboot, this is to be expected.
AFAIK, the update is not applied until you reboot, and AFAIK, you can
still do stuff by yourself using yum. So if your point is "you cannot
use the update before the update is applied", I have yet to find what
you mean exactly.
* in particular, you cannot install new packages built against the
ones before the reboots,
Then this mean there is a problem in dependency. If I install kevin-
simulator-1.0 that requires libmichael1.1 while libmichael1.0 is
installed, either it need it and it will pull it, or it doesn't need and
it will not pull it. This also ask the whole question of having non
compatible library, etc, but I think we already answered that question
with the update policy and need to keep a proper compatible ABI.
* security fixes also only take effect after the reboots.
unlike now, where they take effect based on random factors such as "was
firefox already running", or "did I logged out after the update", or
"did I reboot on the new kernel" ?
At least, the new system bring coherency, you know that everything is up
to date after the reboot. And again, if you like the previous way, you
can still opt-out of the system.
It also violates the principle of least surprise.
In what way ? If the system clearly say "we are gonna need to reboot to
apply thoses updates", it is hard to say that you are surprised. And the
principe of least surprise would be violated if we didn't followed the
dominant paradigm, which is still windows afaik.