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