From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10711062129v12fc7afcgfd7da14060288f79@mail.gmail.com> Date: Tue, 6 Nov 2007 21:29:16 -0800 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] consterm In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <719bc0fd763d14adf5d99d93e6a9b2f0@quanstro.net> Topicbox-Message-UUID: eda45420-ead2-11e9-9d60-3106f5b1d025 I use xcpu for a lot of what you are talking about. I'm using it now on a small PNFS cluster I built. If I want interactive access ... xcpu /bin/bash done. And the bash comes from my machine so, if the nodes are busybox nodes (they usually are) then I need not worry that they don't have my binaries. But, that said, I keep cursing my bad luck in not having a real cpu on linux. I could use your consterm for things I'm doing. I'm finding that xcpu is fine for some things, but cpu really is nicer. I'm considering adding namespace support to xcpu so that when you start (e.g.) a shell via xcpu, once the shell starts up, its namespace is there. Hmm, I just recreated cpu -- save that I can run without the name space stuff -- it's optional. And, cpu doesn't do the nice tree spawn stuff that Lucho put into xcpu. Note that we did this on bproc, 5 years ago, and it was pretty nice. We could define the namespace for a process, and then start the process up on 1024 nodes and have them all start with the desired namespace. Handy! one thing you can't easily do on cpu, though, that xcpu is nice for: xcpu md,d1,d2,d3 fdisk /dev/sda (gets me 4 parallel interactive fdisk's on the four nodes md,d1,d2,d3 -- it seems weird but worked wonderfully well. cpu is just not set up to do this type of thing, and neither would your consterm be). It seems to me from watching it that the real weight in 'cpu' is in the all the stuff that gets run when you log in, not necessarily cpu itself. That's not too hard to get around. All this points (to me) to the fact that we have not really reached the final answer on the things we want to do with remote access. Or, maybe, there's no final answer at all. ron