From owner-freebsd-chat@FreeBSD.ORG Wed Feb 16 05:16:41 2005 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B3B16A4CE for ; Wed, 16 Feb 2005 05:16:40 +0000 (GMT) Received: from sccimhc92.asp.att.net (sccimhc92.asp.att.net [63.240.76.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F08A43D1D for ; Wed, 16 Feb 2005 05:16:40 +0000 (GMT) (envelope-from freebsd@nbritton.org) Received: from [192.168.1.10] (12-223-129-46.client.insightbb.com[12.223.129.46]) by sccimhc92.asp.att.net (sccimhc92) with ESMTP id <20050216051639i92004tvvde>; Wed, 16 Feb 2005 05:16:39 +0000 Message-ID: <4212D732.8040004@nbritton.org> Date: Tue, 15 Feb 2005 23:16:34 -0600 From: Nikolas Britton User-Agent: Mozilla Thunderbird 1.0 (X11/20050202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Kinsey References: <9C4E897FB284BF4DBC9C0DC42FB34617641AEC@mvaexch01.acuson.com> <42110635.3080209@nbritton.org> <268244209.20050215005013@wanadoo.fr> <42115637.6080307@nbritton.org> <42121360.2050905@daleco.biz> In-Reply-To: <42121360.2050905@daleco.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-chat@freebsd.org Subject: Re: SPAM: Score 2.3: Re: SPAM: Score 3.3: Re: Instead of freebsd. com, why not... X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 05:16:41 -0000 :-D that was a good one... > touch woman touch: woman: Permission denied Yea ever notice the sexual undertones in unix... touch, finger, mount, fsck, fork... :-). Kevin Kinsey wrote: > Nikolas Britton wrote: > > ><> Also how come we have a man page for man but none for > > woman, all I get is "No manual entry for woman"? > > woman(x) is a unique and seperate server; woman(x) has an > extremely efficient security mechanism and uses a proprietary > protocol that man(1) doesn't speak. However, woman(x) is > generally compiled to translate man(1) commands automatically > as long as man(1) limits the amount of requests to a reasonable > level (e.g. don't use the "-a" switch). > > But unless woman(x) is listening on an open socket, man(1) > can't make a connection. > > Occasionally the client/server (for lack of a better term) relationship > between man(1) and woman(x) works very well. In those cases, > I recommend adoption of the following manual page (after conversion > from Slowlaris lingo, of course.... > :-D > > Kevin Kinsey > > ************************************************************** > > BABY(1) USER COMMANDS BABY(1) > > NAME > BABY - create new process from two parent processes > > SYNOPSIS > BABY sex [ name ] > > SYSTEM V SYNOPSIS > /usr/5bin/BABY [ -sex ] [ -name ] > > AVAILABILITY > The System V version of this command is available with the Sys- > tem V software installation option. Refer to Installing > SunOS 4.1 for information on how to install and invoke BABY. > > DESCRIPTION > BABY is initiated when one parent process polls another server > process > through a socket connection (BSD) or through pipes in the system V > implementation. BABY runs at a low priority for approximately 40 weeks > then > terminates with heavy system load. Most systems require constant > monitoring > when BABY reaches its final stages of execution. > > Older implentations of BABY required that the initiating > process not > be present at the time of completion, In these versions the initiating > process is awakened and notified of the results upon completion. Modern > versions allow both parent processes to be active during the final > stages of > BABY. > > > example% BABY -sex m -name fred > > OPTIONS > > -sex > option indicating type of process created. > > -name > touch woman > touch: woman: Permission denied > > process identification to be attaced to the new process. > > RESULT > Successful execution of the BABY(1) results in new process > being created and named. Parent processes then typically > broadcast messages to all other processes informing them of their > new status in the system. > > > BUGS > The SLEEP command may not work on either parent processes for some > time afterward, as new BABY processes constantly send interrupts > which must be handled by one or both parents. > > BABY processes upon being created may frequently dump > in /tmp, requiring /tmp to be cleaned out frequently by one > of the parent processes. > > The original AT&T version was provided without instructions > regarding the created process; current implementations, regrettably, > also suffer from a lack of documentation. > > SEE ALSO > cigars(6) dump(5) cry(3) > > OTHER IMPLEMENTATIONS > > gnoops(1) > FSF version of BABY where none of the authors will accept > responsibility for anything. > > NOTES > > baby -sex f -name Cathryn Leigh Beck > > completed sucessfully at the Grey Nuns Hospital on March 30 at > 9:59 P.M. after 5 hours of labour. New Mom Chenelle is doing > fine, as is the baby, Dad is tickled pink. Both will probably > come home sometime on Tuesday. More information can be gotten > from Dad by e-mail or when he brings his new little girl by to > show her off (should be soon) Celebrations can probably begin > in earnest after Dad catches up on all the work he couldn't do > this weekend. > > > Sun Release 4.1 Last change: Just before I left the hospital last. > >