So, you're saying I want a process running all the time that sucks up CPU cycles while I'm on my own machine talking only to myself on a base install of BSD.<br><br><div class="gmail_quote">On Thu, Mar 10, 2011 at 5:46 PM, Michael Paoli <span dir="ltr"><<a href="mailto:Michael.Paoli@cal.berkeley.edu">Michael.Paoli@cal.berkeley.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

From: "Karen Hogoboom" <<a href="mailto:khogoboom@gmail.com" target="_blank">khogoboom@gmail.com</a>><br>
Subject: Re: login [not] a daemon? ... & CDs<br>
Date: Thu, 10 Mar 2011 06:30:13 -0800<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I still don't see why a base install of BSD decided I wanted to use PAM.<br>
</blockquote>
<br>
Because PAM is generally the right way to do it.  It rather cleanly<br>
(via API) separates out most authentication, etc. from the programs<br>
that need to use such.<br>
<br>
In the "bad old days" before PAM, if one needed to add a new<br>
authentication scheme, one would have to update (e.g. recode/recompile)<br>
all the programs that used authentication to support the new<br>
authentication scheme.  Likewise if a bug was found in said<br>
authentication scheme, all those programs would need to be updated.<br>
With PAM, just the PAM modules/programs themselves would need to be<br>
updated.  The concept and practice is relatively similar to shared<br>
libraries in general.<br>
<br>
</blockquote></div><br>