On Tue, 16 Mar 1999, Thor Lancelot Simon wrote:

> Is there a good argument against PAM

1. lack of support for S/Key, KerberosIV, and GSSAPI.

  i realize there are likely to be some development versions of PAM
  libraries that do these things, but in my experience such projects are
  often abandoned before they become nearly as reliable as their
  (currently working) alternatives.  we should consider them existant
  when it seems inevitable that they will become reliable.

  i suspect most PAM users do not use Kerberos or S/Key, and that most
  Kerberos and S/Key users do not use PAM, and base my judgement partly
  on this.

2. flakiness (still) of the current versions of PAM, and likelihood of 
   substantial future architectural changes in PAM.  unlikelihood that 
   the NetBSD project would have much influence on these changes, which 
   would intimately affect the source tree.

3. likelihood that future versions of PAM will become needlessly 
   complex, as its advocates try to compete feature-for-feature
   with Solaris.

4. good, consistent, shadow-capable authentication support already in the
   NetBSD tree (something Linux didn't have, which largely motivated the
   adoption of PAM)

> or modular rc scripts?

i have several NFS-rooted NetBSD boxes, and one NFS-rooted Linux box.  
All the NetBSD boxes can halt or reboot just fine, but the RedHat box
cannot.  I have fixed two rc.d-related problems that get it _closer_ to
rebooting, but it still won't go all the way.

IMHO, `kill -TERM; sleep 10; kill -KILL' is the best way to bring down a
box.  I didn't always feel this way, but now that I have some perspective
on the chore of debugging my own rc.d scripts, i've changed my mind.

i think the best thing about rc.d, and the reason it was invented, is that
it works better with vendor package management software.  many UNIX
sysadmins are not comfortable editing text files, and prefer to use HP's
sam or RedHat's glint.  however i think people ditch vendorware in favor
of NetBSD because their preference is just the opposite.

The NetBSD project so far seems to believe strongly in an economy of
complexity.

if i become better at writing Makefiles, it would interest me to write a
startup system that used make's parallel features to start several
subsystems concurrently, observing the dependencies among them, and deal
properly with errors such that:
 a. sometimes, it would elect to not attempt starting a subsystem with 
    a failed dependency
 b. the multiuser login prompt would be treated as a subsystem, and it 
    would always start eventually, even if some of the other start scripts
    hung forever.

i feel this system would better justify its unfortunate complexity than
the rc.d improvement.

i think contributors (and presently mere `enthusiasts' like myself) would
do well to advocate a deeper, sometimes mysterious and questionable
philosophy--rather than being ashamed of our collective laziness merely
because someone makes a chart of Free-UNIX features, and NetBSD lacks a
check mark.

this, my brothers, is something to be proud of.  let us earn no more check
marks than we must!

-- 
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700