Path: utzoo!utgpu!watmath!uunet!lll-winken!killer!texbell!loci!clb From: clb@loci.UUCP (Charles Brunow) Newsgroups: unix-pc.general Subject: Re: login clone vs. Chuck Brunow Summary: Can smoke obscure lousy code? Message-ID: <198@loci.UUCP> Date: 6 Dec 88 22:05:04 GMT References: <9139@rpp386.Dallas.TX.US> Distribution: na Organization: Loci Products, 75083 Lines: 184 In article <9139@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >Quite a few of you wrote want to know what Chuck Brunow had against the >login package I've been working on, and why he was on this religious >campaign. I thought I might also add a few words of general freeware >wisdom. Actually I doubt that anyone cares except the "Tin-foil Cowboy" himself, but since this is a subject that only I can answer authoritatively, I'll waste a couple of minutes on the subject. As my posting was a mere three lines saying, in effect, the program is suspect and should be inspected, the appropriate subject is the software. However, john haugh lives in the sewer of alt.flame and can't tell the difference between flames and software and responds by trying to put up a smoke screen of lies and distortions. He does this a great deal in order to obscure his numerous failures, and I am but one of his many targets. Greg Woods has the right idea about how to deal with him, ... In article <8187@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: [ wild, unfounded accusations against Rick Adams and Greg Woods] In article <895@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > Whether it is true or not, you have slandered my name in public by making >such a charge, and I demand to see your evidence. I claim you're full of it. To quickly brush aside the drivel and for the benefit of those who aren't familiar with haugh, aka "Beach Bum", I'll give a brief rule for interpreting haugh; he hasn't any imagination so there is SOME truth in everything he says but it is he who does the things he likes to accuse many others with. In other words, to read between the lines, substitute his name for whom- ever he is ranting about and you'll be close to the truth. Now let's quickly deal with the meat of the subject: is the "software" being pushed worth having, even if it's free? As a side note, the recent "worm" was free, and I don't think that anyone can say that "free makes it good". In the excerpt below, haugh credits Dennis Mumaugh for being the author of the software which is being misrepresented as his in this group, and Dennis points out some portability problems that have surfaced. As I said "I recommend that you check this program very carefully." >In article <8693@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >> I got impatient. Attached is my clone which I'll be including in the soon >> to be released login clone. The routines were all very simple, I didn't >> see any point in holding out ... >> >> This was all written straight off of Dennis' article. You may do with it >> as you please. So much for security by obscurity [ Thanks James ... ] >> It is as simple minded as possible, your suggestions, as always, are >> more than welcome. >> >> - John. >A colleague contacted me and expressed concern that the >implementation of /etc/shadow might not exactly reflect that of >AT&T. I checked John's version of shadow.h and discovered a >small difference over the "Official" shadow.h. For those with >sizeof(int) == sizeof(long) there is no problem but "All's the >world is not a VAX [or 3B2]." Here is the changed shadow.h: > ... ># End of shell archive -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com Dennis puts a bit more explanation in response to another person's port of this program ... >>In article <1358@tmpmbx.UUCP> pengo@tmpmbx.UUCP (Hans H. Huebner) writes: >> Hello, >> >> here is my shadow password file library. It should be System V R3.2 >> compatible. I haven't seen the original manual pages, thus there might be >> some discrepancies. Please let me know if you have compatibility >> suggestions. >> >> I have written and tested this on XENIX System V. There is a raw XENIX >> Makefile included. There should be no problems in getting this to run on >> BSD systems. Correct me, if I'm wrong. >> >> Thanks, >> Hans >> > >Please see my article <2233@cuuxb.ATT.COM> for a small fix to >shadow.h: Change all ints in the spwd struct to long. >-- >=Dennis L. Mumaugh > Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com Maybe someone thought I was kidding when I said that haugh uses xenix rather that real Unix. Observe his words ... >Submitted-by: "The Beach Bum">Archive-name: xenix.w > >i have hacked the hell out of your "w" command to produce one which >works on sco xenix for a '386. i don't know what order you will >receive the submissions in, but this is one of two. the other is >a fuser command. oh yes, both of them need to be re-wrapped because >my shar doesn't know about the perils of being mailed about. > Ok, he uses xenix, which is known to differ from Unix, he writes for a '386 which is very different from a 68010, he can't write a "shar" that works, and ... > >No Makefile; the compile commands are trivial: What a guy! No Makefile. > Briefly, some of the known bugs ... >.SH BUGS >JCPU and current process are both kludges. The former is really only the >CPU of running programs in the terminal session, as Xenix does not retain >user and system times for all programs in a session; the latter attempts to >disregard background processes, but it is nearly impossible to successfully >determine if a program is in the background or not. This is exacerbated by >the fact that VAR csh(1)'s, when available, look suspiciously like >background processes because they close their standard input. Sounds nice, eh? There's more ... >If the user block is demand paged, 'w' won't find it; >I don't have access to a demand-paged system. That's nice. And who does have demand paging? Bingo! Anyway, skipping down a bit ... >If you want "w" to work correctly, get 4.2BSD. >Because Xenix lacks the appropriate kernel variables, load averages are >not available. Now, remember where haugh said you could use the program for any purpose? Check this out ... >.SH CREDIT >Based on a utility written at the University of California at Berkeley. >Original written by Brandon S. Allbery. >Modified for SCO Xenix 386 by John F. Haugh II (jfh@rpp386). >SHAR_EOF >cat << \SHAR_EOF > 'w.c' >/* > * %W% %E% %U% ncoast!bsa %Z% > * %Z% Copyright (C) 1985 by Brandon S. Allbery, All Rights Reserved %Z% > * > * 8-Jul-88 John F. Haugh II (jfh@rpp386) > * Major hacks to force to work on SCO Xenix 386 > */ >#define KERNEL "/xenix" Alright, so who invited this babboon into the unix-pc groups anyway? What a public service you have done. Clearly who ever it was (both of you) don't know anything about the evaluation of software because the subject strayed far from it. I suggest that you use the stuff; go right ahead. But for anyone with good sense, don't touch it with a stick. And as far as haugh's opinion's ... In article <8880@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >Hmmm. Maybe I should replay my 'Oh My God, I Need The Practice' flame of >this past summer. Any votes? It was such a *NICE* flame ... ... go play in the sewer with him if you like; I'd prefer to use my time for something useful. While he was having his fun in alt.flame, I released yet another program to the net. If you haven't heard, it's called "birdie" and dozens of people requested (and received it) world-wide. My next program, under development currently, is a set of graphics utilities for the 3b1, with tie-in's to "Paint Power", MacPaint, PBM, PKM, and other formats. Lot's of modular code makes it very flexible, and it understands the 7300; the question is whether or not the readers of this group appreciate good code. Will I get flamed again if I express another opinion? Natch! -- -- #_\_@\\/\_@\\/\_@\ Charles Brunow Loci Products # /--u// --u// --o/ clb@loci.UUCP POB 833846-131 # _ __ _ _ __ __ __ ..!uunet!texbell!loci!clb Richardson, Texas 75083