• Re: Unix point?

    From Tim Schattkowsky@2:240/1120.29 to Maurice Kinal on Thu Jan 13 17:05:36 2022
    //Hello Maurice,//

    on *13.01.22* at *2:21:07* You wrote in rea *FTSC_PUBLIC*
    to *Tim Schattkowsky* about *"Unix point?"*.

    Hey Tim!
    There is no advantage in your proposal
    What proposal?

    All those redundant Kludges you use instead of the standard ones that cause your messages to shop up in the wrong place in my message list (no TZ info) and render with some garbage (no CHRS).

    Regards,
    Tim
    --- WinPoint 389.0
    * Origin: Original WinPoint Origin! (2:240/1120.29)
  • From Maurice Kinal@1:153/7001 to Tim Schattkowsky on Thu Jan 13 16:40:06 2022
    Hey Tim!

    All those redundant Kludges you use instead of the standard ones

    Ah! Here is a reply with none of that. I seriously doubt that is the problem though and if it is then you will discover many msgs that don't follow those particuar standards. As far as I know they aren't required. Do you know better?

    I think you got suckered in.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From mark lewis@1:3634/12.73 to Tim Schattkowsky on Thu Jan 13 14:46:24 2022

    On 2022 Jan 13 17:05:36, you wrote to Maurice Kinal:

    There is no advantage in your proposal
    What proposal?

    All those redundant Kludges you use instead of the standard ones that cause
    your messages to shop up in the wrong place in my message list (no TZ info)
    and render with some garbage (no CHRS).

    his point is that he did not make a proposal (yet)...

    granted, he could/should use the existing control lines in addition to the one's he testing and may eventually propose...

    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... an Australian kiss is basically a French kiss, BUT DOWN UNDER
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001.2989 to mark lewis on Thu Jan 13 13:48:36 2022
    Hey mark!

    he could/should use the existing control lines in addition to
    the one's he testing

    Do you mean like this reply?

    and may eventually propose...

    I doubt I'll live that long.

    Anyhow I've already tested this particular idea and ended up rejecting it. However in the spirit of demonstration, I'll try one more time although it doesn't look any better than the last test. I maintain the CHRS and TZUTC should both be turfed never to be mentioned ever again for all eternity. Also the two digit year in the msgHeader while we're at it but that is another can of worms that *could* have been fixed with a proper utc offset and not the emasculated fts-4008.002 version.

    Life is good,
    Maurice

    ... Ælces monnes lif bið sumes monnes lar.
    Every man's life may be a lesson to someone.
    --- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
    * Origin: One of us @ (1:153/7001.2989)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Fri Jan 14 07:00:38 2022

    On 2022 Jan 13 13:48:36, you wrote to me:

    @REPLY: 1:3634/12.73 61e08216
    @MSGID: 1:153/7001.2989 61e0a1bb
    @ENCODING: UTF-8
    @CHRS: UTF-8 4
    @TZ: UTC+08:15:02
    @TZUTC: -0815
    Hey mark!

    he could/should use the existing control lines in addition to
    the one's he testing

    Do you mean like this reply?

    yes... but i have to wonder about the TZ control line having seconds in it... i'm also not so sure that UTC+8 hours is right for a system located on the western coast of Canada... unless your TZ code is using a/the non-POSIX format(?) or you are playing with your clock time as well ;)

    and may eventually propose...

    I doubt I'll live that long.

    it doesn't take long to come up with an idea that is good which other developers pick up and put into use... once that's done, the idea is all fleshed out, and working properly, one then only needs to write the proposal with the details of the idea and it's implementation and present said proposal for other developers to also pick up and start using if they want to...

    Anyhow I've already tested this particular idea and ended up rejecting
    it.

    why?

    However in the spirit of demonstration, I'll try one more time
    although it doesn't look any better than the last test. I maintain
    the CHRS and TZUTC should both be turfed never to be mentioned ever
    again for all eternity.

    TZUTC is in place to clarify the time stamp in the message header since it is local time with no other indication of where "local" is...

    have you looked at any of the other PKT and packed message formats? have you implemented any of them and gotten other developers to also implement them? that's what it takes to get things changed, ya know...

    Also the two digit year in the msgHeader while we're at it but that is another can of worms that *could* have been fixed with a proper utc
    offset

    this is true but we also have to remember how storage was back in the days when these formats were created... i remember being logged into a few BBSes and having to ask the operator to change floppies in some drive so i could read older or newer messages or even to access some files that were offline at that time... generally speaking, after a few minutes, they would tell me to try again and there they were... that being because they had switched the data floppy out for the desired one... ahhh, the olden days when operators had to actually operate their systems :)

    and not the emasculated fts-4008.002 version.

    i still cannot believe all this knicker twisting because somehow one cannot or refuses to code for a space or lack of a negative symbol to be recognized as a positive indicator before a number... i mean, that is the defacto standard all over the world where numbers are used... imagine if our math had to be written like this

    +2 + +2 = +4

    instead of the much more common

    2 + 2 = 4

    really?? [smh]

    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... We can't have a crisis today, my schedule is already full.
    ---
    * Origin: (1:3634/12.73)
  • From Tim Schattkowsky@2:240/1120.29 to mark lewis on Fri Jan 14 15:13:50 2022
    //Hello mark,//

    on *14.01.22* at *12:00:38* You wrote in rea *FTSC_PUBLIC*
    to *Maurice Kinal* about *"Unix point?"*.

    have you looked at any of the other PKT and packed message formats? have you implemented any of them and gotten other developers to also implement them? that's what it takes to get things changed, ya know...

    Foremost, he should try to fix things that are actually broken. CHRS and TZUTC are not (although CHRS is slightly overengineered, but does the job).

    For Fido, I see other problems like privacy/security and even message length where the existing technology really is not state of the art. Also, use of MIME etc. comes to mind when it comes to message content. But given the current state of Fido, I do not think that there will be any substatial technology changes at all. Also, because they are more likely to drive people away than to attract new users.

    On the other hand, even the two-digit date is not pressing at all. If Fido still exists when that becomes relevant ...

    Regards,
    Tim
    --- WinPoint 390.0
    * Origin: Original WinPoint Origin! (2:240/1120.29)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Fri Jan 14 10:48:08 2022

    On 2022 Jan 14 05:30:50, you wrote to me:

    have you looked at any of the other PKT and packed message formats?

    Type 2, 2+ and 2.2. 2.2 only works with one of my uplinks.

    so none of the Type 3 or Type 10 formats?

    +2 + +2 = +4

    Fine for numbers but lousy for strings.

    TZUTC1 + TZUTC2 = ?!?!?!?!?!?!

    What in the name of strftime() is confusing you? You appear to be suffering from the same affliction as everyone east of prime meridian (castration?). +0000 is a string (N)ot (a) (N)umber (<- NaN). Stripping off the '+' character effectively corrupts it.

    until you convert it to a number for the necessary math when needed ;)

    really??

    Yes. Basic programming skills inform me that strings are not numbers even if they look like numbers. The utc offset *is* a string ... or at least real life ones are.

    yep... and at some point, their contents are converted from their string representation to some sort of numeric representation so they can be added or subtracted from a time value to give the time in another location...

    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... Age is a very high price to pay for maturity.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Tim Schattkowsky on Fri Jan 14 11:07:18 2022

    On 2022 Jan 14 15:13:50, you wrote to me:

    have you looked at any of the other PKT and packed message formats?
    have you implemented any of them and gotten other developers to also
    implement them? that's what it takes to get things changed, ya
    know...

    Foremost, he should try to fix things that are actually broken. CHRS
    and TZUTC are not (although CHRS is slightly overengineered, but does
    the job).

    agreed... to a point :)

    For Fido, I see other problems like privacy/security and even message length where the existing technology really is not state of the art.

    FWIW: message bodies are unbounded in FTN specs... any limitations seen are placed there by the devs of those particular tools that exhibit message length problems...

    from FTS-0001...

    1. Application Layer Data Definition : a Stored Message

    Stored Message

    Offset
    dec hex
    .-----------------------------------------------.
    [...]
    +-----------------------+-----------------------+
    190 BE | text |
    ~ unbounded ~
    | null terminated |
    `-----------------------------------------------'
    [...]
    1. Presentation Layer Data Definition : the Packed Message

    [...]
    Packed Message

    Offset
    dec hex
    .-----------------------------------------------.
    [...]
    +-----------------------+-----------------------+
    34 22 | toUserName |
    ~ max 36 bytes ~
    | null terminated |
    +-----------------------+-----------------------+
    | fromUserName |
    ~ max 36 bytes ~
    | null terminated |
    +-----------------------+-----------------------+
    | subject |
    ~ max 72 bytes ~
    | null terminated |
    +-----------------------+-----------------------+
    | text |
    ~ unbounded ~
    | null terminated |
    `-----------------------------------------------'

    just saying ;)


    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... When you're the devil, women instantly suspect your motives. -Satan
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Fri Jan 14 14:27:12 2022

    On 2022 Jan 14 10:18:14, you wrote to me:

    so none of the Type 3 or Type 10 formats?

    None. What for? From what I've witnessed over the last two decades is that there is no official acceptance of type 2+ headers which from this angle looks to be the most used.

    not all proposals are accepted or if accepted, stick around...

    Besides why tackle a new idea

    they're not new ideas... just no one, other than their originator, has looked at them and considered to actually implement them...

    if we can't get the even the simplest things right such as telling the difference between a number and a string.

    Just saying ... :-)

    you really should take a closer look at strftime, then... somewhere inside it, there is a conversion from string to numerics and back to string again otherwise the hour in the time could not be added or subtracted from the hour in the offest string... think about it... just saying...

    until you convert it to a number for the necessary math when
    needed ;)

    Sure. I'd appreciate seeing your routine for taking care of that,

    trace out all the code in your strftime... i'm pretty sure you'll find something in there that does the conversion ;)

    their string representation to some sort of numeric
    representation so they can be added or subtracted from a time
    value to give the time in another location...

    You don't even have to do that if you use strftime() and a suitable offset.

    strftime /HAS/ to convert from string to digit and back /somewhere/ within itself or a routine it makes use of... there's no other way to do math, my friend ;)

    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... The vegetarian has rejected a foundational principle of our culture.
    ---
    * Origin: (1:3634/12.73)
  • From Tim Schattkowsky@2:240/1120.29 to mark lewis on Fri Jan 14 18:31:56 2022
    //Hello mark,//

    on *14.01.22* at *16:07:18* You wrote in rea *FTSC_PUBLIC*
    to *Tim Schattkowsky* about *"Unix point?"*.

    FWIW: message bodies are unbounded in FTN specs... any limitations seen are placed there by the devs of those particular tools that exhibit message length problems...

    I know, but this clash with the reality of many implementations (not including WP, at least up to ~2GB message length) makes the situation worse. What I have seen is that commonly messages are in practice split at slightly below 64k and I am not sure if any real world software bothers recombining them (WP does not). However, since this was mostly relevanted for gated emails, it is today probably of little practical interest anyway.

    Regards,
    Tim
    --- WinPoint 390.0
    * Origin: Original WinPoint Origin! (2:240/1120.29)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Fri Jan 14 18:21:50 2022

    On 2022 Jan 14 20:27:36, you wrote to me:

    not all proposals are accepted or if accepted, stick around...

    Too bad they missed out on the opportunity to not accept a few of them that stick around when they have no right to exist in the first place.

    that's your opinion... i won't even ask who it is you think assigns any so-called rights to any proposals' existence...

    somewhere inside it, there is a conversion from string to numerics
    and back to string again

    No doubt.

    thank you...

    However it REQUIRES the first character in the string to be either a
    '+' (east) or a '-' (west). Note the REQUIRE and that is part and
    parcel of the offset ... which is always a string ... which is always
    NaN.

    you keep forgetting to add "in your chosen routine" to your statements... other routines that do the same or similar job do not have such a requirement...

    Dropping the '+' character ist vorboten.

    mmmhummm... no '+' here... plus you just said that it could be one of two specific characters so...

    TZ=UTC date --rfc-3339=sec --date="14 Jan 2022 22:27:36 -0000"
    2022-01-14 22:27:36+00:00

    then there's this which also works just fine IF you like the ISO8601 format... some do not care for it...

    TZ=UTC date --rfc-3339=sec --utc
    2022-01-14 22:27:36+00:00

    but you already know these things and are just trying to get your jollies arguing about something... meh... i'm done because it isn't worth it, it is a very old argument (like 2 decades now you've been going on about this??), and simply said, it is not what the developer who wrote the accepted spec decided to use...


    PS: yes, i did time my use of the above 2nd date call (with --utc) to match the example naturally :)

    PPS: i also note your use of a two-digit year in your examples ;)

    PPPS: the resulting '+' or '-' on the time zone is likely due to the use of a boolean array where only true or false are allowed...

    eg:
    const
    FmtOffset: string = '%.02d%.02d';
    Sign: array[Boolean] of Char = ('+', '-');

    var
    LocalTimeOffset: Integer;

    begin
    LocalTimeOffset := GetLocalTimeOffset;
    Writeln (FormatDateTime('YYYY MMM DD hh:mm:ss', Now) + ' ' + Sign[LocalTimeOffset>0],
    Format(FmtOffset, [LocalTimeOffset div MinsPerHour, LocalTimeOffset mod MinsPerHour]));
    end.

    2022 Jan 14 17:27:36 -0500


    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... Remember: Landings should always equal takeoffs!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Tim Schattkowsky on Fri Jan 14 18:23:42 2022

    On 2022 Jan 14 18:31:56, you wrote to me:

    FWIW: message bodies are unbounded in FTN specs... any limitations
    seen are placed there by the devs of those particular tools that
    exhibit message length problems...

    I know,

    i thought you probably did :)

    but this clash with the reality of many implementations (not including
    WP, at least up to ~2GB message length) makes the situation worse.
    What I have seen is that commonly messages are in practice split at slightly below 64k

    this is what happens when hobbiests in highschool or early university write things for use in a network like fidonet... i remember someone, years ago, being quite happy and posting about them figuring out how to buffer the excess to a disk file instead of trying to handle everything in memory with the 64k limitation that was in effect back in those days... i think this was some time after i had released a tool that was capable of posting the entire nodelist of that time in one message... yeah... IIRC it was over 2G in size :)

    and I am not sure if any real world software bothers recombining them
    (WP does not).

    perhaps you might look at the ^ASPLIT specification? there are tools that can unsplit those messages, too... i've used one or two of them in the past... generally they were used on the local side in the middle of the PKT processing flow... they would process the incoming PKT and create a new PKT with the messages put back together... then the tosser would run and place the full message into the message base while also tossing to downstream system and again splitting the message according to that system's tosser configs...

    TBH, ^ASPLIT should have only been used on the local system if the message could not fit in the local message base storage format... that would have been a lot better than foisting it on all the systems in the path and making them have more messages to process but that made too much sense, really...

    However, since this was mostly relevanted for gated emails, it is
    today probably of little practical interest anyway.

    sadly, it wasn't limited to only gated messages... it was more of "lazy coders unwilling or not knowing how to buffer to disk files"... this in the name of processing speed and trying to get or have the fastest message processing throughput they could attain... in today's world, they would still do everything in memory without disk buffering but this is because the whole methodology has changed and those former restrictions simply don't exist any more...

    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... On T-Day that rash on your stomach turns out to be steering wheel burn.
    ---
    * Origin: (1:3634/12.73)
  • From Maurice Kinal@1:153/7001 to mark lewis on Fri Jan 14 23:51:58 2022
    Hey mark!

    i'm done because it isn't worth it

    Amen.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Sat Jan 15 11:29:10 2022
    Hi mark,

    On 2022-01-14 18:23:42, you wrote to Tim Schattkowsky:

    ... i think this was some time after i had released a tool that was capable of posting the entire nodelist of that time in one message... yeah... IIRC it was over 2G in size :)

    You probably mean 2M ! It was never in the G size...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Sat Jan 15 12:11:00 2022
    Wilfred wrote (2022-01-15):

    Hi mark,

    On 2022-01-14 18:23:42, you wrote to Tim Schattkowsky:

    ... i think this was some time after i had released a tool that was
    capable of posting the entire nodelist of that time in one
    message... yeah... IIRC it was over 2G in size :)

    You probably mean 2M ! It was never in the G size...

    inflation-adjusted 2M is around 2G nowadays ;-)

    ---
    * Origin: Birds aren't real (2:280/464.47)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Sat Jan 15 07:50:30 2022

    On 2022 Jan 15 11:29:10, you wrote to me:

    ... i think this was some time after i had released a tool that was
    capable of posting the entire nodelist of that time in one message...
    yeah... IIRC it was over 2G in size :)

    You probably mean 2M ! It was never in the G size...

    oops! you're right :LOL:

    )\/(ark

    "The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
    ... IF I HEAR THAT WORD ONE MORE TIME, I'M GONNA LEVEL THIS PLACE.
    ---
    * Origin: (1:3634/12.73)
  • From Tim Schattkowsky@2:240/1120.29 to Oliver Deiter on Sat Jan 15 16:57:32 2022
    //Hello Oli,//

    on *15.01.22* at *11:11:01* You wrote in rea *FTSC_PUBLIC*
    to *Wilfred van Velzen* about *"Unix point?"*.

    Wilfred wrote (2022-01-15):

    Hi mark,

    On 2022-01-14 18:23:42, you wrote to Tim Schattkowsky:

    ... i think this was some time after i had released a tool that was
    capable of posting the entire nodelist of that time in one message...
    yeah... IIRC it was over 2G in size :)

    You probably mean 2M ! It was never in the G size...

    Which bringst me to the point that I simply do not understand the memory usage of certain kinds of applications nowadays. For some things like web browsers, it is at least obvious that there is potential to abuse a lot of memory. For others, like many simple business applications, I dont see any reason why something the would have easily fit a C64 nowadays instally to GBs on disk and requires GBs to operate.

    Regards,
    Tim
    --- WinPoint 390.1
    * Origin: Original WinPoint Origin! (2:240/1120.29)
  • From Wilfred van Velzen@2:280/464 to Tim Schattkowsky on Sat Jan 15 17:39:10 2022
    Hi Tim,

    On 2022-01-15 16:57:32, you wrote to Oliver Deiter:

    You probably mean 2M ! It was never in the G size...

    Which bringst me to the point that I simply do not understand the memory usage of certain kinds of applications nowadays. For some things like web browsers, it is at least obvious that there is potential to abuse a lot of memory. For others, like many simple business applications, I dont see any reason why something the would have easily fit a C64 nowadays instally to GBs on disk and requires GBs to operate.

    Because they use java for instance? That comes with a ton of "needed" libraries...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Tim Schattkowsky@2:240/1120.29 to Wilfred van Velzen on Sun Jan 16 14:36:50 2022
    //Hello Wilfred,//

    on *15.01.22* at *16:39:10* You wrote in rea *FTSC_PUBLIC*
    to *Tim Schattkowsky* about *"Re: Unix point?"*.

    Hi Tim,

    On 2022-01-15 16:57:32, you wrote to Oliver Deiter:

    You probably mean 2M ! It was never in the G size...

    Which bringst me to the point that I simply do not understand the memory
    usage of certain kinds of applications nowadays. For some things like
    web browsers, it is at least obvious that there is potential to abuse a
    lot of memory. For others, like many simple business applications, I
    dont see any reason why something the would have easily fit a C64
    nowadays instally to GBs on disk and requires GBs to operate.

    Because they use java for instance? That comes with a ton of "needed" libraries...

    Even that seems to be nowadays a drop on the hot stone in the whole picture. Still, how those got that big is also interesting.

    Regards,
    Tim
    --- WinPoint 391.0
    * Origin: Original WinPoint Origin! (2:240/1120.29)