glasscoc@silver.bacs.indiana.edu (john glasscock) (01/19/89)
When I tried to print files that were not WriteNow files, I got a blank page output between every printed page. This was after changing the typesize from 12 pt. to 10 pt. so that I could get the whole document lines within the margins. The files I was printing were all documentation files. Does anyone know how to load those documentation files into WriteNow? Is WriteNow sufficiently unbuggy?? Help me Obi Wan Kenobi, you're my only hope! --Princess Leia
jst@cca.ucsf.edu (Joe Stong) (09/23/89)
This is the posting of a bug report I sent to NeXT a 52 days ago. The tone is probably a bit testy, since it is the result of hours of frustration in working with the machine, sorry. We've received nothing more than an acknowledgement of receipt. I'm indeed working with the machine with only the online documentation, and through a rlogin on the ethernet. I don't yet know how to get reasonable printouts of .wn (WriteNow) documents. Sometimes I "strings" them. My understanding is that all the printed documents are availiable on-line (Are they?). Is this stuff fixed in 1.0? # #The manual page for "passwd" mentions nothing about NetInfo. There #should be cross-references to niutil, niload, and nidump, and nu. #All sorts of wierd interactions occur. # #chfn and chsh don't work. This should be stated up front, when the #programs run, and not after you've typed in several lines of input #which it subsequently refuses to admit to NetInfo. # #There should be a program that gets all the files synchronized with #each other. # #There needs to be a document about NetInfo in general. # #/bin/passwd only updates NetInfo. It doesn't touch /etc/passwd or # /etc/passwd.dir or /etc/passwd.pag or /usr/adm/nu.passwd # #It is possible for more than one entry to exist in NetInfo for users. #We had it happen here. The output from nidump had an error message #concatenated with the root passwd entry. The error message should have #gone out stderr and not stdout, and should have had a newline following it. #We're still not sure how the multiple entries were created. # #Niutil will not -destroy a blank entry. What ARE those reference #numbers for, anyway (on the niutil -list listings)? There's no #documentation on how to use them. We had to resort to the #console administration program to do the job, which was annoying. # #nu is obnoxious about not allowing one to enter multiple superuser #accounts. We use them so that different people have different superuser #passwords. (It doesn't allow a uid of 0 to be entered). # #The entry of the Sri-Nic hosts file into NetInfo has been going on for #a couple of hours now, and still isn't done. Is this really the way to #do things? # #We have avoided running the Yellow Pages, and don't know what complexity and #bugs this would bring up.
jst@cca.ucsf.edu (Joe Stong) (09/24/89)
I got private mail from Avadis Tevanian, who appears to be a software manager at NeXT. As it was private, I will not include it, but I will mention the content: It did NOT contain either helpful suggestions or sympathy about my situation in maintaining a NeXT box. It merely re-iterated observations that I had already made, and told me what I CANNOT do with the NeXT box (namely remote system administration). I'd much rather be told what I *CAN* do to improve my situation. I don't have much choice in doing remote system administration. I would expect better public relations from a NeXT employee!
avie@wb1.cs.cmu.edu (Avadis Tevanian) (09/24/89)
In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: >I got private mail from Avadis Tevanian, who appears to be a software >manager at NeXT. As it was private, I will not include it, but I will >mention the content: It did NOT contain either helpful suggestions or >sympathy about my situation in maintaining a NeXT box. It merely >re-iterated observations that I had already made, and told me what I CANNOT >do with the NeXT box (namely remote system administration). I'd much rather >be told what I *CAN* do to improve my situation. I don't have much choice >in doing remote system administration. > >I would expect better public relations from a NeXT employee! This last line really hurts. I'm trying as hard as possible to provide reasonable answers to people in what little time I have available. In any case, when I wrote to Joe, I basically was interested in knowing if he was reporting 1.0 bugs or was going through his laundry list of 0.9 bugs. Joe is indeed still running 0.9. Here is the text of the message I sent to Joe: >You seem to be posting lots of bugs to comp.sys.next that are related to >0.9. Is this the case or are you finding them in 1.0 as well? > >Also, you cannot expect to administer a NeXT easily through an rlogin >connection from somewhere else! At a minimum, as you have discovered, >you need a NeXT to read the documentation (in WriteNow format). Also, >in 1.0, most system administration is done through applications which >require the window system. > > Avie It seemed appropriate to mention to Joe that what he was trying to do was next to impossible. When he mentioned that he uses "strings" it seemed appropriate to mention that he needs a NeXT to read it (or at least print it out). In any case, Joe has posted a long list of bugs, suggestions and complaints. Let me try to address those that make sense in this forum. >I'm indeed working with the machine with only the online documentation, >and through a rlogin on the ethernet. I don't yet know how to >get reasonable printouts of .wn (WriteNow) documents. Sometimes I >"strings" them. My understanding is that all the printed documents >are availiable on-line (Are they?). The way to print out WriteNow documents is to run WriteNow on a NeXT machine (or even a Mac will work if you can transfer the files). Not all printed documents are on-line (e.g., User Documentation is not online). Is this stuff fixed in 1.0? #The manual page for "passwd" mentions nothing about NetInfo. There #should be cross-references to niutil, niload, and nidump, and nu. #All sorts of wierd interactions occur. Users are generally expected to use Preferences to change their password. System Managers can use UserManager if they wish. niutil, niload, ... are provided to assist in managing a heterogeous network (e.g., get or put your database on machines without NetInfo) and are documented elsewhere. #chfn and chsh don't work. This should be stated up front, when the #programs run, and not after you've typed in several lines of input #which it subsequently refuses to admit to NetInfo. We just removed these from the 1.0 release since we didn't have time to make them work using NetInfo. Again, UserManager (or NetInfoManager) can be used to change this information. #There should be a program that gets all the files synchronized with #each other. Well, niload and nidump attempt to do this. I recommend that one keep things synchronized by just using the Administration Apps (NetInfoManager can handle just about anything related to NetInfo). In those cases where you'd like to edit a file, the best bet is to nidump, edit and niload. #There needs to be a document about NetInfo in general. Included online in 1.0. #/bin/passwd only updates NetInfo. It doesn't touch /etc/passwd or # /etc/passwd.dir or /etc/passwd.pag or /usr/adm/nu.passwd This is a feature. Don't be surprised if those files aren't even on our next software release. #It is possible for more than one entry to exist in NetInfo for users. #We had it happen here. The output from nidump had an error message #concatenated with the root passwd entry. The error message should have #gone out stderr and not stdout, and should have had a newline following it. #We're still not sure how the multiple entries were created. I need more info to understand this one. I think nidump has been fixed to use stderr, but I don't have any way to verify it at this moment. #Niutil will not -destroy a blank entry. What ARE those reference #numbers for, anyway (on the niutil -list listings)? There's no #documentation on how to use them. We had to resort to the #console administration program to do the job, which was annoying. The reference numbers are just NetInfo directory tags. You don't really use them unless you are a NetInfo wizard and want to know what they are. #nu is obnoxious about not allowing one to enter multiple superuser #accounts. We use them so that different people have different superuser #passwords. (It doesn't allow a uid of 0 to be entered). nu is obnoxious is several ways. Its a tradeoff between letting experienceds users do things and preventing not-so-experienced users from getting things screwed up. nu errs on the sid of the naive user. #The entry of the Sri-Nic hosts file into NetInfo has been going on for #a couple of hours now, and still isn't done. Is this really the way to #do things? I believe that this aspect of NetInfo has been sped up in 1.0; however, the better way to get the entire Internet namespace is to run BIND (we do within NeXT, for example). #We have avoided running the Yellow Pages, and don't know what complexity and #bugs this would bring up. If you don't need it, don't bother running it. >Is there a sensible way for me to get at the .wn documents on an ascii >terminal? No, you really need to use a NeXT to run WriteNow. # We are trying to back up files on our optical disk. # # Karpinsi's attempts to use "dump" resulted in various hung copies of dump. You can use dump so long as you don't go beyond the size of the OD. dump gets confused when you run out of space on the OD. I don't know why you are getting hung copies of dump, we've tried it and it works fine (at least in 1.0). # There is no online documentation (unix man page) for the od device driver. There is nothing you need to know about for the od device driver, do you have specific questions? # It would be nice if you're accessing the od from a standard unix terminal # (via rlogin) that it wouldn't put a dialogue box up on the main screen # asking to insert a new disk. Well, you need to go to the machine anyway to insert the disk :-). I agree though that a message on your rlogin'ed terminal also seems appropriate though. # We have a disk that allows itself to be inserted and written upon. # It dumps tar with an I/O error about 41 megabytes into the 250MB # surface. Do you have more info on the I/O error? You may have a bad disk. # We want to re-cycle the 0.8 distribution disk. The system won't let us # put it in, it says something like "wrong volume". How do we re-label # the disk if it won't even let us insert it. # Sep 21 14:28:43 ccnext vmunix: Please insert new disk for volume 0 # Sep 21 14:28:43 ccnext vmunix: (press 'n' key if volume is not available) If you request a disk to be initialized (disk -i or from workspace) and this happens the only thing I can think of is a 0.9 bug when dealing with multiple volumes. I've initialzed many disks and used multiple volumes on 1.0 with no problems (0.9 was very preliminary, 1.0 is much more solid). # The "su" command doesn't seem to run ANY .cshrc or .login, neither the # one in my home directory nor root's home. Where should I put the .cshrc? # I'm su'ing to a secondary root account: # jstr:xxx:0:1:jdkjfkjdkf:/home/jst:/bin/csh The classic pilot error problem here is to have the wrong permissions on the .cshrc and .login. The csh checks this to prevent security problems. If everything is set up right, it will run the .cshrc from the home directory of the user being su'ed to. # There is various documentation in WriteNow format (.wn) files that I # cannot read, because I'm using a standard ascii terminal. Is there a # way to convert this stuff so I can read it? Again, use a NeXT and print it out. If you still want it online, you can use WriteNow to save as an ascii file, but you still need to use a NeXT to do that. # I discovered the "disk" command, only through the NetNews group, # comp.sys.next . It has an interestingly misleading help message, from # which I might conclude that typing "disk -i /dev/rod0a" is a way to # bring it up in interactive mode. Pretty frightening, -i is INITIALIZE, # and not interactive. Correct, disk -i is initialize. I don't know why its frightening. # Getting into the "disk" command, we discover that ALL the bad blocks # are taken on this floptical cartridge. It continues to read and # write on bad areas of the cartridge, but it takes a huge amount of time # 10-40 seconds instead of 1/3second to write 8 sectors, and generates # lots of errors. Reinitialize the disk under 1.0 (which uses a new remap strategy). If the bad block table still fills up, then throw away the media, it is bad. # The documentation about assigning badblocks indicates we should use # block numbers out of /usr/adm/messages. We get block numbers there # that are sometimes larger than 250MB. # Sep 22 14:43:29 ccnext vmunix: od0a: write failed (ECC) # block 250448 phys block 250459 (19802:0:11) The disk does actually have more than 250MB on it. Although, 250459 is NOT larger that 250MB. In any case, badblock remaping is done automatically for you. # The disk program is confusing about writing patterns. Why does it # ask, "random pattern" in the write command, when you actually use # the "set" command to set the pattern to be written? Because it only writes the pattern you set if you say no to the "random pattern" questoin. # Why is there no major/minor number device assigned to the font and # back porches of the od? How about doing programs like disk with # a script front end and some hardware interface programs, so a smart # user could begin to decipher things without the OS source? Most information like this is accessed via an ioctl interface. Noone should ever need to play around with this stuff. And if you have an application that needs this info, you should contact NeXT about getting the info you need. # How do you increase the size of the badblock space on a floptical # cartridge? Should we throw this one away? Back to-how do we # recycle an old distribution cartridge? You don't, if you have a suspicious OD, reinitialize under 1.0, if it still doesn't work, throw it away. ># disk /dev/rod0a >disk>bulk > >Crashes the system, reliably. "Golly" folks, what's happening? :-( Fixed in 1.0. -- Avadis Tevanian, Jr. (Avie) Manager, Systems Software NeXT, Inc. avie@NeXT.COM
greid@adobe.com (Glenn Reid) (09/25/89)
In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes:
I got private mail from Avadis Tevanian, who appears to be a software
manager at NeXT. As it was private, I will not include it, but I will
mention the content: It did NOT contain either helpful suggestions or
sympathy about my situation in maintaining a NeXT box. It merely
re-iterated observations that I had already made, and told me what I CANNOT
do with the NeXT box (namely remote system administration). I'd much rather
be told what I *CAN* do to improve my situation. I don't have much choice
in doing remote system administration.
I would expect better public relations from a NeXT employee!
It seems to me that the best public relations is the truth. If you
don't want to hear the truth, don't blame the messenger. There is a
lot you can do remotely to administer a NeXT machine, and some things
that you can't. If you can't do it, you can't do it. Nothing magic
about that. I actually am having a hard time understanding why you
don't have physical access to the NeXT machine if you are supposedly
the systems administrator.
Just personal observations on my part, not company comment.
Glenn Reidjacob@gore.com (Jacob Gore) (09/25/89)
/ comp.sys.next / avie@wb1.cs.cmu.edu (Avadis Tevanian) / Sep 24, 1989 / > In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: > >I got private mail from Avadis Tevanian [which] > >did NOT contain either helpful suggestions or > >sympathy about my situation in maintaining a NeXT box. It merely > >re-iterated observations that I had already made, and told me what I CANNOT > do with the NeXT box (namely remote system administration). Well, you can, if you are on *a* NeXT---not necessarily the one that you are administering. (I know, that's not a satisfactory answer either.) > >I would expect better public relations from a NeXT employee! > > This last line really hurts. I'm trying as hard as possible to provide > reasonable answers to people in what little time I have available. I beg you not to be turned off by such remarks. I found your participation in comp.sys.next very helpful (the same goes for Ali and for everybody else from NeXT who posts here). Not all of my questions that I posted got answered here to my satisfaction (or at all), but I hardly think that's something to get worked up about. Anyway, I'd like to offer a suggestion or two that would fix many of the problems brought up by Joe. I did send some of them to Northwestern's local 'nereportq' address, but I have no clue as to what happened to them since then. First of all, about all this nidump/niload stuff. There is a very clean way to make NetInfo transparent to all utilities that expect to see an /etc/passwd file: make /etc/{passwd,group,hosts,...} (all files that can be niload'ed) SPECIAL FILES. Their device drivers would incorporate niload (for input) and nidump (for output) for their respective formats. Then you will never have inconsistent data between, say, /etc/passwd, and the NetInfo database. I think this is a MUCH better solution than just getting rid of "chfn" and other programs like it. The rest of my comments on this subject assume the current situation--that you have to use nidump and niload. > #There should be a program that gets all the files synchronized with > #each other. > > Well, niload and nidump attempt to do this. I recommend that one keep > things synchronized by just using the Administration Apps (NetInfoManager > can handle just about anything related to NetInfo). In those cases where > you'd like to edit a file, the best bet is to nidump, edit and niload. The first recomendation is not practical in many situation. Not all people charged with administering NeXTs have a NeXT at their desk. The second can be sort of automated: replace the passwd, chfn and others like them with scripts that call nidump, then the original command, then then niload. The biggest problem is with those files that you just modify with an editor instead of using a special command (/etc/services, for example). The only thing I can suggest there is, if you use Emacs, putting a "magic cookie" at the top of the file that runs niload when the file is read in and rereads the file, and sets things up so that niload is done after the buffer is written out. (Sorry, I can't offer the actual elisp code, since I haven't done this -- I just run nidump and niload manually.) > #/bin/passwd only updates NetInfo. It doesn't touch /etc/passwd or > # /etc/passwd.dir or /etc/passwd.pag or /usr/adm/nu.passwd > > This is a feature. Don't be surprised if those files aren't even on our > next software release. It's not a feature, it's a tradeoff (between having NetInfo and having the "traditional" Unix administration stuff). And it's a false tradeoff at that -- if you use a special file for /etc/passwd which is just a window into NetInfo, you CAN have both. /etc/passwd.{dir,pag} are not needed, they are an implementation detail. But please leave /etc/passwd. > >Is there a sensible way for me to get at the .wn documents on an ascii > >terminal? > > No, you really need to use a NeXT to run WriteNow. It would be really nice if WriteNow could read and write TeX files. If not general TeX, then at least the texinfo format. > [...] use a NeXT and print it out. If you still want it online, you > can use WriteNow to save as an ascii file, but you still need to use > a NeXT to do that. ASCII file is OK, but Emacs info file would be better. Jacob -- Jacob Gore Jacob@Gore.Com {boulder,nucsrl}!gore!jacob
iyengar@russ.cis.upenn.edu (Anand Iyengar) (09/25/89)
In article <6247@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: >In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: ># bring it up in interactive mode. Pretty frightening, -i is INITIALIZE, ># and not interactive. >Correct, disk -i is initialize. I don't know why its frightening. Because it's inconsistant with things like rm and mv, which flag -i as interactive. The inconsistancy alone is no big deal, but since people are probably going to type it erroneously, it should be something more reversible. Anand. -- "Surely you're not happy: you no longer play the game." {arpa | bit}net: iyengar@eniac.seas.upenn.edu uucp: !$ | uunet --- Lbh guvax znlor vg'yy ybbx orggre ebg-guvegrrarg? ---
bruceh@zygot.ati.com (Bruce Henderson) (09/25/89)
In article <2420@ucsfcca.ucsf.edu>, jst@cca.ucsf.edu (Joe Stong) writes: > mention the content: It did NOT contain either helpful suggestions or > sympathy about my situation in maintaining a NeXT box. It merely > re-iterated observations that I had already made, and told me what I CANNOT > do with the NeXT box (namely remote system administration). I'd much rather > I would expect better public relations from a NeXT employee! I think that you need to realize that what you are trying to do is not the sort of thing that you should be doing, and try to get with the program . I can't pick my teeth with my toes, but it does not make me upset, nor does it give me any great desire to do so. The NeXT is not a generic Unix machine, and every new release of the System software takes it farther away from being like a generic workstation. If you REALLY want to be involved with NeXT machines, It would be in your best interest to learn the way things are intended to be done. And for pete's sake! don't give any of the NeXT employees who take THEIR OWN TIME to respond to postings in this group a bad time. Their apperance here is not condoned ny NeXT, Inc. and they do it out of the kindness of thier heart. -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bruce Henderson Software Engineer zygot!bruceh@Apple.COM "Sorry, Mathematica can't goon this much" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rock@lighthouse.com (Roger Rock Rosner) (09/25/89)
In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: >I got private mail from Avadis Tevanian, who appears to be a software >manager at NeXT. As it was private, I will not include it, but I will > [...various criticisms...] > >I would expect better public relations from a NeXT employee! I quite possibly do not fully appreciate the problems Joe is having, however I found his message unnecessarily critical of one of the net's most valuable resources. So to try to heal injured feelings, let me just say that I for one (and I think the net in general) am most grateful for Avie's (and Ali's) presence. They've done an excellent job helping dozens if not hundreds of people. Roger Rosner Lighthouse Design, Ltd. Usenet: ...!uunet!lighthouse!rock Internet: rock@lighthouse.com /* No disclaimer necessary--we all agree on this one. */
jgreely@oz.cis.ohio-state.edu (J Greely) (09/25/89)
In article <6247@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: >In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: >>It has an interestingly misleading help message, from which I might >>conclude that typing "disk -i /dev/rod0a" is a way to bring it up in >>interactive mode. Pretty frightening, -i is INITIALIZE, and not >>interactive. >Correct, disk -i is initialize. I don't know why its frightening. I do! Mostly because we fell for it when I got the 0.9 release disk. The problem with "disk" is that it was undocumented under 0.9, and all you got was the usage message (unchanged for 1.0), which looks like this: usage: /usr/etc/disk [option flags] [action flags] raw-device option flags: ... action flags: ... -i initialize disk ... interactive mode if no action flags specified example: /usr/etc/disk -i /dev/rod0a The key is the last two lines. "Oh, -i is interactive mode. That makes sense". One, I think it's silly for the example to be "initialize disk, no questions asked". It's not something you want to give a novice system administrator (or a tired one!). Two, the presence of the previous line makes it much more likely that someone will make a mistake. Three, if there weren't a proper manual page in 1.0 for this dangerous but useful command, I'd be screaming for blood. "But *sniff*, you will come back to play with us again, won't you?" "Of *course* I will! On the second Tuesday of next week." "Hooway! Hooway!" "Wait! The *second* Tuesday?" -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (09/26/89)
In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: >I got private mail from Avadis Tevanian, who appears to be a software >manager at NeXT. As it was private, I will not include it, but I will >mention the content: It did NOT contain either helpful suggestions or >sympathy about my situation in maintaining a NeXT box. It merely >re-iterated observations that I had already made, and told me what I CANNOT >do with the NeXT box (namely remote system administration). I'd much rather >be told what I *CAN* do to improve my situation. I don't have much choice >in doing remote system administration. > >I would expect better public relations from a NeXT employee! Alright Mr. Stong, I have had it with your problems. I have to do remote NeXT Admin. as well and I DO sympathize with your situation, but I am going to draw the line right here and now. Avi and Ali have both been FREQUENT and super contibutors to this net. You even stated yourself that Avi sent you direct mail. Now, when have you ever gotten more than a "please contact your dealer for more information" from Apple, IBM, or heck from anyone else for that matter. Contact your dealer means YOU pay the dealer to solve a problem, NeXT posts problems from the designers of the system to a free and public access forum like comp.sys.next. How often do you see this from Apple or IBM (I believe Mr. Sculley has made a significant point to RESTRICT such access vis a vis the BIX posting). I manage the country's largest single NeXT installation, 30 machines in one site, 5 at another, and 7 scattered across campus, and I do the entire thing remote...but on a NeXT! How could anyone expect you to manage a machine with a KNOWN and PRONOUNCED GUI with anything but a character acsii terminal. This is rediculous...witness your situation. I will now stop my flame. I fully encourage Ali and Avi to CONTINUE (please :-) their postings. They are an enormous effort and show NeXT's continuing committment to the University community. I think most readers here will share this view (I hope they would, just call Apple for a problem and watch them either ask you for a field certification number or a developer's agreement number...heck, Avi and Ali wrote the darn stuff and they tell us how to use this GREATTT box!) Thanks guys, continue the good work. As for Mr. Stong. I think I can solve most of your problems. Why don't you give me a call anytime from 8:00AM to 19:00 PM EST (sorry, I have to study sometime). Or send me mail directly and I'll try to answer as much as possible. Sorry about the flames, but I believe in this machine and I have to fight enough MAChooked people as it is...over a Network of dump AppleTalk no less. Forget it. Thanks Avi, Ali...good night John Boy! Roger Jagoda FQOJ@CORNELL.CIT.CORNELL.EDU (607) 255-8960 ************************************************************************ Working for, but in no way representing those who pay me: --Roger Jagoda, Cornell University-- ************************************************************************
epsilon@wet.UUCP (Eric P. Scott) (09/26/89)
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 <sys/param.h> 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 <disclaimer.h> #endif
aisl@uhura.cc.rochester.edu (Lawrence Landry) (09/26/89)
In article <2420@ucsfcca.ucsf.edu> jst@cca.ucsf.edu.UUCP (Joe Stong) writes: >I got private mail from Avadis Tevanian, who appears to be a software >manager at NeXT. As it was private, I will not include it, but I will >mention the content: It did NOT contain either helpful suggestions or >sympathy about my situation in maintaining a NeXT box. It merely >re-iterated observations that I had already made, and told me what I CANNOT >do with the NeXT box (namely remote system administration). I'd much rather >be told what I *CAN* do to improve my situation. I don't have much choice >in doing remote system administration. > If you look at the big picture of what NeXT is attempting to do with their operating system, you would realize that remote system administration over a tty line is kind of ridiculous. They are attempting to make system administration a user friendly graphical interface so that you don't have to be a UNIX guru to run your system. Along with everyone else, I have been frustrated from time to time because things are temporarily more clumsy than they were with the old way of doing things. I can sympathize with your problems but I agree with NeXT. They have other projects which will better serve more people than to add remote system administration. If you have a NeXT in your office, you can set up the machines that you administer so that you can run NetInfo, etc. from your MegaPixel display on the remote machine ushing the rsh command. This should solve most of your problems (provided that you have a cube.) -- Larry Landry University of Rochester
gft_robert@gsbacd.uchicago.edu (09/26/89)
In article <8932@batcomputer.tn.cornell.edu>, rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) writes... [...] >pay the dealer to solve a problem, NeXT posts problems from the designers >of the system to a free and public access forum like comp.sys.next. How >often do you see this from Apple or IBM (I believe Mr. Sculley has made >a significant point to RESTRICT such access vis a vis the BIX posting). [...] Actually, to set the record straight, Apple software engineers, programmers and technical support people are frequent posters to comp.sys.mac.programmer and comp.sys.mac, and provide a valuable service, as the NeXT people have been doing. Robert ------ gft_robert@gsbacd.uchicago.edu ----------------------------- generic disclaimer: all my opinions are mine
rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (10/01/89)
In article <5542@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >Actually, to set the record straight, Apple software engineers, programmers and >technical support people are frequent posters to comp.sys.mac.programmer and >comp.sys.mac, and provide a valuable service, as the NeXT people have been >doing. > For all of those who have set me straight, I humbly apologize. Since I am NOT a frequent reader of comp.sys.mac (there's well over 250 files each time I check it...:-0 ) I was not aware that Apple does indeed have systems people that post to the nets as well. For all those who have flamed, thanks for setting me straight. For tall those who haven't yet, please don't...:-) Roger Jagoda (humbled) Systems Analyst Cornell University FQOJ@CORNELLA.CIT.CORNELL.EDU (607) 255-8960