• oxp locks up, again

    From Martin Foster@2:310/31.3 to mark lewis on Sun Jan 26 09:52:00 2020
    Hello mark!

    * 19.01.20 at 07:57, mark lewis wrote to Martin Foster:

    i have a question that may be helpful to you guys...

    instead of faffing about with nodediffs, can you simply replace the nodelist with a daily nodelist and the tool will automatically see the nodelist is different and recompile its indexes?

    Thanks for the suggestion but that method won't work with OpenXP.

    Regards,
    Martin

    --- OpenXP 5.0.42
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From mark lewis@1:3634/12 to Martin Foster on Sun Jan 26 08:21:05 2020
    Re: oxp locks up, again
    By: Martin Foster to mark lewis on Sun Jan 26 2020 09:52:00


    i have a question that may be helpful to you guys...

    instead of faffing about with nodediffs, can you simply replace the nodelist
    with a daily nodelist and the tool will automatically see the nodelist is
    different and recompile its indexes?

    Thanks for the suggestion but that method won't work with OpenXP.

    that's kinda sad... especially in this day in time ;)


    )\/(ark
    --- SBBSecho 3.10-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From August Abolins@2:221/1.58 to mark lewis on Sun Jan 26 18:33:00 2020
    instead of faffing about with nodediffs, can you simply replace the ml>nodelist with a daily nodelist and the tool will automatically see the ml>nodelist is different and recompile its indexes?

    Hi marc,

    I would guess that oxp doesn't know how to handle diffs if more than one arrived at a time.

    The weekly process is fairly doable. There are enough days inbetween to
    catch up and just get "one" and then just process that one.

    Just guessing.

    --- OpenXP 5.0.42
    * Origin: (2:221/1.58)
  • From Martin Foster@2:310/31.3 to August Abolins on Sat Feb 1 09:28:00 2020
    Hello August!

    * 26.01.20 at 18:33, August Abolins wrote to mark lewis:

    instead of faffing about with nodediffs, can you simply replace the
    nodelist with a daily nodelist and the tool will automatically see the
    nodelist is different and recompile its indexes?

    Hi marc,

    I would guess that oxp doesn't know how to handle diffs if more than one arrived at a time.

    Guessed wrong buddy :-)

    OpenXP can apply as many contiguous diffs as you like, so long as
    there aren't any missing in the sequence.

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:221/360 to Martin Foster on Sat Feb 1 18:22:13 2020
    On 01/02/2020 4:28 a.m., Martin Foster : August Abolins wrote:

    instead of faffing about with nodediffs, can you simply
    replace the nodelist with a daily nodelist and the tool will
    automatically see the nodelist is different and recompile its
    indexes?

    Hi marc,

    I would guess that oxp doesn't know how to handle diffs if more
    than one arrived at a time.

    Guessed wrong buddy

    OpenXP can apply as many contiguous diffs as you like, so long
    as there aren't any missing in the sequence.


    But then why did you tell marc that oxp couldn't handle daily diffs in
    this message:

    Date: Sun, 26 Jan 2020 09:52:00 +0000
    X-JAM-MSGID: 2:310/31.3@fidonet e0ca7838



    --
    Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

    --- TB68/Win7 (just keeping things short!)
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From mark lewis@1:3634/12 to August Abolins on Sat Feb 1 15:22:58 2020
    Re: oxp locks up, again
    By: August Abolins to Martin Foster on Sat Feb 01 2020 18:22:13


    But then why did you tell marc that oxp couldn't handle daily diffs
    in this message:

    NOTE: i was specifically trying to steer away from diffs... they really are not
    necessary in this day in time and one can easily get a full nodelist every day
    that is as up to date as possible with current processing...


    )\/(ark
    --- SBBSecho 3.10-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From August Abolins@2:221/360 to mark lewis on Sat Feb 1 23:17:33 2020
    On 01/02/2020 3:22 p.m., mark lewis : August Abolins wrote:

    NOTE: i was specifically trying to steer away from diffs... they
    really are not necessary in this day in time and one can easily
    get a full nodelist every day that is as up to date as possible
    with current processing...

    Hi mark!

    My bad. I erroneously referred to your "daily" solution as diffs.

    I rather like the idea of just implementing a daily full nodelist. But
    it is rather cool to witness a program to chug away and construct an
    update locally from the diffs. ;)

    Sadly (or maybe to the benefit of oxp), in my case, I have uncovered
    something that should be fixed.

    From a user POV, a daily updated nodelist is probably overkill. A "full
    daily" makes sense for a sysop who relies heavily on contacting other
    systems every day. As an ex-sysop I like the notion of a nearly
    real-time updated nodelist. But I would imagine that users (for which something like oxp was designed for) may not be online every day, and/or
    don't really need to contact other systems very much.

    As for oxp actually processing a full daily updated list automatically,
    I don't understand why that can't be so. Is oxp hardcoded to expect the
    full nodelist to be exactly 7 days from a previous one before it
    overrides the old one? If so, THEN a full daily wouldn't work, I guess.


    --
    Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

    --- TB68/Win7 (just keeping things short!)
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Martin Foster@2:310/31.3 to August Abolins on Fri Feb 7 13:05:00 2020
    Hello August!

    * 01.02.20 at 18:22, August Abolins wrote to Martin Foster:

    instead of faffing about with nodediffs, can you simply
    replace the nodelist with a daily nodelist and the tool will
    automatically see the nodelist is different and recompile its
    indexes?

    Hi marc,

    I would guess that oxp doesn't know how to handle diffs if more
    than one arrived at a time.

    Guessed wrong buddy

    OpenXP can apply as many contiguous diffs as you like, so long
    as there aren't any missing in the sequence.

    But then why did you tell marc that oxp couldn't handle daily diffs in this message:

    Date: Sun, 26 Jan 2020 09:52:00 +0000
    X-JAM-MSGID: 2:310/31.3@fidonet e0ca7838

    I didn't actually say that.

    Marc was suggesting the use of daily *nodelists*, which OpenXP can't
    handle *automatically*. It can, however, handle them if the user is
    prepared to install each one every day which, of course, would be a
    real PITA.

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:221/1.58 to Martin Foster on Fri Feb 7 23:10:00 2020
    Hello Martin!

    ** 07.02.20 - 13:05, Martin Foster wrote to August Abolins:

    Marc was suggesting the use of daily *nodelists*, which OpenXP can't
    handle *automatically*. It can, however, handle them if the user is
    prepared to install each one every day which, of course, would be a
    real PITA.

    Doh! My bad. I see now in the Config that the automated updates setting only applies to "diffs". Full nodelists, when received, are NOT automatically updated.

    +- Fido Options ---------------------------------+
    Ý Ý
    Ý Int. dial prefix 00 Ý
    Ý Nat. dial prefix 0 Ý
    Ý Your dialing code 49-631 Ý
    Ý Ý
    Ý [x] Import nodelist updates automatically Ý <--- for DIFFs only?
    Ý [ ] Delete empty messages Ý
    Ý [x] Automatic TIC file processing Ý
    Ý [x] Hold requests if files are missing Ý
    Ý Ý
    Ý [ ] Delete hidden kludges Ý
    Ý [x] Use TZUTC kludge Ý


    Maybe that line could be:

    Ý [x] Import nodelist DIFFs automatically Ý


    ..someday? <BG>




    ../|ug

    --- OpenXP 5.0.43
    * Origin: /|ug's EuroPoint (2:221/1.58)
  • From Martin Foster@2:310/31.3 to August Abolins on Sat Feb 8 13:03:00 2020
    Hello August!

    *** 07.02.20 at 23:10, August Abolins wrote to Martin Foster:

    [snip]
    +- Fido Options ---------------------------------+
    Ý Ý
    Ý Int. dial prefix 00 Ý
    Ý Nat. dial prefix 0 Ý
    Ý Your dialing code 49-631 Ý
    Ý Ý
    Ý [x] Import nodelist updates automatically Ý <--- for DIFFs only?
    Ý [ ] Delete empty messages Ý
    Ý [x] Automatic TIC file processing Ý
    Ý [x] Hold requests if files are missing Ý
    Ý Ý
    Ý [ ] Delete hidden kludges Ý
    Ý [x] Use TZUTC kludge Ý

    Maybe that line could be:

    Ý [x] Import nodelist DIFFs automatically Ý

    ..someday? <BG>

    Yeah maybe but the help topic does mention diffs :-)

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Martin Foster@2:310/31.3 to August Abolins on Sun Feb 9 11:36:00 2020
    Hello August!

    *** 19.01.20 at 11:44, August Abolins wrote to Martin Foster:

    [snip]
    Which leads me to the security/bug/weakeness.

    If the FILES directory is used for the arriving nodelists, and it is the same directory for other arriving files such as attachments from other people, then anyone could arbitrarily send me a nodelist, and its
    presence can screw up oxp (just like the presence of the old nodelist/diffs that I still had in there did).

    It wasn't the presence of the old nodlists/diffs that was causing the
    problem :)

    However, if OpenXP sees a nodelist in the FILES directory, it ignores it
    just as it ignores most other files in the FILES directory. The only files
    it takes action on are nodediffs/pointdiffs and if any of them are out of sequence, it just ignores them.

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:221/1.58 to Martin Foster on Mon Feb 10 22:48:00 2020
    Hello Martin!

    ** 09.02.20 - 11:36, Martin Foster wrote to August Abolins:

    Which leads me to the security/bug/weakeness.

    ..then anyone could arbitrarily send me a nodelist, and its
    presence can screw up oxp (just like the presence of the old
    nodelist/diffs that I still had in there did).

    It wasn't the presence of the old nodlists/diffs that was causing the
    problem :)

    Correct. The main problem was having a Z1 nodelist and using a Z2 diff
    update file. But the only way I managed to clear the lock up was to
    delete the latent nodelist/nodediff files I still had in the incoming
    /FILES directory.


    ..The only files it takes action on are nodediffs/pointdiffs and if
    any of them are out of sequence, it just ignores them.

    It was still taking action on the NODEDIFF that was in /FILES, even though
    I had cleared out the nodelist config tables. The /FIDO directory was
    empty!

    The following settings marked "<==THIS" were probably enabled:

    +- Configure Node/Pointlist ------------------------+
    | |
    | List name NODELIST.### Number 038 |
    | |
    | Format of list Nodelist ? |
    | Zone/Address |
    | |
    | Update file NODEDIFF.### |
    | Update archive NODEDIFF.Z## |
    | |
    | Process by |
    | |
    | [x] Use internal nodelist processor |<==THIS
    | [x] Delete update after processing |

    +- Fido Options ---------------------------------+
    Ý Ý
    Ý Int. dial prefix 00 Ý
    Ý Nat. dial prefix 0 Ý
    Ý Your dialing code 49-631 Ý
    Ý Ý
    Ý [x] Import nodelist updates automatically Ý<==THIS
    Ý [ ] Delete empty messages Ý
    Ý [x] Automatic TIC file processing Ý<==THIS?


    Is it the presence of a .TIC file in /FILES that can trigger the "action" too?

    Maybe I am worried over nothing since OXP probably takes a more secure process (ie acting on files only received from my Boss system via the TIC information) before it acts on just anything that looks like a diff file
    in the /FILES directory.


    ../|ug

    --- OpenXP 5.0.43
    * Origin: ....................... (2:221/1.58)
  • From August Abolins@2:221/1.58 to mark lewis on Mon Feb 10 23:31:00 2020
    Hello mark!

    ** 26.01.20 - 08:21, mark lewis wrote to Martin Foster:

    instead of faffing about with nodediffs, can you simply replace the
    nodelist with a daily nodelist and the tool will automatically see
    the nodelist is different and recompile its indexes?

    Thanks for the suggestion but that method won't work with OpenXP.

    that's kinda sad... especially in this day in time ;)


    I've just learned that OXP is designed to process the diffs automatically, but not a fresh incoming full nodelist. So, in theory, I would imagine
    that it could work if the daily nodelist had a matching daily diff.

    I guess that importing/compiling the full nodelist manually was a concious design decision. But, we'll never know the original reason at this time.

    Further to what is "sad... especially in this day", there are probably far more examples of FTN programs that are not going to get any improvements
    or fixes at all, yet they are accomodated without incident, for now.

    Y2K-broken programs have probably left the FTN scene gracefully.

    And unless we all move to 64-bit OS/programs, will many 32-bit programs
    that rely on dates (like this OXP) expire on March 19 2038 03:14:07 UTC?


    ../|ug

    --- OpenXP 5.0.43
    * Origin: ....................... (2:221/1.58)
  • From Alan Ianson@1:153/757 to August Abolins on Tue Feb 11 05:16:08 2020
    Hello August,

    I've just learned that OXP is designed to process the diffs
    automatically, but not a fresh incoming full nodelist. So, in
    theory, I would imagine that it could work if the daily nodelist had
    a matching daily diff.

    When I first joined Fidonet in 1995 those diff's were essential. The compressed
    nodelists were 1.5MB and I really didn't want to transfer that on the 2400 baud modem I had at the time.. :)

    I don't process diff's anymore although I have software to do it if I needed to.

    Can OXP not skip processing the diff and just compile a new nodelist?

    I guess that importing/compiling the full nodelist manually was a
    concious design decision. But, we'll never know the original reason
    at this time.

    It was a different time and place. I blew my nodelist away a couple of times back then and had no choice but to go searching for a full nodelist somewhere and hope I had enough online time to grab a new one.

    It was not an easy thing to find just anywhere and my BBS was offline while I got that done. Well, not offline but busy.. :)

    Further to what is "sad... especially in this day", there are probably
    far more examples of FTN programs that are not going to get any improvements or fixes at all, yet they are accomodated without
    incident, for now.

    As long as those old programs work properly we are OK. Squish is one example of
    an old software that is still in use today at some nodes.

    Y2K-broken programs have probably left the FTN scene gracefully.

    I hope so.. but we do have pktdate should the need arise.. :)

    And unless we all move to 64-bit OS/programs, will many 32-bit
    programs that rely on dates (like this OXP) expire on March 19 2038 03:14:07 UTC?

    I don't think they'll expire but the dates they display might be wonky. I think
    the OpenXP developers are still developing, or at least maintaining OXP so I think OXP users will be OK. I'm not so sure about some other software.

    There were 2020 problems in Mystic that were quickly fixed. These sorts of niggles can show up unexpectedly.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From August Abolins@2:221/360 to Alan Ianson on Tue Feb 11 19:50:21 2020
    On 11/02/2020 8:16 a.m., Alan Ianson : August Abolins wrote:

    According to the TZUTC, you wrote that just after 5am! You certainly
    start your day very early. I have a couple of house-broken cats that
    wake me up between 3a and 5a to be let out, each at their own time! But
    I promptly settle back to sleep.


    When I first joined Fidonet in 1995 those diff's were essential.
    The compressed nodelists were 1.5MB and I really didn't want to
    transfer that on the 2400 baud modem I had at the time..

    I used a 2400 baud that came with my computer only briefly. But, by the
    time I joined Fidonet with my own bbs I had a 14.4 kbit/s internal
    modem. The increase in speed seemed amazing at the time.

    I really enjoyed utilizing simultaneous upload/download. Was that with Ymodem/G...? I don't quite remember. It was cool to "chat" with
    another sysop during the upload/download session too.

    1.5MB seems rather large for a text-based nodelist. Were you relying on
    one of the non-zip archives? But the math seems right:

    Today, approx 1000 nodes = 50K
    Peak, approx 40000 nodes = 2000K or 2meg


    Can OXP not skip processing the diff and just compile a new
    nodelist?

    Processing the diff is actually preferred.

    As I wrote in my original message, OXP does not seem to be designed to
    offer automatic full nodelist detection upon arrival. But that's ok.
    The diff processing works and is pretty magical - now that I've learned
    that there are different versions of the "same" nodelist and nodediffs depending on the Zone you pull them from. I had no idea.


    Y2K-broken programs have probably left the FTN scene gracefully.

    I hope so.. but we do have pktdate should the need arise..

    That reminds me, I recently discovered a date problem when I used
    Tommi's BBS (ie logged in manually) to send a netmail few weeks ago. His Concord BBS software produced a future date of 2056. LOL

    Date: Sat, 19 Feb 2056 21:45:16 GMT
    Message-ID: <5473$netmail@JamNNTPd>
    References: <5470$netmail@JamNNTPd>
    X-JAM-From: August Abolins <2:221/360>
    X-JAM-To: Martin Foster <2:310/31.3>
    X-JAM-MSGID: 2:221/360 1ced0c7d
    X-JAM-REPLYID: 2:310/31.3 f99352d3
    X-JAM-PID: Concord 0.01 Beta-30d OS/2 ser#cc38c58d


    I should drop by and see if he had a chance to hack netmails with pktdate.


    ..will many 32-bit
    programs that rely on dates (like this OXP) expire on March 19
    2038 03:14:07 UTC?

    I don't think they'll expire but the dates they display might be
    wonky.

    It's really fun to hack a fix and witness the magic. But it's more fun
    when things run right the first time.


    I think the OpenXP developers are still developing, or at
    least maintaining OXP so I think OXP users will be OK. I'm not so
    sure about some other software.

    I never really thought that I would warm up to OXP, it being a dos/texty interface requiring mostly keyboard action. But its message search capabilities are very good, among other things.


    There were 2020 problems in Mystic that were quickly fixed. These
    sorts of niggles can show up unexpectedly.

    Lots of fun to be had!


    --
    Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

    --- TB68.4.1/Win7 (the abbr. string!)
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Tommi Koivula@2:221/360.1 to August Abolins on Tue Feb 11 22:18:20 2020
    Hi August.

    11 Feb 20 19:50:20, you wrote to Alan Ianson:

    Y2K-broken programs have probably left the FTN scene gracefully.

    I hope so.. but we do have pktdate should the need arise..

    That reminds me, I recently discovered a date problem when I used
    Tommi's BBS (ie logged in manually) to send a netmail few weeks ago. His Concord BBS software produced a future date of 2056. LOL

    Date: Sat, 19 Feb 2056 21:45:16 GMT
    Message-ID: <5473$netmail@JamNNTPd>
    References: <5470$netmail@JamNNTPd>
    X-JAM-From: August Abolins <2:221/360>
    X-JAM-To: Martin Foster <2:310/31.3>
    X-JAM-MSGID: 2:221/360 1ced0c7d
    X-JAM-REPLYID: 2:310/31.3 f99352d3
    X-JAM-PID: Concord 0.01 Beta-30d OS/2 ser#cc38c58d

    I should drop by and see if he had a chance to hack netmails with
    pktdate.

    No, not yet. The problem is still there. Pktdate is able to fix every outbound message but it is not in operation yet.

    Or I can shut down the bbs. :)

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/360.1)
  • From Alan Ianson@1:153/757 to August Abolins on Wed Feb 12 15:59:00 2020
    Hello August,

    According to the TZUTC, you wrote that just after 5am!

    I don't like to leave things to the last minute!

    When I first joined Fidonet in 1995 those diff's were essential.
    The compressed nodelists were 1.5MB and I really didn't want to
    transfer that on the 2400 baud modem I had at the time..

    I used a 2400 baud that came with my computer only briefly. But, by
    the time I joined Fidonet with my own bbs I had a 14.4 kbit/s internal modem. The increase in speed seemed amazing at the time.

    When I joined Fidonet I was a little behind everyone else but it didn't take long and I upgraded to 14.4 and then 28.8. 28.8 seemed like freedom then. :)

    I really enjoyed utilizing simultaneous upload/download. Was that with Ymodem/G...? I don't quite remember. It was cool to "chat" with
    another sysop during the upload/download session too.

    I think that is Hydra that has bi-directional transfers and chat.

    1.5MB seems rather large for a text-based nodelist. Were you relying
    on one of the non-zip archives? But the math seems right:

    That was the compressed nodelist, ARC format then.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Martin Foster@2:310/31.3 to August Abolins on Thu Feb 13 11:02:00 2020
    Hello August!

    *** 10.02.20 at 22:48, August Abolins wrote to Martin Foster:

    [snip]
    ..The only files it takes action on are nodediffs/pointdiffs and if
    any of them are out of sequence, it just ignores them.

    It was still taking action on the NODEDIFF that was in /FILES,

    Yes, that's what I said but .....

    even though I had cleared out the nodelist config tables. The /FIDO directory was empty!

    ..... I forgot to mention that the nodelist routines still run regardless
    of whether there's anything in the /FILES directory that they need to process.

    The following settings marked "<==THIS" were probably enabled:

    [snip]
    | [x] Use internal nodelist processor |<==THIS

    That's fine.

    [snip]
    Ý [x] Import nodelist updates automatically Ý<==THIS

    As is this.

    Ý [ ] Delete empty messages Ý
    Ý [x] Automatic TIC file processing Ý<==THIS?


    Is it the presence of a .TIC file in /FILES that can trigger the "action" too?

    That has nothing to do with the nodelist routines, see the help topic for
    a full explanation of what this feature is/does :)

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Martin Foster@2:310/31.3 to Alan Ianson on Thu Feb 13 11:13:00 2020
    Hello Alan!

    *** 11.02.20 at 05:16, Alan Ianson wrote to August Abolins:

    [snip]
    Can OXP not skip processing the diff and just compile a new nodelist?

    Unfortunately not.

    I don't think they'll expire but the dates they display might be
    wonky. I think the OpenXP developers are still developing, or at
    least maintaining OXP so I think OXP users will be OK. I'm not so
    sure about some other software.

    OpenXP is definitely still being developed/maintained.

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:333/808.7 to Martin Foster on Thu Feb 13 18:50:00 2020
    Hello Martin!

    13 Feb 20 11:02, you wrote to me:


    Is it the presence of a .TIC file in /FILES that can trigger the
    "action" too?

    That has nothing to do with the nodelist routines, see the help topic
    for a full explanation of what this feature is/does :)

    You are a tough teacher. As you can see, I am in Italy at this time! ;) I'll
    back in Finland in about 6 hours.


    August


    --- GoldED+/W32-MINGW 1.1.5-b20170303
    * Origin: ----> Point Of VeleNo BBs (http://www.velenobbs.net) (2:333/808.7)
  • From Tommi Koivula@2:221/360.1 to August Abolins on Thu Feb 13 19:11:02 2020
    Hi August.

    13 Feb 20 18:50:00, you wrote to Martin Foster:

    As you can see, I am in Italy at this time!
    ;) I'll back in Finland in about 6 hours.

    There is only one hour gap in time, why does it take so long? :D

    'Tommi

    ---
    * Origin: Point One, Le Gros-Theil, France (2:221/360.1)
  • From Alan Ianson@1:153/757.2 to Martin Foster on Thu Feb 13 11:05:20 2020
    Can OXP not skip processing the diff and just compile a new nodelist?

    Unfortunately not.

    Hmm.. might be a good feature suggestion.. :)

    I don't think they'll expire but the dates they display might be
    wonky. I think the OpenXP developers are still developing, or at
    least maintaining OXP so I think OXP users will be OK. I'm not so
    sure about some other software.

    OpenXP is definitely still being developed/maintained.

    That's good to hear. I notice I am a version behind in what I have on the BBS for OXP downloads. Is there a file echo for OXP or other point software?

    --- BBBS/Li6 v4.10 Toy-4
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Martin Foster@2:310/31.3 to Alan Ianson on Fri Feb 14 10:59:00 2020
    Hello Alan!

    *** 13.02.20 at 11:05, Alan Ianson wrote to Martin Foster:

    Can OXP not skip processing the diff and just compile a new nodelist?

    Unfortunately not.

    Hmm.. might be a good feature suggestion.. :)

    I'll think about that one.

    I don't think they'll expire but the dates they display might be
    wonky. I think the OpenXP developers are still developing, or at
    least maintaining OXP so I think OXP users will be OK. I'm not so
    sure about some other software.

    OpenXP is definitely still being developed/maintained.

    That's good to hear. I notice I am a version behind in what I have on the BBS for OXP downloads.

    Thanks very much for making them available for d/load, much appreciated.

    The current release version is 5.0.42, whereas 5.0.43 is a development version.

    Here's a full list of the 5.0.42 releases .....

    28/12/2019 10:59 8,073,696 openxp-5.0.42.src.tar.gz
    28/12/2019 10:59 8,266,509 openxp-5.0.42.src.zip
    28/12/2019 11:16 2,158,240 openxp-5.0.42-1.i586.rpm
    28/12/2019 11:16 2,777,186 openxp-5.0.42-1.i586-lnx.zip
    28/12/2019 10:59 2,285,404 openxp-5.0.42-1.x86_64.rpm
    28/12/2019 10:59 3,009,424 openxp-5.0.42-1.x86_64-lnx.zip
    28/12/2019 09:58 3,239,026 OpenXP5.0.42-win.zip

    If you don't have them all, please feel free to grab them from my puny
    little space on the Web: https://openxp.uk

    Is there a file echo for OXP or other point software?

    Nope.

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:221/360 to Alan Ianson on Fri Feb 14 20:19:16 2020
    On 13/02/2020 2:05 p.m., Alan Ianson : Martin Foster wrote:


    ...I notice I am a version behind in what I
    have on the BBS for OXP downloads. Is there a file echo for OXP
    or other point software?

    In addition to Martin's list, there is a collection also at the
    Sourceforge site.

    But look for "OpenXP 5", not "OpenXP".

    The latter depository is much older.



    --
    Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc

    --- TB68.4.1/Win7 (the abbr. string!)
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Martin Foster@2:310/31.3 to August Abolins on Sat Feb 15 10:42:00 2020
    Hello August!

    *** 14.02.20 at 20:19, August Abolins wrote to Alan Ianson:

    ...I notice I am a version behind in what I
    have on the BBS for OXP downloads. Is there a file echo for OXP
    or other point software?

    In addition to Martin's list, there is a collection also at the Sourceforge site.

    https://sourceforge.net/projects/openxp5/
    This is the official OpenXP5 site which, in addition to all the release packages, is the official code repository. The source code can be either downloaded or checked out via 'svn'.

    But look for "OpenXP 5", not "OpenXP".

    Yes, that's a very good point you make, thanks.

    The latter depository is much older.

    It's also inactive and has been for many many years and, IIRC, all that
    stuff was put on there purely for archival/historical purposes.

    Regards,
    Martin

    --- OpenXP 5.0.43
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)