Note: Apparently written by engebret@sg1.cr.usgs.gov (Chris Engebretson). This is not confirmed.

Chow Hoi Ka"  writes:
|> Who can provide me some information about BUDDY SYSTEM in OS ????
 
As far as its relation to comp.lang.c goes, the "BUDDY SYSTEM" is
a mechanism that is designed to promote safety in code maintenance.
The basic premise is that maintaining some code is inherently
dangerous, especially unfamiliar code.  What the "BUDDY SYSTEM"
does is attempt to provide some basic ground rules for safety.

Quite often, people who write programs for a living find occasion
to critique the work of their predecessors and/or coworkers.  On
most occasions, this simply involves some minor style issues and
bug fixes.  But in some more rare instances, code maintenance can
introduce a very volatile situation where precautions must be
taken to ensure the health and well-being of those around you.
That's where the "BUDDY SYSTEM" comes to your aid.

It was originally developed at Stanford University in the early
1970's, when a graduate student whose name escapes me now was asked
to make some minor modifications to a pipe-stress-simulation 
program written in FORTRAN by an engineer who had little to no 
prior programming experience.  This student obtained a hard copy of
the program, disappeared into a small, windowless office, and was
never seen or heard from ever again.

Even to this day, the conspiracy and mystery newsgroups are still
speculating as to what actually happened.  Suicide is a common
guess, as is some form of spontaneous combustion.  Other more
esoteric offerings include alien abduction, time travel, and even
instantaneous teleportation to a parallel universe populated by
nothing but clones of Donald Knuth.  Yet another popular rumor
says that the student turned into the evangelist we now know as
"Jim Bakker."  Nobody knows for sure what happened to him, but if 
anything good came out of the whole incident, it was that an ad 
hoc set of guidelines was created to prevent such a bizarre 
and needless tragedy from happening again.

In many situations, these rules are not necessary, but in some
more severe cases, they are.  To summarize:

* NEVER go over unfamiliar code alone.  It's always a good idea
  to have another person (a "BUDDY") with you to help you through
  any unanticipated ill effects that the code may cause (such as
  convulsions, murderous fits of rage, uncontrollable laughter.)
  It is best to pick a buddy with a large life insurance policy.

* NEVER peruse unfamiliar code within a half hour of eating.
  Study after study has shown that chemicals found within vomit
  have a detrimental effect on the mechanical well-being of
  computer hardware (keyboards, mice, storage devices, etc.)

* NEVER dive into unfamiliar code in an unsafe environment.  Do
  not have destructive objects lying around within arm's reach
  (such as knives, guns, compasses, "C: The Complete Reference",
  etc.)  Along the same lines, do not have a root shell handy.
  The temptation to wipe out entire filesystems with a few short
  keystrokes may prove too overpowering to resist.

* NEVER translate and execute somebody else's code without first
  checking it out.  Sure, it may *look* safe, and you may have
  seen others do it without getting themselves injured or killed,
  but unless you have checked it out thoroughly, you have no idea
  what hazards may lie directly beneath the surface.

And the final guideline, the Most Important One:

* NEVER, EVER go over unfamiliar code while in the same time zone
  as the original author.  Long drives have a soothing effect
  that weeds homicidal tendencies out of your system.

These guidelines, while short and sweet, are invaluable for
promoting employee well-being and office safety.  Learn them,
love them, live them.  The life you save may be your own.

HTH