This is Next-Bugs in view mode; [Up]
Date: Sun 24-Sep-1989 02:10:04 From: Unknown Subject: Next Bugs 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! >From: avie@wb1.cs.cmu.edu (Avadis Tevanian)
Date: Sun 24-Sep-1989 08:34:29 From: Unknown Subject: Re: Next Bugs 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.
Date: Sun 24-Sep-1989 17:37:00 From: Unknown Subject: Re: Next Bugs / 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
Date: Sun 24-Sep-1989 17:36:12 From: Unknown Subject: Re: Next Bugs 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 Reid >From: iyengar@russ.cis.upenn.edu (Anand Iyengar)
Date: Sun 24-Sep-1989 19:36:31 From: Unknown Subject: Re: Next Bugs 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.
Date: Sun 24-Sep-1989 23:03:46 From: Unknown Subject: Re: Next Bugs 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.
Date: Sun 25-Sep-1989 03:24:07 From: Unknown Subject: Re: Next Bugs 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. /* No disclaimer necessary--we all agree on this one. */ >From: jgreely@oz.cis.ohio-state.edu (J Greely)
Date: Sun 25-Sep-1989 16:45:05 From: Unknown Subject: Re: Next Bugs 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 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) >From: davis@groucho.ucar.edu (Glenn P. Davis)
Date: Sun 26-Sep-1989 13:13:12 From: Unknown Subject: Re: Next Bugs 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.)
Date: Sun 26-Sep-1989 12:37:50 From: Unknown Subject: Re: Next Bugs 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 >From: gft_robert@gsbacd.uchicago.edu
Date: Sun 26-Sep-1989 16:25:55 From: Unknown Subject: Re: Next Bugs 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 >From: aisl@uhura.cc.rochester.edu (Lawrence Landry)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.