Re: DBus reconnect support (initial attempt)



On Tue, 2005-03-15 at 09:28 -0500, Colin Walters wrote:
> If you run a desktop system, you should include X and gdm in there.
> Neither are restarted automatically for security updates.  I'm sure
> there are others too that I'm not thinking of.
> 
> I would argue that there is really no fundamental difference between
> restarting X and restarting the system.  Sure, you have the output of
> 'uptime', but what you *really* care about is how long it takes you to
> get back into the desktop session and do work.  If we can make the
> system bootup fast enough (and Windows XP and MacOS X show it's
> possible), then restarting the whole system isn't a big deal.

No. What I care about is app & subsystem state. There are still a lot of
applications that hold some kind of state, and don't require restart
even if X and gdm are restarted. Any background applications (P2P file
sharing, servers, screen sessions, ...).

Obviously, if you upgrade something like glibc, almost everything will
have to get restarted. Now you can fully argue that dbus falls into the
same category, but the key here is in "almost". You actually can have an
app not using dbus and even glibc. Now obviously, system restart
requirement simplifies the design, but it opens the door to Windows like
behavior, where an app requires system restart just to e.g. update mime
db. 

Now, I completely agree that automatic restart in rpm scripts is
sometime evil, but I can always manually restart X and gdm to get the
upgrade functionality without affecting my network connection and my
downloads.

Famous "Worse is better" text written by Richard P. Gabriel describes
problems caused by exactly this kind of simplification. For examples
look at xemacs, it can survive restart of X, moving to other X servers,
etc.

I would go as far as to say that we should work on enabling apps to
survive the kernel restart instead of arguing on which applications
should be considered a part of basic infrastructure and therefore can
require restart.

> Not necessarily.  We could have a way for the system to ask the user
> sessions "do you have any unsaved data".  If they don't, and it's
> between 3am and 5am, and the user hasn't touched the computer in 3
> hours, we simply reboot.  Note that if apps are written correctly and
> preserve state otherwise (what documents were open, what web pages were
> being visited, what IM conversations were active, etc), then to the user
> there isn't a big difference.

The problem here is that app status also depends on different subsystem
and external system status. In the other words, can I keep my TCP
connections after the reboot.

> > I'll admit here that I am not deeply familiar with the dbus interface, but
> > why shouldn't be possible to reliably wait for d-bus to start again? 
> 
> In theory, it is possible.  Just like in theory, you could take the code
> from a new kernel update and attempt to overlay it into the running
> kernel, by writing custom upgrade code.

> The problem is it has to work 100% reliably, for every application, or
> you have lost any benefit from all of the work.  As soon as e.g. some
> app locks up and the user is unable to save their data (this actually
> happened to me when I upgraded dbus in Fedora, which screwed HAL, which
> then screwed gnome-vfs, which in turn screwed gedit), then we lose.
> Far, far better to require a reboot at the user's convenience for just a
> few packages and ensure we reliably preserve their data and running
> applications until they choose to reboot.


Let me on the end play down my argument a bit. I like the apps like NM,
the main reason being - it just works. I pull out the network cable, it
connects to wireless. I pull it in, it is back there. It handles
environmental situations gracefully. I hate evolution because it
doesn't. 

I am not trying to fanatically fight the reboot, I am just worried that
the lack of dbus reconnect support in the NM, would introduce different
situations which we cannot handle gracefully.

Best regards,
-- 
Tomislav Vujec
Manager, Client Development
Red Hat  Otto-Hahn-Straße 20  85609 München-Dornach
Tel +49 89 205071 212 Fax +49 89 205071 111 Cell. +49 172 623 1214

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]