• not all is lost but far too much for far too long

    From Maurice Kinal@1:153/7001 to Alexey Vissarionov on Wed Jun 26 19:50:52 2019
    Hey Alexey!

    ичто из ничего не оставляет ничего.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001.2989 to Maurice Kinal on Wed Jun 26 20:23:21 2019
    Hey Maurice!

    Again I won't quote back but it is noticably missing the '╨Э' character at the beginning of the sentence, which happens to be 0x8d in CP866. I am thinking this is a significant failure to communicate properly.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (aarch64-raspi3b+-linux-gnu)
    * Origin: Little Mikey's CanadARM - Ladysmith BC, Canada (1:153/7001.2989)
  • From Torsten Bamberg@2:240/5832 to Maurice Kinal on Fri Jun 28 01:09:10 2019
    Hallo Maurice!

    26.06.2019 20:23, Maurice Kinal schrieb an Maurice Kinal:

    @REPLY: 1:153/7001 5d13cc9c
    @MSGID: 1:153/7001.2989 5d13d439

    @CHRS: UTF-8 4

    Hey Maurice!

    Again I won't quote back but it is noticably missing the '■э'
    character at the beginning of the sentence, which happens to be 0x8d
    in CP866. I am thinking this is a significant failure to communicate properly.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (aarch64-raspi3b+-linux-gnu)
    * Origin: Little Mikey's CanadARM - Ladysmith BC, Canada (1:153/7001.2989)
    SEEN-BY: 103/705 153/7001 154/10 30 40 700 203/0 221/0 6 227/201 400 SEEN-BY: 229/310 426 240/5832 280/464 5003 5006 5555 292/854 310/31 SEEN-BY: 320/219 340/800 396/45 423/120 712/848 770/1 2452/250 3634/12 SEEN-BY: 5020/545
    @PATH: 153/7001 154/10 280/464
    Common practice as defintion is 7-Bit ascii not utf-8

    Bye/2 Torsten

    ... MAILBOX01 on OS2: up 0d 0h 08m load: 33 proc, 126 threads (tbupv1.1)
    --- GoldED+ 1.1.5-19
    * Origin: DatenBahn BBS Hamburg (2:240/5832)
  • From Maurice Kinal@1:153/7001 to Torsten Bamberg on Fri Jun 28 02:01:09 2019
    Hey Torsten!

    Common practice as defintion is 7-Bit ascii not utf-8

    The orignal was done in CP866 and the missing letter '╨Э' was valued at 0x8d. In this case 7-bit ascii couldn't demonstrate the flaw. Also the utf-8 value for the letter '╨Э' - 0x41d or '0xd0 0x9d' in 8-bit speak - is not affected by the flaw given the trailing byte is not 0x8d.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Ozz Nixon@1:1/123 to Maurice Kinal on Fri Jun 28 21:23:37 2019
    On 2019-06-28 02:01:09 +0000, Maurice Kinal -> Torsten Bamberg said:

    FTN Header versus actual message body conveying Unicode.

    When I telnet to a SQL server that speaks Unicode only, it always
    returns the following characters (pascal): #239#187#191

    When I telnet to a web page that speaks Unicode, it too returns
    #239#187#191 plus the <!doctype html> etc.

    So... would it not stand true that systems that are posting UTF8 do the
    same introduction on the message body? Then authors *know* it
    potentially has Unicode and leave it damn well alone, and also parse it
    based upon UTF8 instead of 8bit char...

    This is how I am coding things here, just based upon NexusSQL,
    PremierSQL, MS SQL, Apache and Nexus Web Service. I do not have access
    to my Oracle box nor the MySQL 5 server to see if they do the same
    during the initial connection negotiation(s).

    A quick google: It's the utf8 byte order mark. Some editors save the
    BOM inside the file (in order to be used as a header) which regularly
    causes confusion because it is optional.

    So, if we wanted to help enforce at a reader (or even tosser level) how
    to handle, I would offer this up as a required BOM to the message body
    that is UTF8.

    Ozz

    --- ExchangeBBS NNTP Server v3.1/Linux64
    * Origin: (1:1/123)
  • From mark lewis@1:3634/12.73 to Ozz Nixon on Sat Jun 29 01:25:12 2019
    On 2019 Jun 28 21:23:36, you wrote to Maurice Kinal:

    FTN Header versus actual message body conveying Unicode.

    When I telnet to a SQL server that speaks Unicode only, it always
    returns the following characters (pascal): #239#187#191

    that's a UTF8 BOM (Byte Order Mark)...

    When I telnet to a web page that speaks Unicode, it too returns #239#187#191 plus the <!doctype html> etc.

    i'm sure you know what it is but if not, it is a magic number that may appear at the start of a text stream... it signals at least one of several things to program processing the stream...

    1. the byte order, or endianness, of the stream
    2. that the text stream's encoding is unicode
    3. which nnicode encoding the stream is using

    So... would it not stand true that systems that are posting UTF8 do
    the same introduction on the message body?

    they could but it is not required... it actually interfers with software using UTF8 that do not expect non-ascii bytes at the beginning of a stream...

    Then authors *know* it potentially has Unicode

    see above... it does indicate that the stream is unicode... not potentially...

    and leave it damn well alone, and also parse it based upon UTF8
    instead of 8bit char...

    it is an idea except that everyone else that uses plain ascii will be saying, what's that garbage at the beginning of these messages?

    This is how I am coding things here, just based upon NexusSQL,
    PremierSQL, MS SQL, Apache and Nexus Web Service. I do not have access
    to my Oracle box nor the MySQL 5 server to see if they do the same
    during the initial connection negotiation(s).

    it is probably a configuration option... apache shouldn't care as it just sends
    whatever is in the file... i don't know about nexus...

    A quick google: It's the utf8 byte order mark. Some editors save the
    BOM inside the file (in order to be used as a header) which regularly causes confusion because it is optional.

    ahh, you found it :)

    So, if we wanted to help enforce at a reader (or even tosser level)
    how to handle, I would offer this up as a required BOM to the message
    body that is UTF8.

    tossers shouldn't be modifying message bodies anyway... that's in the specs... the problem is how some coders interpreted "ignore"... the funny thing is if they chose to ignore the problematic character by stripping it, they actually added code to remove it... if they had selected the other form of ignore and left it in the stream, their code would be (slightly) smaller and faster... it is kinda funny on the one hand...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... You know you're in YK when: you have to break your dog loose from the tree.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001.2989 to Ozz Nixon on Sat Jun 29 15:45:23 2019
    Hey Ozz!

    Just for the record, the message I am replying to -> MSGID: 1:1/123.0 5D164D19 <- never arrived at 1:153/7001 through the normal uplink 1:153/757. However it was recieved via 1:154/10 which I am using as the main link for 1:153/7001.2989. Also it shows up on the Europoint which I use for verification purposes as well.

    With or without a BOM makes no difference not unlike the CHRS kludge for UTF-8. Also it does nothing to solve the obvious flaw of the 'ignored' 0x8d characters no matter what the encoding is or whether or not the CHRS kludge is deployed. I see no fix proposed in your message.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (aarch64-raspi3b+-linux-gnu)
    * Origin: Little Mikey's CanadARM - Ladysmith BC, Canada (1:153/7001.2989)
  • From Alan Ianson@1:153/757 to Maurice Kinal on Sat Jun 29 12:56:28 2019
    Hello Maurice,

    Just for the record, the message I am replying to -> MSGID: 1:1/123.0 5D164D19
    <- never arrived at 1:153/7001 through the normal uplink 1:153/757. However
    was recieved via 1:154/10 which I am using as the main link for 1:153/7001.2989. Also it shows up on the Europoint which I use for verification purposes as well.

    That message was received at 153/757 via 1/123 229/426 280/464 154/10 3634/12 153/7715.

    My guess is that since you are connected at 154/10, 153/7001 was already listed in the seen by lines when it arrived here so it was not sent to your node?

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Maurice Kinal@1:153/7001.2989 to Alan Ianson on Sat Jun 29 20:34:49 2019
    Hey Alan!

    My guess is that since you are connected at 154/10, 153/7001 was
    already listed in the seen by lines when it arrived here so it
    was not sent to your node?

    That would have been my guess as well except that it appears to be totally random to which msg's go missing. In the latest case it was a msg originating from afar or sometimes one that originates from here ... 'here' being CanadARM or Brain.

    As far as I am concerned the missing 0x8d characters are of greater need of attention than missing msg's although if missig elsewhere might give it a higher priority. So far I seem to be the only one noticing.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (aarch64-raspi3b+-linux-gnu)
    * Origin: Little Mikey's CanadARM - Ladysmith BC, Canada (1:153/7001.2989)
  • From Alan Ianson@1:153/757 to Maurice Kinal on Sat Jun 29 15:20:44 2019
    Hello Maurice,

    That would have been my guess as well except that it appears to be totally
    random to which msg's go missing. In the latest case it was a msg originating
    from afar or sometimes one that originates from here ... 'here' being CanadARM
    or Brain.

    Messages can and do arrive here by different paths. If a message arrives here with your node in the seen bys you will not get a copy of it, if it arrives by another path without your node in the seen bys then you will. That is random, depends on who gets here first.. :)

    As far as I am concerned the missing 0x8d characters are of greater need of attention than missing msg's although if missig elsewhere might give it a higher priority. So far I seem to be the only one noticing.

    I think missing messages are a greater concern. 0x8d's don't matter if the message goes missing. Both echo and netmail must flow freely to their destination(s) or there is a problem that needs immediate attention. If anything like that is happening here I'll do everything in my power to correct it.

    These 0x8d characters are important too I think, but that's all a bit beyond my
    ability to understand.. so I'll leave that in the care and keeping of those who do..

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Maurice Kinal@1:153/7001 to Alan Ianson on Sat Jun 29 22:39:21 2019
    Hey Alan!

    Messages can and do arrive here by different paths. If a message
    arrives here with your node in the seen bys you will not get a
    copy of it, if it arrives by another path without your node in
    the seen bys then you will. That is random, depends on who gets
    here first.. :)

    I'll start keeping better track of that particular aspect but I think there is a little more to it seeing most of my replies get through to both ... sometimes. ;-)

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Rob Swindell@1:103/705 to Ozz Nixon on Wed Jul 3 14:44:35 2019
    Re: Re: not all is lost but far too much for far too long
    By: Ozz Nixon to Maurice Kinal on Fri Jun 28 2019 09:23 pm

    On 2019-06-28 02:01:09 +0000, Maurice Kinal -> Torsten Bamberg said:

    FTN Header versus actual message body conveying Unicode.

    When I telnet to a SQL server that speaks Unicode only, it always
    returns the following characters (pascal): #239#187#191

    Using telnet to connect to services that don't speak Telnet is generally a bad idea. Use netcat (nc) instead.

    When I telnet to a web page that speaks Unicode, it too returns
    #239#187#191 plus the <!doctype html> etc.


    So... would it not stand true that systems that are posting UTF8 do the
    same introduction on the message body? Then authors *know* it
    potentially has Unicode and leave it damn well alone, and also parse it based upon UTF8 instead of 8bit char...

    It's an idea. But that's not how *other* charsets/encodings work and certainly not how MIME-encoded messages (e.g. email) works - header fields are used instead.

    This is how I am coding things here, just based upon NexusSQL,
    PremierSQL, MS SQL, Apache and Nexus Web Service. I do not have access
    to my Oracle box nor the MySQL 5 server to see if they do the same
    during the initial connection negotiation(s).

    A quick google: It's the utf8 byte order mark.

    That's actually a misnomer (there is not "byte order" in UTF-8). The actual unicode code point is Zero Width No-Break Space: https://www.compart.com/en/unicode/U+FEFF

    Some editors save the
    BOM inside the file (in order to be used as a header) which regularly
    causes confusion because it is optional.

    So, if we wanted to help enforce at a reader (or even tosser level) how
    to handle, I would offer this up as a required BOM to the message body
    that is UTF8.

    And why is that better than a header field ("control paragraph" as defined in FTS-5003) which indicates UTF-8?
    --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Maurice Kinal@2:280/464.113 to Rob Swindell on Wed Jul 3 22:13:45 2019
    Hallo Rob!

    It's an idea. But that's not how *other* charsets/encodings work

    Other than the existance of 8-bit characters utf-8 is totally different than standard 8-bit character sets. If one is to scan msgs for 8-bit characters it won't help to decypher the message without knowing beforehand what the character set is, whereas with utf-8 it doesn't matter. The "CHRS: UTF-8 4" is totally useless especially when it is wrong such as in "CHRS: UTF-8 2" which still happens.

    So, if we wanted to help enforce at a reader (or even tosser
    level) how to handle, I would offer this up as a required BOM to
    the message body that is UTF8.

    And why is that better than a header field ("control paragraph"
    as defined in FTS-5003) which indicates UTF-8?

    It isn't. Also the 0x8d bug present in many fidonet software will ensure that the utf-8 kludge will be false if there is the existance of that particular trailing byte. With true 8-bit character sets, such as CP866 that only affects one character in 128 whereas in utf-8 increases to about 3 or four per language probably more for many of the 24-bit languages.

    -={ echo "A M├╕├╕se once bit my sister..." | file -b - }=-
    UTF-8 Unicode text

    Going purely with UTF-8 is the way to go. It is rather obvious that it is superior to all the 8-bit character sets combined ... which is a ridiculous statement but true.

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Rob Swindell@1:103/705 to Maurice Kinal on Wed Jul 3 17:19:30 2019
    Re: not all is lost but far too much for far too long
    By: Maurice Kinal to Rob Swindell on Wed Jul 03 2019 10:13 pm

    Hallo Rob!

    It's an idea. But that's not how *other* charsets/encodings work

    Other than the existance of 8-bit characters utf-8 is totally different
    than
    standard 8-bit character sets. If one is to scan msgs for 8-bit characters it won't help to decypher the message without knowing beforehand what the character set is, whereas with utf-8 it doesn't matter.

    Yes, but what I'm saying is that there's already a control paragraph (FTN kludge) defined for charsets, just use that.

    The "CHRS: UTF-8 4"
    is totally useless especially when it is wrong such as in "CHRS: UTF-8 2" which still happens.

    FTS-5003 seems to address that just fine:
    Some implementations do not add the <level> field and some
    implementations erroneously present "UTF-8 2" instead of "UTF-8 4".
    Well mannered implementations should gracefully handle this situation
    when reading messages. The recommended way of doing this is to
    ignore the level parameter and only use the name of the identifier.
    In future the level parameter may become obsolete.

    So, if we wanted to help enforce at a reader (or even tosser
    level) how to handle, I would offer this up as a required BOM to
    the message body that is UTF8.

    And why is that better than a header field ("control paragraph"
    as defined in FTS-5003) which indicates UTF-8?

    It isn't.

    That's my perspective as well.
    --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Maurice Kinal@1:153/7001 to Rob Swindell on Thu Jul 4 02:50:04 2019
    Hey Rob!

    Well mannered implementations should gracefully handle this
    situation

    Do you mean like the 'ignoring' of 0x8d as opposed to deleting it? Anyhow for my part it really doesn't matter as there is no consequences for 'ignoring' ftsc standards with utf-8. With or without it is still utf8 ... unless of course there are any 0x8d trailing bytes which will the be stripped and then the kludge will be wrong.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Rob Swindell@1:103/705 to Maurice Kinal on Wed Jul 3 20:03:45 2019
    Re: not all is lost but far too much for far too long
    By: Maurice Kinal to Rob Swindell on Thu Jul 04 2019 02:50 am

    Hey Rob!

    Well mannered implementations should gracefully handle this
    situation

    Do you mean like the 'ignoring' of 0x8d as opposed to deleting it?

    I think that's a completely different issue.

    Anyhow
    for my part it really doesn't matter as there is no consequences for 'ignoring' ftsc standards with utf-8. With or without it is still utf8 ... unless of course there are any 0x8d trailing bytes which will the be stripped and then the kludge will be wrong.

    I agree: tossers probably should not be stripping 0x8d's.

    I don't think that has anything to do with "CHRS: UTF-8 2" vs "CHRS: UTF-8 4". --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Maurice Kinal@2:280/464.113 to Rob Swindell on Thu Jul 4 04:01:12 2019
    Hallo Rob!

    I think that's a completely different issue.

    Not really. The fact that nothing is ever done about these "bugs" when raised with suitable evidence isn't going to change anything if my observations have been correct over the decades.

    I agree: tossers probably should not be stripping 0x8d's.

    Amen. There ought to be a law against it.

    I don't think that has anything to do with "CHRS: UTF-8 2" vs
    "CHRS: UTF-8 4".

    It doesn't matter. 4, 2 or any other number will change nothing in the case of utf8. The 0x8d training bytes will all be stripped, as theu will for all the 8-bit characters. I posted a CP866 as an example and lo and behold the single 16-bit charater with the trailing bit 0x8d was deleted. The only differece is that in utf8 those bytes matter way more than they do in purely 8-bit land.

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Rob Swindell@1:103/705 to Maurice Kinal on Thu Jul 4 02:07:36 2019
    Re: not all is lost but far too much for far too long
    By: Maurice Kinal to Rob Swindell on Thu Jul 04 2019 04:01 am

    Hallo Rob!

    I think that's a completely different issue.

    Not really. The fact that nothing is ever done about these "bugs" when raised with suitable evidence isn't going to change anything if my observations have been correct over the decades.

    If it's a problem for you, then switch software? SBBSecho used to strip 0x8d's and since rev 3.113 (Apr-30-2019) no longer does (at least, not by default). See? "bugs" can be fixed, so long as someone has the source code.

    I agree: tossers probably should not be stripping 0x8d's.

    Amen. There ought to be a law against it.

    I don't think that has anything to do with "CHRS: UTF-8 2" vs
    "CHRS: UTF-8 4".

    It doesn't matter. 4, 2 or any other number will change nothing in the
    case
    of utf8. The 0x8d training bytes will all be stripped, as theu will for
    all
    the 8-bit characters.

    And... that's a different issue.

    I posted a CP866 as an example and lo and behold the
    single 16-bit charater with the trailing bit 0x8d was deleted. The only differece is that in utf8 those bytes matter way more than they do in
    purely
    8-bit land.

    So find out what software is stripping the 0x8d's and start a campaign to get that software "fixed".
    --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From mark lewis@1:3634/12.73 to Rob Swindell on Thu Jul 4 08:39:38 2019

    On 2019 Jul 04 02:07:36, you wrote to Maurice Kinal:

    I think that's a completely different issue.

    Not really. The fact that nothing is ever done about these "bugs"
    when raised with suitable evidence isn't going to change anything if
    my observations have been correct over the decades.

    If it's a problem for you, then switch software?

    the problem is in the path... he writes messages and checks them at other systems... some system(s) along the path are stripping out 0x8d and that's (one of) the problem(s) he's pointing out...

    FWIW: maurice's stuff is all bash code using traditional linux tools... there's no BBS or FTN specific compiled code in the mix... it is about as basic as one can get... i think he reads the messages pkt by pkt using his raw methodology but i've not looked deeper into his setup... i think nicholas boel did at one time, though...

    SBBSecho used to strip 0x8d's and since rev 3.113 (Apr-30-2019) no
    longer does (at least, not by default).

    thanks for that, too!

    See? "bugs" can be fixed, so long as someone has the source code.

    or can sufficiently hack the binaries ;)

    I posted a CP866 as an example and lo and behold the single 16-bit
    charater with the trailing bit 0x8d was deleted. The only differece
    is that in utf8 those bytes matter way more than they do in purely
    8-bit land.

    So find out what software is stripping the 0x8d's and start a campaign
    to get that software "fixed".

    we've been looking... the possibilities are down to only a few software packages ;)

    )\/(ark

    And to this end they built themselves a stupendous super-computer which was
    so amazingly intelligent that even before its data banks had been connected
    up it had started from "I think therefore I am" and got as far as deducing
    the existence of rice pudding and income tax before anyone managed to turn
    it off.
    ... The four seasons are salt, pepper, mustard and vinegar.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@2:280/464.113 to Rob Swindell on Thu Jul 4 16:46:08 2019
    Hallo Rob!

    If it's a problem for you, then switch software?

    Why would I do that? The FTN schtuff I have working strips out NOTHING, even if it is obviously wrong. I refuse to mess with other peoples messages.

    "bugs" can be fixed, so long as someone has the source code.

    As well as the willingness to fix it.

    So find out what software is stripping the 0x8d's and start a
    campaign to get that software "fixed".

    That is why I am posting here in this particular echo. Whoever/whatever is responsible is not saying, not that it would really matter since there is no mechanism to force anyone to correct their "bugs".

    Het leven is goed,
    Maurice

    ... Huil niet om mij, ik heb vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Thu Jul 4 13:17:12 2019

    On 2019 Jul 04 16:46:08, you wrote to Rob Swindell:

    So find out what software is stripping the 0x8d's and start a
    campaign to get that software "fixed".

    That is why I am posting here in this particular echo.
    Whoever/whatever is responsible is not saying, not that it would
    really matter since there is no mechanism to force anyone to correct
    their "bugs".

    oh but there is... getting that mechanism into operation like used to be done is a little harder to do these days for some reason...

    )\/(ark

    And to this end they built themselves a stupendous super-computer which was
    so amazingly intelligent that even before its data banks had been connected
    up it had started from "I think therefore I am" and got as far as deducing
    the existence of rice pudding and income tax before anyone managed to turn
    it off.
    ... Zombie on the team, you gotta play him in right field.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to mark lewis on Thu Jul 4 17:38:10 2019
    Hey mark!

    oh but there is... getting that mechanism into operation like
    used to be done is a little harder to do these days for some
    reason...

    I'll believe it when I see it. Also I don't buy into the "good ol' days" when everything was peacho-keen-neato. I am sure some (most?) of that is selective memory.

    Anyhow I look forward to seeing the 0x8d bug die a horrible, miserable death. Make my day. :-)

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Thu Jul 4 16:21:34 2019

    On 2019 Jul 04 17:38:10, you wrote to me:

    oh but there is... getting that mechanism into operation like used to
    be done is a little harder to do these days for some reason...

    I'll believe it when I see it.

    the mechanism is the *Cs and them letting folks know that they are running banned software due to the flaw(s) causing problems on the network... the detection of the flaw(s) comes from the FTSC... the *Cs, guided by their ZC, then let their nodes know and get them to downgrade to an approced version of the software or to upgrade to a newer one without the flaw... if there is no newer one and the system doesn't downgrade, the enforcement is temporary blocking of their node number...

    Also I don't buy into the "good ol' days" when everything was peacho-keen-neato. I am sure some (most?) of that is selective
    memory.

    i don't have a clue what you're speaking of... i only know that both frontdoor and binkleyterm had beta versions banned at one time because of interoperability problems... the problems were fixed very quickly and a new beta released... some beta testers elected to downgrade to the previous beta... others didn't get that chance for one reason or another...

    Anyhow I look forward to seeing the 0x8d bug die a horrible, miserable death. Make my day. :-)

    we have to find exactly which software it is causing it... no guessing if it is this one or that one... several of us have done a good portion of this tracking... you and i included ;)

    )\/(ark

    And to this end they built themselves a stupendous super-computer which was
    so amazingly intelligent that even before its data banks had been connected
    up it had started from "I think therefore I am" and got as far as deducing
    the existence of rice pudding and income tax before anyone managed to turn
    it off.
    ... My other car is a BUDD.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001.2989 to mark lewis on Thu Jul 4 23:24:38 2019
    Hey mark!

    the mechanism is the *Cs

    So I brought this up in the wrong echo? This seems like the place for thes issues.

    i don't have a clue what you're speaking of

    I was just responding to the line that says, "getting that mechanism into operation like used to be done is a little harder to do these days for some reason". It sounded like a "back in the good ol' days" type of thing. Sorry if I read that wrong.

    we have to find exactly which software it is causing it

    Good idea.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.0.7(1)-release (aarch64-raspi3b+-linux-gnu)
    * Origin: Little Mikey's CanadARM - Ladysmith BC, Canada (1:153/7001.2989)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Thu Jul 4 20:32:12 2019

    On 2019 Jul 04 23:24:38, you wrote to me:

    the mechanism is the *Cs

    So I brought this up in the wrong echo?

    i dunno... it was easier where there was an IC...

    This seems like the place for thes issues.

    the FTSC was the proper place and it would pass the word to the IC who then sent down the notice to the ZCs who sent it to the RCs who sent it to the NCs who contacted the nodes with the problematic software...

    i don't have a clue what you're speaking of

    I was just responding to the line that says, "getting that mechanism into operation like used to be done is a little harder to do these days for
    some
    reason". It sounded like a "back in the good ol' days" type of thing. Sorry if I read that wrong.

    oh... the lack of an IC has hampered numerous things in fidonet... sure the ZCC looks to be able to do the same tasks but getting edicts handed down might be troublesome...

    we have to find exactly which software it is causing it

    Good idea.

    the hard part will be getting hold of those operators and getting them to backlevel until a fix is out... some of them set their systems up and they run unattended except for maybe once a month or so when the operator decides to look in on it... by then they could be out of the nodelist and not even know it since a lot of the newer software doesn't even require a nodelist to operate...

    i seem to be tagging at least one or two operators a week who's systems have gone TITSUP (Total Inability To Support Usual Performance) for several days... when my outbound is approaching 2000+ PKTs for one system, i start to get real antsy... i can see it pretty easily since i have a bash script that monitors my BSO and checks the flo files' contents for a count and date/time of the oldest file listed...

    )\/(ark

    And to this end they built themselves a stupendous super-computer which was
    so amazingly intelligent that even before its data banks had been connected
    up it had started from "I think therefore I am" and got as far as deducing
    the existence of rice pudding and income tax before anyone managed to turn
    it off.
    ... Press to test. <click> Release to detonate...
    ---
    * Origin: (1:3634/12.73)
  • From Sean Dennis@1:18/200 to mark lewis on Sat Jul 6 15:14:14 2019
    mark lewis wrote to Maurice Kinal <=-

    have gone TITSUP (Total Inability To Support Usual Performance) for

    You read The Register too, eh? :D

    --Sean


    --- MultiMail/Win
    * Origin: Outpost BBS * Limestone, TN, USA (1:18/200)
  • From mark lewis@1:3634/12.73 to Sean Dennis on Sun Jul 7 15:21:42 2019

    On 2019 Jul 06 15:14:14, you wrote to me:

    have gone TITSUP (Total Inability To Support Usual Performance) for

    You read The Register too, eh? :D

    absolutely! i think i've posted numerous links to their articles over the years, as well :)

    )\/(ark

    And to this end they built themselves a stupendous super-computer which was
    so amazingly intelligent that even before its data banks had been connected
    up it had started from "I think therefore I am" and got as far as deducing
    the existence of rice pudding and income tax before anyone managed to turn
    it off.
    ... Today is a good day to die. -Apache warrior proverb
    ---
    * Origin: (1:3634/12.73)