Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Re: persistent xterm sessions



 Greg Galperin wrote: 
> there's active work in "virtualization", which often does include 
> checkpointing and migration.  this should work on multiple processes with 
> hierarchy (and disk state, and net interfaces, etc.). 
... 
> as a starting point, you might browse around the virtualization packages 
> openvz, xen, and kvm to see if they can do what you want. 

Yes, good point. The virtualization tools should have solved the process 
tree migration problem by now. Providing they followed good UNIX design 
of small, specific purpose tools, it should be fairly easy to extract 
the checkpointing functionality. On the other hand, the checkpointing 
tool may end up being highly dependent on the hypervisor, which would 
make it useless in a non-VM situation. 


> ...what I'm not sure of is how an xterm by itself could maintain 
> state with your console x server across a restart of your console x 
> server, so the right approach may be to run your xterms plus an x 
> server inside the environment and checkpoint them together... 

If I can get screen to play nice with gnome-terminal, then GNOME would 
handle managing gnome-terminal, and a bit of script glue could handle 
getting the right screen instance restored. 


> actually, there's some appeal to having your entire user state 
> be a virtual environment which can survive reboots or be migrated to 
> whatever console you're sitting at; you might not want to have any state 
> living outside your virtual environment. 

Perhaps. If you're going to virtualize everything only for the purpose 
of preserving state, then you might as well use hibernation, and avoid 
the VM overhead. 

My thought is to save as little state as is necessary to make resuming 
tasks easy. You want as much as possible to be non-persistent so 
upgraded dynamically loaded libraries can get reloaded, and memory leaks 
cleared. Console apps are usually fairly well behaved, so I don't mind 
having them persist. 

  -Tom 

-- 
Tom Metro 
Venture Logic, Newton, MA, USA 
"Enterprise solutions through open source." 
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org