On Tue, 2005-03-15 at 07:11 -0800, Tomislav Vujec wrote: > 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, Both of these would just say to the system whether or not they were busy. > screen sessions, ...). I guess a terminal would always just say it was busy and required user interaction. Maybe if you had good shell integration the shell could tell the terminal whether it was busy or not. > 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. Sure, it might not use dbus directly; but as we move forward it's almost certain it will indirectly depend on it, at least if the app has any value. > Now obviously, system restart > requirement simplifies the design, It's an engineering tradeoff. > but it opens the door to Windows like > behavior, where an app requires system restart just to e.g. update mime > db. Er, I'm certain Windows doesn't require a restart for that. Neither is anyone suggesting we should. > 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. You must have some kind of complicated setup to have a logout of X not interrupt your downloads. We can't do that in general. Anyways, we have this exact issue for the kernel today (and it is a frequently updated package), and so we need to have the infrastructure to support it. > 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. Sure; now try asking the authors of every other X application to do the same. Because that's what you need to do (*every* app needs to support it) in order to live-restart the X server. > 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. Yes, clearly we need better session management. > 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. No, but in laptop+suspend case TCP connections are often broken anyways, so apps need to be able to handle it. > Let me on the end play down my argument a bit. I like the apps like NM, > the main reason being - it just works. Amen! > 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. Once we fix the Fedora bug that restarts the system bus in the init scripts on upgrade, there is no problem. At least not one different from the one we already have (kernel and X server updates requiring restart too).
Attachment:
signature.asc
Description: This is a digitally signed message part