• Messages too long?

    From Jerry Schwartz@1:142/928 to All on Sunday, February 05, 2006 18:14:37
    Hello, All...

    Since I've been feeding from 1:106/1, I get some messages that Squish says are "too long." This gets the packet renamed as *.LNG and left in my Squish directory. I'm using BUFFERS LARGE.

    Any suggestions?

    Regards,

    Jerry Schwartz

    mailto:jerryschwartz@comfortable.com
    http://www.writebynight.com

    --- Msged/NT 6.0.1
    * Origin: Write by Night (1:142/928)
  • From Peter Knapper@3:772/1.10 to Jerry Schwartz on Monday, February 06, 2006 17:01:42
    Hi Jerry,

    Since I've been feeding from 1:106/1, I get some
    messages that Squish says are "too long." This gets the
    packet renamed as *.LNG and left in my Squish
    directory. I'm using BUFFERS LARGE.

    Any suggestions?

    Are you using SQUISH or SQ386?

    Cheers..................pk.


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Jerry Schwartz@1:142/928 to Peter Knapper on Monday, February 06, 2006 17:44:35
    Hello, Peter...

    Feb 06, 2006 at 17:01, Peter Knapper wrote to Jerry Schwartz:

    Since I've been feeding from 1:106/1, I get some
    messages that Squish says are "too long." This gets the
    packet renamed as *.LNG and left in my Squish
    directory. I'm using BUFFERS LARGE.

    Any suggestions?

    Are you using SQUISH or SQ386?

    SQ386 in a .BAT file under Windows XP. I haven't tried changing the file to a .CMD file, but I doubt that would do it.

    Regards,

    Jerry Schwartz

    mailto:jerryschwartz@comfortable.com
    http://www.writebynight.com

    --- Msged/NT 6.0.1
    * Origin: Write by Night (1:142/928)
  • From Peter Knapper@3:772/1.10 to Jerry Schwartz on Tuesday, February 07, 2006 19:54:06
    Hi Jerry,

    Are you using SQUISH or SQ386?

    SQ386 in a .BAT file under Windows XP. I haven't tried
    changing the file to a .CMD file, but I doubt that
    would do it.

    No, that should be fine then. Do you know what size the messages are that are being trapped? About the only thing I can think of causing this are messages larger than 64KB, but its unusual that no-one else is mentioning them.

    About the only other thing I can think of is that something is corrupt. Possibly the executable, or a Message base, or perhaps the packet itself. Does something like INSPECTA complain about the packet or its contents?

    Cheers..............pk.


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Alan Ianson@1:153/757 to Peter Knapper on Tuesday, February 07, 2006 01:20:46
    Peter Knapper wrote to Jerry Schwartz:

    No, that should be fine then. Do you know what size the messages are that are being trapped? About the only thing I can think of causing this are messages larger than 64KB, but its unusual that no-one else is mentioning them.

    I've seen things like that with the linux version too. It could be
    messages in the stats echo, some of them can be 500KB. I'd get .pkt's
    renamed to .lng in my inbound. I never did find a solution. I just
    checked my stats msg base, 70 megs!

    Ttyl :-),
    Al

    ... Age and treachery can always overcome youth and skill.

    --- MBSE BBS v0.83.12 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)
  • From Dale Shipp@1:261/1466 to Peter Knapper on Tuesday, February 07, 2006 23:24:00
    On 02-07-06 19:54, Peter Knapper <=-
    spoke to Jerry Schwartz about Messages too long? <=-

    Are you using SQUISH or SQ386?

    SQ386 in a .BAT file under Windows XP. I haven't tried
    changing the file to a .CMD file, but I doubt that
    would do it.

    I use sq386n.exe, called from a CMD file by Argus running in Win XP.

    No, that should be fine then. Do you know what size the
    messages are that are being trapped? About the only thing I
    can think of causing this are messages larger than 64KB,
    but its unusual that no-one else is mentioning them.

    I noticed them quite some time ago. Now that the line in my batch
    file immediately after the call to sq386n reads
    *del /q *.lng
    I no longer notice them -- they go poof as soon as they get here.

    As I recall, it was because of a message in the STATS echo that was
    posted periodically by someone -- don't recall exactly who. I think
    that the files often ran in excess of 100KB.

    Dale Shipp
    fido_261_1466 (at) comcast (dot) net
    (1:261/1466)


    ... Shipwrecked on Hesperus in Columbia, Maryland. 23:14:10, 07 Feb 2006
    ___ Blue Wave/DOS v2.30

    --- Maximus/NT 3.01
    * Origin: Owl's Anchor (1:261/1466)
  • From Jerry Schwartz@1:142/928 to Peter Knapper on Wednesday, February 08, 2006 18:23:30
    Hello, Peter...

    Feb 07, 2006 at 19:54, Peter Knapper wrote to Jerry Schwartz:


    Are you using SQUISH or SQ386?

    SQ386 in a .BAT file under Windows XP. I haven't tried
    changing the file to a .CMD file, but I doubt that
    would do it.

    No, that should be fine then. Do you know what size the messages are
    that are being trapped? About the only thing I can think of causing
    this are messages larger than 64KB, but its unusual that no-one else
    is mentioning them.

    About the only other thing I can think of is that something is
    corrupt. Possibly the executable, or a Message base, or perhaps the packet itself. Does something like INSPECTA complain about the packet
    or its contents?

    I have never used INSPECTA. So far as I can tell, Squish simply skips the oversized message and tosses the rest of the package. It doesn't bark about anything other than to say

    # 07 Feb 00:04:10 SQSH Tossing/scanning msgs from . (secure)
    * 07 Feb 00:04:10 SQSH 43e82a7e.Pkt, 02/06/06, 23:05:01, by ff 1.04
    - 07 Feb 00:04:10 SQSH Orig=1:106/1.0, Dest=1:142/928.0, Type=2+
    ! 07 Feb 00:04:10 SQSH Msg too long to toss: skipping to next msg.
    ! 07 Feb 00:04:10 SQSH Packet contains long msg: renamed to .\43e82a7e.LNG
    : 07 Feb 00:04:10 SQSH BATPOWER (Toss=0001 Sent=0001)
    : 07 Feb 00:04:10 SQSH COFFEE_KLATSCH (Toss=0002 Sent=0008)
    : 07 Feb 00:04:10 SQSH MBSE (Toss=0002 Sent=0006)
    : 07 Feb 00:04:10 SQSH MENSA (Toss=0001 Sent=0001)
    : 07 Feb 00:04:10 SQSH POL_INC (Toss=0003 Sent=0006)
    : 07 Feb 00:04:10 SQSH STATS (Toss=0002 Sent=0004)
    : 07 Feb 00:04:10 SQSH WIN95 (Toss=0001 Sent=0001)

    Regards,

    Jerry Schwartz

    mailto:jerryschwartz@comfortable.com
    http://www.writebynight.com

    --- Msged/NT 6.0.1
    * Origin: Write by Night (1:142/928)
  • From Jerry Schwartz@1:142/928 to Alan Ianson on Wednesday, February 08, 2006 18:27:18
    Hello, Alan...

    Feb 07, 2006 at 01:20, Alan Ianson wrote to Peter Knapper:

    I've seen things like that with the linux version too. It could be messages in the stats echo, some of them can be 500KB. I'd get .pkt's renamed to .lng in my inbound. I never did find a solution. I just
    checked my stats msg base, 70 megs!

    Thanks. I've always suspected the STATS echo, although it was just a WAG.


    Regards,

    Jerry Schwartz

    mailto:jerryschwartz@comfortable.com
    http://www.writebynight.com

    --- Msged/NT 6.0.1
    * Origin: Write by Night (1:142/928)
  • From Peter Knapper@3:772/1.10 to Jerry Schwartz on Thursday, February 09, 2006 20:30:10
    Hi Jerry,

    About the only other thing I can think of is that something is
    corrupt. Possibly the executable, or a Message base, or perhaps the packet itself. Does something like INSPECTA
    complain about the packet or its contents?

    I have never used INSPECTA.

    I can recommend it, its invaluable for looking into mail packets, etc.

    Cheers............pk.


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Alan Ianson@1:153/757 to Jerry Schwartz on Thursday, February 09, 2006 21:56:22
    Jerry Schwartz wrote to Alan Ianson:

    I've seen things like that with the linux version too. It could be messages in the stats echo, some of them can be 500KB. I'd get .pkt's renamed to .lng in my inbound. I never did find a solution. I just checked my stats msg base, 70 megs!

    Thanks. I've always suspected the STATS echo, although it was just a WAG.

    Luckily squish doesn't crash on a message like that, it just skips
    it and continues on. Dale's del /q *.lng is probably a safe operation
    on those .lng's..

    Ttyl :-),
    Al

    ... DISK ERROR: DISK ERROR: DISK ERROR: @$%#&%!! *WHACK* C:\>

    --- MBSE BBS v0.83.12 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)
  • From Bob Jones@1:343/41 to Jerry Schwartz on Thursday, February 09, 2006 22:22:54
    I've seen things like that with the linux version too. It could be messages in the stats echo, some of them can be 500KB. I'd get .pkt's renamed to .lng in my inbound. I never did find a solution. I just
    checked my stats msg base, 70 megs!

    If I remember correctly, with the SQ386(p) version of squish, the maximum message size is aboue 256Kb. If you are seeing 500Kb message size in an echo, that is probably what is doing it....

    I suspect the Linux version of Squish could be updated to support longer messages. I don't know if anyone has the code compiling to change toe OS/2 and
    Win NT versions for larger packets.

    Take care.....

    Bob Jones, 1:343/41


    --- Maximus/2 3.01
    * Origin: Top Hat 2 BBS (1:343/41)
  • From Mike Tripp@1:382/61 to Bob Jones on Friday, February 10, 2006 09:41:56
    Hello Bob!

    09 Feb 06 22:22, Bob Jones wrote to Jerry Schwartz:

    If I remember correctly, with the SQ386(p) version of squish, the
    maximum message size is aboue 256Kb. If you are seeing 500Kb message
    size in an echo, that is probably what is doing it....

    I believe you are correct, for the parameters pointed to by the "Large" keyword. However, if you take manual control of the individual parameters, you
    should be able to tax whatever the limits of your environment are (theoretically 2gb for OS/2).

    I tried allowing 512k for some of my gated newsgroups for a while. It worked, but I didn't find the content of those messages particularly useful (usually UUENCODEd trash unrelated to the group topic) and eventually went back to letting LARGE filter the trash, instead.<g>

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Alan Ianson@1:153/757 to Mike Tripp on Friday, February 10, 2006 17:40:00
    Mike Tripp wrote to Bob Jones <=-

    If I remember correctly, with the SQ386(p) version of squish, the
    maximum message size is aboue 256Kb. If you are seeing 500Kb message
    size in an echo, that is probably what is doing it....

    I believe you are correct, for the parameters pointed to by the "Large" keyword. However, if you take manual control of the individual parameters, you should be able to tax whatever the limits of your environment are (theoretically 2gb for OS/2).

    How did you do that?

    I tried allowing 512k for some of my gated newsgroups for a while. It worked, but I didn't find the content of those messages particularly useful (usually UUENCODEd trash unrelated to the group topic) and eventually went back to letting LARGE filter the trash, instead.<g>

    That's a useful option too.. :)


    Ttyl :-),
    Al

    ... My opinions are my own; mistakes are the computer's fault.
    --- MultiMail/Linux v0.47
    * Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)
  • From Matt Bedynek@1:106/1 to Jerry Schwartz on Friday, February 10, 2006 18:43:14
    Hello Jerry.

    05 Feb 06 18:14, you wrote to All:

    Since I've been feeding from 1:106/1, I get some messages that Squish
    says are "too long." This gets the packet renamed as *.LNG and left in
    my Squish directory. I'm using BUFFERS LARGE.

    Any suggestions?

    Find out what areas they are in. Reading into the thread I see stats echo being mentioned. I see that two systems post large messages there. 229/2000 with messages around 400K+ and 123/500 with messages around 130K+. My node does not split passthrough traffic but does split traffic originating from itself. Its been many years since I ran squish but I recall even with 'large' the message buffer is either 512K or 256K.

    Some folks forget that others run software that might crash or not pass on large messages. Even though many of us run systems capable of handling large messages; all to often the software cannot or at least is not configured to do so. At least squish is smart enough to skip them. I suspect there are tossers
    that stop up completely when they encouter very large messages?

    Let me know if there is anything I can do to help.

    Matt

    e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

    "to be loved is fortunate, but to be hated is to achieve distinction"

    ---
    * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)
  • From Matt Bedynek@1:106/1 to Jerry Schwartz on Friday, February 10, 2006 18:52:32
    Hello Jerry.

    08 Feb 06 18:27, you wrote to Alan Ianson:

    Thanks. I've always suspected the STATS echo, although it was just a
    WAG.

    If that is the case, you may want to leave your buffer small to stop them. Reason being that some of your downlinks might have severe issues with them? People really should split large messages before injecting them into the echomail stream; especially if they are the originator of them ..

    Matt

    e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

    "to be loved is fortunate, but to be hated is to achieve distinction"

    ---
    * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)
  • From Alan Ianson@1:153/757 to Matt Bedynek on Friday, February 10, 2006 18:57:20
    Matt Bedynek wrote to Jerry Schwartz:

    Some folks forget that others run software that might crash or not pass on large messages.

    One thing I never concidered when I commented deleting *.lng files is
    nodes that need to pass messages on. In a case like that then it is
    more of a problem.

    I suspect there are tossers that stop up completely when they
    encouter very large messages?

    I took the new dbridge out for a test drive a month or two back and
    it crashed completely on those messages...

    I think 229/2000 runs hpt, maybe we should ask him if he wouldn't
    mind splitting messages at 128 or 256kb or some safe value, just so
    those who run tossers that can't handle the large messages can still
    pass those messages on for those interested in reading them. I read
    the area myself periodiclly just to see what areas are getting
    traffic.

    Ttyl :-),
    Al

    ... An Elephant; A Mouse built to government specifications.

    --- MBSE BBS v0.83.12 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)
  • From Jerry Schwartz@1:142/928 to Matt Bedynek on Saturday, February 11, 2006 19:44:47
    Hello, Matt...

    Feb 10, 2006 at 18:43, Matt Bedynek wrote to Jerry Schwartz:


    Let me know if there is anything I can do to help.

    I doubt anyone misses those messages. I haven't gotten any complaints, so I'll continue letting Squish skip them.

    Regards,

    Jerry Schwartz

    mailto:jerryschwartz@comfortable.com
    http://www.writebynight.com

    --- Msged/NT 6.0.1
    * Origin: Write by Night (1:142/928)
  • From Jerry Schwartz@1:142/928 to Matt Bedynek on Saturday, February 11, 2006 19:45:53
    Hello, Matt...

    Feb 10, 2006 at 18:52, Matt Bedynek wrote to Jerry Schwartz:

    Thanks. I've always suspected the STATS echo, although it was just a
    WAG.

    If that is the case, you may want to leave your buffer small to stop them. Reason being that some of your downlinks might have severe
    issues with them? People really should split large messages before injecting them into the echomail stream; especially if they are the originator of them ..

    Nobody has complained.

    Regards,

    Jerry Schwartz

    mailto:jerryschwartz@comfortable.com
    http://www.writebynight.com

    --- Msged/NT 6.0.1
    * Origin: Write by Night (1:142/928)
  • From Dale Shipp@1:261/1466 to Jerry Schwartz on Saturday, February 11, 2006 23:43:04
    On 02-11-06 19:44, Jerry Schwartz <=-
    spoke to Matt Bedynek about Messages too long? <=-

    I doubt anyone misses those messages. I haven't gotten any
    complaints, so I'll continue letting Squish skip them.

    IIRC, they are automatically generated by whatever stats program those
    sysops are using, and they are the listing of echos that had no
    traffic.

    Dale Shipp
    fido_261_1466 (at) comcast (dot) net
    (1:261/1466)


    ... Shipwrecked on Hesperus in Columbia, Maryland. 22:58:22, 11 Feb 2006
    ___ Blue Wave/DOS v2.30

    --- Maximus/NT 3.01
    * Origin: Owl's Anchor (1:261/1466)
  • From mark lewis@1:3634/12 to Matt Bedynek on Wednesday, February 15, 2006 04:57:01
    Some folks forget that others run software that might crash or not
    pass on large messages.

    speaking as one of those folk, /i/ don't forget... i _know_ that there is software available for those who can't/don't want to handle large messages... this software can cut/split (by FTSC proposal) messages too large for their systems to handle... i've said this for years... in fact, i've had this stance ever since the ^aSPLIT proposal was presented to the FTSC... i have /always/ believed it the responsibility of the -=recieving=- system to split messages according to _their_ capabilities rather than "forcing" everyone else to succumb to their individual restrictions...

    Even though many of us run systems capable of handling large
    messages; all to often the software cannot or at least is not
    configured to do so.

    that is the operator's problem, IMHO... the real "problem" is getting folk to look at the other side of the coin...

    At least squish is smart enough to skip them.

    and thus loose mail... there's one part of that blackhole that folk speak of...

    I suspect there are tossers that stop up completely when they
    encouter very large messages?

    i don't doubt that... that's one of the main reasons why i see that ^aSPLIT proposal is written and directed to the wrong folk...

    Let me know if there is anything I can do to help.

    educate folk and teach them to cut messages up to what /their/ systems can handle and don't restrict others in what they can handle ;) O:)

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Matt Bedynek on Wednesday, February 15, 2006 05:04:50
    Thanks. I've always suspected the STATS echo, although it was just a
    WAG.

    If that is the case, you may want to leave your buffer small to
    stop them. Reason being that some of your downlinks might have
    severe issues with them? People really should split large messages
    before injecting them into the echomail stream; especially if they
    are the originator of them ..

    wrong... should i wear a condom to prevent you from getting a disease that i may transmit to a whore that you may also spend time with or should you wear a condom to protect yourself from anything she may have and try to deliver to you?

    i believe that it should be you wearing that condom, my friend... CYOA and all that stuff... if your system has a limit of 100k messages, then -=you=- should be running "preprocessor" software to cut messages down to 100k of smaller...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Alan Ianson on Wednesday, February 15, 2006 05:08:28
    I took the new dbridge out for a test drive a month or two back and
    it crashed completely on those messages...

    did you report those details back to the d'bridge echo so they might be fixed in the sources?

    I think 229/2000 runs hpt, maybe we should ask him if he wouldn't
    mind splitting messages at 128 or 256kb or some safe value, just so
    those who run tossers that can't handle the large messages can
    still pass those messages on for those interested in reading them.
    I read the area myself periodiclly just to see what areas are
    getting traffic.

    i'd say that you need to be running software as i just spoke of in previous messages to matt...

    )\/(ark


    * Origin: (1:3634/12)
  • From Mike Tripp@1:382/61 to mark lewis on Wednesday, February 15, 2006 10:03:48
    Hello mark!

    15 Feb 06 04:57, mark lewis wrote to Matt Bedynek:

    speaking as one of those folk, /i/ don't forget... i _know_ that there
    is software available for those who can't/don't want to handle large messages... this software can cut/split (by FTSC proposal) messages
    too large for their systems to handle... i've said this for years...
    in fact, i've had this stance ever since the ^aSPLIT proposal was presented to the FTSC... i have /always/ believed it the
    responsibility of the -=recieving=- system to split messages according
    to _their_ capabilities rather than "forcing" everyone else to succumb
    to their individual restrictions...

    This is really a dirt-common networking design issue that has been addressed in
    both hardware and software protocols years before Fido emerged. There are appropriate data structures and algorithms to accommodate datagrams of fixed length or variable length, but unfortunately Fido standards failed to define quite enough technical detail to realistically accomplish either.

    Nobody in Fido has hardware and software that can process and forward infinitely sized messages, though that is what is effectively allowed by the Fido standards.<g> The advantage of a formal splitting algorithm is that it implies a formal unsplitting mechanism, which means that all are not required to "succumb" to the lowest common denominator determined by one worst-case hop on the route.

    I suspect there are tossers that stop up completely when they
    encouter very large messages?

    i don't doubt that... that's one of the main reasons why i see that ^aSPLIT proposal is written and directed to the wrong folk...

    All Fido systems are theoretically "tranceivers", so it is really irrelevant whether the responsibility for the execution of the algorithm is assigned to the sending process, the receiving process, or distributed between both...since
    we'd all need to support "it", whatever "it" is. Whether I like messages "too small" or you like messages "too big" is simply a matter of perspective...and there is a technical path to render it transparent to us both. Unfortunately, the necessary groundwork to lay the infrastructure to resolve the issue came along a little too late to benefit the folks that need it the most.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Alan Ianson@1:153/757 to mark lewis on Wednesday, February 15, 2006 08:36:06
    mark lewis wrote to Alan Ianson:

    I took the new dbridge out for a test drive a month or two back and
    it crashed completely on those messages...

    did you report those details back to the d'bridge echo so they might be fixed in the sources?

    No, I never did. I presumed that there were folks who knew the software
    better than I did so I didn't. My bad I think. I'll go post that today.

    I think 229/2000 runs hpt, maybe we should ask him if he wouldn't
    mind splitting messages at 128 or 256kb or some safe value, just so those who run tossers that can't handle the large messages can
    still pass those messages on for those interested in reading them.
    I read the area myself periodiclly just to see what areas are
    getting traffic.

    i'd say that you need to be running software as i just spoke of in previous messages to matt...

    Sounds repulsive to me. Glad my software tosses them, and hope I don't
    find any limits in the future. ;)

    Ttyl :-),
    Al

    ... Our program, who art in memory. EXE be thy name.

    --- MBSE BBS v0.83.13 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)
  • From Matt Bedynek@1:106/1 to mark lewis on Wednesday, February 15, 2006 21:03:06
    Hello mark.

    15 Feb 06 04:57, you wrote to me:

    speaking as one of those folk, /i/ don't forget... i _know_ that there
    is software available for those who can't/don't want to handle large messages... this software can cut/split (by FTSC proposal) messages
    too large for their systems to handle... i've said this for years...
    in fact, i've had this stance ever since the ^aSPLIT proposal was presented to the FTSC... i have /always/ believed it the
    responsibility of the -=recieving=- system to split messages according
    to _their_ capabilities rather than "forcing" everyone else to succumb
    to their individual restrictions...

    If you are thinking of pktsort and psrt, both are buggy despite the fact that there are at least a few hubs out that that still use it. pktsoft had a bug with regard to occassionally grunging netmail messages. i believe that splitting and recombination should be built into the tosser anyway but the likelihood of a standard, dated and valuable as it seems, will make a mass entry into software being utilized by sysops today.

    that is the operator's problem, IMHO... the real "problem" is getting
    folk to look at the other side of the coin...

    and thus loose mail... there's one part of that blackhole that folk
    speak of...

    educate folk and teach them to cut messages up to what /their/ systems
    can handle and don't restrict others in what they can handle ;) O:)

    In a perfect fidonet of conformity and appreciation for the latest technology that is true. However, when joe sysop comes home every day and his tosser is frozen because it hit a large message (he does not know why) he will likely shutdown the system in frustration because his use of it and/or time is limited. The problem is two fold in that you have sysops running systems that might not have the memory to handle large messages or they have the hardware but they are using older software that does not take advantage of it (abandonware, ect).

    My tosser is generations ahead of yours just like yours is above the guy using software 10 years old. A message here can be the size of free memory. Being that I have two gigs of ram and a highspeed disk backplane, i could handle messages in minutes that might take you hours but that is beside the point.

    Not everybody wants to or can run fastecho or hpt. Besides, you cant register fastecho anymore anyway. :-)

    :-)

    Matt

    e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

    "to be loved is fortunate, but to be hated is to achieve distinction"

    ---
    * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)
  • From Matt Bedynek@1:106/1 to mark lewis on Wednesday, February 15, 2006 21:11:58
    Hello mark.

    15 Feb 06 05:04, you wrote to me:

    i believe that it should be you wearing that condom, my friend... CYOA
    and all that stuff... if your system has a limit of 100k messages,
    then -=you=- should be running "preprocessor" software to cut messages down to 100k of smaller...

    Feel free to code that preprocessor for the rest of us to use.

    Matt

    e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

    "to be loved is fortunate, but to be hated is to achieve distinction"

    ---
    * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)
  • From Peter Knapper@3:772/1.10 to Mark Lewis on Thursday, February 16, 2006 18:16:14
    Hi Mark,

    i've said this for years... in fact, i've
    had this stance ever since the ^aSPLIT proposal was
    presented to the FTSC... i have /always/ believed it
    the responsibility of the -=recieving=- system to split
    messages according to _their_ capabilities rather than
    "forcing" everyone else to succumb to their individual restrictions...

    I think you overlook some pretty basic human instincts here, and your ability to read so many 500KB messages is nothing short of staggering......;-)

    If Fidonet were a 100% commercial environment then I doubt many people would disagree with you, but the origins of the network have forced all of us to accept that some things are historical and need to be accomodated in the interests of self preservation.

    Message length has long been an issue, and in the case of Fidonet I see no reason to force everyone to change to a new method of handling these things, voluntarily perhaps, but not by force.

    Netmail and Echomail were constructed to allow people to communicate with each other, and stuffing 500KB of computer generated text into a message in which the text is NOT created by humans, but with the expectation that SOMEONE will read it, is nothing short of abuse of the medium (IMHO).

    I use and generate stats myself, but unless they are only 1 or 2 screens in length I do NOT output it via messages, the longer form of stats presentation is meant for a file (IMHO).

    Cheers.........pk.


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Roy Witt@1:1/22 to Matt Bedynek on Thursday, February 16, 2006 08:53:21
    15 Feb 06 21:03, Matt Bedynek wrote to mark lewis:

    Not everybody wants to or can run fastecho or hpt. Besides, you cant register fastecho anymore anyway. :-)

    Yes you can.


    Roy
    --- Twit(t) Filter v2.1 (C) 2000
    * Origin: Hacienda de Rio de Guadalupe * South * Texas, USA * (1:1/22)
  • From mark lewis@1:3634/12 to Matt Bedynek on Friday, February 17, 2006 14:36:50
    Not everybody wants to or can run fastecho or hpt. Besides, you
    cant register fastecho anymore anyway. :-)

    says who? certainly not me ;) i'm also aware of at least one individual who has registered FE in the recent past ;)

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Matt Bedynek on Friday, February 17, 2006 14:38:02
    i believe that it should be you wearing that condom, my friend... CYOA
    and all that stuff... if your system has a limit of 100k messages,
    then -=you=- should be running "preprocessor" software to cut messages down to 100k of smaller...

    Feel free to code that preprocessor for the rest of us to use.

    that preprocessor has already been coded and available to fidonet in several flavors for... hummm... gee... at least 10 years...

    )\/(ark


    * Origin: (1:3634/12)
  • From Marty Blankenship@1:2320/303 to Mark Lewis on Friday, February 17, 2006 20:40:49
    |11┌─|03─[|15Quoting |12Mark Lewis |15to |12Matt Bedynek |03]──∙·· |11└─|03─[|15Taken from: |13[Fido] Squish Help |03]──»

    Feel free to code that preprocessor for the rest of us to use.

    that preprocessor has already been coded and available to fidonet in severa flavors for... hummm... gee... at least 10 years...

    A link to where we can find this jewel would be of some help, as well as the name of such a program.

    The GameMaster BBS Home of Marty's Mercantile, an IGM for L.O.R.D.
    Also home of Bluenet message network. Telnet to any of the following.
    gamemasterbbs.darktech.org gamemaster.dtdns.net gamemasterbbs.no-ip.com gamemaster.bbs.us Lots of InterBBS games available as well as local ones.

    --- Renegade v08-30.5 DOS/EXP
    * Origin: The GameMaster BBS | gamemasterbbs.darktech.org (1:2320/303)
  • From Matt Bedynek@1:106/1 to mark lewis on Saturday, February 18, 2006 03:13:36
    Hello mark.

    17 Feb 06 14:38, you wrote to me:

    Feel free to code that preprocessor for the rest of us to use.

    that preprocessor has already been coded and available to fidonet in several flavors for... hummm... gee... at least 10 years...

    )\/(ark

    If you're thinking pktsort, I have already said, I found numerous bugs in it.

    Matt

    e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

    "to be loved is fortunate, but to be hated is to achieve distinction"

    ---
    * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)