Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
| ASIAN_LINK | Not the kind that loves you long time | 8,456 messages |
[ << oldest | < older | list | newer > | newest >> ]
| Message 6,482 of 8,456 |
| mark lewis to Maurice Kinal |
| Name that compression... |
| 30 Mar 19 14:54:00 |
REPLY: 2:280/464.113 5c9f9bf7 MSGID: 1:3634/12.73 5c9fbf47 PID: GED+LNX 1.1.5-b20180707 CHRS: CP437 2 TZUTC: -0400 TID: hpt/lnx 1.9.0-cur 07-09-15 On 2019 Mar 30 16:40:22, you wrote to me: ml>> do not take into account offline mail users MK> True but in that case the incremental methodology you posted could be MK> deployed for robotic packing. this is true and when it really comes down to it, all FTN related messaging tools should use the same serial number generating routines to avoid separate programs generating the same serial number... MK> Now if offline readers generated their own MSGIDs then this wouldn't MK> be an issue. they cannot... maybe QWKE but the readers on the user's end just don't... remember that this QWK/QWKE/BW stuff was porce-pushed into FTNs by folks coming from the RIME/PCRelay side of the world... MK> Either that or get rid of MSGIDs but I already know of one well used MK> messaging system that will freak out and cause much grief. I won't MK> say which one. hehehe... i'd say that one would be better off to develop new formats of packets and packed messages to get rid of these old problems... however, without more developers, it just won't happen... then there's the historic side where folks want to bring their old systems back out of hibernation now that they've had years to play on the 'net and find out it really isn't all that to begin with ;) ml>> or automated posting tools like those used to post monthly rules or ml>> advertisements or even newly arrived files listings... MK> Why wouldn't they be generating their own MSGID? why wouldn't what be doing that? ml>> wrong node number, man MK> Ah! Too late now. hehehe... ml>> you might be surprised ;) MK> Yes I would be. :) ml>> it comes much sooner for systems using signed long integers like ml>> those from the TP/BP5,6,7 days... MK> I am guessing their definition of long ints was 32 bits in pascal back in the day, you had byte, word, real, int and longint... longint was signed 32bit... these days, there are more available and even unsigned ones... word would have worked but it was only two bytes... it there had been a 32bit word, things would have been a little different... they call it a longword, these days... FWIW: From the FPC manual, this is the new stuff available today but you can see the ranges of what has been available since the beginning... integer types Type Range Bytes ========================================================= Byte 0 .. 255 1 Shortint -128 .. 127 1 Smallint -32768 .. 32767 2 Word 0 .. 65535 2 Integer smallint or longint 2 or 4 Cardinal longword 4 Longint -2147483648 .. 2147483647 4 Longword 0..4294967295 4 Int64 -9223372036854775808 .. 9223372036854775807 8 QWord 0 .. 18446744073709551615 8 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 Comp -2E64+1 .. 2E63-1 19-20 8 Currency -922337203685477.5808 922337203685477.5807 8 MK> given the shelf lifes you posted for ntp and unixtime. These days it MK> isn't an issue and if it is then there is another good reason for MK> abandoning abandonware. yep, and the reasons for doing so are getting more nad more prolific, too... MK> If I am not mistaken ntp has made the switch to 64 bit ints quite some MK> time ago. yes but there's still a lot of older embedded systems in place... they'll be found when they fall over and/or start emitting invalid dates... MK> Speaking of which, beats me why they'd need a 64 bit int for MK> fractional seconds. Heck even 32 bit fractional second is overkill MK> other than for nanoseconds which are way beyond the resolution of most MK> computer clocks and network speeds. The best error I've seen posted MK> for clocks was in the order of 30-40 nanoseconds and we're unlikely to MK> ever see such a clock in action. i dunno... i suspect it was for extremely accurate timing capabilities... maybe something to do with nuclear isotope timings?? one would have to check the history to see for sure... )\/(ark Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... Chocolate and |
(c) 1994, bbs@darkrealms.ca