At Fri, 28 Apr 2006 00:34:57 +0200, Pierre THIERRY <[EMAIL PROTECTED]> wrote: > It would make the interface more complex, but the life of the user > easier. Only the average computer-savvy knows how to kill a process from > outside the application that spawned it, either in the shell or with > some WM dialog. > > A menu that would have 'kill the X plugin', and/or maybe a watchdog that > barks at the user when something goes wrong, would definitely help the > user keeping its environment in a safe and working state with autonomy.
I don't see a problem with providing users a process tree and the option attempt to kill parts of the tree, including leaf-nodes. The only problem is if your jobs are not cooperating: If the browser has been compromised and refuses to kill the plugin for example. In that case, the only option you have is to go up in the process hierarchy and kill parent jobs until you found one that is cooperating. This search will stop at the shell. As long as we make clear to the user that success is _only_ guaranteed at the top level of the tree, there shouldn't be any problem. A similar issue arises with authorising access to files via the powerbox: A browser could advise the user that access to a file is for a certain plugin only. But the browser can compromise this guarantee and provide the same file to other plugins. Thus, the decision must be a made by forming the intersection of access you are willing to grant each component along the path. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
