🚀 go-pugleaf

In article <1992Oct18.133444.8688@vpnet.chi.il.us> lisbon@vpnet.chi.il.us (Gerry Swetsky) writes:
>karl@ddsw1.mcs.com (Karl Denninger) writes:
>>lisbon@vpnet.chi.il.us (Gerry Swetsky) writes:
>>>kdenning@portal.hq.videocart.com (Karl Denninger) writes:
>>>>lisbon@vpnet.chi.il.us (Gerry Swetsky) writes:
>>>>>karl@ddsw1.MCS.COM writes:
>>>>
>>>>No, that was karl@portal.hq.videocart.com, but that's ok.  We all make
>>>>mistakes. :-)
>>>
>>>    *I* didn't write that!  That's the way it came!  Don't you remember
>>>    where you posted from?
>>
>>I most certainly DO remember where I posted from; when I forget could
>>someone please call the funny farm? :-)
>
>    Obviously it's time, Karl.  The only thing I do to the *quote line*
>    in articles I respond to here is a 3dW to remove the first part of
>    the line so that Akcs - a program you wrote - will not reject it!
>    Did you get that, Karl?  A program YOU wrote!  Obviously, dealing 
>    with news headers is not your strong suit.

Remove the first part of the line?  Excuse me?  What are you talking about?

AKCS does properly understand news headers.  If you disagree, DOCUMENT your
discrepancy and report it via email.  "3dW" doesn't document or explain 
anything.

IF you do this it will receive proper attention and be fixed.

Greg Gulik has pointed out that "trn" does some odd things with attributions
when there is a "Reply-To" header present.  Ok, so it wasn't intentional.
Granted.

I still didn't write the article here!

>    That was only one of the several things that was wrong with Akcs
>    that I've been complaining about and never got any satisfaction on.
>    Even while I was paying you for product support!

Gerry, that's unadulterated nonsense.  Since you have now taken the issue 
public I will reply in kind:

1)	Your last support check for AKCS was received here on 1/1/91.  It
	ran for one year.  That means that as of 1/1/92 you were no longer
	on support.  You have in fact refused to renew it.  Further, I have 
	in the past granted you support even though you were not up to date 
	(in '89) and "forgave" about 6 months of support charges that you 
	didn't want to pay -- but still kept sending updates.  You've 
	groused about there being a charge for update service ever since.

	If that isn't enough, you have only once (in 1987) been charged the 
	standard update costs on the product as the list price (and feature 
	set) advanced over time.  I have the records going back to 6/30/1987 
	when you had a 3b1.  The remainder of the updates were comp'd to you 
	and Vpnet against MCS' standard policies of the time -- on the 
	condition that you would assist us in running problems down and 
	serve as a linked site.

	Obviously that isn't something you're interested in doing now.

2)	You have had >installation-related< problems with the product.  
	Admitted.  The installation scripts and documentation have been at
	times been vague or incomplete.  There was, if I remember, a 
	permissions-related problem which a user on your system found.  I 
	gave you a way to work around it via email.  You IGNORED the 
	work-around and left the permissions problem (and the resulting 
	security problem) open to all comers.  Months later (or was it over
	a a year?)  you bashed me for not fixing the problem -- yet the fix 
	WAS given to you on 11 January 1992 (change the group the AKCS 
	product operates under, and change one directory's permissions).  
	The entire installation manual has since been re-written, and the 
	scripts re-done.  It is now difficult to do what ended up happining
	at Vpnet with regards to this issue.

3)	There has been an intermittent problem with the summary file sizes
	on and off.  I have asked you for assistance, such as a forced core
	dump or other analytical assistance, for nearly two years.  It was not
	forthcoming.  FINALLY, with the help of another customer who WAS 
	cooperative and interested in fixing the problem it was found and 
	fixed about two months ago.  This was an >extremely< difficult problem
	to find -- it affected only summary file sizes, not operational 
	integrity, and left no obvious traceback to follow.

	When I announced that I had found it, and offered to place you back
	on support WITHOUT CHARGING YOU FOR THE YEAR YOU WEREN'T ON IT (which
	is standard procedure) you refused and instead demanded that I give 
	you the update free -- an update which hasn't even been qualified on 
	SVR3.2 machines yet.  It >IS< available on V.4 systems.  
	
	Again, I had offered to violate my policy and do something "nice" -- 
	because in fact the problem HAD been known to exist (but not the fix)
	while you were covered.

4)	There have been RFC-complience problems with >inbound< Usenet
	messages, and one violation of the RFCs on outbound messages -- 
	back in version 6, which is over three years old now.  History?  
	I would say so.  Relavent today?  Nope.

5)	The proper response to a message which does not fit the definition
	of an RFC-complient news article is to dump it.  AKCS' filters do
	this, although they will tolerate >some< problems that can be
	corrected.  They will not tolerate all of them.  IF your editor
	chooses to insert line breaks in non-standard places inside a
	header (without following correct continuation practice) that is 
	your problem (this is one problem I am aware of, and it is a clear 
	violation of the RFCs in question -- on the part of the poster, not 
	the gateway).  As an aside, some versions of news software will ALSO
	break if you do this.  You reported this on 6 September 1991, and
	the cause was diagnosed and sent back to you on 8 Sept.  The problem
	was a mangled references line >before< it hit the gateway.

6)	I offered on 10 September to comp you an update to the SVR4 release
	of the AKCS product since you had reported the file problem and one
	other related to "tedit".  FOR FREE.  ZERO dollars.  You weren't sure 
	if you could run ELF binaries and said you'd get back to me.  I asked 
	you to do that on 14 September.  No response as of yet.  The problem
	with "tedit" was traced to a seg fault in a system shared library
	with no traceback -- that might not even be the software's fault!
	It has NOT been reported anywhere else.

Enough said.  Let the people who read this judge for themselves whether or
not I've been more than fair on the issues.  I choose not to respond to
further attacks on this subject.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions