With the move to more mobile devices (laptops, etc.), we're more likely to have very long-running sessions that are just suspended and resumed, as opposed to a workstation that is logged out every day.
This means that for me on rawhide, my session is often much longer-lived than my software set, as I'll have a two-week session that is running older code that I've long since upgraded past. Even for those on an actual release, this can be an issue given our update stream.
For system-level services, we have the idea of try-restart on upgrades; if the service is running, we automatically restart it on upgrade. How can we implement this sanely for session/desktop services? For example, in my session I see:
gvfsd obex-client/obex-data-server evolution-data-server packagekitd notification-daemon any number of status icons (volume control, gpk, g-p-m, etc.) ... and more I'm forgetting ...
Since very few of these have state, can't we implement a framework where they automatically get restarted on upgrade?
Bill
On Tue, Sep 29, 2009 at 8:12 PM, Bill Nottingham notting@redhat.com wrote:
With the move to more mobile devices (laptops, etc.), we're more likely to have very long-running sessions that are just suspended and resumed, as opposed to a workstation that is logged out every day.
This means that for me on rawhide, my session is often much longer-lived than my software set, as I'll have a two-week session that is running older code that I've long since upgraded past. Even for those on an actual release, this can be an issue given our update stream.
For system-level services, we have the idea of try-restart on upgrades; if the service is running, we automatically restart it on upgrade. How can we implement this sanely for session/desktop services? For example, in my session I see:
gvfsd
Wouldn't this affect current mounts?
On Tue, 2009-09-29 at 14:12 -0400, Bill Nottingham wrote:
With the move to more mobile devices (laptops, etc.), we're more likely to have very long-running sessions that are just suspended and resumed, as opposed to a workstation that is logged out every day.
This means that for me on rawhide, my session is often much longer-lived than my software set, as I'll have a two-week session that is running older code that I've long since upgraded past. Even for those on an actual release, this can be an issue given our update stream.
For system-level services, we have the idea of try-restart on upgrades; if the service is running, we automatically restart it on upgrade. How can we implement this sanely for session/desktop services? For example, in my session I see:
gvfsd obex-client/obex-data-server evolution-data-server packagekitd notification-daemon any number of status icons (volume control, gpk, g-p-m, etc.) ... and more I'm forgetting ...
Since very few of these have state, can't we implement a framework where they automatically get restarted on upgrade?
Brainstorming: perhaps when rpm updates/deletes a file it could look at what processes are mapping that file (in particular ELF files), and thus build a list for a transaction of all PIDs that now have stale data (e.g. using old versions of a .so file that now has a security fix in the new on-disk version).
No idea how to pass this information up through yum/PackageKit in a useful way though.
Hope this is helpful Dave
On Tue, 29 Sep 2009, David Malcolm wrote:
gvfsd obex-client/obex-data-server evolution-data-server packagekitd notification-daemon any number of status icons (volume control, gpk, g-p-m, etc.) ... and more I'm forgetting ...
Since very few of these have state, can't we implement a framework where they automatically get restarted on upgrade?
Brainstorming: perhaps when rpm updates/deletes a file it could look at what processes are mapping that file (in particular ELF files), and thus build a list for a transaction of all PIDs that now have stale data (e.g. using old versions of a .so file that now has a security fix in the new on-disk version).
No idea how to pass this information up through yum/PackageKit in a useful way though.
at the risk of getting myself in trouble - you don't have to do it at the rpm layer... You could do it in yum or in a yum plugin and then not have to worry about propagating it up the stack.
-sv
Seth Vidal (skvidal@fedoraproject.org) said:
at the risk of getting myself in trouble - you don't have to do it at the rpm layer... You could do it in yum or in a yum plugin and then not have to worry about propagating it up the stack.
The alternative is to have apps set inotify watches on their own binaries, I suppose. (There was something in Fedora that used to do this.)
Bill
On Tue, 29 Sep 2009, Bill Nottingham wrote:
Seth Vidal (skvidal@fedoraproject.org) said:
at the risk of getting myself in trouble - you don't have to do it at the rpm layer... You could do it in yum or in a yum plugin and then not have to worry about propagating it up the stack.
The alternative is to have apps set inotify watches on their own binaries, I suppose. (There was something in Fedora that used to do this.)
wow, that would be, umm, special.
How well does inotify cope with THOUSANDS of watches?
-sv
On Tue, Sep 29, 2009 at 8:44 PM, Seth Vidal skvidal@fedoraproject.org wrote:
On Tue, 29 Sep 2009, Bill Nottingham wrote:
Seth Vidal (skvidal@fedoraproject.org) said:
at the risk of getting myself in trouble - you don't have to do it at the rpm layer... You could do it in yum or in a yum plugin and then not have to worry about propagating it up the stack.
The alternative is to have apps set inotify watches on their own binaries, I suppose. (There was something in Fedora that used to do this.)
wow, that would be, umm, special.
How well does inotify cope with THOUSANDS of watches?
There is a 8k limit for non root users, besides that sounds racy (what if the binary changed but some lib is still not updated and the soname got bumped?) so it will restart itself while the upgrade process is still running an fail.
tis 2009-09-29 klockan 20:46 +0200 skrev drago01:
There is a 8k limit for non root users, besides that sounds racy (what if the binary changed but some lib is still not updated and the soname got bumped?) so it will restart itself while the upgrade process is still running an fail.
Hmm, true.
When rpm is done with a transaction, it provides a list of files it modified. The next step is to send a signal to all processes that has any of those files open and has indicated that it is capable of dealing with such signals, so that the process can take appropriate action. That should catch the binary and all loaded libraries. Should be enough, right?
Maybe DBus is the right way to broadcast that list of files? Either send the whole list to all recipients that asks for it or filter it for each process based on its open files.
In the case of shared roots, you want to do this on each machine that has this filesystem mounted. Can't it just be a program that takes a list of paths on stdin and broadcasts it? Normally run directly by rpm or yum but in some cases triggered by other means, like manually when the sysadmin released an update to the shared root?
/abo
On Tue, Sep 29, 2009 at 6:12 PM, Bill Nottingham notting@redhat.com wrote:
This means that for me on rawhide, my session is often much longer-lived than my software set, as I'll have a two-week session that is running older code that I've long since upgraded past. Even for those on an actual release, this can be an issue given our update stream.
Note we should optimize the system for the main release, not rawhide. Not that a good rawhide experience isn't useful, but it's a rather extreme case.
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade.
How does that work? Obviously you can't restart packagekitd while it's in the middle of upgrading. Another one you obviously can't just kill and restart is libvirtd.
How can we implement this sanely for session/desktop services? For example, in my session I see:
I think this ends up being a case by case thing. If someone wants to implement things so that a live upgrade works, that's all well and good. The default state though must be reliable; so any generic mechanism that kills processes blindly is just not going to work.
If someone wanted to work on this, packagekit may already have a signal for when things are upgraded, and it could make sense to just listen to that.
The live replace files on disk part of upgrade is also problematic, and is actually the most broken thing relating to updates we have right now. For this reason among others I think we should move to installing updates immediately before logout/reboot.
Colin Walters (walters@verbum.org) said:
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade.
How does that work? Obviously you can't restart packagekitd while it's in the middle of upgrading. Another one you obviously can't just kill and restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the init scripts.
The live replace files on disk part of upgrade is also problematic, and is actually the most broken thing relating to updates we have right now. For this reason among others I think we should move to installing updates immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where there *is* no logout/reboot except by accident in a large number of cases.
Bill
On Tue, 29 Sep 2009 14:51:29 -0400, Bill Nottingham notting@redhat.com wrote:
Really? I think we're moving more towards a model on mobile devices where there *is* no logout/reboot except by accident in a large number of
cases.
I think the mobility argument is a very valid one, but it isn't truly specific to mobile devices. I log out/log back in on my desktop or laptop about as much as my phone runs out of juice, sorta speak (unless I forget my phone in Rheinfelden, that is).
What we have to remember is the type of security issue you would want to require a reboot/restart for. If it's a memory leak, for instance, then hey all of a sudden my device isn't going to work the way I want it. I'll restart the application myself, or reboot my device. Either one is pretty much intuitive to a no-know, including my girlfriend (in fact it's the first thing she does and *then* she calls me her PC was sooooo slow, and she's glad a reboot solved the problem *sigh*).
If it's a majorly important "you-are-going-to-be-hacked-standing-too-close-to-starfucks" type of security issue, then hey... your call drops, your application restarts, and maybe you lose a session where you had this amazing one-liner with all kinds of ifs and fors and whiles and awks and seds. There's a price either way for these kinds of bugs, right?
-- Jeroen
On Tue, Sep 29, 2009 at 6:51 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
For system-level services, we have the idea of try-restart on upgrades;
if
the service is running, we automatically restart it on upgrade.
How does that work? Obviously you can't restart packagekitd while it's
in
the middle of upgrading. Another one you obviously can't just kill and restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the init scripts.
But...hm, ok, so all of the state is in the config data/cache, and child qemu processes I guess. The real point here is the qemu processes.
The live replace files on disk part of upgrade is also problematic, and is
actually the most broken thing relating to updates we have right now.
For
this reason among others I think we should move to installing updates immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where there *is* no logout/reboot except by accident in a large number of cases.
The update system should prompt to start installing updates and automatically do a logout/reboot as necessary.
On Tue, 29 Sep 2009, Colin Walters wrote:
On Tue, Sep 29, 2009 at 6:51 PM, Bill Nottingham notting@redhat.com wrote: Colin Walters (walters@verbum.org) said: > For system-level services, we have the idea of try-restart on upgrades; if > > the service is running, we automatically restart it on upgrade. > > > How does that work? Obviously you can't restart packagekitd while it's in > the middle of upgrading. Another one you obviously can't just kill and > restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the init scripts.
But...hm, ok, so all of the state is in the config data/cache, and child qemu processes I guess. The real point here is the qemu processes.
> The live replace files on disk part of upgrade is also problematic, and is > actually the most broken thing relating to updates we have right now. For > this reason among others I think we should move to installing updates > immediately before logout/reboot.Really? I think we're moving more towards a model on mobile devices where there *is* no logout/reboot except by accident in a large number of cases.
The update system should prompt to start installing updates and automatically do a logout/reboot as necessary.
And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the app in question, if they are told which apps are impacted.
I don't expect to have to reboot just b/c of an issue in the sound server. -sv
On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal skvidal@fedoraproject.orgwrote:
And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the app in question, if they are told which apps are impacted.
This is what I meant in saying it's case by case, not something where one policy applies to all software. If you just updated Firefox, then yes, we can and should have a system which knows how to restart just that application.
The discussion started about infrastructure bits, like:
I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin. Well, you can choose not to of course, but the point of an update is to actually update what's running on people's computers. If the system doesn't reliably get us there it's not working..
On Tue, 29 Sep 2009, Colin Walters wrote:
On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal skvidal@fedoraproject.org wrote:
And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the app in question, if they are told which apps are impacted.
This is what I meant in saying it's case by case, not something where one policy applies to all software. If you just updated Firefox, then yes, we can and should have a system which knows how to restart just that application.
The discussion started about infrastructure bits, like: I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin. Well, you can choose not to of course, but the point of an update is to actually update what's running on people's computers. If the system doesn't reliably get us there it's not working..
So what was suggested by dmalcolm was tracking down which programs in use are being updated/changed and telling the user 'this application that is currently in use by [userid] needs to be restarted to take advantage of this update'.
I was suggesting we could get that info in yum and make it available.
-sv
On Tue, Sep 29, 2009 at 7:32 PM, Seth Vidal skvidal@fedoraproject.orgwrote:
So what was suggested by dmalcolm was tracking down which programs in use are being updated/changed and telling the user 'this application that is currently in use by [userid] needs to be restarted to take advantage of this update'.
By program do you mean package, or .desktop file? There's a big difference, in that we expect all desktop users to know roughly what the things are named by .desktop, but if we have a UI with packages it's going to contain incomprehensible stuff (what is gvfs? what is pulseaudio? What is...). All of this should basically all be grouped under "Operating System" with a "Details |>" expander to see the packages for power users.
We could probably implement generic application restart using http://live.gnome.org/GnomeShell/ApplicationBased by sending a close event to the app's windows. It wouldn't be awful to backport this to GNOME 2.
But there's just no way you can have some generic system for the infrastructure, and we need the logout/reboot system for that.
On Tue, 2009-09-29 at 15:32 -0400, Seth Vidal wrote:
On Tue, 29 Sep 2009, Colin Walters wrote:
On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal skvidal@fedoraproject.org wrote:
And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the app in question, if they are told which apps are impacted.
This is what I meant in saying it's case by case, not something where one policy applies to all software. If you just updated Firefox, then yes, we can and should have a system which knows how to restart just that application.
The discussion started about infrastructure bits, like:
I don't expect to have to reboot just b/c of an issue in the sound server.Not reboot for this one but relogin. Well, you can choose not to of course, but the point of an update is to actually update what's running on people's computers. If the system doesn't reliably get us there it's not working..
So what was suggested by dmalcolm was tracking down which programs in use are being updated/changed and telling the user 'this application that is currently in use by [userid] needs to be restarted to take advantage of this update'.
I was suggesting we could get that info in yum and make it available.
My thought was to do it at the level of ELF files i.e. both binaries and the libraries consuming them. That way, if e.g. there's a libldap update, you know which PIDs are still mapping the old implementation of that file on disk.
FWIW, here's some python code that tells you files per PID and PIDs per file; this code also spots e.g. .mo files, shared fontconfig caches, etc:
import os import re from pprint import pprint
pids_per_file = {}
print "Files per PID:" for pid in os.listdir('/proc'): if re.match('([0-9]+)', pid): pid = int(pid) files = set() for line in open(os.path.join('/proc', str(pid), 'maps')): # Expect lines of the form: # '00101000-0023e000 r-xp 00000000 fd:00 1835017 /lib/libc-2.5.so' fields = line.split() if len(fields) > 5: file = fields[5] if file.startswith('/'): files.add(file) if file in pids_per_file: pids_per_file[file].append(pid) else: pids_per_file[file] = [pid] print pid, files
print print "PIDS per file:" pprint(pids_per_file)
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams are idle, could it not?
The apps would have to reconnect to pa.
On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams are idle, could it not?
The apps would have to reconnect to pa.
Which they manage to do every time I have to killall -9 pulseaudio when it gets wedged. Seems like we already have support for pulse going away and coming back.
On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams are idle, could it not?
The apps would have to reconnect to pa.
Which they manage to do every time I have to killall -9 pulseaudio when it gets wedged. Seems like we already have support for pulse going away and coming back.
well the volume-applet in F11 sure does not do that which is annoying as hell (fixed in F12 though).
On Tue, 2009-09-29 at 22:46 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams are idle, could it not?
The apps would have to reconnect to pa.
Which they manage to do every time I have to killall -9 pulseaudio when it gets wedged. Seems like we already have support for pulse going away and coming back.
well the volume-applet in F11 sure does not do that which is annoying as hell (fixed in F12 though).
It's also fixed in F-11, seeing as it ships the same version as F-12...
On Wed, 2009-09-30 at 15:47 +0100, Bastien Nocera wrote:
On Tue, 2009-09-29 at 22:46 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote:
On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
> I don't expect to have to reboot just b/c of an issue in the sound server.
Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams are idle, could it not?
The apps would have to reconnect to pa.
Which they manage to do every time I have to killall -9 pulseaudio when it gets wedged. Seems like we already have support for pulse going away and coming back.
well the volume-applet in F11 sure does not do that which is annoying as hell (fixed in F12 though).
It's also fixed in F-11, seeing as it ships the same version as F-12...
It certainly wasn't for me a couple weeks ago before I upgraded to F12.
Zack
On Tue, Sep 29, 2009 at 7:46 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
I don't expect to have to reboot just b/c of an issue in the sound
server.
Not reboot for this one but relogin.
How so? PA could in theory restart itself at some point when all streams are idle, could it not?
Sure. Though how long do you wait? Is it conditional on update urgency? And pulse has a similar problem in that the stream source identification needs the same infrastructure we're doing for the shell, so it could tell you what applications are using it.
This is highly specific to pulse, which gets back to my point: If someone wants to work on case-by-case for individual daemons I think that's great. However, it's not a substitute for a default-reliable update system.
Hey Bill,
On Tue, Sep 29, 2009 at 2:51 PM, Bill Nottingham notting@redhat.com wrote:
Colin Walters (walters@verbum.org) said:
For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade.
How does that work? Obviously you can't restart packagekitd while it's in the middle of upgrading. Another one you obviously can't just kill and restart is libvirtd.
Actually, libvirtd does restart on upgrade. It's implemented in the init scripts.
The live replace files on disk part of upgrade is also problematic, and is actually the most broken thing relating to updates we have right now. For this reason among others I think we should move to installing updates immediately before logout/reboot.
Really? I think we're moving more towards a model on mobile devices where there *is* no logout/reboot except by accident in a large number of cases.
Yes and no. My (linux based) phone, for example, reboots automatically as part of the update process. However, the OS update is bundled and occurs, so far, only once a month.
Personally, I've been advocating for our next generation update system to do something similar.
Jon
On Tue, Sep 29, 2009 at 8:46 PM, Colin Walters walters@verbum.org wrote:
The live replace files on disk part of upgrade is also problematic, and is actually the most broken thing relating to updates we have right now. For this reason among others I think we should move to installing updates immediately before logout/reboot.
We could just do:
1) switch to brtfs 2) have a separte /home by default
When updating: 1) create a snapshot of / 2) mount it 3) update stuff there 4) prompt for reboot 5) on reboot switch to the new snapshot
We could even keep the last one for rollback reasons.
On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote:
For this reason among others I think we should move to installing updates immediately before logout/reboot.
Completely agree. FWIW, this is what most mobile "computers" such as the iPhone and Android does. And, for the record, how OS X works too (unless the only update is for an application like iTunes). They can of course do this because they don't issue updates almost _every day_ (or what feels like every day, anyway) like we do in Fedora.
So I segwayed nicely into this: I think another huge (and, I think, well-known too) problem, which is related to this, is that we issue updates way too often. A cause and/or effect of this is that our updates (and main release) aren't really well-tested, at least not in my experience. Another problem is that we're very militant in Fedora and other distros with dynamic linking - while this sounds great on paper (especially in 1990 when RAM was scarce), it does mean that if you update a shared library you end up breaking many applications. There are other downsides too, e.g. app folders. So it puts even more load on QA that we don't really have.
Sorry if what I said sounds ranty and insulting to the Fedora community. If it did, I didn't mean it. But I really really think that "how can we make daemons survive lots of updates?" is the wrong question. The right question, IMO, is "how can we ship software that doesn't need many updates?". Which, of course, is harder to solve (the solution may include a longer, more realistic release-cycle). But solving it brings other benefits too.
These are tough questions. Not flamebait. Thanks.
David
On Tue, 29 Sep 2009 15:20:01 -0400, David Zeuthen davidz@redhat.com wrote:
On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote:
For this reason among others I think we should move to installing updates immediately before logout/reboot.
Completely agree. FWIW, this is what most mobile "computers" such as the iPhone and Android does. And, for the record, how OS X works too (unless the only update is for an application like iTunes). They can of course do this because they don't issue updates almost _every day_ (or what feels like every day, anyway) like we do in Fedora.
The major difference obviously being, that OS X is not a version of rawhide with a release number attached to it. It is more like, dare I say it, RHEL (in that aspect).
The ultimate problem though is not the number of updates. One can cron a yum -y update every 5 minutes without it (euh, the updates being applied) interrupting (m)any of the services or applications running on the system (as long as they are running, that is).
The ultimate challenge is; how, if at all, can we make sure a running daemon picks up the new blobs so that we can seamlessly update/upgrade, especially with regards to "i'm in ur board eating your keez" security issues.
Making the release cycle longer (including the development cycle) works two ways;
1) you have more time to perform QA 2) everytime you perform QA the amount of changes is going to be bigger (53 features in 6 months anyone?)
Also, the militant attitude of Fedora against static linking works two ways;
1) my blob runs on its own 1a) ignoring updates (security fixes anyone?) to the statically linked other blobs. Weeeee! 1b) putting the load on all packagers of blobs depending on blob, and/or vice-versa 2) my blob runs with the help of other blobs
And, to not continue on why it would be bad, how much RAM does your Android have? Your iPhone? Your HTC X7500? Your HTC Touch? Is it... scarse?
Still though, the interesting question is how we can ship software that doesn't need as many updates... like you said ;-)
-- Jeroen
tis 2009-09-29 klockan 21:57 +0200 skrev Jeroen van Meeuwen:
And, to not continue on why it would be bad, how much RAM does your Android have? Your iPhone? Your HTC X7500? Your HTC Touch? Is it... scarse?
It is definitely scarce on my N810.
I don't understand why dynamic linking is a problem in this context, if that's what you're saying.
/abo
On Tue, 2009-09-29 at 23:19 +0200, Alexander Boström wrote:
I don't understand why dynamic linking is a problem in this context, if that's what you're saying.
It is not a problem per se, but it a major source of our deeply nested dependencies graphs, which make updating, installing and removing applications harder than it would be with, say, an appfolder-like approach. Of course, that has its own downsides...
On Tue, 2009-09-29 at 15:20 -0400, David Zeuthen wrote:
On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote:
For this reason among others I think we should move to installing updates immediately before logout/reboot.
Completely agree. FWIW, this is what most mobile "computers" such as the iPhone and Android does. And, for the record, how OS X works too (unless the only update is for an application like iTunes). They can of course do this because they don't issue updates almost _every day_ (or what feels like every day, anyway) like we do in Fedora.
One of the things Those Other OSes do is to batch updates into larger Service Pack / point-release updates, and only offer the individual pieces as "hotfixes" to those who really, really need (or want) them.
If we were just trying to improve the *perception* that there's too many updates (and they're not that useful), the simplest solution would be to batch updates and release them as point-release updates along with release notes and an appropriate amount of fanfare about new features and fixes.
A cause and/or effect of this is that our updates (and main release) aren't really well-tested, at least not in my experience.
Well, batching updates would also mean that they'd spend more *required* time in the testing repository. Which is a necessary step to get better manual QA on updates. It's not sufficient to guarantee better QA - "spends time in the testing repo" does not necessarily imply "has been tested" - but it can't really hurt.
Furthermore, while it's obvious simpler to test a single package than a whole load of 250 packages, it's *much* easier to test one large update payload than each possible combination of 250 individual updates.
[snip]
So it puts even more load on QA that we don't really have.
Sorry if what I said sounds ranty and insulting to the Fedora community. If it did, I didn't mean it. But I really really think that "how can we make daemons survive lots of updates?" is the wrong question. The right question, IMO, is "how can we ship software that doesn't need many updates?". Which, of course, is harder to solve (the solution may include a longer, more realistic release-cycle). But solving it brings other benefits too.
No, I totally agree - making the daemons survive updates better is probably not the most pressing problem with the Fedora update system.
On the other hand, it's a problem that can be solved with code rather than needing long bikesheddy discussions and policy arguments. And I think we all know that, as a group, we're way better with code than talk.
Still, I think it's worth trying to get some *data* about what the *actual* problems are with the update system and see if we can't have some good, productive discussions that lead to actual positive change.
So, uh, let's.. just.. go ahead and do that, then.
-w
2009/9/29 Bill Nottingham notting@redhat.com:
packagekitd
packagekitd and gpk-update-icon already restart themselves in a sane way when the binary changes.
Richard.
desktop@lists.fedoraproject.org
-
Alexander Boström -
Bastien Nocera -
Bill Nottingham -
Colin Walters -
David Malcolm -
David Zeuthen -
drago01 -
Jeroen van Meeuwen -
Jesse Keating -
Matthias Clasen -
Richard Hughes -
Seth Vidal -
Will Woods -
William Jon McCann -
Zack Cerza