-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
This message has been _forwarded_! The original message was: <
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
Area: *POINTS*
From: *Adam Wysocki(2:480/138)*
To: *Andy Ball*
Subject: *Unix point?*
Sent: *27.01.07* *22:36:34*
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
@CHRS: FIDOMAZ 2Hej Andy!
How difficult is it to set up a point on a system that runs NetBSD or Linux? I have a DSL connection to the Internet, but could probably arrange dial-up access if that's preferable. I'm in zone 1, region
11, so I should probably find a boss node that's somewhere in r11.
End of forwarded message <
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
any idea what the charset below is supposed to mean? Pure garbage?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=
-< This message has been _forwarded_! The original message was:
<
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-<
Area: *POINTS*
From: *Adam Wysocki(2:480/138)*
To: *Andy Ball*
Subject: *Unix point?*
Sent: *27.01.07* *22:36:34*
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-<
@REA:POINTS
@MSGID: 2:480/138@FidoNet 45bbc62c
@CHRS: FIDOMAZ 2
How difficult is it to set up a point on a system that runs NetBSD or Linux?
@ENCODING: UTF-8
@ENCODING: UTF-8
Whats that?
Hey Tim!
@ENCODING: UTF-8
Whats that?
On this point it corresponds to the 1179 IANA endorsed encodings and proper aliases. I wanted something more powerful at my disposal in order to support CP866 and the like.
"CHRS: UTF-8 2"
Thank God the CHRS kludge never made it to a standard and nobody
uses it ....
🖀 🕹️
Hey Oli!
"CHRS: UTF-8 2"
Thank God the CHRS kludge never made it to a standard and nobody uses it
....
Are you being sarcastic? Also you're getting it wrong just like every other DOS-think braindead editor.
🖀 🕹️
U+1F580 = joystick
U+1F579 = telephone over modem
I am guessing it is meant to symbolize online gaming.
Life is good,
Maurice
... Wel bið þam eorle þe him on innan hafað... rume heortan.
Well shall it be for the man who has within him a generous heart.
--- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
There is no advantage in your proposal
Hey Tim!
There is no advantage in your proposalWhat proposal?
All those redundant Kludges you use instead of the standard ones
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).
he could/should use the existing control lines in addition to
the one's he testing
and may eventually propose...
@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?
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.
i have to wonder about the TZ control line having seconds in it
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?
+2 + +2 = +4
really??
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...
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.
+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.
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.
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.
so none of the Type 3 or Type 10 formats?
until you convert it to a number for the necessary math when
needed ;)
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...
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.
Besides why tackle a new idea
if we can't get the even the simplest things right such as telling the difference between a number and a string.
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,
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.
not all proposals are accepted or if accepted, stick around...
somewhere inside it, there is a conversion from string to
numerics and back to string again
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...
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.
somewhere inside it, there is a conversion from string to numerics
and back to string again
No doubt.
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.
Dropping the '+' character ist vorboten.
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.
i'm done because it isn't worth it
... 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 :)
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...
... 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...
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...
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.
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.
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,040 |
Nodes: | 15 (0 / 15) |
Uptime: | 212:34:52 |
Calls: | 500,251 |
Calls today: | 20 |
Files: | 95,199 |
D/L today: |
5,678 files (978M bytes) |
Messages: | 464,238 |
Posted today: | 1 |