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 system > > 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 currently changed. > > 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 > > intervention. > > 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 updated > 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. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
