On Wed, 14 May 2025 16:50:23 -0500, olcott wrote:

On 5/14/2025 4:16 PM, dbush wrote:

On 5/14/2025 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts.
Huboy,
what a train wreck.  (But like a train wreck, it's hard to look
away, which might explain how this has been going on for 20(?)
years.)

I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
Mikko, and anybody else I've forgotten for trying to explain to Mr. >>>>>> Olcott and Mr. Flibble how you all see their claims.  I wanted to >>>>>> point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating
input and halts.  But others (I forget who) report that -- due to a >>>>>> bug -- D would actually terminate on its own.  His HHH simulator
therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own,
and that's a consequence of PO's intended design.  (Yes, there are
bugs, but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug (rather >>>> than e.g. a design error) is entirely dependent on the program's
specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then

And *yet again* you lie by implying Sipser agrees with your
interpretation of the above when definitive proof has been repeatedly
provided that he did not:

On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

I exchanged emails with him about this. He does not agree with
anything substantive that PO has written. I won't quote him, as I
don't have permission, but he was, let's say... forthright, in his
reply to me.

Your dishonesty knows no bounds.

Ben knows that Professor Sisper does agree with my meaning of my words
and that got Ben all riled up.
Ben was convinced that I tricked professor Sipser into agreeing with
these words.

THE COMPLETE PROOF THAT PROFESSOR SIPSER DOES AGREE WITH MY MEANING MY
MY WORDS IS THAT THE EXACT WORDS ONLY HAVE ONE MEANING.

Pathological input is undecidable just not for the reason given by Turing.
You are wrong to treat it as non-halting.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/14/25 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts.
Huboy,
what a train wreck.  (But like a train wreck, it's hard to look
away, which might explain how this has been going on for 20(?) years.) >>>>
I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
Mikko, and anybody else I've forgotten for trying to explain to
Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to >>>> point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating
input and halts.  But others (I forget who) report that -- due
to a bug -- D would actually terminate on its own.  His HHH
simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own, and
that's a consequence of PO's intended design.  (Yes, there are bugs,
but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug (rather
than e.g. a design error) is entirely dependent on the program's
specification.

void DDD()
{
  HHH(DDD);
  return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D
    would never stop running unless aborted then

Since you DDD isn't a program, since you say that it doesn't include the
HHH that it calls, means that you can't use this, since here D *IS* a
program, as that is from the defintion of a Halt Decider, its input is
the representation OF A PROGRAM.

I did not notice how all of the rebuttals of this have
always committed the straw-man error until yesterday.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A correct simulation has always meant that according
to the rules of the x86 language HHH must emulate
itself emulating DDD.

Right, which fails at the call to HHH, which MUST go into HHH, but CAN'T
since that isn't in DDD, and thus a correct emulation of *DDD* can't go
outside it,

A correct simulation has NEVER meant that HHH
can interpret "call 000015d2" to mean "jmp 00002183".

Right, it needs to push the PC onto the stack and then go to 000015D2,
but that isn't part of the input, so it can't.

Yet all of my reviewers say that HHH must do
something like this so that the behavior of DDD
correctly emulated by HHH matches the directly
executed DDD().

No, we say it must go to 000015D2.

Where are you getting the claim of jmp 00002183?

That seems to be just another of your lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/14/25 10:10 PM, olcott wrote:

On 5/14/2025 8:55 PM, Richard Damon wrote:

On 5/14/25 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts.
Huboy,
what a train wreck.  (But like a train wreck, it's hard to look
away, which might explain how this has been going on for 20(?)
years.)

I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
Mikko, and anybody else I've forgotten for trying to explain to
Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to >>>>>> point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating
input and halts.  But others (I forget who) report that -- due
to a bug -- D would actually terminate on its own.  His HHH
simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own,
and that's a consequence of PO's intended design.  (Yes, there are
bugs, but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug
(rather than e.g. a design error) is entirely dependent on the
program's specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then

Since you DDD isn't a program, since you say that it doesn't include
the HHH that it calls, means that you can't use this, since here D
*IS* a program, as that is from the defintion of a Halt Decider, its
input is the representation OF A PROGRAM.

I did not notice how all of the rebuttals of this have
always committed the straw-man error until yesterday.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A correct simulation has always meant that according
to the rules of the x86 language HHH must emulate
itself emulating DDD.

Right, which fails at the call to HHH,

Liar!

So, how does it LEGALLY do it?

The code of HHH is not part of the input, so HHH can not correctly
emulate its input *DDD* and go somewhere else.

If you were told to measure how much pipe was underground, and you
measured all the way up to the upstairs bathroom, you just measured the
wrong thing.

WHen asked about the simulation of "DDD", then you must only look at DDD.

If the code is supposed to be part of what you are to look at, it needs
to be part of the input.

Since you have EXPLICITLY said it isn't, you can't look at it, unless of
course you admitt that you logic is based on lying about the defintions
of things.

Until you actually answer some of these questions, the only possible
answer is that you are just a liar with no proper basis for your claims.

If you don't understand something I say, ask for clarification.

If you disagree with my definitions, point that out and provide a
reliable source for something that you do agree with.

Otherwise, you are just proving that you are just a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/05/2025 03:10, olcott wrote:

<snip>

Liar!

As arguments go, that one's less convincing than you might think.


If you can't lucidly explain why Mr Damon is at odds with the
facts (and it seems you can't), we have to consider the strong
possibility that he isn't.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-14 21:50:23 +0000, olcott said:

On 5/14/2025 4:16 PM, dbush wrote:

On 5/14/2025 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts. Huboy, >>>>>> what a train wreck.  (But like a train wreck, it's hard to look
away, which might explain how this has been going on for 20(?) years.) >>>>>>
I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
Mikko, and anybody else I've forgotten for trying to explain to
Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to >>>>>> point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating
input and halts.  But others (I forget who) report that -- due
to a bug -- D would actually terminate on its own.  His HHH
simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own, and >>>>> that's a consequence of PO's intended design.  (Yes, there are bugs, >>>>> but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug (rather >>>> than e.g. a design error) is entirely dependent on the program's
specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then

And *yet again* you lie by implying Sipser agrees with your
interpretation of the above when definitive proof has been repeatedly
provided that he did not:

On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

I exchanged emails with him about this. He does not agree with anything
substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.

Your dishonesty knows no bounds.

Ben knows that Professor Sisper does agree with my
meaning of my words and that got Ben all riled up.
Ben was convinced that I tricked professor Sipser
into agreeing with these words.

THE COMPLETE PROOF THAT PROFESSOR SIPSER DOES
AGREE WITH MY MEANING MY MY WORDS IS THAT
THE EXACT WORDS ONLY HAVE ONE MEANING.

Do you agree that the meaning of the word "would" includes that
something in the same clause is counter-factual?

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 15.mei.2025 om 06:00 schreef olcott:

On 5/14/2025 10:00 PM, Richard Damon wrote:

On 5/14/25 10:10 PM, olcott wrote:

On 5/14/2025 8:55 PM, Richard Damon wrote:

On 5/14/25 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts. >>>>>>>> Huboy,
what a train wreck.  (But like a train wreck, it's hard to look >>>>>>>> away, which might explain how this has been going on for 20(?) >>>>>>>> years.)

I want to thank both Richard's, wij, dbush, Mike, Keith, Fred, >>>>>>>> Mikko, and anybody else I've forgotten for trying to explain to >>>>>>>> Mr. Olcott and Mr. Flibble how you all see their claims.  I
wanted to
point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating >>>>>>>> input and halts.  But others (I forget who) report that -- due >>>>>>>> to a bug -- D would actually terminate on its own.  His HHH
simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own, >>>>>>> and that's a consequence of PO's intended design.  (Yes, there
are bugs, but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug
(rather than e.g. a design error) is entirely dependent on the
program's specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then

Since you DDD isn't a program, since you say that it doesn't include
the HHH that it calls, means that you can't use this, since here D
*IS* a program, as that is from the defintion of a Halt Decider, its
input is the representation OF A PROGRAM.

I did not notice how all of the rebuttals of this have
always committed the straw-man error until yesterday.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A correct simulation has always meant that according
to the rules of the x86 language HHH must emulate
itself emulating DDD.

Right, which fails at the call to HHH,

Liar!

So, how does it LEGALLY do it?

The code of HHH is not part of the input, so HHH can not correctly
emulate its input *DDD* and go somewhere else.

DDD going somewhere is not a part of its own
behavior yet is an aspect of the behavior that
DDD specifies.

The functions called by DDD are part of the program and also specify the behaviour of the program.

Its not that hard when you give up rebuttal as
the first priority and instead make an honest
dialogue the top priority.





--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/15/25 12:00 AM, olcott wrote:

On 5/14/2025 10:00 PM, Richard Damon wrote:

On 5/14/25 10:10 PM, olcott wrote:

On 5/14/2025 8:55 PM, Richard Damon wrote:

On 5/14/25 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts. >>>>>>>> Huboy,
what a train wreck.  (But like a train wreck, it's hard to look >>>>>>>> away, which might explain how this has been going on for 20(?) >>>>>>>> years.)

I want to thank both Richard's, wij, dbush, Mike, Keith, Fred, >>>>>>>> Mikko, and anybody else I've forgotten for trying to explain to >>>>>>>> Mr. Olcott and Mr. Flibble how you all see their claims.  I
wanted to
point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating >>>>>>>> input and halts.  But others (I forget who) report that -- due >>>>>>>> to a bug -- D would actually terminate on its own.  His HHH
simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own, >>>>>>> and that's a consequence of PO's intended design.  (Yes, there
are bugs, but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug
(rather than e.g. a design error) is entirely dependent on the
program's specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then

Since you DDD isn't a program, since you say that it doesn't include
the HHH that it calls, means that you can't use this, since here D
*IS* a program, as that is from the defintion of a Halt Decider, its
input is the representation OF A PROGRAM.

I did not notice how all of the rebuttals of this have
always committed the straw-man error until yesterday.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A correct simulation has always meant that according
to the rules of the x86 language HHH must emulate
itself emulating DDD.

Right, which fails at the call to HHH,

Liar!

So, how does it LEGALLY do it?

The code of HHH is not part of the input, so HHH can not correctly
emulate its input *DDD* and go somewhere else.

DDD going somewhere is not a part of its own
behavior yet is an aspect of the behavior that
DDD specifies.

WRONG. A Program is defined by its algorithm, which is all that it does.

I guess you are just admitting you haven't been talking about computer
science at all, but just some mythicall POOPS that you can't even define.

Its not that hard when you give up rebuttal as
the first priority and instead make an honest
dialogue the top priority.

No, I give TRUTH the first priorigty, which gives me a lot of work since
it seems I am talking with someone who doesn't understand what that is.

You, it seems like to talk about your mythological fantasy world where
aything is possible due to the magical truth fairy that just waves her
wand and says it is so, even if it creates contradictions. But that is
ok, as in your world contradictions are true, so everything can be true.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-16 03:02:58 +0000, olcott said:

On 5/15/2025 3:30 AM, Mikko wrote:

On 2025-05-14 21:50:23 +0000, olcott said:

On 5/14/2025 4:16 PM, dbush wrote:

On 5/14/2025 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts. Huboy,
what a train wreck.  (But like a train wreck, it's hard to look >>>>>>>> away, which might explain how this has been going on for 20(?) years.) >>>>>>>>
I want to thank both Richard's, wij, dbush, Mike, Keith, Fred, >>>>>>>> Mikko, and anybody else I've forgotten for trying to explain to >>>>>>>> Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to >>>>>>>> point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating >>>>>>>> input and halts.  But others (I forget who) report that -- due >>>>>>>> to a bug -- D would actually terminate on its own.  His HHH
simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own, and >>>>>>> that's a consequence of PO's intended design.  (Yes, there are bugs, >>>>>>> but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug (rather >>>>>> than e.g. a design error) is entirely dependent on the program's
specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then

And *yet again* you lie by implying Sipser agrees with your
interpretation of the above when definitive proof has been repeatedly
provided that he did not:

On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

I exchanged emails with him about this. He does not agree with anything >>>>> substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.

Your dishonesty knows no bounds.

Ben knows that Professor Sisper does agree with my
meaning of my words and that got Ben all riled up.
Ben was convinced that I tricked professor Sipser
into agreeing with these words.

THE COMPLETE PROOF THAT PROFESSOR SIPSER DOES
AGREE WITH MY MEANING MY MY WORDS IS THAT
THE EXACT WORDS ONLY HAVE ONE MEANING.

Do you agree that the meaning of the word "would" includes that
something in the same clause is counter-factual?

Not at all.

Then your claim that those words have just one meaning is refuted.
Usually the word "would" is not used except when discussing counter-
factual situations, so caounter-factuality is a part of its normal
meaning.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-15 10:35:28 +0000, Fred. Zwarts said:

Op 15.mei.2025 om 06:00 schreef olcott:

On 5/14/2025 10:00 PM, Richard Damon wrote:

On 5/14/25 10:10 PM, olcott wrote:

On 5/14/2025 8:55 PM, Richard Damon wrote:

On 5/14/25 3:17 PM, olcott wrote:

On 5/14/2025 2:06 PM, Mike Terry wrote:

On 14/05/2025 18:50, Mike Terry wrote:

On 14/05/2025 08:11, vallor wrote:

Spent a couple of hours reading back the last few days of posts. Huboy,
what a train wreck.  (But like a train wreck, it's hard to look >>>>>>>>> away, which might explain how this has been going on for 20(?) years.)

I want to thank both Richard's, wij, dbush, Mike, Keith, Fred, >>>>>>>>> Mikko, and anybody else I've forgotten for trying to explain to >>>>>>>>> Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to
point out three things:

a) Mr. Olcott claims his HHH simulator detects an non-terminating >>>>>>>>> input and halts.  But others (I forget who) report that -- due >>>>>>>>> to a bug -- D would actually terminate on its own.  His HHH >>>>>>>>> simulator therefore gives the wrong answer.

Not really due to a bug.  D actually /does/ terminate on its own, and >>>>>>>> that's a consequence of PO's intended design.  (Yes, there are bugs, >>>>>>>> but D's coding is what PO intended.)

Hmm, I thought some more about this.  What's considered a bug (rather >>>>>>> than e.g. a design error) is entirely dependent on the program's >>>>>>> specification.

void DDD()
{
   HHH(DDD);
   return;
}

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>      If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D >>>>>>      would never stop running unless aborted then

Since you DDD isn't a program, since you say that it doesn't include >>>>> the HHH that it calls, means that you can't use this, since here D *IS* >>>>> a program, as that is from the defintion of a Halt Decider, its input >>>>> is the representation OF A PROGRAM.

I did not notice how all of the rebuttals of this have
always committed the straw-man error until yesterday.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A correct simulation has always meant that according
to the rules of the x86 language HHH must emulate
itself emulating DDD.

Right, which fails at the call to HHH,

Liar!

So, how does it LEGALLY do it?

The code of HHH is not part of the input, so HHH can not correctly
emulate its input *DDD* and go somewhere else.

DDD going somewhere is not a part of its own
behavior yet is an aspect of the behavior that
DDD specifies.

The functions called by DDD are part of the program and also specify
the behaviour of the program.

Its not that hard when you give up rebuttal as
the first priority and instead make an honest
dialogue the top priority.

What if the top priority is to forget that one could do something more
useful?

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)