kcb@macaw.jhuapl.edu (Kevin C Brown x4700 1-e136) (01/26/89)
>I am finding that wnl's commentaries in messages are more irksome than >helpful these days. John, Your comments are out of line. Kevin Brown Applied Physics Laboratory Laurel, MD 20707 (301) 953-5000 ARPA: kcb@macaw.jhuapl.edu
matt@uhura.cc.rochester.edu (01/26/89)
Although I wouldn't go so far as John Gilmore, I too have been a bit disgruntled with wnl's comments as of late. So I decided to look through the v7 issues to find comments that I knew to be wrong or at the very least misleading. I found nine "errors" of varying severity. Briefly: 1) "Integer overflow is (I believe) not detectable in C", which isn't quite true, but it is difficult. 2) The various problems with a suid uudecode program. wnl doesn't mention the possible security hole opened when making uudecode non-suid (the "decode" alias). 3) /dev/rmt0 vs. /dev/rmt8. Both CAN hold about the same amount of data, it's just that the older QIC-11 drives that Sun sold were 4-track and thus DID hold less data than the QIC-11 (/dev/rmt0) and QIC-24 (/dev/nrm8) 9-track drives that Sun sells now. 4) wnl correctly stated that a problem with ftp wasn't due to the kernel trying to read /etc/hosts, but went on to suggest that the problem was tfpd trying to do so. In reality, it is ifconfig that needs this information. 5) A minor quibble about ncheck being faster than find, which turned out to be false. 6) The problem of trying to restore a /usr partition under SunOS 4.0. wnl gives good advice for 3.X, but the needed binaries (the most notable being restore) are not present in the root partition under 4.0. 7) The gaffe about 8-bit characters having always been supported by the Unix kernel, which wasn't quite true (from what I can gleam from the responses, it wasn't properly supported until 4.3? I'm still a little foggy on this.) 8) Not really an actual error, but mentioning the 's' vs. 'S' permissions on group access for directories and having no idea why they were there (SunOS 4.0 uses this bit to determine how a file created in such a directory will be assigned group ownership). 9) And, of course, we have the 4.3 fast "find" controversy... The funny thing here is that in the original message, wnl actually tried the "find name" usage and got: "/usr/lib/find/find.codes: No such file or directory" Instead of accusing the author of coming from the "twilight zone", wnl could have looked in /usr/lib/find to see what was really going on -- even though the behavior isn't documented anywhere (that's what I did). I'm sure there could be more, as I don't claim to be a Unix guru and we don't have a diverse collection of hardware sitting on our little Sun network. Now, I don't look at 9 "errors" as being that many for 100 issues. However, most of these occurred fairly recently. Overall, I think wnl is doing a wonderful job, and providing a wonderful service. I guess what I am saying is that one shouldn't answer questions unless they are sure of the answers. The problem with that advice is that people tend to think that they are absolutely correct, even when they aren't, until someone proves otherwise (and sometimes, even after that). I am starting to find the wording of some of wnl commentary a bit annoying, up to and including the latest, "[[ I would insert a comment here, but Mr. Gilmore doesn't want me to. --wnl ]]" which I find most inappropriate. I think just a little less commentary would be the appropriate solution... ----- Matt Goheen uucp: rutgers!rochester!srs!matt domain: srs!matt@cs.rochester.edu, matt@srs.uucp internet: matt%srs.uucp@harvard.harvard.edu
phil@Rice.edu (William LeFebvre) (01/26/89)
This is in response to the previous article by Matt Goheen. The comment I included in John Gilmore's article was a joke. Get it? Why are so many people on the net so serious? Lighten up a little. Enjoy life. Relax! As for your nine "errors", I think you are really stretching some of them to try and say they are incorrect. > 1) "Integer overflow is (I believe) not detectable in C" The fact that a simple arithmetic operation caused the overflow bit to be set is not detectable without standard compiler or run-time library support. Yes, you can check the values before or after and determine algorithmically if the computation would cause an overflow, but you cannot actually detect the overflow event. What I'm saying is that there is nothing like a PL/I "on error goto foo;" capability. And there is no way to convert an overflow into a Unix signal: the 680x0 doesn't support that sort of behavior. > 2) The various problems with a suid uudecode program. wnl doesn't mention > the possible security hole opened when making uudecode non-suid (the > "decode" alias). There are many things that I don't mention, especially in a comment that is intended to be brief. First you tell me I put in too many comments, then you fault me for not making the comments thorough enough? You can't have it both ways, fellah. > 7) The gaffe about 8-bit characters having always been supported by the > Unix kernel, which wasn't quite true (from what I can gleam from the > responses, it wasn't properly supported until 4.3? I'm still a little > foggy on this.) Yes, this was a genuine (and rather serious) mistake. I know for an absolute and definite fact that 8-bit names were legal under 4.1. The only byte values that were not allowed were 0, '/', and '/'+0200. I cna't speak authoritatively about previous versions of Bell and BSD Unix. The change happened with 4.2 BSD and was carried over into SunOS. > 8) Not really an actual error, but mentioning the 's' vs. 'S' permissions > on group access for directories and having no idea why they were there As you said, "not really an actual error". Am I also to be faulted for admitting my ignorance? William LeFebvre <phil@Rice.edu>
vern@acacia.lbl.gov (Vern Paxson) (01/26/89)
gnu@toad.com writes: > ... > I am finding that wnl's commentaries in messages are more irksome than > helpful these days. This message is just a vote of confidence to say that I haven't noticed any such irksome messages on your part and prefer your current style of editing as opposed to that which he suggests. Hang in there! Vern Vern Paxson vern@lbl-csam.arpa Real Time Systems ucbvax!lbl-csam.arpa!vern Lawrence Berkeley Laboratory (415) 486-6411
shn@think.com (01/26/89)
> gnu@toad.com writes "I am finding that wnl's commentaries in messages are > more irksome than helpful these days." A couple of comments. I treat all suggestions from the net with the same suspicion, no matter who writes them. Nobody here is batting 1.000. The moderator can save everyone a lot of time by sending a quick responce in the comments. Otherwise, the sender might get one hundred repsonces to the obvious question. I am sure wnl spends a lot of time running Sun-Spots, but if gnu@toad.com would like to take his place, I am sure wnl would like the spare time. Personally I would like to thank wnl for his performance given the volumn of mail he processes *every day*, including weekends. Sam Nuwayser (shn@think.com) Thinking Machines Corporation
wwtz@uunet.uu.net (Wolfgang Wetz) (01/26/89)
gnu@toad.com writes: >I am finding that wnl's commentaries in messages are more irksome than >helpful these days. ..... rest of message deleted I think, you are wrong. To me wnl's comments and notes are very helpful and I appreciate very much his effort by adding comments and explanations. Especially to newcomers his comments and notes are of great value because they give a better feeling on how to categorize the information contained in the articles. >[[ I would insert a comment here, but Mr. Gilmore doesn't want me to. >--wnl ]] I hope that you, dear William, continue to make comments; I'd bet that the majority likes them. Let me take the opportunity to thankyou for the great job you are doing. therefore: the moderator gets the last word - a VERY GOOD idea! In case he really *is* wrong: there is a way to submit a followup, isn't it? Wolfgang Wetz, Systems Administrator, Scientific Computing Centre c/o CIBA-GEIGY AG, R-1045.330, CH-4002 Basel, Switzerland Internet: wwtz%cgch.uucp@uunet.uu.net UUCP: ...!mcvax!cernvax!cgch!wwtz Phone: (+41) 61 697 54 25 BITNET: wwtz%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 32 88
gam@uunet.uu.net (Gregory Miller) (01/26/89)
Recently John Gilmore (gnu@toad.com) contributed: >"I am finding that wnl's commentaries in messages are more irksome than >helpful these days. Partly this is because his error rate is way up; up >to half of the recent comments, by my random accounting, are wrong in one >way or another. ****" All in all I think Mr. LeFebvre efforts to provide this valuable service to us should be applauded, however, I agree with the essence of Mr. Gilmore's assertion with an additional comment. I think Mr. LeFebvre must bear in mind the apparent authority that runs with being a moderator. For those gurus out there, the transparency of such authority may be readily apparent; for the more common class of us (and more so for the new readers or neophytes), we respect Bill and give his comments a default value of validity. Therefore, one can be somewhat shaken to discover an error in the moderator's comments. This tends to deteriorate whatever credibility he has built up. On the other hand, I appreciate Bill's apparent objectivity and ability to sustain a little constructive criticism by supplying Mr. Gilmore's comments. The important caveat for all of us is to remember that egos tend to run high in this profession, and yet we are all human and subject to mistake. Unfortunately for Mr. LeFebvre, his mistakes are more glaring because of his visibility. And so perhaps Mr. Gilmore's next suggestion is a very good one: >I would personally prefer if the moderator's comments were limited to >pointers to answers (e.g. [[ See Sun-Spots v5n33 about this....]]) >without adding facts or opinions in the middle of other peoples' messages. >If something really deserves comment, rather than just gossip, the >moderator's comments should appear just like any other message in the >digest or newsgroup -- and with the same delay. Here, here. There is no reason why Mr. LeFebvre cannot identify himself as the moderator in his own separate submissions. And I suspect that delaying his own response an issue or two will serve a measure of equality. Unfortunately, due to his own hectic schedule, and efforts in putting this digest out, he has hastily responded incorrectly; this has dampened the effectiveness of his in-line commentary. Therefore, I too call for Bill to carefully measure his commentary, and reserve regular response to the standard forum and submission procedures. A moderator's job is to keep a smooth and fair flow of information and not to prepare it or adjust it by his own commentary so to position the material in a light favorable to anyone. In six years of reading netnews, I have never seen a better use of the medium than Sunspots. It has proven its worth time and again. All in all I think Bill LeFebvre has made an outstanding effort in an otherwise thankless service support type position. Keep up the good work, but measure your response - perhaps the less said, the better. We know you are one of the ranking experts and it doesn't need to be proved at the risk of ruining credibility over a rash of goofs. :-) Gregory Miller UUCP: get-it-to!sun!nosun!cvedc!gam Technical Staff INTERNET: gmiller@cvbnet.prime.com PRIME/Computervision Electronics AT&T: 503/645-2410 Development Center FAX: 503/645-4734 14952 NW Greenbrier Parkway Beaverton, Oregon USA 97006-5733 #include disclaimers.h [[ Believe me, I do not insert comments like this just to inflate my ego. I do it primarily to hold down traffic on the list by providing a (hopefully correct) answer to a simple question. My primary motivation for these comments is the interests of the general Sun-Spots readership. Take it from one who knows, anyone who moderates a list solely to inflate his or her own ego isn't going to last very long (especially if the list has a large volume). --wnl ]]
mac@mrk.ardent.com (Michael McNamara) (02/03/89)
Since all these people are nit picking at wnl's comments, I'll nit at his detractors comments... In article <8901161947.AA03374@flash.srs.com> srs!matt@uhura.cc.rochester.edu writes: > Although I wouldn't go so far as John Gilmore, I too have been a bit > disgruntled with wnl's comments as of late. So I decided to look through > the v7 issues to find comments that I knew to be wrong or at the very > least misleading.... ... > 3) /dev/rmt0 vs. /dev/rmt8. Both CAN hold about the same amount of > data, it's just that the older QIC-11 drives that Sun sold were > 4-track and thus DID hold less data than the QIC-11 (/dev/rmt0) > and QIC-24 (/dev/nrm8) 9-track drives that Sun sells now. Sorry, Matt, but you are *very* wrong. /dev/rmt0 holds about 1/4 as much data as /dev/rmt8. rmt0 refers 1600 BPI on the nine track reel to reel tape drive, and rmt8 to 6250 BPI on that same drive. /dev/rst? is the SCSI QIC-11/24 drive. >From the mt man page : (so few people seem to have these things these days :-) FILES /dev/rmt* Raw magnetic tape interface /dev/rar* Raw Archive cartridge tape interface /dev/rst* Raw SCSI tape interface /dev/rxt* Raw Xylogics tape interface Just remember, when you critique someone else, run your mail through spell(1)!!! Michael McNamara mac@ardent.com [[ Thank you. I had missed that. Just proves that none of use, not moderators nor even their critics, are perfect. --wnl ]]