Nyfb, V xabj va gur by' qnlf jr hfrq EBG13 gb zrff jvgu a00of (zlfrys vapyhqrq)... vf vg fgvyy fhccbegrq?
Guvf Hfrarg Ernqre unf vg nf n srngher - naq jnf phevbhf nalbar ryfr
unir vg gbb?
Great to know... in your JAM implementation, what theory(s) did you implement for MSG_COMPRESS and MSG_ENCRYPT?
In your implementation, what are you using for the MSGID 1:3634/12.73 5c9e81b1 <-- 5c9e81b1?
i didn't write GoldED and i haven't dug into the C code to try
to find out...
Just looking at it I get the impression that it is the 32 bit hex value
for unixtime. Take a look at the following for confirmation;
TZ=EST5EDT date --date=@$(printf "%d" 0x5c9ec143) +"%d %b %y %T" =
29 Mar 19 21:07:15
which is very close to the obsoleted msgHeader's datetime stamp in your
reply = 29 Mar 19 21:04:38.
it would make sense on the server to use timestamp
two nodes post during the same second
Anyone know what the name of the ASCII compression algorithm that is based upon 6bit ASCII and most frequently used characters?
etaonirshdl
I have working code in my old Tosser but not sure what this is called, and if it was NNTP only or if Fido supported it also?
Also, I know in the ol' days we used ROT13 to mess with n00bs (myself included)... is it still supported?
This Usenet Reader has it as a feature - and was curious anyone else have it too?
Nalbar xabj jung gur anzr bs gur NFPVV pbzcerffvba nytbevguz gung vf onfrq hcba 6ovg NFPVV naq zbfg serdhragyl hfrq punenpgref?
Also a sysop could give each user on a node a point address so that
MSGID uniquiness would be guarenteed ... at least up to Sun Feb 7
06:28:15 UTC 2106, for unsigned 32 bit unixtimes which from my
observations seems to be the case in Fidonet, not counting abandonware
of course. Your mileage may vary.
Anyone know what the name of the ASCII compression algorithm that is
based upon 6bit ASCII and most frequently used characters?
This point concept totally fixes that
it would make sense on the server to use timestamp - and a piece of
logic to make sure no two nodes post during the same second.
Quoting Paul Edwards to Mikael St†ldal <=-
There is no requirement for there to be a MSGID kludge, and can you honestly say that you have NEVER been at risk of violating the MSGID standard, ie there was no possibility that you ever generated two
MSGID's the same within any 3 year period? I certainly can't.
it would make sense on the server to use timestamp
Agreed. There is very little chance that the sysop would be creating
two messages at the same time which is the danger on a multiuser
system such as a busy BB S.
two nodes post during the same second
That won't matter since the node number is part of the MSGID.
Thus even if the 32 bit hex number is exactly the same the nodes'
MSGID will still be unique.
It is only if a multisuer node with only one address is this a danger
and probably not much of a danger these days.
Also a sysop could give each user on a node a point address
so that MSGID uniquiness would be guarenteed ... at least up to Sun
Feb 7 06:28:15 UTC 2106, for unsigned 32 bit unixtimes which from my observations seems to be the case in Fidonet, not counting abandonware
of course. Your mileage may vary.
Anyone know what the name of the ASCII compression algorithm that is based upon 6bit ASCII and most frequently used characters?
do not take into account offline mail users
or automated posting tools like those used to post monthly rules
or advertisements or even newly arrived files listings...
wrong node number, man
you might be surprised ;)
it comes much sooner for systems using signed long integers like
those from the TP/BP5,6,7 days...
do not take into account offline mail users
True but in that case the incremental methodology you posted could be deployed for robotic packing.
Now if offline readers generated their own MSGIDs then this wouldn't
be an issue.
Either that or get rid of MSGIDs but I already know of one well used messaging system that will freak out and cause much grief. I won't
say which one.
or automated posting tools like those used to post monthly rules or
advertisements or even newly arrived files listings...
Why wouldn't they be generating their own MSGID?
wrong node number, man
Ah! Too late now.
you might be surprised ;)
Yes I would be.
it comes much sooner for systems using signed long integers like
those from the TP/BP5,6,7 days...
I am guessing their definition of long ints was 32 bits
given the shelf lifes you posted for ntp and unixtime. These days it isn't an issue and if it is then there is another good reason for abandoning abandonware.
If I am not mistaken ntp has made the switch to 64 bit ints quite some time ago.
Speaking of which, beats me why they'd need a 64 bit int for
fractional seconds. Heck even 32 bit fractional second is overkill
other than for nanoseconds which are way beyond the resolution of most computer clocks and network speeds. The best error I've seen posted
for clocks was in the order of 30-40 nanoseconds and we're unlikely to ever see such a clock in action.
to avoid separate programs generating the same serial number...
maybe QWKE but the readers on the user's end just don't
in pascal back in the day, you had byte, word, real, int and
longint
there's still a lot of older embedded systems in place
i suspect it was for extremely accurate timing capabilities
(*) Clarity - "Turbo Pascal", not "Pascal".
Same problem C guys have when picking up some of the old code
"int" 16bit or 32bit?
Hi Ozz!
28 Mar 2019 13:37, from Ozz Nixon -> Ozz Nixon:
ON> Anyone know what the name of the ASCII compression algorithm that is
ON> based upon 6bit ASCII and most frequently used characters?
No.
What use would it be?
On 2019 Mar 28 13:34:42, you wrote to All:
ON> Anyone know what the name of the ASCII compression algorithm that
is based
ON> upon 6bit ASCII and most frequently used characters?
are you thinking of uuencode or xxencode?
integer types
Type Range Bytes
=========================================================
Longint -2147483648 .. 2147483647 4
Longword 0..4294967295 4
Free Pascal does automatic type conversion in expressions where
different kinds of integer types are used.
real types
Type Range Significant digits Bytes
=========================================================
Real platform dependent ??? 4 or 8
Single 1.5E-45 .. 3.4E38 7-8 4
Double 5.0E-324 .. 1.7E308 15-16 8
Extended 1.9E-4932 .. 1.1E4932 19-20 10
I am uncertain as to when "back in the day" was. However when I first learned F77 way back when, an int was 32 bits, whether signed or
unsigned. What Pascal is calling an int would be called a short (16
bits) and they could also be signed or unsigned.
date command uses a 64 bit floating point for unixtime which has a shelf life to Wed Dec 31 23:59:59 UTC 2147485547 all things being equal ... which is highly unlikely over two billion years.
Yeah, I will have to remember to login and check my software the
next morning to see if I broke or not :-)
Yeah, I will have to remember to login and check my software the
next morning to see if I broke or not :-)
Judging by the message I am replying to I am guessing there may be an issue.
Not an issue but when he's working, he tends to incognito a bit
Sysop: | Ruben Figueroa |
---|---|
Location: | Mesquite, Tx |
Users: | 3 |
Nodes: | 4 (0 / 4) |
Uptime: | 95:24:27 |
Calls: | 79 |
Files: | 53 |
Messages: | 73,847 |