Re: [9fans] Re: Free Plan 9 "shell" accounts?

[Dan Cross <cross@math.psu.edu>]

I know I shouldn't get into this....

> > I don't understand what this means; doesn't the ability to start a
> > process on a remote machine (``process pool'') mean you can start a
> > shell on it?
>
> Plan 9 has per process namespace, and there is really nothing that says
> the namespace that a particular process is running on a particular piece
> of hardware are shared. In other words the resources for a given shell
> don't necessarily have to reside on that machine. In other words the
> process server doesn't have to share any of its kfs resources into the
> namespace of the process). The namespace doesn't even have to come from a
> single machine. So, if you've got a process that has it's I/O connected to
> your machine, and various namespaces transitively mounted from machines
> other than the process server executing the job, can you really say the
> shell is running on 'that machine'?
>
> I'd say "No".

Yes.  It's executing on that machine.  It's effectively the same
situation as a program running on a diskless Unix machine with the
filesystem served by NFS.

So you agree that you will allow someone to run code on your machine,
you just won't provide them with a filesystem.  So they can run a copy
of /bin/rc on your machine if they like.

> If you have a process server executing a job that spawns multiple
> processes, Tower of Hanoi or a factorial might be a job that would do for
> an example, and those processes are running on different machines; can
> you say that the program runs on 'that machine'?
>
> I'd say "No",

Yes.  What it does, such as starting jobs on other machines, is
irrelevant.  It itself is still running on that machine.

> You're running a 'shell on a machine' and that machine hiccups, with
> traditional operating systems the only result is to throw an error
> condition and halt. On Plan 9 it's possible that in cases that if a
> machine were to die the namespace resources (which we'll assume aren't on
> the process server native) are saved and the machine that started the
> process would simply re-init that job on another processer, without the
> user even knowing about it. Is that running that program 'on a machine'?
>
> I'd say "No".

It's possible, perhaps, but doesn't happen now.  At least not without
writing code.  But it would be possible to write the same code on any
number of systems; amoeba comes to mind as an example of a system that
already approximates that sort of behavior.

But that doesn't change the fact that, yes, the program is running on
a machine somewhere.  The only thing you're saying is new is that you
don't care what machine it's running on.

> There are many other examples I could think of, you will too; eventually.

I'm sorry, but I think you're confused about basic definitions.  What
it means for a piece of code to be running on a computer is that it's
executing on that computer.  Whether you can do clever things behind to
scenes to give the illusion of it being transparantly relocatable to
another computer is irrelevant.

Even then, I'm disappointed that all you're talking about is restarting
a program on a different machine.  If you were talking about generalizing
/proc to replicate process state across multiple machines operating
in lockstep in real time, I might start to be kind of impressed.

> Plan 9 has the unique advantage of being able to create a distributed
> virtual machine. This means that where the job runs is irrelevant, and
> where the resources of the namespace exist is irrelevant. Plan 9 is not so
> much 'where' but 'how to impliment'.

That's not unique.  Condor, MOSIX, Amoeba, and other systems implement
similar functionality.

> To worry about the specific machine is a pretty archaic viewpoint that is
> not really compatible with understanding what one can get out of Plan 9.
>
> Plan 9 is a -distributed- operating system. This means that you have to
> think of 'process clouds' and many resources clustered together to form a
> namespace. The fact the namespace is -per process- is what takes it a step
> above the 'run a shell on a machine' perspective.

Again, you're misunderstanding the definition of what it means to run
a shell on a machine.

> You have to get past thinking of Plan 9 as a OS 'on a machine' and think
> of it as a OS -across machines-. Note the plural in that, it's critical to
> understanding the true power of the OS from the perspective of the user.
> [1]

I don't see how the two are mutually exclusive.

> If you really want to have an OS on -a machine- then Plan 9 will bring you
> nothing of interest. Stick with traditional operating systems. If you want
> to join a -community of resources- then look into Plan 9, it will surpise
> you. [2]

Or Amoeba.

> Hope that helps clear up your confusion...;)

I see what you're saying, but I think you missed my point.  It might
help if you reviewed a book on operating systems basics; it's pretty
clear you don't have much of a formal background here.  I can recommend
a titles, if you'd like.

> [1] This goes right to the heart of one of my issues with the Plan 9
> community here with regard to lack of understanding of 'user' space as
> compared to looking at everything as a 'developer' space issue. Such is
> the flaw of having a goal of keeping a technology limited to a niche (ie
> research OS).
>
> [2] I've mentioned this distinction many times in the past, and it amazes
> me that many long time users of Plan 9 still don't 'get it'.

And how.

	- Dan C.