Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    MAKENL_NG    |    MakeNL Next Generation.    |    1,725 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 572 of 1,725    |
|    mark lewis to Marc Lewis    |
|    follow-up on: NCs who've updated to Make    |
|    22 Jan 13 14:16:11    |
       MarcL> Important to note here - it's NOT the file date that MakeNL is         MarcL> looking at, it's the julian extension which it apparently         MarcL> calculates on the fly based on the system date/time as to which         MarcL> extensions are acceptable.               ml> ahh! that makes a difference, then... my configs do not use julian        ml> dated extensions... i know about them and could use them but for        ml> security reasons, do not... this also prevents the creation of        ml> netseg diffs but that's never been a problem...               MarcL> The julian date extension is the default for ALL diffs and lists.               right... i thought i had noted that i use full filenames, including       extensions, and that's why i apparently haven't seen this in my testing...               MarcL> It, I don't think, would not show up anywhere in your normal         MarcL> config file - it's how the segments are normally transmitted         MarcL> after whichever program has produced them. E.g., Net9000.018 or        MarcL> Net9000.242. It's the intended distribution date; that's what        MarcL> MakeNL is looking at in the Master directory and calculating the        MarcL> file's relative age from that extension.              unless you use a specific extension (that your upstream *C knows about and       configures for)... of course, that also means that historic files are not       available as each new rendition of the specific filename would have to       overwrite previous the one when it is hatched out to others in the region or       net if one does that for those in their coverage area...              i had thought that it was looking at the file's date(s) instead of the       extension... i can see where the extension in the julian day serialized       methodology is ok but we also know that there can be problems... but the same       is true with looking at the dates, as well...              i can also understand the software automatically saving the last one, two or       three submittal files as noted in the history file and documentation but i       have to wonder if something like that is better left up to the operator to       do... back in the day, there weren't as many tools available as there are       today but then again, having the software manage it is also easier and puts       the onus on the coder(s) to get it right ;)              )\/(ark              ---         * Origin: (1:3634/12.42)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca