... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@1:153/7001.2989 to Nick Boel on Sat Apr 5 22:07:54 2025
Hey Nick!
Are we missing one here?
Now that you mention it I don't see UTF-8 in /usr/lib/gconv/gconv-modules but it still shows up in 'iconv --list'. So far a search hasn't yielded any information about this other than one that reports missing LATIN1 which isn't an issue with glibc-2.41 from what I see here. UTF-8 does work despite this flaw.
when are we making the jump to UTF-16?
Heh, heh. Ask Bill Gates why that should be avoided.
If you are seriously asking, the reason it should be avoided is that UTF-16, as well as UTF-32, are not compatible with ASCII, whereas the first 128 codes of UTF-8 *are* ASCII and will produce standard text messages as this nonreply is evidence of.
Life is good,
Maurice
o- o- -o -o o- -o -o -o o- -o o- o- -o o- o- -o /) /) (\ (\ /) (\ (\ (\ /) (\ /) /) (\ /) /) (\ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ... Fidonet 4K - You load sixteen penguins and what do you get?
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)
From Nick Boel@1:154/700 to Maurice Kinal on Sat Apr 5 17:53:10 2025
Hey Maurice!
On Sat, Apr 05 2025 12:07:54 -0500, you wrote:
Now that you mention it I don't see UTF-8 in
/usr/lib/gconv/gconv-modules but it still shows up in 'iconv --list'.
So far a search hasn't yielded any information about this other than
one that reports missing LATIN1 which isn't an issue with glibc-2.41
from what I see here. UTF-8 does work despite this flaw.
And it proves that you're still around and kickin'. You've been fairly quiet recently (besides the character set list) so I was checking up on you.
Heh, heh. Ask Bill Gates why that should be avoided.
Does this have to do with 640k being enough memory for anyone?
If you are seriously asking, the reason it should be avoided is that UTF-16, as well as UTF-32, are not compatible with ASCII, whereas the
first 128 codes of UTF-8 *are* ASCII and will produce standard text messages as this nonreply is evidence of.
I definitely wasn't serious, and know exactly why. I just didn't see UTF-8 on the list of character sets you pasted, so figured maybe it was coming time to move on. ;)
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@1:153/7001.2989 to Nick Boel on Sat Apr 5 23:36:50 2025
Hey Nick!
And it proves that you're still around and kickin'.
A little worse for wear but yes I am not dead yet. Still gettting probed and scanned as they still haven't found the cause.
Does this have to do with 640k being enough memory for anyone?
Heh, heh. I think the opposite but am unsure if he had anything to do with it. Seems to me that about 15-ish years ago, maybe more, MS came up with a windows release where UTF-16 was the default, which of course wreaked havoc given the lack of compatibility with standard 7-bit and 8-bit character sets that everyone was using and still are. Since MS adopted UTF-8 instead, I haven't heard anything about that particular fsck-up since.
I definitely wasn't serious
I am not surprised.
it was coming time to move on.
Probably, but I do prefer the layout I posted as opposed to the glibc's gconv-modules or 'iconv --list' and especially IANA's html page of encodings and corresponding aliases. The posting in this echoarea is more along the line of file listings on BBSes which is vastly more humanly readable than anything else I've seen.
HTML definetly sucks. Beats me why anyone in their right mind would subscribe to that format over plain text output, including (espcially?) UTF-8. :::sigh:::
Life is good,
Maurice
o- o- o- -o -o -o o- -o -o -o o- o- -o -o o- o- /) /) /) (\ (\ (\ /) (\ (\ (\ /) /) (\ (\ /) /) ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ... Fidonet 4K - You load sixteen penguins and what do you get?
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: One of us @ (1:153/7001.2989)
From Nick Boel@1:154/700 to Maurice Kinal on Sun Apr 6 01:30:24 2025
Hey Maurice!
On Sat, Apr 05 2025 13:36:50 -0500, you wrote:
A little worse for wear but yes I am not dead yet. Still gettting
probed and scanned as they still haven't found the cause.
What are they probing and scanning for?
Heh, heh. I think the opposite but am unsure if he had anything to
do with it. Seems to me that about 15-ish years ago, maybe more, MS
came up with a windows release where UTF-16 was the default, which of course wreaked havoc given the lack of compatibility with standard
7-bit and 8-bit character sets that everyone was using and still are. Since MS adopted UTF-8 instead, I haven't heard anything about that particular fsck-up since.
It seems 15 years ago was around the time of WinXP and Win7. I've even recently installed both of those in a virtual machine to check out some old BBS software, and I don't remember anything odd in regards to charsets. As far as I can remember, the command prompt has always used CP437, but there was a time I didn't use Windows at all (nothing in between Win 3.11 for Workgroups and Win2kPro, and then I never used ME or Vista, either).
A quick look at Wikipedia states that Windows has been using UTF-16 since Windows 2000, and didn't support UTF-8 in it's API until 2019. If that is the case, it was a thing for a lot longer than we thought..
I definitely wasn't serious
I am not surprised.
Does my new tagline sway your decision on that? ;)
Probably, but I do prefer the layout I posted as opposed to the
glibc's gconv-modules or 'iconv --list' and especially IANA's html
page of encodings and corresponding aliases. The posting in this
echoarea is more along the line of file listings on BBSes which is
vastly more humanly readable than anything else I've seen.
When is the last time you actually listed files on a BBS? If it's been awhile, you can check the address in my origin line. However, I'd recommend CP437 capabilities in some capacity. I can use a UTF-8 enabled Putty client with proper settings to telnet and it displays pretty good (CP437 and UTF-8), though.
HTML definetly sucks. Beats me why anyone in their right mind would subscribe to that format over plain text output, including
(espcially?) UTF-8. :::sigh:::
The incessant need for fancy emojis, maybe?
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@1:153/7001 to Nick Boel on Sun Apr 6 07:46:12 2025
Hey Nick!
What are they probing and scanning for?
It's varied over the last year from internal bleeding to potential cancerous polyps. The latest scan (ultrasound) showed a polyp on my gall bladder which will need to be checked out. So far anything they've found has proved to be benign or cauterized in the case of internal bleeding. No real fix yet and I have to get blood transfusions far too often. :-(
A quick look at Wikipedia states that Windows has been using UTF-16
since Windows 2000, and didn't support UTF-8 in it's API until 2019.
Whoa! Seems to me that they were recommending UTF-8 adoption further back than 2019. Not having anything to do with MS products I can only account for what I've heard through the grapevine over the years.
Does my new tagline sway your decision on that?
Somewhat but I believe my decision is/was based on any dealings we've had over the years.
When is the last time you actually listed files on a BBS?
Somewhere around 1995-ish.
I can use a UTF-8 enabled Putty client with proper settings to
telnet and it displays pretty good (CP437 and UTF-8), though.
I started using tmux to take care of display issues that I used to use setserial for. DOS-think based ansi art and the such now works much better but I haven't tried setting the terminal's character set to cp437 yet and logging onto a regular BBS with it ... yet. I'll try yours later once I have a tmux terminal set to a proper DOS-think configuration.
The incessant need for fancy emojis, maybe?
That sounds about right.
Life is good,
Maurice
o- -o -o o-
/) (\ (\ /)
^^ ^^ ^^ ^^
... Gemyne mærþo, mægenellen cyð, waca wið wraþum.
Think of glory, show great courage, keep watch against the foe.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
From Nick Boel@1:154/700 to Maurice Kinal on Sun Apr 6 04:27:02 2025
Hey Maurice!
On Fri, Apr 06 1900 20:46:12 -0600, you wrote:
It's varied over the last year from internal bleeding to potential cancerous polyps. The latest scan (ultrasound) showed a polyp on my
gall bladder which will need to be checked out. So far anything
they've found has proved to be benign or cauterized in the case of
internal bleeding. No real fix yet and I have to get blood
transfusions far too often. :-(
Are the transfusions for blood loss, or that it's not getting filtered properly? I take it they've already looked at your liver and kidneys?
Whoa! Seems to me that they were recommending UTF-8 adoption further
back than 2019. Not having anything to do with MS products I can
only account for what I've heard through the grapevine over the
years.
Seems as though it has always been UTF-16 after UCS 2, although since WinXP they introduced code page 65001, which was designated for UTF-8.. so maybe that's about the time the issues started to decrease. It wasn't until 2019 that MS started recommending programmers use UTF-8, and only now in Windows 11 some system files are required to use UTF-8 and do not require a Byte Order Mark. Seems as though they had slapped in a workaround back in 2005-ish, and hadn't really done anything about it for some 14 years, or so.
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Nick Boel@1:154/700 to Maurice Kinal on Sun Apr 6 04:29:56 2025
Hey Maurice!
Date: Fri, 6 Apr 1900 02:46:12 +0000
Woah there buddy! When did you build the time machine?! ;)
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@1:153/7001 to Nick Boel on Sun Apr 6 10:44:30 2025
Hey Nick!
Woah there buddy! When did you build the time machine?! ;)
It looks fine from this angle - 06 Apr 25 05:44:30.
Life is good,
Maurice
o- -o o- o-
/) (\ /) /)
^^ ^^ ^^ ^^
... Betere byþ oft feðre þonne oferfeðre.
Better to be often loaded than overloaded.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
From August Abolins@2:221/1.58 to Nick Boel on Sun Apr 6 10:47:00 2025
Hello Nick Boel!
** On Saturday 05.04.25 - 23:29, Nick Boel wrote to Maurice Kinal:
Hey Maurice!
Date: Fri, 6 Apr 1900 02:46:12 +0000
Woah there buddy! When did you build the time machine?! ;)
Is that for this one?
MID: 1:153/7001 67f1eaf4
EDA: 20250406024600W+0
That one looks just fine here.
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From Nick Boel@1:154/700 to Maurice Kinal on Sun Apr 6 11:58:14 2025
Hey Maurice!
On Sun, Apr 06 2025 00:44:30 -0500, you wrote:
It looks fine from this angle - 06 Apr 25 05:44:30.
That would be the datetime stamp for this message. I believe I quoted the previous message you wrote. Either way, that message is stored here with a year of 1900, as you could see in my reply header when I originally replied to that message. Then I quoted the header specifically in my second message.
Looks like whatever it was has fixed itself after that message. Must have been a glitch on my end, as August has reported that it looks fine on his end, also.
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Nick Boel@1:154/700 to August Abolins on Sun Apr 6 12:16:24 2025
Hey August!
On Sun, Apr 06 2025 04:47:00 -0500, you wrote:
Is that for this one?
MID: 1:153/7001 67f1eaf4
EDA: 20250406024600W+0
That one looks just fine here.
It was, yes. But if it looks fine there and it looks fine before it left Maurice's system, then it had to be something on my end. That was the only messages I noticed, so I'll just chalk it up as a hiccup and move on as long as it doesn't happen again.
Thanks for the confirmation.
By the way (and veering way off here), I just tried OpenXP again this past week. I first installed on Windows, and for the life of me I couldn't get it to display anything in UTF-8. I tried setting the Windows command prompt to CP 65001, etc. So I became a little irritated (moreso with Windows), and installed it on one of my Linux VMs where I know UTF-8 works properly. Still no dice for most situations..
Come to find out the UTF-8 that /does/ work, has to do with MIME decoding only. Dovenet's 'Tech Talk' area pulls directly from the TLDR website which includes html and MIME encoded text that OpenXP handles very nicely. Not only does it remove html tags, it decodes MIME and displays everything in readable text even with the UTF-8 glyphs that come with it. Unfortunately, that's where UTF-8 stops, though..
I found that extremely odd, that so much work was put into that (MIME decoding and preserving UTF-8), but a simple message with UTF-8 characters can't be displayed properly. Eh well, maybe some day. Definitely on the right track, though! ;)
Other than that, once you get used to where everything is and how it all works.. it's actually pretty cool. Mind you, I didn't mess with any of the Fido stuff, I only used NNTP with it, since it was the easiest way to test without creating a new link or point and messing with my other configurations.
Is this a project you're at all involved with? Or are you just their super-user/beta-tester, or just a fan?
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From August Abolins@2:221/1.58 to Nick Boel on Sun Apr 6 16:35:00 2025
Hello Nick!
** On Sunday 06.04.25 - 07:16, Nick Boel wrote to me:
By the way (and veering way off here), I just tried OpenXP
again this past week. I first installed on Windows, and
for the life of me I couldn't get it to display anything
in UTF-8. I tried setting the Windows command prompt to CP
65001, etc. So I became a little irritated (moreso with
Windows), and installed it on one of my Linux VMs where I
know UTF-8 works properly. Still no dice for most
situations..
I don't there is UTF-8 support on the incoming. OpenXP is a
terminal/console program afterall.
Come to find out the UTF-8 that /does/ work, has to do
with MIME decoding only. Dovenet's 'Tech Talk' area pulls
directly from the TLDR website which includes html and
MIME encoded text that OpenXP handles very nicely.
I just tried the dove-tech-talk echo, and the TLDR material
with OpenXP looks messy with unresolved conversions. So, not
sure what you consider is "handles very nicely".
Not only does it remove html tags, it decodes MIME and
displays everything in readable text even with the UTF-8
glyphs that come with it. Unfortunately, that's where UTF-
8 stops, though..
Oh.. so yes.. the plaintext is what OpenXP does well.
I found that extremely odd, that so much work was put into
that (MIME decoding and preserving UTF-8), but a simple
message with UTF-8 characters can't be displayed properly.
Eh well, maybe some day. Definitely on the right track,
though! ;)
I doubt that OpenXP can ever support UTF-8 like in gui-type
windows. The limitation is the charset/font support in Windows
DOS terminal. I currently use Lucinda TT console. It has
limits to what foreign chars it supports. German, French,
Italian, Spanish chars are supported.
Other than that, once you get used to where everything is
and how it all works.. it's actually pretty cool. Mind
you, I didn't mess with any of the Fido stuff, I only used
NNTP with it, since it was the easiest way to test without
creating a new link or point and messing with my other
configurations.
AFIK, OpenXP maintains UTF-8 chars on the outbound in NNTP-type
areas. Not sure if it renders as expected on the inbound.
Is this a project you're at all involved with?
Not exactly. I'm primarily a user, sold on the great
performance and features of the system.
Or are you just their super-user/beta-tester,
I *did* kinda kickstart a push to have some problems corrected.
...or just a fan?
See above! :D
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From August Abolins@2:221/1.58 to Nick Boel on Sun Apr 6 16:57:00 2025
Hello Nick!
Come to find out the UTF-8 that /does/ work, has to do
with MIME decoding only. Dovenet's 'Tech Talk' area pulls
directly from the TLDR website which includes html and
MIME encoded text that OpenXP handles very nicely. Not
only does it remove html tags, it decodes MIME and
displays everything in readable text even with the UTF-8
glyphs that come with it. Unfortunately, that's where UTF-
8 stops, though..
A follow-up. I pulled in Endoftheline's NNTP version of
dovenet-techtalk and the content *does* indeed look MUCH
cleaner than the Fidonet version!
F-PID: Synchronet 3.20e-Linux master/3622e0ce8 Mar 04 2025 GCC 12.2.0
F-CHRS: UTF-8 4
^^^^^^^
+1
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From Nick Boel@1:154/700 to August Abolins on Sun Apr 6 16:37:04 2025
Hey August!
On Sun, Apr 06 2025 10:35:00 -0500, you wrote:
I don't there is UTF-8 support on the incoming. OpenXP is a terminal/console program afterall.
I'm currently using slrn (a linux console newsreader) that displays UTF-8 just fine, just as well as most other console based Linux applications I use here, so I don't think this is really an excuse/reason. Maybe moreso for Windows, though.
I just tried the dove-tech-talk echo, and the TLDR material
with OpenXP looks messy with unresolved conversions. So, not
sure what you consider is "handles very nicely".
Either something on your end must not be configured correctly for this. You have to enable UTF-8 and there might have even been some mime decoding options in the only place OpenXP has these settings (I don't remember exactly). You'll see what I mean when you have it configured right. Or, it could be Windows specific where it doesn't work as well.
It's also possible I set this up more precisely on Linux, and maybe didn't get this far in regards to setup on Windows.. after realizing the Windows command prompt doesn't work anything like a Linux console in regards to UTF-8. After fiddling with Windows' code page 65001 for about 30 minutes, I gave up on it and downloaded/installed it on Linux to see if I could get further.
Oh.. so yes.. the plaintext is what OpenXP does well.
I'd have to agree with you there. At least the ascii part of it. I don't even think I spent much time checking on CP437 as I probably assumed it just worked, but I'm guessing that works OK?
I doubt that OpenXP can ever support UTF-8 like in gui-type
windows. The limitation is the charset/font support in Windows
DOS terminal. I currently use Lucinda TT console. It has
limits to what foreign chars it supports. German, French,
Italian, Spanish chars are supported.
Sure it can. At least on Linux. Windows console may need a bit more work, but that's way above my pay grade.
You could try using 'chcp 65001' to change to whatever MS considers it's UTF-8 console support.
AFIK, OpenXP maintains UTF-8 chars on the outbound in NNTP-type
areas. Not sure if it renders as expected on the inbound.
I didn't try sending anything off, however on display it was all question marks. I questioned it even more when I got Dovenet's Tech Talk area to display properly (minus html and also mime decoded - as good as my console newsreaders handle it) with UTF-8 characters and glyphs.
I *did* kinda kickstart a push to have some problems corrected.
There may be one left to push! :)
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Nick Boel@1:154/700 to August Abolins on Sun Apr 6 16:41:32 2025
Hey August!
On Sun, Apr 06 2025 10:57:00 -0500, you wrote:
A follow-up. I pulled in Endoftheline's NNTP version of
dovenet-techtalk and the content *does* indeed look MUCH
cleaner than the Fidonet version!
Who is gating that echo to Fidonet? And is it coming across as UTF-8 or something else?
Also, I'm sure you noticed the UTF-8 glyphs in the content that is properly displayed?
F-PID: Synchronet 3.20e-Linux master/3622e0ce8 Mar 04 2025 GCC 12.2.0
I believe this was addressed in 3.20 at some point, also. So if you were originally pulling it from someone who hasn't upgraded to a version that supports handling UTF-8 and mime decoding, then that could be the reason also.
F-CHRS: UTF-8 4
^^^^^^^
+1
Yessir! But what baffles me, is that UTF-8 is unsupported literally everywhere else in OpenXP.
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@2:280/464.113 to Nick Boel on Sun Apr 6 21:46:41 2025
Hej Nick!
I believe I quoted the previous message you wrote.
Understood. I've checked all the packed MSGs originating from the node and they show up with the correctly formatted ftn datetime stamp.
Must have been a glitch on my end
Offhand it looks that way, especially considering it shows the correct datetime on this machine as well as the node where the original was created.
Speaking for myself, I believe the FTN datetime stamp should get the heave-ho. The obsolete 2 digit year has always created problems even before y2k.
Het leven is goed,
Maurice
-o o- -o -o
(\ /) (\ (\
^^ ^^ ^^ ^^
... Sorh cymeð manig ond mislic in manna dream.
Sorrow comes in many and various ways amid the joys of men.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)
From Maurice Kinal@1:153/7001 to Nick Boel on Mon Apr 7 03:16:24 2025
Hey Nick!
Are the transfusions for blood loss, or that it's not getting
filtered properly?
That depends on who you talk to. I am guessing that it is a filtering problem but the powers that be have been focussing on blood loss saving the worst for last.
I take it they've already looked at your liver and kidneys?
For sure. They all show up as 'good to go', including lungs and heart, which seems odd to me but I am not complaining. However it would be good to know what the actual problem is and that there is a fix for it. Blood loss from bleeding should be fixable but a blood disorder might not be.
Anyhow that is my story and I am sticking to it ... for now.
some system files are required to use UTF-8 and do not require a
Byte Order Mark.
UTF-8 doesn't require a BOM since it is exactly the same for both little and big endian systems thanks to what I call the masterbyte (leading byte). The same isn't true for UTF-16 and UTF-32.
Seems as though they had slapped in a workaround back in 2005-ish
That is probably when they discovered that everything they knew was wrong. :::evil grin:::
Life is good,
Maurice
o- o- o- o-
/) /) /) /)
^^ ^^ ^^ ^^
... Ðonne se heretoga wacað þonne bið eall se here swiðe gehindred.
When the general weakens, the whole army is greatly hindered.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
From August Abolins@2:221/1.58 to Nick Boel on Mon Apr 7 01:10:00 2025
Hello Nick!
A follow-up. I pulled in Endoftheline's NNTP version of
dovenet-techtalk and the content *does* indeed look MUCH
cleaner than the Fidonet version!
Who is gating that echo to Fidonet? And is it coming
across as UTF-8 or something else?
My bad. I meant FTN-stye, not Fidonet per se.
Endoftheline is 723:320/1
F-CHRS: UTF-8 4
^^^^^^^
+1
Yessir! But what baffles me, is that UTF-8 is unsupported
literally everywhere else in OpenXP.
Yeah.. dunno why UTF-8 can't be part of the FTN subsystem of
OpenXP. Sofar, it's stickly supported with NNTP type
connections.
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From August Abolins@2:221/1.58 to Maurice Kinal on Mon Apr 7 14:58:00 2025
Hello Maurice!
Speaking for myself, I believe the FTN datetime stamp
should get the heave-ho. The obsolete 2 digit year has
always created problems even before y2k.
But if there was a change, wouldn't that "break" many existing
FTN progs that are nolonger supported and cannot be upgraded?
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From Maurice Kinal@1:153/7001 to August Abolins on Tue Apr 8 00:11:43 2025
Hey August!
But if there was a change, wouldn't that "break" many existing
FTN progs that are nolonger supported and cannot be upgraded?
Yes it would. Is that a problem?
Life is good,
Maurice
-o -o -o o-
(\ (\ (\ /)
^^ ^^ ^^ ^^
... Forst sceal freosan, fyr wudu meltan, eorþe growan, is brycgian.
Frost must freeze, fire melt wood, earth grow, ice form bridges.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
From Aug@2:460/256 to Maurice Kinal on Tue Apr 8 03:46:15 2025
Hi Maurice...
Hey August!
But if there was a change, wouldn't that "break" many existing
FTN progs that are nolonger supported and cannot be upgraded?
Yes it would. Is that a problem?
Life is good,
Maurice
-o -o -o o-
(\ (\ (\ /)
^^ ^^ ^^ ^^
... Forst sceal freosan, fyr wudu meltan, eor├╛e growan, is brycgian.
Frost must freeze, fire melt wood, earth grow, ice form bridges.
How do propose fidonet would survive or develop a sufficient following to be worthwhile?
--- Want fido for iOS/MacOS/Android/Win/Linux? https://shrtco.de/tpJ9yV
* Origin: Fido by Telegram BBS from Stas Mishchenkov (2:460/256)
From Maurice Kinal@2:280/464.113 to Aug on Tue Apr 8 01:46:29 2025
Hej Aug!
How do propose fidonet would survive or develop a sufficient
following to be worthwhile?
I think a better question would be to ask how fidonet will survive depending on obsolete software that more than likely won't run on modern systems.
The current track record indicates we have little to nothing to lose.
Het leven is goed,
Maurice
o- -o o- -o
/) (\ /) (\
^^ ^^ ^^ ^^
... Wineleas wonsælig mon genimeð him wulfas to geferan.
A friendless, unfortunate man takes wolves as his companions.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)
From August Abolins@2:221/1.58 to Maurice Kinal on Mon Apr 7 23:36:00 2025
Hello Maurice!
How do propose fidonet would survive or develop a
sufficient following to be worthwhile?
I think a better question would be to ask how fidonet will
survive depending on obsolete software that more than
likely won't run on modern systems.
I think most sysops are quite fine with running VM's with the
older OSes that they need, or NTVDM or that other one called
NT64XVDM or something.
The current track record indicates we have little to
nothing to lose.
There isn't much of a rising public demand for BBSes and
echomail systems, but I doubt that an "updated" FTN design will
make a difference.
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From Maurice Kinal@2:280/464.113 to August Abolins on Tue Apr 8 04:16:05 2025
Hej August!
I doubt that an "updated" FTN design will make a difference.
It will make a difference but not necessarily in the direction hoped for. On the flip side, maintaining the current mode of operation won't make a difference.
Het leven is goed,
Maurice
-o -o o- o-
(\ (\ /) /)
^^ ^^ ^^ ^^
... Leana forleosaþ, se þe hit lyþran deð.
He who gives to an unworthy person wastes his gifts.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)
From Nick Boel@1:154/700 to August Abolins on Mon Apr 7 23:32:36 2025
Hey August!
On Sun, Apr 06 2025 19:10:00 -0500, you wrote:
My bad. I meant FTN-stye, not Fidonet per se. Endoftheline is
723:320/1
Honestly, the transfer method shouldn't matter much. EOTL is running Synchronet, so I would imagine he's getting his Dovenet feed via QWKnet, and then sending it out to you via FTN. There are some settings in between that decide whether or not that message stays UTF-8, though.
Yeah.. dunno why UTF-8 can't be part of the FTN subsystem of OpenXP. Sofar, it's stickly supported with NNTP type connections.
No sir. It's not NNTP connections at all. All UTF-8 characters display as question marks, and all I used was NNTP. UTF-8 seems to *only* be supported in messages that contain MIME encoding, and I bet those same messages would display the same via NNTP or FTN, as long as the message is unaltered.
I remember the config setting for "Enable UTF-8" in OpenXP was in a wierd place. Doesn't it have MIME related settings in the same box/area? Either way, it definitely didn't seem like a universal, application-wide setting (to me) just by where it was located.
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From August Abolins@2:221/1.58 to Nick Boel on Tue Apr 8 00:42:00 2025
Hello Nick!
Yeah.. dunno why UTF-8 can't be part of the FTN subsystem of OpenXP.
Sofar, it's stickly supported with NNTP type connections.
No sir. It's not NNTP connections at all. All UTF-8
characters display as question marks, and all I used was
NNTP. UTF-8 seems to *only* be supported in messages that
contain MIME encoding, and I bet those same messages would
display the same via NNTP or FTN, as long as the message
is unaltered.
Well.. OpenXP seems to handle some UTF-8 fine from the UTF8
echo. But glyphs? ..forget it.
I remember the config setting for "Enable UTF-8" in OpenXP
was in a wierd place. Doesn't it have MIME related
settings in the same box/area? Either way, it definitely
didn't seem like a universal, application-wide setting (to
me) just by where it was located.
┌─ Internal message reader options ────────────┐
│ │
│ [x] Full screen │
│ [x] Display clock │
│ [x] Line break in column 80 │
│ [x] Show reference arrows │
│ [x] Fixed message header display │
│ │
│ [ ] Convert German ISO Umlauts │
│ [x] Use UTF-8 │
│ [x] *Highlight* words by colour │
│ [x] Multi-coloured quotes │
│ │
│ [ ] Mouse scroll bar │
│ [x] AutoScrolling │
│ │
│ [ ] Exit message reader with <Return> │
│ │
│ Viewer for URLs H:\ProgramFiles\Palemoon\► │ └──────────────────────────────────────────────┘
--
../|ug
--- OpenXP 5.0.64
* Origin: (2:221/1.58)
From Nick Boel@1:154/700 to Maurice Kinal on Mon Apr 7 23:41:51 2025
Hey Maurice!
On Sun, Apr 06 2025 17:16:24 -0500, you wrote:
That depends on who you talk to. I am guessing that it is a
filtering problem but the powers that be have been focussing on blood
loss saving the worst for last.
But they can't find any blood loss, either.. except that you need transfusions every so often?
For sure. They all show up as 'good to go', including lungs and
heart, which seems odd to me but I am not complaining. However it
would be good to know what the actual problem is and that there is a
fix for it. Blood loss from bleeding should be fixable but a blood disorder might not be.
Anyhow that is my story and I am sticking to it ... for now.
Hopefully they're not just scamming your insurance. Haven't you been doing this for the past 6 months or more now?
Seems as though they had slapped in a workaround back in 2005-ish
That is probably when they discovered that everything they knew was
wrong. :::evil grin:::
Probably not. They still to this day keep making bad decisions. ;)
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Nick Boel@1:154/700 to August Abolins on Tue Apr 8 00:07:55 2025
Hey August!
On Mon, Apr 07 2025 18:42:00 -0500, you wrote:
Well.. OpenXP seems to handle some UTF-8 fine from the UTF8
echo. But glyphs? ..forget it.
I don't remember seeing any, in a regular message with UTF-8 text, to be honest.
I only saw it on MIME encoded messages.
[ ] Convert German ISO Umlauts
[x] Use UTF-8
[x] *Highlight* words by colour
[x] Multi-coloured quotes
And that is the only spot, correct? I thought there was some MIME related stuff close to that setting, but I guess I was wrong.
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@1:153/7001 to Nick Boel on Tue Apr 8 05:03:04 2025
Hey Nick!
you need transfusions every so often?
On average, once a month for the past year - Apr 15, 2024 was the first transfusion - except the latest two which were only two weeks apart.
Hopefully they're not just scamming your insurance.
This is Canada. We have universal health care. If it wasn't for that, I'd be long dead already.
I am hoping that whatever the cause, it is reversable or fixable. Internal bleeding is fixable, whereas some blood disorder might not be. To be honest I'd just as soon know which.
That is probably when they discovered that everything they knew was
wrong. :::evil grin:::
Probably not. They still to this day keep making bad decisions. ;)
That is not a good sign.
Life is good,
Maurice
-o -o o- o-
(\ (\ /) /)
^^ ^^ ^^ ^^
... Mon sceal... gebidan þæs he gebædan ne mæg.
One must wait for what cannot be hastened.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
From Nick Boel@1:154/700 to Maurice Kinal on Tue Apr 8 23:45:54 2025
Hey Maurice!
On Mon, Apr 07 2025 19:03:04 -0500, you wrote:
On average, once a month for the past year - Apr 15, 2024 was the
first transfusion - except the latest two which were only two weeks
apart.
So you're losing blood at a speed where this is necessary this often? And you don't see any of it? That's creepy.
I am hoping that whatever the cause, it is reversable or fixable.
Internal bleeding is fixable, whereas some blood disorder might not
be. To be honest I'd just as soon know which.
Definitely. It's worse not knowing what is going on, than actually knowing and possibly being able to do something about it.
Regards,
Nick
... Sarcasm: because beating people up is illegal.
--- SBBSecho 3.24-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
From Maurice Kinal@1:153/7001 to Nick Boel on Wed Apr 9 05:44:29 2025
Hey Nick!
And you don't see any of it? That's creepy.
For the mostpart I see it but was hoping we could skip over the gory details. Not creepy but definetly gross. I already think I've said far too much as it is.
It's worse not knowing what is going on, than actually knowing and
possibly being able to do something about it.
Agreed, even if there isn't anything I can do about fixing it.
Speaking of fixing, playing around with the bash loadable "strftime" has produced some interesting prospects.
It matches with the MSG's datetime stamp. Also I checked and made sure that unixtime (1744159469 seconds) isn't limited to 32-bit time_t. Given the output it looks like they are using a 64-bit float which has a shelf life of over 2 billion years from the unix epoch shown below in the obsoleted two digit year format;
Note that normally the year 10000 would lengthen the string by an extra character, in the case of ftn_datetime it will remain constrained to 19 characters, not counting the \0 (null) that terminates that string.
Having said that I still think the two digit year needs to be turfed.
Life is good,
Maurice
-o -o -o o-
(\ (\ (\ /)
^^ ^^ ^^ ^^
... Se cræft þæs lareowdomes bið cræft ealra cræfta.
The art of teaching is the art of all arts.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
From Maurice Kinal@2:280/464.113 to Maurice Kinal on Wed Apr 9 06:45:05 2025
Hej Maurice!
You forgot to include;
$ strftime --help
strftime: strftime format [seconds]
Display formatted time.
Converts date and time format to a string and displays it on the
standard output. If the optional second argument is supplied, it
is used as the number of seconds since the epoch to use in the
conversion, otherwise the current time is used.
Het leven is goed,
Maurice
o- o- -o -o
/) /) (\ (\
^^ ^^ ^^ ^^
... Wa þære þeode þe hæfð ælðeodigne cyng.
Woe will come to the nation which has a foreign king.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint @ (2:280/464.113)
Who's Online
Recent Visitors
Zengarden
Wed Feb 11 17:39:27 2026
from
Bowling Green, Ky
via
Telnet
Ilop
Sat Jan 31 03:58:07 2026
from
Canada
via
Telnet
A L L E O N
Fri Jan 16 23:33:08 2026
from
Loveland, Colorado
via
Telnet
Mr Chats
Sat Dec 27 20:46:15 2025
from
Florence, Alabama
via
Telnet