Random comments

[TVR%CCRMA-F4 at SAIL.Stanford.EDU]

*  Embedding some form of the machine name in your password when dealing
   large numbers of machines sounds like the most practical and humane
   suggestion i've heard in quite some time for the problem of people
   with lots of accounts.  Then, those of us who tend to get passwords
   hardwired into our fingers from frequent use can keep the number of
   machines with identical passwords down to a bare minimum, on machines
   that are relatively secure.

*  I agree the environment variable, SHELL, should not affect 'make'
   for the reasons stated; it will tend to break things unpredictably.
   I would suggest another variables, such as MAKE_SHELL, to become the
   default variable for SHELL in 'make'.  This would allow knowledgable
   people to explicitly change the shell for 'make' without problems for
   the rest of the users who may not understand the ramifications and/or
   want their 'makefile's to be portable.  On the other hand, those users
   who care can simply explicitly include a SHELL variable in their
   'makefile's and save someone else alot of grief further down the line
   who has to figure out why 'make foo' doesn't work for him/her.

*  Be very careful about changing what 'long' and 'int' mean.  Using a
   certain, otherwise quite decent, Macintosh 'c' compilers which defines
   'int' as 'short', has cost me phenomenal amounts of debugging time, even
   more than Apple's (shall we say) *unusual* memory management scheme.  On
   the other hand, we do need to address the issue of longer word sizes.
   For someone responsible for a PDP-10 system, 32 bit longs hardly seem
   very long; having not hacked UNIX in the 11/40 days, i might naively
   expect a 'long' to be something on the order of 72 bits!

   The other assumption you'd better be careful about is what a pointer is.
   How many people still use '(long)' when that should be saying '(char *)'?
   Hopefully everyone at least says '(long)' and not '(int)' [c.f. Mac].