Path: utzoo!attcan!cmtl01!matrox!uvm-gen!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request From: srs!matt@uhura.cc.rochester.edu Newsgroups: comp.sys.sun Subject: Re: The Moderator Always Gets the Last Word Message-ID: <8901161947.AA03374@flash.srs.com> Date: 26 Jan 89 04:30:23 GMT Sender: usenet@rice.edu Organization: Sun-Spots Lines: 63 Approved: Sun-Spots@rice.edu Original-Date: Mon, 16 Jan 89 14:47:17 EST X-Sun-Spots-Digest: Volume 7, Issue 121, message 3 of 8 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