Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!cca.ucsf.edu!wet!epsilon
From: epsilon@wet.UUCP (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: Next Bugs
Message-ID: <599@wet.UUCP>
Date: 26 Sep 89 12:37:50 GMT
References: <2420@ucsfcca.ucsf.edu> <130019@gore.com>
Reply-To: epsilon@wet.UUCP (Eric P. Scott)
Organization: Wetware Diversions, San Francisco
Lines: 72

In article <130019@gore.com> jacob@gore.com (Jacob Gore) writes:
>Then you will never have inconsistent data between, say, /etc/passwd, and
>the NetInfo database.

You can only do this in the trivial case of a single, local
NetInfo domain.  It doesn't do any good on our clustered
machines.  Besides, there is really no investment in passwd files
these days, with hashed passwd files, and shadow passwd files.
The "traditional UNIX administration" has been dead for years.
I've very happy with what NetInfo does, I just wish it didn't
have certain limitations.

>I think this is a MUCH better solution than just getting rid of "chfn" and
>other programs like it.

I don't see why chfn (or passwd -f) should be any harder to
implement than a password change.  I'm getting really tired of my
0.9 users asking to have office/phone information added.  On any
other UNIX system I'd tell them to do it themselves.  Here, they
can't.  I hope this is fixed.  (I'm still waiting for 1.0...
with my luck, it got shipped UPS ground.)

>The rest of my comments on this subject assume the current situation--that
>you have to use nidump and niload.

Not for passwd.  Maybe for other things (like fstab because
niutil is stupid about colons in fields).

>> #There should be a program that gets all the files synchronized with
>> #each other.

I'd rather see NeXT make NetInfo available for non-NeXT systems.
It's a significant improvement over YP.

>The first recomendation is not practical in many situation.  Not all people
>charged with administering NeXTs have a NeXT at their desk.

I haven't found this to be much of a handicap.

>But please leave /etc/passwd.

For us there is no such animal.  There is an effective passwd
file, but it doesn't correspond to anything I can load or dump
easily.


What does bother me are the statements that the NeXT isn't
"supposed to be a UNIX workstation."  We buy them as UNIX
workstations and use them as UNIX workstations.  They are
currently the most cost-effective choice for UNIX workstations.
They have enough horsepower to run excellent UNIX timesharing,
especially if you shut down the window system.

If NeXT continues to make them better (4.3-compatible) UNIX
workstations, we are likely to do a great deal of business with
them.  If not... we are likely to do a great deal of business
with a vendor that will.  Not having /etc/passwd is not a
handicap.  Not having /usr/lib/calendar is, and it's trivial to
fix.  Not being able to include  in a program
compiled with -bsd is, and it's trivial to fix.  Yet these are
the kinds of things that made 0.9 unfriendly.  We are using NeXTs
for classes this semester, and the next couple of months are
going to be "make it or break it."  So far the cube is very
promising.

I sincerely hope NeXT doesn't shaft its university customers
now that it has BusinessWeenies.

					-=EPS=- / SFSU
#ifndef _DISCLAIMER_
#include 
#endif