[EMAIL PROTECTED] wrote:
On Thu Sep 15 11:40:59 EDT 2005, rminnich@lanl.gov wrote:
...
Meant to be shared, by lots of folks, hence that ' ... big boys' comment
in the startup code, reserving more kernel memory since there would be
more users on a cpu than on a terminal.
life has changed.
r
> blackdog is the xlininx v2p. I talked to one of the engineers -- he
> visited here. They are not averse to the idea of Plan 9.
We are planning to use the PowerPCs in Virtex 2Pros at work soon,
I would be interested in any progress on that front. I may well be
involved in the port of our interna
ozinferno is not plan9 and they are diverging rapidly. once the drivers
were interchangeable. i'll try and release something soon if i can
find the appropriate spare cycles. an auth server on a $40 router
is not out of the question.
BTW qantas uses $100 pcs from china running inferno for their
> In other words, Sape's complaints is more highlighting a surmountable
> drawback than really suggesting that cacheing isn't usable. He gave
> the impression that he'd stopped useing cacheing because of this.
What I was trying to convey was that, if you reboot daily with a clean
cache, the perfo
> You can do that with plan9.ini: set up two different
> [whatever] sections with root= and cfs= lines.
> It's only when you're typing the root at root is from:
> that you get in trouble, because there is no cache is from:
> prompt.
In other words, Sape's complaints is more highlighting a surmount
> > Yes, you can tell cfs to clear the cache on startup, but then you lose a lot
> > of speed during the early phases of running.
>
> Out of ignorance, perhaps, I'd expect to be able to distinguish at
> startup between the target roots and make a decision accordingly.
> Would the namespace not be a
> Yes, you can tell cfs to clear the cache on startup, but then you lose a lot
> of speed during the early phases of running.
Out of ignorance, perhaps, I'd expect to be able to distinguish at
startup between the target roots and make a decision accordingly.
Would the namespace not be able to offe
>> Just to be clear, Sape is saying that if you boot and
>> sometimes you use one file server as root and sometimes
>> you use a different one, then cfs will use the data cached
>> on behalf of the first one when you're using the other
>> one.
That was indeed what I meant.
> Is there not a simple
> Just to be clear, Sape is saying that if you boot and
> sometimes you use one file server as root and sometimes
> you use a different one, then cfs will use the data cached
> on behalf of the first one when you're using the other
> one.
Is there not a simple mechanism to clean the cache on boot,
Wes Kussmaul wrote:
Blackdog? Nice, but it runs Linux. I have a fingerprint USB token that
"runs" Inferno so I can connect with a grid from anywhere.
blackdog is the xlininx v2p. I talked to one of the engineers -- he
visited here. They are not averse to the idea of Plan 9.
ron
On Sep 15, 2005, at 11:50 AM, Ronald G Minnich wrote:
I want a backpack full of cpu servers, a laptop with no disk, and
a fossil in my pocket (maybe an ipod? Or see the blackdog device --
can't turn on fossil until it takes your thumbprint).
Blackdog? Nice, but it runs Linux. I have a f
> although you can now run all components on one
> cpu server, it's still best to scrounge the extra
> machine to keep the file server and cpu server
> separate, and to run a limited set of services on
> the file server.
That's what made sense to me. And I was hoping for
a slick trick resulting i
> I've connected through cfs for years but
> gave it up now that I have to connect
> to more than one file server — cfs isn't
> good at tracking what server you use and
> will interpret cached data from one server
> as belonging to another. Not good.
Just to be clear, Sape is saying that if yo
>> Are you using caching?
>
> not that I'm aware of.
>
>> Would/does it make a difference?
>
> good question.
> experience, anyone?
>
>> What speed is the link?
>
> cable modem, I think it is 1024/256.
I've connected through cfs for years but gave it up now that I have to connect
to more than
On Fri, Sep 16, 2005 at 09:34:39AM -0400, erik quanstrom wrote:
> you know, i was thinking the linux folks have hacked those linksys
> wireless routers. now that would be an excellent auth server. ;-)
Rumor has it that those things run great with OzInferno, now if we
could only convince Brucee to t
>> Are you using caching?
>
> not that I'm aware of.
I have.
>
>> Would/does it make a difference?
>
> good question.
> experience, anyone?
not for compilation. as it creates object files and binaries it
necessarily needs to write absolutely everything past the cache and
onto the file server
i've got this dim memory of reading in the plan 9 papers that the
security model is based on physically removing the auth server from
everybody else.
you know, i was thinking the linux folks have hacked those linksys
wireless routers. now that would be an excellent auth server. ;-)
erik
Charles
> > the connection home-work is fast enough to do remote editing,
> > but limited enough to make local (at home) compilation of files
> > residing on the remote (work) fs more painful.
just to be complete: the home machine takes root from local disk
(I have been using a diskless setup in the past
> the connection home-work is fast enough to do remote editing,
> but limited enough to make local (at home) compilation of files
> residing on the remote (work) fs more painful.
Are you using caching? Would/does it make a difference? What speed
is the link? Just to get an idea of the options..
> I didn't say that wasn't the main reason, just that proximity to the
> file server was also a factor, I can't find the quote I'm looking for
> which I think was more explicit, but from
> http://www.cs.bell-labs.com/sys/doc/9.html
>
> "The effect of running a cpu command is therefore to start a s
> One day I logged into our file server and ran it out of
> swap by mistake.
although you can now run all components on
one cpu server, it's still best to scrounge the
extra machine to keep the file server and cpu server
separate, and to run a limited set of services on the file server.
i don't se
You don't need to run a second authentication server,
just a second authentication domain. The way to do this
is to start the fossil as normal but then replace the usual
aux/listen command with
@{
rfork n
auth/factotum
read -m new.factotum >/mnt/factotum/ctl
aux/listen tcp
}
and
> Split the authentication domain into two.
> One for ordinary users in which "our CPU server" and
> the file server (fossil processes) runs, and the other
> in which the file server (the box itself) boots and runs.
I remember reading about that. To be honest, I was wondering
if there might be a
> Your file server swaps when too many people log in?
One day I logged into our file server and ran it out of
swap by mistake. I don't remember what I was doing, but
it can be done, and I'd prefer to at least keep the size
of the pool of people who can do it small (and maybe
I flatter myself into
Lyndon Nerenberg wrote:
On Sep 15, 2005, at 1:27 PM, Charles Forsyth wrote:
I've been planning to put a cluster of embedded (HOT!) Pentium Ms in a
wine cooler for some time now. Tasteful design, nice glass door, quiet,
the height of elegance!
the heat will ruin the burgundy, though.
An
On Sep 15, 2005, at 1:27 PM, Charles Forsyth wrote:
I've been planning to put a cluster of embedded (HOT!) Pentium Ms
in a
wine cooler for some time now. Tasteful design, nice glass door,
quiet,
the height of elegance!
the heat will ruin the burgundy, though.
And the acid from the wine
> life has changed.
life is always changing.
I'm getting older, and I have to find a new way for my left life etc...
By the way, I agree the role of CPU servers is changing.
Here, it's only for inter/intranet daemon processes.
Terminals are powefull enough these days for our work here.
Kenji
> Ok, I'll ask this question which I've been meaning
> to look into: what is the easiest/cleanest way to
> restrict logins to our file server to certain people
> (to avoid, say, it running out of swap) while allowing
> everybody to log into our CPU server?
Split the authentication domain into two
> I've been planning to put a cluster of embedded (HOT!) Pentium Ms in a
> wine cooler for some time now. Tasteful design, nice glass door, quiet,
> the height of elegance!
the heat will ruin the burgundy, though.
I think you are confused:
% cat /bin/Kill
#!/bin/rc
for(i){
ps | sed -n '/ '^$i^'$/s%^[^ ]* *([^ ]*).*%chmod 666 /proc/\1/ctl;echo
kill > /proc/\1/ctl%p'
}
On Thu, Sep 15, 2005 at 03:55:10PM -0400, ISHWAR RATTAN wrote:
> I forgot mention that
> echo Kill > /proc/pid/note
>
> does not
I forgot mention that
echo Kill > /proc/pid/note
does not help. I will have to set up a time for
reboot of cpu-server.
-ishwar
On Thu, 15 Sep 2005, ISHWAR RATTAN wrote:
I have only two boxen:
- auth-server
- cpu-server
and drawterm is used to login into cpu-server
-ishwar
On Thu, 15 Se
I'm drawterm'ed in from a client site. If I'm someplace where the
link is very slow, I boot up Plan9 under VMWare and import parts of
the namespace I need from the cpu.
As a standalone computing service, they're still relevant. Also it's
important to consider them service nodes, serving parts of
> > We forbid them to cpu into a cpu server.
>
> Ok, I'll ask this question which I've been meaning
> to look into: what is the easiest/cleanest way to
> restrict logins to our file server to certain people
> (to avoid, say, it running out of swap) while allowing
> everybody to log into our CPU s
On Thu, Sep 15, 2005 at 01:03:43PM +0100, Steve Simon wrote:
> If you are running as hostowner you can use Kill (capital K) which
> chmods the file first:
>
> chmod 666 /proc/868/ctl;echo kill > /proc/868/ctl
>
> This will not work for factotum as it marks itself as private,
> [perhaps this is a
> We forbid them to cpu into a cpu server.
Ok, I'll ask this question which I've been meaning
to look into: what is the easiest/cleanest way to
restrict logins to our file server to certain people
(to avoid, say, it running out of swap) while allowing
everybody to log into our CPU server?
Dave E
I have only two boxen:
- auth-server
- cpu-server
and drawterm is used to login into cpu-server
-ishwar
On Thu, 15 Sep 2005, Fco. J. Ballesteros wrote:
We forbid them to cpu into a cpu server.
They run their own diskless terminals, which they reboot
when they are done. You might do the s
> These CPU servers you use to drawterm into,
> are shared with other users? Or do you own the machine?
i own the machine but it is shared with other users. it's hidden in a
server room at ucalgary and has been up for three months.
Charles Forsyth wrote:
indeed, and you can put collections of cpu and file servers in cooling rooms,
keeping a smaller, cooler laptop that you can actually put on your lap
without risking burns or setting fire to your trousers...
I've been planning to put a cluster of embedded (HOT!) Pentium
Lucio De Re wrote:
That's the view from a particular location. Think in terms of limited
resources, like electricity, for example. Or networking bandwidth.
Or cooling. And, lastly, multitasking programming skills.
gotcha.
thanks, good point.
ron
> And in the early days, it was a lot easier to buy a really fast
> cpu server than it was to buy a really fast terminal. It's still
> more cost-effective.
indeed, and you can put collections of cpu and file servers in cooling rooms,
keeping a smaller, cooler laptop that you can actually put on y
> I don't see any point in computing on a file server. CPUs are so cheap.
> Just throw as many of them as you need at a problem until the problem
> succumbs to them.
That's the view from a particular location. Think in terms of limited
resources, like electricity, for example. Or networking ba
On Thu, Sep 15, 2005 at 11:27:51AM -0400, Russ Cox wrote:
> This just isn't true. The cpu server lets you use its cpu.
> And in the early days, it was a lot easier to buy a really fast
> cpu server than it was to buy a really fast terminal. It's still
> more cost-effective.
I didn't say that wasn
>
> life has changed.
>
> ron
The only thing we can be sure of is that it will change again.
When we get 256 CPUs on a die and Optical CPUs maybe we may
find the cpu server model fits again.
-Steve
> Well, we use a separate CPU server to provide web,mail,dhcp, etc.,
> and try to keep the file server undisturbed. I wouldn't call this `obsolete',
> we no longer have file server blockouts when spammers find a way to
> really overload our smtpd/httpd.
A good point, I concede. I do likewise, but
I understood that on terminals you want more memory for
images and the like; On CPUs it seems they wanted more
memory for user processes (more users, more processes).
at Coraid, we have two cpu servers that run daemons
and provide machines for the folks who have to run
other systems (bsd, linux). we also have a terminal server
to get to consoles. since our SATA+RAID product runs
Plan 9 you could say we have a good many cpu servers.
however, we don't use the s
And, by the way, cpu servers are the only way I use Plan 9
these days.
I'm going to go that route as soon as I work out how to use a laptop, on
travel, off the network, in that mode. I want a backpack full of cpu
servers, a laptop with no disk, and a fossil in my pocket (maybe an
ipod? Or s
On Thu Sep 15 11:40:59 EDT 2005, rminnich@lanl.gov wrote:
> ...
> Meant to be shared, by lots of folks, hence that ' ... big boys' comment
> in the startup code, reserving more kernel memory since there would be
> more users on a cpu than on a terminal.
>
> life has changed.
>
> ron
Actually,
I don't see any point in computing on a file server. CPUs are so cheap.
Just throw as many of them as you need at a problem until the problem
succumbs to them.
ron
Lucio De Re wrote:
In particular, the 100MHz Cyclone connection between CPU server and
file server always suggests a reality check to me.
It's my turn to miss the point, can you expound on this a bit more?
thanks
ron
> And, by the way, cpu servers are the only way I use Plan 9
> these days.
Thought provoking. My experiences with early drawterm were not
promising (NetBSD as opposed to Windows or Linux, the multithreading
is still not entirely adequate), so I use VNCviewer on NetBSD and VNCS
on a CPU server. P
Uriel wrote:
I think it's already mentioned in the original papers that one of the
main reason for 'cpu' servers is bandwidth/proximity to the file
server(s), so I in a way it has always been a misnomer.
yeah, but ... those cpu servers, IIRC, were big 'ol power challenge
machines.Big fat SMP
Well, we use a separate CPU server to provide web,mail,dhcp, etc.,
and try to keep the file server undisturbed. I wouldn't call this `obsolete',
we no longer have file server blockouts when spammers find a way to
really overload our smtpd/httpd.
: Until now, I
: had considered the Fossil host as
> I think it's already mentioned in the original papers that one of the
> main reason for 'cpu' servers is bandwidth/proximity to the file
> server(s), so I in a way it has always been a misnomer.
A good point. Fossil does provide, at a price, the features of both
worlds and in fact encourages be
> I think it's already mentioned in the original papers that one of the
> main reason for 'cpu' servers is bandwidth/proximity to the file
> server(s), so in a way it has always been a misnomer.
This just isn't true. The cpu server lets you use its cpu.
And in the early days, it was a lot easier
> I wonder, how many 9fans are *actually* using CPU servers?
You and Ron both confirm my experience. The CPU server I have runs
applications: e-mail, web, wiki, that type of thing. I can't use it
to render Geotiffs as I have better resources (physical memory, CPU
cycles, SWAP) in my workstation.
> These CPU servers you use to drawterm into,
> are shared with other users? Or do you own the machine?
I'm essentially the only user,
(there may be others but we do not have that many 9 fans here)
but not hostowner.
Axel.
On Thu, Sep 15, 2005 at 04:44:46PM +0200, Fco. J. Ballesteros wrote:
> : In that sense, the 'cpu server' is outdated nomenclature.
> I wonder, how many 9fans are *actually* using CPU servers? [do not
> count a CPU server that runs your fossil as such, it's a file server,
> isn't it?]
I think it'
These CPU servers you use to drawterm into,
are shared with other users? Or do you own the machine?
Hi Is there any way to know when a user is connected or not?a relation between netstat and procs running by the user may be ?or something easier i missed? gabi
2005/9/15, andrey mirtchovski <[EMAIL PROTECTED]>:
> I wonder, how many 9fans are *actually* using CPU servers?> [do not count a CPU server
> I wonder, how many 9fans are *actually* using CPU servers?
> [do not count a CPU server that runs your fossil as such,
> it's a file server, isn't it?]
[haven't followed the discussion closely, sorry if this is off target]
I'm using a cpu server (even as we speak) that I drawterm
into from my of
> I wonder, how many 9fans are *actually* using CPU servers?
> [do not count a CPU server that runs your fossil as such, it's a file server,
> isn't it?]
i'm using a cpu server 100% of the time -- my terminal is a drawterm
session.
: In that sense, the 'cpu server' is outdated nomenclature.
Yep. In Plan B we don't have CPU servers, actually. (We made an
experiment but its result was not clear). We have "permanent terminals", though.
If you own a machine, you can arrange for remote omeros to browse/exec on it.
I wonder, how
Fco. J. Ballesteros wrote:
Well, we could use Kill as said here, or even
reboot the machine on saturdays 5am to make it clean,
etc.
that's the one nice thing about a cluster node. You have lots of 'em,
they can be single user. So just let one cpu user in to one cluster node
at a time, and wh
: hmm, my irony-meter just went to max.
:-)
: Isn't there a better solution to this problem than not letting people
: use a cpu server as a cpu server?
Well, we could use Kill as said here, or even
reboot the machine on saturdays 5am to make it clean,
etc.
However, the PCs have so much CPU
Fco. J. Ballesteros wrote:
We forbid them to cpu into a cpu server.
hmm, my irony-meter just went to max.
Isn't there a better solution to this problem than not letting people
use a cpu server as a cpu server?
ron
it seems a bit restrictive to stop use of the cpu
server. anyhow, if you're hostowner (eg, bootes)
try using Kill instead of kill. it chmods the ctl file so the hostowner
has permissions.
We forbid them to cpu into a cpu server.
They run their own diskless terminals, which they reboot
when they are done. You might do the same.
: Students leave around running processes on the
: system. Is there a way to kill these?
:echo kill > /proc/868/note
: says permission denied (which
If you are running as hostowner you can use Kill (capital K) which
chmods the file first:
chmod 666 /proc/868/ctl;echo kill > /proc/868/ctl
This will not work for factotum as it marks itself as private,
[perhaps this is a bug - private need not chmod of ctl is impossible?]
Its not much of an iss
Students leave around running processes on the
system. Is there a way to kill these?
echo kill > /proc/868/note
says permission denied (which makes sense as
I am trying to kill them logged as bootes).
-ishwar
70 matches
Mail list logo
