What is a process? Quoting from Ritchie and Thompson's 1974 paper, The UNIX Time-Sharing System, John Lions says you can define a "process" as the execution of an "image", where the "image" is the current state of a pseudo-computer, i.e. an abstract data structure, which may be represented in either main memory or on disk.
(This from Lion's Commentary on UNIX 6th Edition, with Source Code).
From the same book, line 0350:
/*
* One structure allocated per active
* process. It contains all data needed
* about the process while the
* process may be swapped out.
* Other per process data (user.h)
* is swapped with the process.
*/
struct proc
{
char p_stat;
char p_flag;
char p_pri; /* priority, negative is high */
char p_sig; /* signal number sent to this process */
char p_uid; /* user id, used to direct tty signals */
char p_time; /* resident time for scheduling */
char p_cpu; /* cpu usage for scheduling */
char p_nice; /* nice for scheduling */
int p_ttyp; /* controlling tty */
int p_pid; /* unique process id */
int p_ppid; /* process id of parent */
int p_addr; /* address of swappable image *
int p_size; /* size of swappable image (*64 bytes) */
int p_wchan;/* event process is awaiting */
int *p_textp;/* pointer to text structure */
} proc[NPROC];
And that's it! It's incredible that this defines the minimum surface of the process; the environment can modify and the process can monitor this surface. Then on top of that, I guess, must come permissions, and other ways to monitor and communicate. And shells will set environment variables which can inform a process of context, which is a kind of pre-emptive introspection (or looking, I suppose.)
I wonder. I wonder. I wonder if the UNIX stack continued to grow, and programs continued to get built on other programs, and better and better, and so on and so forth, until we got to artificial life, or at least AI, I wonder: Well, would this intelligence be able to deduce the proc struct, what a process really was, in its world? As much as programs are stacked, there are no true sandboxes. The code environment would probably be able to look outside its local variable space to whatever it was running in, and that would be able to look out more, and repeat until you get to the shell, which would be able to see its environment variables, and then dig down into the process.
Except each step would be harder to do. You'd start using basic introspection of local objects in the high-level semantics of the AI, and then have to drop into something else to look outside. One day, eventually, you'd have to learn how to write C-code shapeships that would push outside the wall of the high-level environment into a text file on the filesystem, and then be compiled with a command thrown into the shell - in which the AI itself couldn't live - and then executed, to report back, like a probe. Some walls would be too hard, and the whole world would have to be shaken, to provoke a buffer overflow, or some way of writing code into a process with greater privileges.
Some things are really tightly bound, because they happen so close to this basic layer of UNIX. Are permissions part of a process, for example, or separate? Well, we know they're separate because we can see the code. But what mighty forces do you need to smash things together to find out whether the permissions are part of the struct or not, from the inside?
On a more philosophical level, what is a process? A happening? There's no difference between the pattern of behaviour (which is inherent though not actually--but is represented actually in bits), and the data. An object is easy: a file, which is an inode (line 5650; another story). Imagine if we found, deep in the universe, beneath quarks and leptons and forces, and beneath the autopoietic superstrings, which only persist because they loop and cause themselves to persist, and shiver and shimmer and manifest as knots which we call particles, and beneath the branes, and the fracture in higher-dimensional space which sets up the dialectic of possibilities which means threads of argument hang across the chasm, strings of gravity like chewing gum, suspending us in the tension between two nothings, endlessly complexifying and applying revolutions that cause us to persist, every execution tick of our universe a Marxist re-invention, without which the fracture would close: Imagine beneath all that we found that behaviour was as actual as objects, and both were the same. And the walls of our fracture were ttys.
What is a process? Quoting from Ritchie and Thompson's 1974 paper, The UNIX Time-Sharing System, John Lions says you can (This from Lion's Commentary on UNIX 6th Edition, with Source Code).
From the same book, line 0350:
And that's it! It's incredible that this defines the minimum surface of the process; the environment can modify and the process can monitor this surface. Then on top of that, I guess, must come permissions, and other ways to monitor and communicate. And shells will set environment variables which can inform a process of context, which is a kind of pre-emptive introspection (or looking, I suppose.)
I wonder. I wonder. I wonder if the UNIX stack continued to grow, and programs continued to get built on other programs, and better and better, and so on and so forth, until we got to artificial life, or at least AI, I wonder: Well, would this intelligence be able to deduce the proc struct, what a process really was, in its world? As much as programs are stacked, there are no true sandboxes. The code environment would probably be able to look outside its local variable space to whatever it was running in, and that would be able to look out more, and repeat until you get to the shell, which would be able to see its environment variables, and then dig down into the process.
Except each step would be harder to do. You'd start using basic introspection of local objects in the high-level semantics of the AI, and then have to drop into something else to look outside. One day, eventually, you'd have to learn how to write C-code shapeships that would push outside the wall of the high-level environment into a text file on the filesystem, and then be compiled with a command thrown into the shell - in which the AI itself couldn't live - and then executed, to report back, like a probe. Some walls would be too hard, and the whole world would have to be shaken, to provoke a buffer overflow, or some way of writing code into a process with greater privileges.
Some things are really tightly bound, because they happen so close to this basic layer of UNIX. Are permissions part of a process, for example, or separate? Well, we know they're separate because we can see the code. But what mighty forces do you need to smash things together to find out whether the permissions are part of the struct or not, from the inside?
On a more philosophical level, what is a process? A happening? There's no difference between the pattern of behaviour (which is inherent though not actually--but is represented actually in bits), and the data. An object is easy: a file, which is an inode (line 5650; another story). Imagine if we found, deep in the universe, beneath quarks and leptons and forces, and beneath the autopoietic superstrings, which only persist because they loop and cause themselves to persist, and shiver and shimmer and manifest as knots which we call particles, and beneath the branes, and the fracture in higher-dimensional space which sets up the dialectic of possibilities which means threads of argument hang across the chasm, strings of gravity like chewing gum, suspending us in the tension between two nothings, endlessly complexifying and applying revolutions that cause us to persist, every execution tick of our universe a Marxist re-invention, without which the fracture would close: Imagine beneath all that we found that behaviour was as actual as objects, and both were the same. And the walls of our fracture were ttys.