On Fri, May 30, 2008 at 5:06 PM, Alan Cox <alan(a)redhat.com> wrote:
And what I would really expect is
- icons for dbus dependant things are overlaid with a "?" logo
- maybe a single dialogue (with a 'don't show me again')
- my desktop to reconnect to dbus and recover its state politely
without any restarts by me.
Do you have any idea how much custom code that is, when multiplied by all
services and all programs that use them? And remember, this is all code
that will *almost never be called*. It will not be tested very well.
In fact, I would argue such special recovery code is far more likely to
actually *introduce* problems. For example, will it handle the case where
I'm currently dragging a file from a USB key?
Look; with respect to the desktop and upgrades, we have far larger problems
in Fedora than the system bus. Do you realize that currently in Fedora, we
actually have a *worse* experience upgrading Firefox than compared to
Why is that? Our upgrade process is currently defined just as "untar and
run some shell scripts". What do we do about the running Firefox?
Nothing. No notification. You have to know to hunt and close all the
windows and then click the icon again. Actually the fact that we replace
all the old files means the currently running one breaks in subtle ways; for
example, if you notice the Ctrl-f dialog won't work after an upgrade because
it's trying to load a file from disk that isn't there anymore.
For sure Firefox's versioned structure exacerbates this problem, but it's by
no means limited to Firefox. In general *any* program that opens a file
that it expects to be there in the currently running version but is not in
the new one will break.
How do you solve that? You don't. We need to require a logout and log back
in. Possibly could be more clever about scanning executables in of the RPM
and linking those to running processes, and then linking the processes to X
windows and pulsing them or something but...yeah.
Remember for the desktop use case we do not have a Unix administrator
sitting there with a root shell who knows the details of how the operating
system works. For our users it simply *cannot fail*.
Bad example too - making init restart is on the kernel todo list and there
are some test patches for this floating around.
Ok, let's say that restarting the system bus is on our todo list too. =)