will be inherited, just to bring up one clear example. 

   8) result point 2. 

   The child now has its own fresh copies of the other parts, but highlight the
   inherited environment. 

     (!) I show a wash of green as the child process replaces the forked clone
     with new material. For you readers, in Linux the fork() is really just a
     special case of the clone() system call, which can clone things a number
     of ways. Anyways, it's an easy highlight for the environment this way, at
     least assuming the viewer isn't color blind. Oops. I didn't think of how
     to handle that. I'll have to test with desaturation... but let me finish
     the pictures first.

   (!) 9) zoom back out. Bring the parent and child back to their previous
   sizes. 

   10) meanwhile... 

   The parent exhibits the wait() system call. Now this could be blocking, or
   not blocking, I can spend quite a while on this part, but let's just make
   the drawing assume a blocking wait. 

   11) which waits until... The child does an exit() call. 

     (!) The wait() call actually needs to hang around while the child lives
     since you're blocking, so scribble scribble that'll really read: wait()
     blocked. I'll have to make the child do something brief and cute (goodness
     knows what) then exit() leaving... uhh...

     12) the child dies. Highlight the parent, which unblocks as it catches a
     SIGCHLD signal.

     (!) My first shot at this shows exit() turning into SIGCHLD, and the child
     process' border fading out.

   (!) That's not really right; init generates SIGCHLD after cleaning up most
   of the mess. And the dead child shouldn't hang around. We'll need to show
   the remaining process table, too. Make the kernel float in from offside so
   we can see that, perhaps. 

     (!) My second shot (good enough for your first of several classes) shows
     the child process decaying to a partial border, the word "child" becoming
     SIGCHLD, and going into the wait() which clears.

     Here's where the doodle breaks down, so time to re-doodle it, using the
     facts. The exit leaves a return code. But as you and I know, return codes
     aren't stored in the "dead body" of the child process. It only exists as a
     zombie - an entry in the process table, which is the only thing left of it
     after init sweeps away the main process. The process table itself is in
     the kernel somewhere. So I'm going to need to plot where to sneak in a
     kernel page. (I imagine a bag of popcorn... :D ) Doing that suggests
     having it show while the fork() is spawning the child too, so I can show
     the process id changing, and the parent's id assigned into ppid.

   (!) Yes, that will work much better. Let's get the animation between slides
   in, then fix up the last part and it's good to go. I found you a nice gif to
   flash translator, which we can try on the resulting file for grins. 

   I don't suppose GIMP can output flash yet? 

     (!) Oooh, I will need to google for that :) Probably not. The GIMP's a
     raster  image editor, and SWF is a vector based format. OTOH if the
     converter you're talking about is any good, maybe it can be merged onto
     the GIMP.

     I'm sure there are more aspects of the process creation and lifecycle that
     can be drawn. I'm juggling a few things, but I'll post the drawing in
     progress...

   (!) Just stuff them in SysadMoin on the page TaosLinuxTraining, at least at
   the moment. When I'm happier with the parts you can split them up into
   several images - one per stopping point in our final form. We'll split the
   Process Model commentary onto a new page, and the world can have some fun
   with it. 

     (!) Wiki rocks. Chalkboards and whiteboards of the world, unite!

     Sysadmoin is our house wiki, used for our system administration natter.
     ([117]http://www.starshine.org/sysadmoin) It's based on moinmoin, and I'm
     pleased to say that our dark theme is actually part of the upstream
     sources.  Very pleased, after all the trouble I went to in order to
     [118]http://www.starshine.org/sysadmoin/MakeMoinMoinDark  in  older
     revisions. The moin people are very active in development, so for this
     project at least, it's worth popping into #moin on freenode. Helps to show
     up on European hours though.

     Maybe I'll even post the xcf file and let people enjoy paging around in
     it. I realize xcf isn't readable by anythign but gimp, but that's where
     the real animation lies, in the seperated frames. :)

     For you dithering vidiots out there, frames of about 50 milliseconds
     distances seem to be fairly smooth going, slower's a little more obvious
     but somewhere between that and 140 ms are good for skidding to a halt.
     Anything slower is painful. Your eyeballs may vary, but recall that
     american TV is about 24 or 28 frames a second, and more is better. 50ms is
     a mere 20 frames per. I just don't want my file to get too big.

     For gimp folk specifically, adding (50ms)(replace) to the end of the name