• 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)