• a dear deer visitor

    From August Abolins@2:221/1.58 to All on Sat Apr 10 09:04:00 2021
    Hello All!

    I had a visitor this morning:

    https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

    There were actually two of them, but I only had the mind to try
    and film something when the 1st one had already walked by.



    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sat Apr 10 13:54:43 2021
    -={ 2021-04-10 13:54:43.739887657+00:00 }=-

    Hey August!

    https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

    'mplayer -vo fbdev2' on the console works but was a bit choppy. I tried playing with a cache in hopes to improve it but it didn't so then I downloaded it and played it locally. Bingo! Nice and smooth. Fullscreen too. :-)

    Too slow of a connection. wget shows 706 KB/s. An old fashioned mpeg2 probably would be better for streaming. Just saying ...

    Life is good,
    Maurice

    ... Gemæne sceal maga feoh.
    Wealth should be shared by kinsmen.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:460/256 to Maurice Kinal on Sat Apr 10 18:35:32 2021
    Hi Maurice,
    ...Greets from my Telegram app!

    -={ 2021-04-10 13:54:43.739887657+00:00 }=-

    Hey August!

    https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

    'mplayer -vo fbdev2' on the console works but was a bit choppy. I tried playing with a cache in hopes to improve it but it didn't so then I downloaded it and played it locally. Bingo! Nice and smooth. Fullscreen too. :-)

    Too slow of a connection. wget shows 706 KB/s. An old fashioned mpeg2 probably would be better for streaming. Just saying ...

    Life is good,
    Maurice

    ... Gem?ne sceal maga feoh.
    Wealth should be shared by kinsmen.

    Thanks for the heads-up on that. I had a feeling that maybe I should have built a media "container" in html for it. Directly from the isp, it plays very choppy for me too even on DSL.

    Firefox doesn't give me and option to right-click/download it either.

    Ciao!
    /|ug (https://t.me/aabolins)

    ... Searchable Help for OXP https://openxp.kolico.ca
    --- tg BBS v0.6.4
    * Origin: Fido by Telegram BBS from Stas Mishchenkov (2:460/256)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sat Apr 10 17:48:03 2021
    -={ 2021-04-10 17:48:03.371541649+00:00 }=-

    Hey August!

    Thanks for the heads-up on that.

    You're welcome.

    Firefox doesn't give me and option to right-click/download it
    either.

    Compared to the rest of the GUI based browsers, firefox is the best. At the moment there are issues with firefox and it's required dependencies so I am sticking with console based commandline tools which happens to suit me just fine thank you very much. :-)

    What did you use to shoot the mp4? I got the impression it was either a smart phone or tablet. Whatever it did a nice job of it.

    Life is good,
    Maurice

    ... Yldo beoð on eorðan æghwæs cræftig.
    Old age has power over everything on earth.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sat Apr 10 18:06:00 2021
    Hello Maurice!

    ** On Saturday 10.04.21 - 17:48, you wrote to:

    -={ 2021-04-10 17:48:03.371541649+00:00 }=-
    ^^^^^^^^^

    Down to the æsec?

    Firefox doesn't give me and option to right-click/download
    it either.

    Compared to the rest of the GUI based browsers, firefox is the best.

    I actually managed to get a right-click save-as option when I
    visited this message on a webby-based bbs. :D

    At the moment there are issues with firefox and it's
    required dependencies so I am sticking with console based
    commandline tools which happens to suit me just fine thank
    you very much. :-)

    I don't blame you. There is a certain control and power when
    commanding things via commandline. It's not called commandline
    for nothing! :)


    What did you use to shoot the mp4? I got the impression it
    was either a smart phone or tablet. Whatever it did a nice
    job of it.

    Blackberry Q10.
    Video: 1080p@30fps
    Frame: 1280x720

    If the window was cleaner, the image would have been much
    better. I leaned the BB against the window and panned the scene
    while the top part of the BB was touching the window so that I
    could still swivel the device.
    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sat Apr 10 18:15:00 2021
    Hello Maurice!

    https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

    'mplayer -vo fbdev2' on the console works but was a bit choppy. I tried playing with a cache in hopes to improve it but it didn't so then I downloaded it and played it locally. Bingo! Nice and smooth.
    Fullscreen too. :-)

    Yes.. testing it on a widescreen laptop, the result DOES look
    pretty good.

    Streaming directly from the link sucked for me too. Even with
    DSL, my top speed is usually 650Kbps, and the result was stop-n-
    go. Not nice.


    Too slow of a connection. wget shows 706 KB/s. An old
    fashioned mpeg2 probably would be better for streaming.
    Just saying ...

    At about 15MB and 15sec, 1MB/sec is a pretty rich expectation
    for a stream. A down-conversion for this kind of stuff is
    probably a good idea.

    Funny note: having filmed the scene on my BB, I really had no
    way to "send" the file to my server unless I were to email it to
    myself first. But that would have consumed 15MB (+30% for mime
    encoding) going up, and another 15MB coming down. So, no thanks.
    Instead, I used Bluetooth to send it to a newer laptop that I
    have. From there, I copied it onto a USB stick. Form there, I
    was able to get it on the other laptop that I prefer! From
    there, it went up to the server via FTP.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sat Apr 10 22:57:51 2021
    -={ 2021-04-10 22:57:51.962196849+00:00 }=-

    Hey August!

    -={ 2021-04-10 17:48:03.371541649+00:00 }=-
    ^^^^^^^^^

    If you count the decimal places it is 10^-9 which is nanoseconds. However in terms of accuracy it is impossible for anything I have to get better than 10's of nanoseconds under ideal conditions and I seriously doubt that given dedicated gigabit networks to sync with ntp. In that case I'd be surprised if it better than 10's of microseconds. Given the internet and ntp servers out there in the cold, cruel world I'd be comfotable saying millisecond accuracy. No doubt in my mind that everything here agrees with up to the second accuracy which is overkill for fidonet messaging. The reason for the nanosecond display is for uniqueness of messages for a potential MSGID upgrade when the time comes ... if indeed it comes. I am a good boy scout - be prepared is the motto they live by or so I am led to believe.

    I actually managed to get a right-click save-as option when I
    visited this message on a webby-based bbs. :D

    I use a text browser with no mouse for that. The 'd' key provides that functionality.

    Blackberry Q10.
    Video: 1080p@30fps
    Frame: 1280x720

    Definetly good enough for any usage I might have for such a thing. I've run across a few so-called webcams (usb 3.0) that claim 120fps although those are way too expensive to even consider using as a webcam or the such. However the ability to do up to 60fps might be something of interest if it doesn't break the bank.

    If the window was cleaner

    I noticed that. No matter as I took that into account. At first I thought your lens needed cleaning until you panned following the deer and the obvious dirty spot never moved with the camera. Time to think about spring cleaning. ;-)

    Life is good,
    Maurice

    ... A hafað longunge se þe on lagu fundað.
    He ever has a longing who sets out on the sea.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sat Apr 10 23:24:18 2021
    -={ 2021-04-10 23:24:18.487612181+00:00 }=-

    Hey August!

    Yes.. testing it on a widescreen laptop, the result DOES look
    pretty good.

    From what I saw on a 24" widescreen monitor I wouldn't be surprised.

    Streaming directly from the link sucked for me too.

    You need a better connection for that, especially for x264 live streams. Perhaps 720p might work best for this idea and/or a mpeg2 instead. Given that usb 2.0 was good enough for streaming DVDs then mpeg2 on that particular connection might be just what the doctor ordered.

    A down-conversion for this kind of stuff is probably a good idea.

    That can be done on-the-fly these days. Definetly something to inquire about.

    Life is good,
    Maurice

    ... Onwald mæg wel reccean se þe ægðer ge hiene habban con ge wiðwinnan.
    He wields power well who can both hold and resist it.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sat Apr 10 20:58:00 2021
    Hello Maurice!

    ** On Saturday 10.04.21 - 22:57, you wrote to me:

    -={ 2021-04-10 17:48:03.371541649+00:00 }=-
    ^^^^^^^^^

    If you count the decimal places it is 10^-9 which is nanoseconds.

    Amazing.

    ...The reason for the nanosecond display is for uniqueness
    of messages for a potential MSGID upgrade when the time
    comes ... if indeed it comes. I am a good boy scout - be
    prepared is the motto they live by or so I am led to
    believe.

    For msgid purposes why not just generate a 6 to 9 character hash
    based on the content of the message? That would ALWAYS be
    unique and never repeat for a l-o-n-g time.

    The current approach for msgid has been to have serial number.
    But why can't it be a simple hash?

    FSC-0033 of June 11, 1989 proposes and interesting version for
    msgid:

    ^AFMSGID:DDDYYHHMMSSLLNNNNOOOOPPPP[ZZZZ][Domain]

    But I think progams today stick with the 8-char hex form. It
    would be hard to get existing systems to work with anything
    outside of that format now.

    Synchronet systems have come up with another unique approach to
    the MSGID line which seems to cooperate with existing systems
    quite well.

    I use a text browser with no mouse for that. The 'd' key
    provides that functionality.

    I hear that you use text-based on pretty much everything these
    days.

    ..and the obvious dirty spot never moved with the camera.
    Time to think about spring cleaning. ;-)

    That window was the worst. There is a 15 ft drop to the ground
    outside that particular window. The only way to clean it is to
    disassemble the window from the inside. That's a lot of work. I
    haven't cleaned that one for years.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Jay Harris@1:229/664 to August Abolins on Sat Apr 10 21:14:19 2021
    *** Quoting August Abolins from a message to Maurice Kinal ***

    That window was the worst. There is a 15 ft drop to the ground
    outside that particular window. The only way to clean it is to
    disassemble the window from the inside. That's a lot of work. I
    haven't cleaned that one for years.

    We tried the Windex garden hose attachment a few years back. It worked... okay. Certainly not as great as cleaning them by hand, but better than when we started.

    https://www.canadiantire.ca/en/pdp/windex-outdoor-multi-surface-concentrated-c leaner-0532078p.html


    Jay

    ... Beat inflation - steal!

    --- Telegard v3.09.g2-sp4/mL
    * Origin: Northern Realms | 289-424-5180 | bbs.nrbbs.net (1:229/664)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sun Apr 11 03:20:24 2021
    -={ 2021-04-11 03:20:24.695191775+00:00 }=-

    Hey August!

    For msgid purposes why not just generate a 6 to 9 character hash
    based on the content of the message? That would ALWAYS be
    unique and never repeat for a l-o-n-g time.

    The method I am thinking should never repeat and should be good up to -={ 2147485547-12-31 23:59:59.999999999+00:00 }=-. That is over 2 billion years from now.

    Currently I am just using the hex representation of an unsigned 32-bit unixtime but there is just me and I can't produce more then one MSG within minutes, nevermind seconds and the serial number generated is unique up to -={ 2106-02-07 06:28:15+00:00 }=-. Thus the largest unique serial number possible is ffffffff. For signed 32-bit integers -={ 2038-01-19 03:14:07+00:00 }=- is the end of the line and will produce a MSGID serial number of 7fffffff which is the largest hex value for signed 32-bit integers.

    If I am not mistaken -={ 2106-02-07 06:28:15+00:00 }=- is the upper limit for Synchronet systems or at least that is what I was told. When I pay attention to it I have noticed the serial numbers look very familiar to me.

    Your serial number for the MSG I am replying to yields -={ 2097-03-19 18:09:50+00:00 }=- which is obviously not a time based generated serial number and definetly not a 32-bit signed integer.

    I hear that you use text-based on pretty much everything these
    days.

    Since the beginning, which for me was back in the late 1980's on VAX/VMS. Solaris was the first GUI I ever ran across sometime around 1989-ish if I am remembering correctly. For VAX/VMS Fortran (F77) was the compiler of choice while for Solaris it was C all the way which has taken me up to and including today as I upgrade to gcc-10.3.0 as we speak. :-)

    That window was the worst. There is a 15 ft drop to the ground
    outside that particular window. The only way to clean it is to
    disassemble the window from the inside. That's a lot of work. I
    haven't cleaned that one for years.

    I hear you. I am getting too old for that sort of thing. Mind you I have no windows that high up. All mine I can reach without a ladder.

    Life is good,
    Maurice

    ... Æghwilc ðing þe on þys andweardan life licað lænu sindon.
    Everything which is pleasing in this present life is on loan.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Sun Apr 11 13:05:42 2021
    Hi August,

    On 2021-04-10 20:58:00, you wrote to Maurice Kinal:

    For msgid purposes why not just generate a 6 to 9 character hash
    based on the content of the message? That would ALWAYS be
    unique and never repeat for a l-o-n-g time.

    There are those moderator messages that stay the same for ages...

    The current approach for msgid has been to have serial number.
    But why can't it be a simple hash?

    A good secure hash, needs a lot of cpu to be calculated.

    Synchronet systems have come up with another unique approach to
    the MSGID line which seems to cooperate with existing systems
    quite well.

    It isn't according to the standard, which might cause some problems on other systems.

    And I think it went like this: They miss used the MSGID to store some internal information for their messagebase, and came up with an excuse afterwards, when it was difficult to correct.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Sun Apr 11 08:56:00 2021
    Hello Wilfred!

    ** On Sunday 11.04.21 - 13:05, you wrote to me:

    For msgid purposes why not just generate a 6 to 9
    character hash based on the content of the message? That
    would ALWAYS be unique and never repeat for a l-o-n-g
    time.

    There are those moderator messages that stay the same for
    ages...

    Not if the hash includes the entire msg and the date posted.

    The current approach for msgid has been to have serial number.
    But why can't it be a simple hash?

    A good secure hash, needs a lot of cpu to be calculated.

    Even a simple random num generator could work. For example, the
    following took less than a sec to produce:

    H:\myutils>rando2
    lfz$bkmcmmg36ye@jll1xpieaats

    H:\myutils>rando2
    7zc3i6btkuwyax2tpbh814$392c

    H:\myutils>rando2
    g~zys4kmp$9s0h@4jxp169j##8eskb

    H:\myutils>rando2
    p67v3h$vy3pdqo9t6rueljbv0qf

    H:\myutils>rando2
    m0s#trrv~bxjsg0f$mo29q8g$6699l

    H:\myutils>rando2
    $3111un9@je2dey$jwdehlzk01g

    H:\myutils>rando2
    q5ur8jolf#@4227~#73g99@lpy0dh@

    H:\myutils>rando2
    u4iouevy9yrh6~1it~2z$asr5y@

    H:\myutils>rando2
    cu1#0wqju$11~1lu#gklu52o9#k3v

    So.. why couldn't something like that be implemented? And,
    instead of limiting the "serialno" to hex chars, use the entire
    alphabet and throw in some extra chars (# $ ~ % & *)

    Synchronet systems have come up with another unique
    approach to the MSGID line which seems to cooperate with
    existing systems quite well.

    It isn't according to the standard, which might cause some
    problems on other systems.

    I thought it was copacetic with other systems. On which ones
    does it break?

    And I think it went like this: They miss used the MSGID to
    store some internal information for their messagebase, and
    came up with an excuse afterwards, when it was difficult
    to correct.

    I remember something about the MSGID being referred to as a two-
    part string with "origaddr" + "serialno", where "origaddr" is
    intended to be a qualified "address of the originating system".

    Most systems keep it simple:

    z:f/n.p hhhhhhhh

    And some others look like:

    n.areaname@z:f/n.p hhhhhhhh

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Sun Apr 11 17:48:47 2021
    Hi August,

    On 2021-04-11 08:56:00, you wrote to me:

    There are those moderator messages that stay the same for
    ages...

    Not if the hash includes the entire msg and the date posted.

    Ok. But the serial based ones are still better. ;)

    A good secure hash, needs a lot of cpu to be calculated.

    Even a simple random num generator could work. For example, the
    following took less than a sec to produce:

    H:\myutils>> rando2
    lfz$bkmcmmg36ye@jll1xpieaats

    Those aren't 32 bit.

    So.. why couldn't something like that be implemented? And,
    instead of limiting the "serialno" to hex chars, use the entire
    alphabet and throw in some extra chars (# $ ~ % & *)

    Well it could if it complies to the standard. The serial based ones are still better, because they take less cpu. And they can be made so they don't repeat within three years. With random numbers, or with hashes, there's always a change of a collision within 3 years.

    Synchronet systems have come up with another unique
    approach to the MSGID line which seems to cooperate with
    existing systems quite well.

    It isn't according to the standard, which might cause some
    problems on other systems.

    I thought it was copacetic with other systems. On which ones
    does it break?

    I don't know, but it is not according to the standard, so it could cause problems. That doesn't directly mean that things noticeably break. But maybe dupe detection doesn't work as reliable for those...

    And I think it went like this: They miss used the MSGID to
    store some internal information for their messagebase, and
    came up with an excuse afterwards, when it was difficult
    to correct.

    I remember something about the MSGID being referred to as a two-
    part string with "origaddr" + "serialno", where "origaddr" is
    intended to be a qualified "address of the originating system".

    No: "... address for the originating network"
    ^^^^^^^

    http://ftsc.org/docs/fts-0009.001

    Most systems keep it simple:

    z:f/n.p hhhhhhhh

    And some others look like:

    n.areaname@z:f/n.p hhhhhhhh

    That's not a valid fido address.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Sun Apr 11 13:53:00 2021
    Hello Wilfred!

    Not if the hash includes the entire msg and the date posted.

    Ok. But the serial based ones are still better. ;)


    I can see that to be the case as well. A serial-style also has
    a built-in chronological feature.

    H:\myutils>> rando2
    lfz$bkmcmmg36ye@jll1xpieaats

    Those aren't 32 bit.

    Ah... so the "serialno" part *must" be 8-char? Then rando could
    still work like so:

    H:\myutils>rando
    yZn=ZRG-
    i)G)0ej=
    YwSj-6B+
    kwg5r(aR
    Fp902h8A
    lFyNVofN
    R)5vlK+(
    Sg7y-pPE
    DDvCC2Sm
    mX20Wj3d
    ()AO8oN\
    \DTe29VA
    4xqhDjbB
    QXK\uqOs

    :D


    there's always a change of a collision within 3 years.

    Yes.. I've suspected that could be problematic. But look at the
    variation produced above. My math for calculating the minimum
    number of possibilies (if excluding characters like "(, ), \, =,
    -, etc.." and only allowing for the letters of the alphabet,
    upper and lower case, is: 52^8 That's a lot more than just a
    plain hex version: 16^8.

    Echomail traffic would have to attain avalanche proportions
    before collisions would be a concern. ;)


    I remember something about the MSGID being referred to as a two-
    part string with "origaddr" + "serialno", where "origaddr" is
    intended to be a qualified "address of the originating system".

    No: "... address for the originating network"
    ^^^^^^^


    Ah.. that little word "for" makes a big difference. :

    Then the synchronet version adds some added uniqueness.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sun Apr 11 19:31:13 2021
    -={ 2021-04-11 19:31:13.137413143+00:00 }=-

    Hey August!

    Then the synchronet version adds some added uniqueness.

    I disagree. The address itself is unique without adding any extra proprietary bytes that are totally meaningless to the network at large. Any alterations ought to be to the serial number portion.

    Your suggestion is perfectly valid but to be honest I still believe that a 32-bit hex value for the unixtime or rfc-868 (seconds since 1900) is the best choice for uniqueness over the longest span which is much greater than the 3 year period required by the current standard. Also it adds meaning to it beyond what is capable for a randomly generated serial number. Unfortunetly it has a shelf life that is quickly running out whereas the random one doesn't.

    Life is good,
    Maurice

    ... Wa bið þam þe sceal of langoþe leofes abidan.
    Woe it is for the one who must wait in longing for the beloved.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Sun Apr 11 22:24:27 2021
    Hi August,

    On 2021-04-11 13:53:00, you wrote to me:

    H:\myutils>> rando2
    lfz$bkmcmmg36ye@jll1xpieaats

    Those aren't 32 bit.

    Ah... so the "serialno" part *must" be 8-char? Then rando could
    still work like so:

    You should read the fts document on it! ;)

    "...The serial number may be any eight character hexadecimal number"

    H:\myutils>> rando
    yZn=ZRG-

    there's always a change of a collision within 3 years.

    Yes.. I've suspected that could be problematic.

    It's a very small chance, but it can still happen. I think I have seen a few cases where it happend in the last decades... ;)

    I remember something about the MSGID being referred to as a two-
    part string with "origaddr" + "serialno", where "origaddr" is
    intended to be a qualified "address of the originating system".

    No: "... address for the originating network"
    ^^^^^^^

    Ah.. that little word "for" makes a big difference. :

    Then the synchronet version adds some added uniqueness.

    As Maurice said... ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Sun Apr 11 16:50:00 2021
    Hello Wilfred van Velzen!

    Ah... so the "serialno" part *must" be 8-char? Then rando could
    still work like so:

    You should read the fts document on it! ;)

    "...The serial number may be any eight character hexadecimal number"
    ^^^

    I have! And the little word "may" is merely a suggestion. ;)


    H:\myutils>> rando
    yZn=ZRG-

    An 8-char series where each char can be [a-z]|[A-Z] = 52^8
    possible strings. Add the numbers [0-9] and the possibilities
    climb to 62^8. Throw in some special char options, and the
    number climbs even higher. That approach far surpasses the hex
    choice at 16^8.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sun Apr 11 17:06:00 2021
    Hello Maurice Kinal!

    Your suggestion is perfectly valid but to be honest I still
    believe that a 32-bit hex value for the unixtime or rfc-868
    (seconds since 1900) is the best choice for uniqueness over
    the longest span which is much greater than the 3 year
    period required by the current standard.

    But what if two or more systems process messages at exactly the
    same time of the day? A collision seems far more likely than if
    the respective systems produce random 32 bit strings.

    Also it adds meaning to it beyond what is capable for a
    randomly generated serial number. Unfortunetly it has a
    shelf life that is quickly running out whereas the random
    one doesn't.

    Right. Therefore, I see two +1's for the random [a-z]|[A-Z]|[0-
    9] version, and atleast one -1 for the time-serial version.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sun Apr 11 23:04:06 2021
    -={ 2021-04-11 23:04:06.451242390+00:00 }=-

    Hey August!

    But what if two or more systems process messages at exactly the
    same time of the day?

    It won't matter since two or more systems will have two or more unique addresses. Also points off the same system creating the same id would still be unique given the differing point numbers in the address. Using my node address in comparison for a point system off my node potentially could create MSGIDs as follows;

    MSGID: 1:153/7001.0 01234567
    MSGID: 1:153/7001.1 01234567

    That odds of that happening given the number of fidonet users here are pretty much nil here but why tempt the fates? As for random collisions there isn't any guarentee that either of the above two systems won't create a collision within three years no matter how remote that possibility is whereas the serial number created by the number of seconds since 1970|1900 should NEVER create a collision within it's lifetime, 2106 in my particular case since I am using the 1970 benchmark with an unsigned 32-bit integer. Also this serial number has real meaning that can be extracted by those in the know whereas a random serial number offers nothing in that direction other than uniqueness. Using your scoring system then the serial time generated one scores higher when compared to the random serial number no matter if it is a hex representation or not. Adding more characters doesn't add meaning or additional functionality to it.

    Life is good,
    Maurice

    ... Gif ðu hwæt on druncen misdo, ne wit ðu hit ðam ealoþe.
    If you do something wrong when drunk, don't blame it on the ale.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sun Apr 11 20:56:00 2021
    Hello Maurice!

    It won't matter since two or more systems will have two or more unique addresses..

    MSGID: 1:153/7001.0 01234567
    MSGID: 1:153/7001.1 01234567

    OH! Ok, if dupe-checking takes into consideration the "address"
    part along with the "serialno" part, then uniqueness is pretty
    good as it stands.

    I thought the concern was that some dupe-check implementations
    only use the "serialno" part.

    ..As for random collisions there isn't any guarentee that
    either of the above two systems won't create a collision
    within three years no matter how remote that possibility
    is..

    True. There could very well be a collision created on the same
    system given enough time.

    whereas the serial number created by the number of seconds
    since 1970|1900 should NEVER create a collision within it's
    lifetime, 2106 in my particular case..

    Good point. That guarantees uniqueness. You win.

    ..Adding more characters doesn't add meaning or additional
    functionality to it.

    BUT.. you must agree that the likely hood of two rando numbers
    colliding given that any of the 8 chars in the serialno part can
    be [a-z][A-Z][0-9] at 62^8, is pretty unlikely.

    Even a serial number based on an incremental 8 char string with [a-z][A-Z][0-9] could work too.

    I'm amazed how long the services of TinyURL have relied on 8-
    char uniqueness. As far as I can tell they only use the
    lowercase letters + the numbers:

    https://tinyurl.com/ydpdc3td
    https://tinyurl.com/ydt9y4os

    ..the service as been operating for a l-o-n-g time.


    And, now that we've totally bored the vast number of ASIAN_LINK
    listeners, we should probably move to something less technical.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Mon Apr 12 01:41:38 2021
    -={ 2021-04-12 01:41:38.694142067+00:00 }=-

    Hey August!


    I thought the concern was that some dupe-check implementations
    only use the "serialno" part.

    You could be right about that but I was under the impression that the entire MSGID is used. I say we give it a try using the [:alnum:] regex which I've taken the liberty of doing in this reply. In my case I am using /dev/urandom to generate the random characters in conjunction with tr and the [:alnum:] regex to strip out 8 suitable characters as shown in the MSGID of this reply to you. It certainly doesn't add that much drag but I am going to reserve judgement on that once I try it out on the slowest cpu I have running at the moment. It is busy upgrading itself to the newest gcc-10.3.0 release so it might be awhile before I can give it a proper test. Offhand I think your idea might be best all things considered. I still think my idea is the ultimate but I have serious doubts about getting it adopted any time soon. Definetly something we have time to ponder ... or at least I do. :-)

    And, now that we've totally bored the vast number of ASIAN_LINK
    listeners, we should probably move to something less technical.

    Bah! I say if they are bothered by it then they should speak up instead of just lurking. Besides I think we need to test your idea to see what constitutes
    valid characters in the serial number. Once we get a better handle on what works and what doesn't as far as acceptable characters are concerned we can safely
    drop this subject. Offhand I think this might be a keeper. Also I want to try it on the EuroPoint once I get confirmation about it's validity. Only one way
    to find out.

    Sound like a plan?

    Life is good,
    Maurice

    ... Sprec ofter embe oðres monnes weldæde þonne emb ðine agna.
    Speak more often about other people's good deeds than about your own.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Mon Apr 12 12:05:04 2021
    Hi August,

    On 2021-04-11 16:50:00, you wrote to me:

    H:\myutils>> rando
    yZn=ZRG-

    An 8-char series where each char can be [a-z]|[A-Z] = 52^8
    possible strings. Add the numbers [0-9] and the possibilities
    climb to 62^8. Throw in some special char options, and the
    number climbs even higher. That approach far surpasses the hex
    choice at 16^8.

    Yes, but it's not according to the standard.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Mon Apr 12 12:05:59 2021
    Hi August,

    On 2021-04-11 17:06:00, you wrote to Maurice Kinal:

    Also it adds meaning to it beyond what is capable for a
    randomly generated serial number. Unfortunetly it has a
    shelf life that is quickly running out whereas the random
    one doesn't.

    Right. Therefore, I see two +1's for the random [a-z]|[A-Z]|[0-
    9] version, and atleast one -1 for the time-serial version.

    You forget the -INFINITE for the random [a-z]|[A-Z]|[0-9] version, because it's not according to the standard.


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Mon Apr 12 12:08:17 2021
    Hi August,

    On 2021-04-11 20:56:00, you wrote to Maurice Kinal:

    I thought the concern was that some dupe-check implementations
    only use the "serialno" part.

    If they do that is a bug in the software.

    ..Adding more characters doesn't add meaning or additional
    functionality to it.

    BUT.. you must agree that the likely hood of two rando numbers
    colliding given that any of the 8 chars in the serialno part can
    be [a-z][A-Z][0-9] at 62^8, is pretty unlikely.

    Even a serial number based on an incremental 8 char string with [a-z][A-Z][0-9] could work too.

    My suggestion for anyone who thinks the current MSGID isn't good enough and needs improving, is to not mess with the MSGID itself, because it is a FTSC standard, and systems more or less depend on it to be according to that standard.

    Just create a new kludge, so you can do with it what you want, and you are guaranteed not to cause any problems.
    For instance:

    @UUID: cd882502-9b77-11eb-a8b3-0242ac130003

    It's 128 bit so the collision problem is virtually non existent, and you don't have to bother with the address. And most modern OS's have standard optimized routines to generate a good and secure number like this.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)