The Moderator Always Gets the Last Word

[srs!matt at uhura.cc.rochester.edu]

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 at cs.rochester.edu, matt at srs.uucp
internet:	matt%srs.uucp at harvard.harvard.edu