rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (10/06/89)
Folks, I have a few more bugs to report concerning 1.0. Has anyone seen similar problems or know of work-arounds? 1) Our NetInfo configuration server seems to have problems with the new NetInfo routines. If I power down the other three clients it serves, then power the configuration server down. On power-up, the config. server will fail somewhere in /etc/rc script. It will get through until nmserver and portmap calls. The it stops with an error: No netserver found, call your network admin- istrator. No netserver found, call your network admin- istrator. It DOES finish boot up and allows logins, but of course doesn't know about any other hosts or printers or anything else loaded into "/" domain. It doesn't execute fstab.net because those are "unknown hosts" (the actual error was : "host unknown"), and ifconfig DOES show the proper en0 configuration, which is really strange. After a reboot, this problem goes away, i.e the server seems to read /etc/netinfo/network. nidb abd remember itself. In /etc/hostconfig I have NETMASTER=-YES- . For the clients this is set to -NO-. Another strange bug involved here is that clients can't "talk" to the server. If a client issues "talk <user>@cinfugserver" the error comes back "remote host doesn't recognize us". Which of course it should since both the user and the machine are niloaded into "/". I suppose the solution to his would be to clone the netinfo database, but we haven't tested that yet. Under 0.9 nidomain -c wasn't at all reliable so I'm leary. Now, I should mention that I have not corrected talk-->ntalk as in 0.9 and I have NOT selected PublicWindow Server everywhere as in 0.9, could that be the problem? What does being a PublicWindow Server allow/ disallow. What does it do if you're NOT a PWS? 2) On the NetInfo Server, when loggeed in as root, if I try to launch NetInfoManager from the dock or from the Browser, I ALWAYS get the following error dialogue box: NetInfo Error: Domain selected failed on open I have to click abort to see that the App has failed to open the NetInfo config. server's "." domain. I'm logged in as root on the config. server, I should be able to open ANY domain, especially the one on the same machine! The weird part is that if I open the Window panel, I can look into "/" or "." easily with no error message. Is this related to #1? Have I made an error in configuring the NetInfo config. server? I did the same thing in 0.9 and it all worked? Hmmm.... 3) During the Install_TeX script, the basic installation worksfine, but when users are instructed to type /usr/lib/tex/Make_Fonts they should be willing to WAIT. the basic.set build takes six hours, and that's on a machine with 16MB of RAM and 660MB of drive! The build for the full.set (all the fonts) just took too long. When I cntrl-c I get some error about there being a problem unpacking one of the fonts. It takes three cntrl-c's to kill this script! 4) Trying to use lpr to print TeX dvi files crashed the lpd deamon. If I use lpr -d as described in man pages for lpr, I kill the daemon. I was told this would be fixed in 1.0 as I posted it before under 0.9! The work-around has been/still is to use dvips and print using Preview. BooHiss. Also, TeXView allows no PRINT options...what a waste! 5) Sometimes on bootup, I see the following error from my diskless clients; nfsgetremotehost() error 13 can't find root file handle. Now, I've lived with this error under 0.9 and I see it under 1.0. NetInfo has the bootparams and bootptab info it needs and all the other diskless clients boot when this happens (it's random, but always the same fix:). The fix is to open the particular host entry under NetManager, make some trivial change in the bootparams field, then save the change. This works mosts times, but I would still like to know from anyone who have source access, what is error 13 from nfsgetremotehosts(). Avie? Is this nfs call something embedding in kernel or I patch it with the proper address? Thanks in advance for these and other problems. Oh, lastly, we upgraded our cube to 16MB but haven't seen any improvements in response time (i.e., Mathmatica still thrashes the disk and printing off the same cube still drags the WindowManager to a halt). Is there something I have to tell the kernel to make better use of this memeory? Under AIX and AUX I had to changes amount of buffer spaces and oterh things, do I have to repeat something similar for MACH? Thanks, just want to make the best use of our investment. Keep those letters and cards coming. Roger Jagoda Systems Analyst 220 CCC/Garden Ave Cornell University Ithaca, NY 14853 (607) 255-8960 FQOJ@CORNELLA.CIT.CORNELL.EDU
erica@kong.gatech.edu (Erica Liebman) (10/06/89)
I am pretty surprised that I have not (as yet) seen an outpouring of general use public-domain or shareware software. Is it that no one is writing it, posting it or I haven't gotten in on the correct channels? Or is it that NeXT hasn't settled its marketing strategy. I've come up with several programs, but don't know what to do next (no pun) with them. Ideas? -- Erica (erica@kong.gatech.edu) // grep foo!
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (10/06/89)
rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) writes: > 3) During the Install_TeX script, the basic > installation worksfine, but when users are > instructed to type /usr/lib/tex/Make_Fonts > they should be willing to WAIT. the basic.set > build takes six hours, and that's on a machine > with 16MB of RAM and 660MB of drive! The build > for the full.set (all the fonts) just took too > long. When I cntrl-c I get some error about there > being a problem unpacking one of the fonts. It > takes three cntrl-c's to kill this script! It does take a while. It warns you about that during the script. And killing the script isn't easy because the various programs have their own idea about how to handle a control-C. The amount of time it takes is commeasurate with the speed of the machine, though; I won't tell you how long it takes my Amiga to generate the same set of fonts. Luckily, both the Amiga and the NeXT machine are fully multitasking so the fonts can run in the background without disturbing operations excessively. And the script is written so it can be restarted without having to remake the fonts that already exist. > 4) Trying to use lpr to print TeX dvi files > crashed the lpd deamon. If I use lpr -d as > described in man pages for lpr, I kill the > daemon. I was told this would be fixed in > 1.0 as I posted it before under 0.9! The > work-around has been/still is to use dvips > and print using Preview. BooHiss. Also, TeXView > allows no PRINT options...what a waste! The lpr daemon has no idea what dvi files are. Use dvips. (As shipped, `dvips foo' will send the output to your current `lpr' default printer. This is easily changed in /usr/lib/tex/config.ps.) I believe it is possible to make lpr spool dvi files correctly, in the same manner you would do this on any other Unix system. Full source is provided for TeXview; adding a Print option is as simple as putting up a panel and then executing `dvips'. Perhaps this will appear in a future version. Of general interest: a new version of dvips and TeXview is available on Radical Eye Radio, at (415) 32-AMIGA. Discussion on desired features, possible bugs, and future directions is welcomed. So is source code for new features (preferably in diff -c format) since full source for TeXview and dvips is provided. > Roger Jagoda Thank you for your comments. -tom
phd_ivo@gsbacd.uchicago.edu (10/06/89)
>> BooHiss. Also, TeXView >> allows no PRINT options...what a waste! Let me make the point that, to the best of my knowledge, Tom is not being paid or employed by NeXT. So, his TeX port comes more or less as an unsupported goody, created by a kind-hearted volunteer. I also think that Tom's TeX implementation is quite decent. It's definitely on par with many commercial versions of TeX. Thanks, Tom... /ivo