login clone vs. Chuck Brunow

Charles Brunow clb at loci.UUCP
Wed Dec 7 08:05:04 AEST 1988


In article <9139 at rpp386.Dallas.TX.US>, jfh at 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 at rpp386.Dallas.TX.US> jfh at rpp386.Dallas.TX.US (The Beach Bum) writes:
	[ wild, unfounded accusations against Rick Adams and Greg Woods]

In article <895 at ncar.ucar.edu> woods at 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 at rpp386.Dallas.TX.US> jfh at 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 at arpa.att.com

	Dennis puts a bit more explanation in response to another
	person's port of this program ...

>>In article <1358 at tmpmbx.UUCP> pengo at 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 at 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 at 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" <jfh at rpp386.UUCP>
>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 at 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 at 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 at rpp386.Dallas.TX.US> jfh at 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 at loci.UUCP                  POB 833846-131
# _ __  _ _ __  __ __   ..!uunet!texbell!loci!clb    Richardson, Texas 75083



More information about the Unix-pc.general mailing list