On Fri, May 30, 2008 at 5:06 PM, Alan Cox <<a href="mailto:alan@redhat.com">alan@redhat.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
And what I would really expect is<br>
<br>
- icons for dbus dependant things are overlaid with a "?" logo<br>
- maybe a single dialogue (with a 'don't show me again')<br>
- my desktop to reconnect to dbus and recover its state politely<br>
without any restarts by me.</blockquote><div><br>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. <br>
<br>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?<br><br>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 Windows? <br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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*. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bad example too - making init restart is on the kernel todo list and there<br>
are some test patches for this floating around.</blockquote><div><br>Ok, let's say that restarting the system bus is on our todo list too. =)<br><br></div></div>