• zone 4 ping

    From Fernando Toledo@4:902/26 to FidoCoord.ZCC-PUBLIC on Sun Feb 18 01:43:00 2024
    alo?!!?

    Is anyone from z4 receiving this?

    I'm routing via 2:241/66
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Ward Dossche@2:292/854 to Fernando Toledo on Sun Feb 18 13:06:57 2024
    alo?!!?

    In the water too ...

    Is anyone from z4 receiving this?

    From my viewpoint, these are the systems receiving this echo. There's a tad of Z4 in it ...

    80/1 90/1 103/705 124/5016 153/757 154/30 203/0 221/0 1 6
    240/1120 5832 280/464 5003 5555 292/789 854 8125 301/1 310/31
    335/364 341/66 200 234 396/45 423/120 460/58 463/68 467/888
    633/280 712/848 770/1 902/26 5020/400

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Fernando Toledo on Mon Feb 19 00:17:04 2024
    Adding ...

    Is anyone from z4 receiving this?

    There's also substantial khrap in the ZONE4-segment, for example ...

    ;A Region 90: http://www.momiabbs.com.ar (Spanish)

    I think there is no "http://www.momiabbs.com.ar" at all.

    Plus ...

    ;S Zone Mail Hour
    ;S --------------
    ;S
    ;S Zone 5 mail hour (01:00 - 02:00 UTC)
    ;S Zone 2 mail hour (02:30 - 03:30 UTC)
    ;S Zone 4 mail hour (08:00 - 09:00 UTC)
    ;S Zone 1 mail hour (09:00 - 10:00 UTC)
    ;S Zone 3 mail hour (17:00 - 18:00 UTC)
    ;S Zone 6 mail hour (20:00 - 21:00 UTC)

    * Zone-5 was removed 12 years ago from the nodelist
    * Zone-6 was removed 17 years ago from the nodelist

    I stopped being bothered by it because it seems impossible to get anything changed/corrected in Z4 for decades.

    Don't the sysops have a sense of pride or achievement to get things done properly?

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Dan Clough@1:135/115 to Ward Dossche on Sun Feb 18 20:38:00 2024
    Ward Dossche wrote to Fernando Toledo <=-

    There's also substantial khrap in the ZONE4-segment, for example
    ...

    ;A Region 90: http://www.momiabbs.com.ar (Spanish)

    I think there is no "http://www.momiabbs.com.ar" at all.

    Plus ...

    ;S Zone Mail Hour
    ;S --------------
    ;S
    ;S Zone 5 mail hour (01:00 - 02:00 UTC)
    ;S Zone 2 mail hour (02:30 - 03:30 UTC)
    ;S Zone 4 mail hour (08:00 - 09:00 UTC)
    ;S Zone 1 mail hour (09:00 - 10:00 UTC)
    ;S Zone 3 mail hour (17:00 - 18:00 UTC)
    ;S Zone 6 mail hour (20:00 - 21:00 UTC)

    * Zone-5 was removed 12 years ago from the nodelist
    * Zone-6 was removed 17 years ago from the nodelist

    I stopped being bothered by it because it seems impossible to get
    anything changed/corrected in Z4 for decades.

    Don't the sysops have a sense of pride or achievement to get
    things done properly?

    Apparently they don't.

    I suggest you start by firing the asshole, and put somebody in there
    that wants to actually do the job.

    Things *can* be cleaned up.



    ... Pros are those who do their jobs well, even when they don't feel like it. === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Fernando Toledo@4:902/26 to Dan Clough on Mon Feb 19 01:06:33 2024
    El 18/2/24 a las 23:38, Dan Clough escribió:

    WD> Don't the sysops have a sense of pride or achievement to get
    WD> things done properly?

    Apparently they don't.

    I suggest you start by firing the asshole, and put somebody in there
    that wants to actually do the job.

    Things *can* be cleaned up.

    I am going to investigate how to apply as a ZC

    thanks!
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Nigel Reed@1:124/5016 to All on Sun Feb 18 22:32:26 2024
    On Mon, 19 Feb 2024 01:06:33 -0300
    "Fernando Toledo" (4:902/26) <Fernando.Toledo@f26.n902.z4.fidonet>
    wrote:
    El 18/2/24 a las 23:38, Dan Clough escribió:

    WD> Don't the sysops have a sense of pride or achievement to get
    WD> things done properly?

    Apparently they don't.

    I suggest you start by firing the asshole, and put somebody in there
    that wants to actually do the job.

    Things *can* be cleaned up.

    I am going to investigate how to apply as a ZC

    thanks!
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
    You touch it, you own it. Congratulations ;)
    --
    End Of The Line BBS - Plano, TX
    telnet endofthelinebbs.com 23
    --- SBBSecho 3.20-Linux
    * Origin: End Of The Line BBS - endofthelinebbs.com (1:124/5016)
  • From Ward Dossche@2:292/854 to Dan Clough on Mon Feb 19 10:34:53 2024
    Dan,

    I suggest you start by firing the asshole, and put somebody in there
    that wants to actually do the job.

    Somebody with a distinct law degree and a beautiful little daughter is not exactly an asshole.

    The zones are autonomous in selecting their ZC ... P4 is clear about that. The IC cannot do anything about it ...

    Alas.

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Fernando Toledo on Mon Feb 19 10:40:56 2024
    Fernando,

    I am going to investigate how to apply as a ZC

    The job needs to be vacant, then you need an election by the RCs.

    Basically the current ZC has to un-elect himself. Talk to Manuel, I think he is pretty decent and open to the idea ... with only 3 RCs in the region it could be managed quick ... well, that is if John Dovey in Panama is still breathing.

    \%/@rd◄

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Wilfred van Velzen@2:280/464 to Ward Dossche on Mon Feb 19 11:03:49 2024
    Hi Ward,

    On 2024-02-19 10:40:56, you wrote to Fernando Toledo:

    I am going to investigate how to apply as a ZC

    The job needs to be vacant, then you need an election by the RCs.

    Basically the current ZC has to un-elect himself. Talk to Manuel, I think he is pretty decent and open to the idea ... with only 3 RCs in the region it could be managed quick ... well, that is if John Dovey in Panama is still breathing.

    I just did a full binkp test of Z4. The results are bad:

    Nodelist for Monday, February 19, 2024 -- Day number 050 parsed, 29 IP-nodes processed (0.009 sec)
    4:4/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:80/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:80/1 fido.rbt.net.br:24554 35.192.92.175 Error: Socket read error.
    4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    4:90/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:90/1 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:92/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:92/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:801/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:801/10 softsolutions.net.br:24554 177.23.233.122 Ok.
    4:801/189 bsbbs.com.br:24554 179.180.145.169 Error: Connection timed out 4:801/197 bbs.rclabs.com.br:24554 85.208.48.115 Ok.
    4:801/200 rmsbbs.ddns.net:24554 179.190.142.218 Ok.
    4:801/202 baffa.zapto.org:24554 187.79.81.18 Ok.
    4:880/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    4:880/1 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    4:900/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:900/100 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Ok.
    4:900/107 darkgame.buanzo.org:24554 31.193.168.246 Error: Connection refused 4:900/108 zooropabbs.ddns.net:24554 181.45.26.197 Error: Connection timed out 4:902/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:902/7 reisub.nsupdate.info:24554 181.12.214.46 Ok.
    4:902/19 ferchobbs.ddns.net:24554 181.23.124.217 Error: Connection timed out 4:902/26 bbs.docksud.com.ar:24554 2803:9800:a015:831e:523e:aaff:fe0f:fb01 Ok. 4:902/26 bbs.docksud.com.ar:24554 186.123.101.23 Ok.
    4:902/27 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:902/100 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:920/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:920/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out

    So John Dovey is currently not connectable.

    Of course this is just one moment in time, it might change in the future hours/days...

    Btw: I count 4 RC's. Of which only 1 is connectable right now...


    Bye, Wilfred.

    --- FMail-lnx64 2.2.1.1
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Ward Dossche on Mon Feb 19 12:54:27 2024
    Hello Ward,

    On Monday February 19 2024 10:40, you wrote to Fernando Toledo:

    The job needs to be vacant, then you need an election by the RCs.

    Basically the current ZC has to un-elect himself.

    If that fails there is the last resort of the impeachment procedure documented in P4 8.7.

    The IC has a role in in, but it is the RCs that must initiate it. That may be a bit of a challenge with only one out of four RCs being reachable...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Ward Dossche@2:292/854 to Michiel van der Vlist on Mon Feb 19 13:36:48 2024
    Michiel,

    If that fails there is the last resort of the impeachment procedure documented in P4 8.7.

    I know about that but it has never been done and, my opinion, it's not a good time to start doing that now.

    The IC has a role in in, but it is the RCs that must initiate it. That
    may be a bit of a challenge with only one out of four RCs being reachable...

    It also makes an election easy...

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Michiel van der Vlist@2:280/5555 to Ward Dossche on Mon Feb 19 14:43:45 2024
    Hello Ward,

    On Monday February 19 2024 13:36, you wrote to me:

    If that fails there is the last resort of the impeachment
    procedure documented in P4 8.7.

    I know about that but it has never been done and, my opinion, it's not
    a good time to start doing that now.

    If all else fails... But it is up to the RCs.

    The IC has a role in in, but it is the RCs that must initiate it.
    That may be a bit of a challenge with only one out of four RCs being
    reachable...

    It also makes an election easy...

    Strange things have happened with votes in Fidonet...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Fernando Toledo on Mon Feb 19 16:13:12 2024
    Hello Fernando,

    On Monday February 19 2024 01:06, you wrote to Dan Clough:

    I am going to investigate how to apply as a ZC

    4:902/26 bbs.docksud.com.ar:24554 2803:9800:a015:831e:523e:aaff:fe0f:fb01 Ok.

    I see you are back on IPv6. Great! I will put you back on the list.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Dan Clough@1:135/115 to Ward Dossche on Mon Feb 19 09:48:00 2024
    Ward Dossche wrote to Dan Clough <=-

    I suggest you start by firing the asshole, and put somebody in there
    that wants to actually do the job.

    Somebody with a distinct law degree and a beautiful little
    daughter is not exactly an asshole.

    Someone's education level, and/or the attractiveness of their offspring,
    does NOT preclude them from being an asshole. History is full of proof/examples of this.

    Somebody who purposely and repetitively refuses to do their job
    properly, *IS* an asshole.

    The zones are autonomous in selecting their ZC ... P4 is clear
    about that. The IC cannot do anything about it ...

    Yes, I see that, I think. But... read again section 1.2.8. In
    particular, quoting this paragraph:

    If a person at any level above sysop is unable to properly perform their duties, the person at the next level may replace them. For example, if a Regional Coordinator fails to perform, the Zone Coordinator can replace him.

    Does that not imply that the ZCC (and/or the IC) cannot replace a ZC?
    Seems like it does, to me. Perhaps worth a discussion amongst the ZCC.

    Alas.

    Don't give up hope, yet.

    Dan



    ... Wisdom is knowing what to do with what you know.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Dan Clough@1:135/115 to Ward Dossche on Mon Feb 19 10:07:00 2024
    Ward Dossche wrote to Michiel van der Vlist <=-

    If that fails there is the last resort of the impeachment procedure documented in P4 8.7.

    I know about that but it has never been done and, my opinion,
    it's not a good time to start doing that now.

    It's hard to imagine a scenario where there could be a better time.

    I mean, the ZC and 3 of the 4 RC's are not connectable? Why isn't that
    a "good time to start"? It needs to be done.



    ... There are two types of people; those who finish what they start and
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Michiel van der Vlist@2:280/5555 to Dan Clough on Mon Feb 19 17:35:03 2024
    Hello Dan,

    On Monday February 19 2024 09:48, you wrote to Ward Dossche:

    If a person at any level above sysop is unable to properly perform
    their duties, the person at the next level may replace them. For
    example, if a Regional Coordinator fails to perform, the Zone
    Coordinator can replace him.

    Does that not imply that the ZCC (and/or the IC) cannot replace a ZC? Seems like it does, to me. Perhaps worth a discussion amongst the
    ZCC.

    According to P4 1.2.7 the IC is the "first among equals". So (s)he is not "next level" of a ZC.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Carlos Navarro@2:341/234.1 to Wilfred van Velzen on Mon Feb 19 18:08:30 2024
    19 Feb 2024 11:03, you wrote to Ward Dossche:

    4:80/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:80/1 fido.rbt.net.br:24554 35.192.92.175 Error: Socket read error.

    :-m

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: cyberiada (2:341/234.1)
  • From Wilfred van Velzen@2:280/464 to Carlos Navarro on Mon Feb 19 18:54:58 2024
    Hi Carlos,

    On 2024-02-19 18:08:30, you wrote to me:

    4:80/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:80/1 fido.rbt.net.br:24554 35.192.92.175 Error: Socket read error.

    :-m

    Good catch! ;-)

    That's a problem in the testing program, when it tries aliasses of the same node at the same time.

    When I test it separately, it's OK:

    Nodelist for Monday, February 19, 2024 -- Day number 050 parsed, 963 IP-nodes processed (0.014 sec)
    Calling '4:80/1'. Call time: '0000-2400' UTC.
    Now is: 1756 UTC.
    fido.rbt.net.br, 24554
    Calling 4:80/1 (35.192.92.175:24554)
    OPT CRAM-MD5-136601be320d8a5463b5d2f688cf110f
    SYS Internet Hub
    LOC Rio de Janeiro - Brazil
    ZYZ Flavio Bessa
    TIME Mon, 19 Feb 2024 14:56:41 -0300
    VER Mystic/1.12A47 binkp/1.0
    BUILD 2021/12/24 21:21:16 Linux/64
    address: 4:80/1@fidonet
    address: 4:801/0@fidonet
    address: 4:80/0@fidonet
    address: 4:801/1@fidonet
    35.192.92.175 - Ok.
    QSIZE 0 files 0 bytes
    Session with 4:80/1 done.


    Bye, Wilfred.

    --- FMail-lnx64 2.2.1.1
    * Origin: FMail development HQ (2:280/464)
  • From Fernando Toledo@4:902/26 to Michiel van der Vlist on Mon Feb 19 19:22:03 2024
    El 19/2/24 a las 12:13, Michiel van der Vlist escribió:
    Hello Fernando,

    On Monday February 19 2024 01:06, you wrote to Dan Clough:

    FT> I am going to investigate how to apply as a ZC

    4:902/26 bbs.docksud.com.ar:24554 2803:9800:a015:831e:523e:aaff:fe0f:fb01 Ok.

    I see you are back on IPv6. Great! I will put you back on the list.

    yeap.. i need to make some test but i think that it is working again.

    Saludos!
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Fernando Toledo@4:902/26 to Wilfred van Velzen on Mon Feb 19 19:26:07 2024
    El 19/2/24 a las 07:03, Wilfred van Velzen escribió:

    Nodelist for Monday, February 19, 2024 -- Day number 050 parsed, 29 IP-nodes processed (0.009 sec)
    4:4/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:80/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:80/1 fido.rbt.net.br:24554 35.192.92.175 Error: Socket read error.
    4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    4:90/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:90/1 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:92/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:92/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:801/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:801/10 softsolutions.net.br:24554 177.23.233.122 Ok.
    4:801/189 bsbbs.com.br:24554 179.180.145.169 Error: Connection timed out 4:801/197 bbs.rclabs.com.br:24554 85.208.48.115 Ok.
    4:801/200 rmsbbs.ddns.net:24554 179.190.142.218 Ok.
    4:801/202 baffa.zapto.org:24554 187.79.81.18 Ok.
    4:880/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    4:880/1 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    4:900/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:900/100 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out
    4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Ok.
    4:900/107 darkgame.buanzo.org:24554 31.193.168.246 Error: Connection refused 4:900/108 zooropabbs.ddns.net:24554 181.45.26.197 Error: Connection timed out 4:902/0 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out 4:902/7 reisub.nsupdate.info:24554 181.12.214.46 Ok.
    4:902/19 ferchobbs.ddns.net:24554 181.23.124.217 Error: Connection timed out
    4:902/26 bbs.docksud.com.ar:24554 2803:9800:a015:831e:523e:aaff:fe0f:fb01 Ok.
    4:902/26 bbs.docksud.com.ar:24554 186.123.101.23 Ok.
    4:902/27 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out
    4:902/100 momiabbs.no-ip.info:24554 181.229.121.152 Error: Connection timed out
    4:920/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:920/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out

    So John Dovey is currently not connectable.

    Of course this is just one moment in time, it might change in the future hours/days...

    Btw: I count 4 RC's. Of which only 1 is connectable right now...


    this is not good =(

    I dont have news from John Dovey too. I think that is offline at Fido.

    The another RC is Flavio Bessa and He is using a secondary link because
    via 4:90/1 also had problems previously.
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Ward Dossche@2:292/854 to Dan Clough on Tue Feb 20 10:53:05 2024
    Dan,

    If a person at any level above sysop is unable to properly perform their duties, the person at the next level may replace them. For example, if a Regional Coordinator fails to perform, the Zone Coordinator can replace him.

    It doesn't work in the case of the ZC if the RCs don't follow ... an IC is a toothless tiger if the ZCC does not operate as 'one'.

    Does that not imply that the ZCC (and/or the IC) cannot replace a ZC?
    Seems like it does, to me. Perhaps worth a discussion amongst the ZCC.

    Talk to whom there? Nick will respond but other than that there's a lot of echo.

    Alas.

    Don't give up hope, yet.

    I can tell you about not giving up hope against all odds ...

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Dan Clough on Tue Feb 20 10:53:24 2024
    It's hard to imagine a scenario where there could be a better time.

    Let me try it another way, suppose as IC I would decide to replace ZC1 just like that.

    How successful do you think I would be?

    The IC is a toothless tiger ... that has been demonstrated in the past.

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Wilfred van Velzen@2:280/464 to Fernando Toledo on Tue Feb 20 11:10:58 2024
    Hi Fernando,

    On 2024-02-19 19:26:07, you wrote to me:

    So John Dovey is currently not connectable.

    Of course this is just one moment in time, it might change in the future
    hours/days...

    Btw: I count 4 RC's. Of which only 1 is connectable right now...

    this is not good =(

    I did another test today. Some IP numbers changed, but not the connection test results. Here's the diff with yesterday:

    5c5
    < 4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    -+-
    4:88/0 mastodontbbs.hopto.org:24554 181.162.215.135 Error: Connection timed out
    16,17c16,17
    < 4:880/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    < 4:880/1 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out
    -+-
    4:880/0 mastodontbbs.hopto.org:24554 181.162.215.135 Error: Connection timed out
    4:880/1 mastodontbbs.hopto.org:24554 181.162.215.135 Error: Connection timed out
    22c22
    < 4:900/108 zooropabbs.ddns.net:24554 181.45.26.197 Error: Connection timed out
    -+-
    4:900/108 zooropabbs.ddns.net:24554 52.4.41.44 Error: Connection timed out
    24c24
    < 4:902/7 reisub.nsupdate.info:24554 181.12.214.46 Ok.
    -+-
    4:902/7 reisub.nsupdate.info:24554 181.91.5.227 Ok.


    Bye, Wilfred.

    --- FMail-lnx64 2.2.1.1
    * Origin: FMail development HQ (2:280/464)
  • From Dan Clough@1:135/115 to Ward Dossche on Wed Feb 21 21:00:00 2024
    Ward Dossche wrote to Dan Clough <=-

    If a person at any level above sysop is unable to properly perform their duties, the person at the next level may replace them. For example, if a Regional Coordinator fails to perform, the Zone Coordinator can replace him.

    It doesn't work in the case of the ZC if the RCs don't follow ...
    an IC is a toothless tiger if the ZCC does not operate as 'one'.

    Understood. But if there's only one remaining active RC in that zone,
    then he becomes a quorum unto himself, by my reckoning. Perhaps that RC should be contacted for discussion about this.

    Does that not imply that the ZCC (and/or the IC) cannot replace a ZC? Seems like it does, to me. Perhaps worth a discussion amongst the ZCC.

    Talk to whom there? Nick will respond but other than that there's
    a lot of echo.

    Well, again, that makes the ZC1 and the ZC2 a majority/quorum to make a decision to replace the ZC4.

    >WD> Alas.

    Don't give up hope, yet.

    I can tell you about not giving up hope against all odds ...

    I'm sure. This whole thought process and possible result of replacing
    that ZC seems like a common-sense win-win, and a betterment of FidoNet.
    Who could reasonably argue that it wasn't an improvement on a bad
    situation?

    Regards,
    Dan


    ... The future's uncertain, the end is always near.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Dan Clough@1:135/115 to Ward Dossche on Wed Feb 21 21:08:00 2024
    Ward Dossche wrote to Dan Clough <=-

    It's hard to imagine a scenario where there could be a better time.

    Let me try it another way, suppose as IC I would decide to
    replace ZC1 just like that.

    That would be a whole 'nother situation, and that replacement would not
    be justified. The difference here, of course, is that the ZC in
    question has disappeared and is un-reachable. Seems like reasonable
    time and effort has been dispensed in *TRYING* to reach him. At what
    point does that unacceptable behavior (and Zone status) become something
    that needs decisive action to correct? Is it allowed to go on
    indefinitely? Seems stupid to allow that, as it clearly is not good for
    the health of FidoNet.

    How successful do you think I would be?

    Not very, for reasons discussed just above. There's no defend-able
    reason to replace that ZC, but there is for the other.

    The IC is a toothless tiger ... that has been demonstrated in the
    past.

    There's an old saying that I've heard (and used a few times): Sometimes
    it's better to ask forgiveness than to seek permission. I don't see how anyone in FidoNet would think this (replacing the AWOL ZC) is not a
    justified and necessary action. It's for the betterment of FidoNet.

    Regards,
    Dan


    ... Why did kamikaze pilots wear helmets?
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Wilfred van Velzen@2:280/464 to Fernando Toledo on Thu Feb 22 09:12:00 2024
    Hi Fernando,

    On 2024-02-20 11:10:58, I wrote to you:

    this is not good =(

    I did another test today. Some IP numbers changed, but not the connection test results.

    I did another test.

    The ZC4 system is connectable today:

    4:4/0 momiabbs.no-ip.info:24554 181.229.54.97 Ok.

    But has a few AKA issues:

    4:900/0 momiabbs.no-ip.info:24554 181.229.54.97 No such AKA. 4:900/100 momiabbs.no-ip.info:24554 181.229.54.97 No such AKA. 4:902/27 momiabbs.no-ip.info:24554 181.229.54.97 No such AKA.

    2 Other systems are now offline:

    4:801/10 softsolutions.net.br:24554 177.23.233.122 Error: Connection timed out
    4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Error: Connection timed out


    Bye, Wilfred.

    --- FMail-lnx64 2.2.1.1
    * Origin: FMail development HQ (2:280/464)
  • From Benny Pedersen@2:230/0 to Ward Dossche on Tue Mar 19 00:06:04 2024
    Hello Ward!

    19 Feb 2024 00:17, Ward Dossche wrote to Fernando Toledo:

    ;S Zone 5 mail hour (01:00 - 02:00 UTC)
    ;S Zone 6 mail hour (20:00 - 21:00 UTC)

    * Zone-5 was removed 12 years ago from the nodelist
    * Zone-6 was removed 17 years ago from the nodelist

    i will think thay are welcommed back if anything permits it

    just not hope fidonet will end as one single node to whole fidonet

    I stopped being bothered by it because it seems impossible to get anything changed/corrected in Z4 for decades.

    it just proved now you don't live up to this statement :)

    Don't the sysops have a sense of pride or achievement to get things
    done properly?

    oh pride, what ever this means


    Regards Benny

    ... too late to die young :)

    --- Msged/LNX 6.1.2 (Linux/6.7.10-gentoo-dist (x86_64))
    * Origin: gopher://fido.junc.eu/ (2:230/0)
  • From Ward Dossche@2:292/854 to Benny Pedersen on Tue Mar 19 08:36:01 2024
    Benny,

    just not hope fidonet will end as one single node to whole fidonet

    At some point it just will stop operating and very little will be left, even the description in Wikipedia is way overdue ...

    There is no growth and eventually the last active sysop will die and no-one will be there to notice it ... they will be busy on some silly forum showing silly 20-second dance moves that only 14-yr olds are interested in.

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Benny Pedersen@2:230/0 to Ward Dossche on Tue Mar 19 10:41:22 2024
    Hello Ward!

    19 Mar 2024 08:36, Ward Dossche wrote to Benny Pedersen:

    Benny,

    just not hope fidonet will end as one single node to whole fidonet

    At some point it just will stop operating and very little will be
    left, even the description in Wikipedia is way overdue ...

    while internet was expansive payment fidonet was populary to many users to cut telephone bills on international bills, when internet godt cheapper then fidonet lost intrest from many many users sadly

    There is no growth and eventually the last active sysop will die and no-one will be there to notice it ... they will be busy on some silly forum showing silly 20-second dance moves that only 14-yr olds are interested in.

    i lost intrest in anything owned by #meta, when instagram was owned by owner living in gr it was good an exactly what i need to my photo collection, now its gone and it now just we want to make money on your content, sadly this works for #meta, copyright holders got nothing

    tictok are slowly gething better, but there is still more an more porn over there aswell, with is unwanted more or less, lets hope for the better, with photos from russia succes on special operations

    how could putin win another 6 years of election with 87% votes, fake number of votes ?, missing votes for alternatives, curruption like hell

    putin is way worse then hitler was, as hitler took his own life on loose

    i think ww2 was olso a bit stand on fakenews, so military wise it ended in bad choises in many places

    worst is that danmark payed for the atlantic wall, and germany got pigs delivery from danmark at same payment, had germany should payed for the wall it was maybe not being buildt, hmm, stupid danes



    Regards Benny

    ... too late to die young :)

    --- Msged/LNX 6.1.2 (Linux/6.7.10-gentoo-dist (x86_64))
    * Origin: gopher://fido.junc.eu/ (2:230/0)
  • From Fernando Toledo@4:902/26 to Ward Dossche on Tue Mar 19 12:19:20 2024
    El 19/3/24 a las 03:36, Ward Dossche escribió:
    Benny,

    just not hope fidonet will end as one single node to whole fidonet

    At some point it just will stop operating and very little will be left, even the description in Wikipedia is way overdue ...

    There is no growth and eventually the last active sysop will die and no-one will be there to notice it ... they will be busy on some silly forum showing silly 20-second dance moves that only 14-yr olds are interested in.

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)

    Unfortunately in the Z4 they are all inert. Nobody has an interest in improving something, or at least keeping the current thing working well.
    The ZC hasn't changed anything for 10 years and no one changes to the ZC =(

    I try all the time to test software, to see what can be improved. IPv6, helping others try Fido and promoting it. But I'm completely alone in that.
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Wilfred van Velzen@2:280/464 to Fernando Toledo on Tue Mar 19 16:34:04 2024
    Hi Fernando,

    On 2024-02-22 09:12:00, I wrote to you:

    this is not good =(

    I did another test today. Some IP numbers changed, but not the
    connection test results.

    I did another test.

    The ZC4 system is connectable today:

    4:4/0 momiabbs.no-ip.info:24554 181.229.54.97 Ok.

    But has a few AKA issues:

    4:900/0 momiabbs.no-ip.info:24554 181.229.54.97 No such AKA.
    4:900/100 momiabbs.no-ip.info:24554 181.229.54.97 No such AKA.
    4:902/27 momiabbs.no-ip.info:24554 181.229.54.97 No such AKA.

    2 Other systems are now offline:

    4:801/10 softsolutions.net.br:24554 177.23.233.122 Error: Connection timed out
    4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Error: Connection timed out

    I did another full Z4 test. Compared to the previous test, there is 1 change;

    4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Ok.

    This is the full result:

    Nodelist for Tuesday, March 19, 2024 -- Day number 079 parsed, 29 IP-nodes processed (0.010 sec)
    4:4/0 momiabbs.no-ip.info:24554 181.229.48.186 Ok.
    4:80/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:80/1 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:88/0 mastodontbbs.hopto.org:24554 181.162.207.40 Error: Connection timed out
    4:90/0 momiabbs.no-ip.info:24554 181.229.48.186 Ok.
    4:90/1 momiabbs.no-ip.info:24554 181.229.48.186 Ok.
    4:92/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:92/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:801/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:801/10 softsolutions.net.br:24554 177.23.233.122 Error: Connection timed out
    4:801/189 bsbbs.com.br:24554 179.180.145.169 Error: Connection timed out 4:801/197 bbs.rclabs.com.br:24554 85.208.48.115 Ok.
    4:801/200 rmsbbs.ddns.net:24554 179.190.142.218 Ok.
    4:801/202 baffa.zapto.org:24554 187.14.34.101 Ok.
    4:880/0 mastodontbbs.hopto.org:24554 181.162.207.40 Error: Connection timed out
    4:880/1 mastodontbbs.hopto.org:24554 181.162.207.40 Error: Connection timed out
    4:900/0 momiabbs.no-ip.info:24554 181.229.48.186 No such AKA.
    4:900/100 momiabbs.no-ip.info:24554 181.229.48.186 No such AKA.
    4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Ok.
    4:900/107 darkgame.buanzo.org:24554 31.193.168.246 Error: Connection refused 4:900/108 zooropabbs.ddns.net:24554 52.4.41.44 Error: Connection timed out 4:902/0 momiabbs.no-ip.info:24554 181.229.48.186 Ok.
    4:902/7 reisub.nsupdate.info:24554 181.12.68.121 Ok.
    4:902/19 ferchobbs.ddns.net:24554 181.23.98.243 Error: Connection timed out 4:902/26 bbs.docksud.com.ar:24554 2803:9800:a015:831e:523e:aaff:fe0f:fb01 Ok. 4:902/26 bbs.docksud.com.ar:24554 186.123.101.23 Ok.
    4:902/27 momiabbs.no-ip.info:24554 181.229.48.186 No such AKA.
    4:902/100 momiabbs.no-ip.info:24554 181.229.48.186 Ok.
    4:920/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:920/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out


    Bye, Wilfred.

    --- FMail-lnx64 2.3.0.1-B20240317
    * Origin: FMail development HQ (2:280/464)
  • From Ward Dossche@2:292/854 to Fernando Toledo on Wed Mar 20 00:10:39 2024
    Fernando,

    Unfortunately in the Z4 they are all inert. Nobody has an interest in improving something, or at least keeping the current thing working well. The ZC hasn't changed anything for 10 years and no one changes to the ZC
    =(

    If you are of the opinion that change is overdue, then now is as good a time as ever to initiate change.

    If you are dissatisfied and of the belief that another ZC could do a better job, then get the ball rolling. But there is a challenge: an impeachment procedure of a zone-coordinator has never been attempted that I know of. Plus in Z4 there are 4 listed RCs of which 2 are absent. Of the remaining 2 which are technically functional one is the ZC himself so unless he votes against himself provided he wakes up, then I fear the chances of achieving it are close to nothing.

    Another possibility is to create one or several IP-only orphan nets and have these accomodated in a region in another zone. Talk to the International Coordinator about this and see how he feels about that.

    I try all the time to test software, to see what can be improved. IPv6, helping others try Fido and promoting it. But I'm completely alone in
    that.

    Don't say that. There are several people willing to help out...

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Dan Clough@1:135/115 to Ward Dossche on Tue Mar 19 19:39:00 2024
    Ward Dossche wrote to Fernando Toledo <=-

    Unfortunately in the Z4 they are all inert. Nobody has an interest in improving something, or at least keeping the current thing working well. The ZC hasn't changed anything for 10 years and no one changes to the ZC =(

    If you are of the opinion that change is overdue, then now is as
    good a time as ever to initiate change.

    There was talk quite recently about this, and somebody... <ahem> seemed to imply that it wasn't possible, or that it "hadn't been long enough" that
    the existing ZC was AWOL...

    If you are dissatisfied and of the belief that another ZC could
    do a better job, then get the ball rolling. But there is a
    challenge: an impeachment procedure of a zone-coordinator has
    never been attempted that I know of. Plus in Z4 there are 4
    listed RCs of which 2 are absent. Of the remaining 2 which are
    technically functional one is the ZC himself so unless he votes
    against himself provided he wakes up, then I fear the chances of
    achieving it are close to nothing.

    If there are only 2 RCs left, doesn't 1 of them make a majority/quorum?
    It's my opinion that it does. With the circumstances thrown in (obvious neglect / disappearance), it pretty much is beyond question.

    Another possibility is to create one or several IP-only orphan
    nets and have these accomodated in a region in another zone. Talk
    to the International Coordinator about this and see how he feels
    about that.

    Okay, let's do that. Wave the magic wand, dissolve Z4, and put the
    survivors in Z3, with Fernando as the RC. Done.


    ... Hard work never killed anyone but why take a risk?
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Ward Dossche@2:292/854 to Dan Clough on Wed Mar 20 02:36:38 2024
    There was talk quite recently about this, and somebody... <ahem> seemed
    to
    imply that it wasn't possible, or that it "hadn't been long enough" that the existing ZC was AWOL...

    Again some *C I expect not willing to face reality ... do I know him/her?

    If there are only 2 RCs left, doesn't 1 of them make a majority/quorum? It's my opinion that it does. With the circumstances thrown in (obvious neglect / disappearance), it pretty much is beyond question.

    P4 mentions that a majority is more than 50% of those voting. If there are 2 RCs 'live' and one votes and the otherone not, then there is no majority.

    Okay, let's do that. Wave the magic wand, dissolve Z4, and put the survivors in Z3, with Fernando as the RC. Done.

    * Dissolving Z4 are your words, not mine
    * Adding orphaned nets to R34 would linguistically make more sense
    * Although Z3 is a live entity, reaching its ZC can be a challenge as well,
    but at least he replies after a while and acts upon things.
    * "we" are not involved, it must come from Z4-sysops

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Dan Clough@1:135/115 to Ward Dossche on Wed Mar 20 07:47:00 2024
    Ward Dossche wrote to Dan Clough <=-

    There was talk quite recently about this, and somebody... <ahem> seemed
    to imply that it wasn't possible, or that it "hadn't been long enough" that the existing ZC was AWOL...

    Again some *C I expect not willing to face reality ... do I know
    him/her?

    Yes. See below.

    If there are only 2 RCs left, doesn't 1 of them make a majority/quorum? It's my opinion that it does. With the circumstances thrown in (obvious neglect / disappearance), it pretty much is beyond question.

    P4 mentions that a majority is more than 50% of those voting. If
    there are 2 RCs 'live' and one votes and the otherone not, then
    there is no majority.

    Perhaps you missed the reference to "circumstances" above?

    Okay, let's do that. Wave the magic wand, dissolve Z4, and put the survivors in Z3, with Fernando as the RC. Done.

    * Dissolving Z4 are your words, not mine
    * Adding orphaned nets to R34 would linguistically make more
    sense * Although Z3 is a live entity, reaching its ZC can be a
    challenge as well,
    but at least he replies after a while and acts upon things.
    * "we" are not involved, it must come from Z4-sysops

    Yes. See above.

    Or, look the other way. Because.... that is easier.


    ... Wisdom is knowing what to do with what you know.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Flavio Bessa@4:801/188 to Fernando Toledo on Wed Apr 10 00:27:20 2024
    On 18 Feb 2024, Fernando Toledo said the following...

    alo?!!?

    Oi!

    Is anyone from z4 receiving this?

    Yes, I am. Better late than never :)

    []s
    Flavio

    ... My software never has bugs. It just develops random features...

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Ward Dossche on Wed Apr 10 00:31:13 2024
    On 19 Feb 2024, Ward Dossche said the following...

    I think there is no "http://www.momiabbs.com.ar" at all.

    Yes, you are right. The domain is not OK.

    ;S Zone Mail Hour
    ;S --------------
    ;S
    ;S Zone 5 mail hour (01:00 - 02:00 UTC)
    ;S Zone 2 mail hour (02:30 - 03:30 UTC)
    ;S Zone 4 mail hour (08:00 - 09:00 UTC)
    ;S Zone 1 mail hour (09:00 - 10:00 UTC)
    ;S Zone 3 mail hour (17:00 - 18:00 UTC)
    ;S Zone 6 mail hour (20:00 - 21:00 UTC)


    Gosh...

    Don't the sysops have a sense of pride or achievement to get things done properly?

    Well, last nodelist cleanup was led by me. Manuel has been keeping his system running, but he is resistant on changing things or cleaning up nodes.

    I will try to talk with him to see if he can change that part of the nodelist...

    Regards,
    Flavio

    ... Anything is possible if you don't know what you're talking about

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Ward Dossche on Wed Apr 10 00:32:39 2024
    On 19 Feb 2024, Ward Dossche said the following...

    Basically the current ZC has to un-elect himself. Talk to Manuel, I
    think he is pretty decent and open to the idea ... with only 3 RCs in
    the region it could be managed quick ... well, that is if John Dovey in Panama is still breathing.

    I think that John has shut down his system... He is now travelling over South Africa and his BBS seem to be down.

    ... Consultant: A person who makes good on a salesman's promises!

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Michiel van der Vlist on Wed Apr 10 00:34:07 2024
    On 19 Feb 2024, Michiel van der Vlist said the following...

    If that fails there is the last resort of the impeachment procedure documented in P4 8.7.

    The IC has a role in in, but it is the RCs that must initiate it. That
    may be a bit of a challenge with only one out of four RCs being reachable...

    We have discussed this internally for a while, but the other systems do not want to start a fight with him.

    ... Youth is glorious, but it isn't a career

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Wilfred van Velzen on Wed Apr 10 00:35:32 2024
    On 19 Feb 2024, Wilfred van Velzen said the following...

    When I test it separately, it's OK:

    Good to know that my system is working fine.

    ... Message encrypted: Press ALT-F4 to read encoded message

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Fernando Toledo on Wed Apr 10 00:36:45 2024
    On 19 Feb 2024, Fernando Toledo said the following...

    I dont have news from John Dovey too. I think that is offline at Fido.

    The another RC is Flavio Bessa and He is using a secondary link because via 4:90/1 also had problems previously.

    Actually I do not route any echo through Manuel anymore, just netmail.

    ... Real Programmers balance their checkbooks in hex

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Fernando Toledo on Wed Apr 10 00:38:42 2024
    On 19 Mar 2024, Fernando Toledo said the following...

    Unfortunately in the Z4 they are all inert. Nobody has an interest in improving something, or at least keeping the current thing working well. The ZC hasn't changed anything for 10 years and no one changes to the ZC =(

    I try all the time to test software, to see what can be improved. IPv6, helping others try Fido and promoting it. But I'm completely alone in

    That is true, we have tried to convince him to move the Hub to the cloud (just like I did with R80) to give the system more stability but he was adamant in not doing anything...

    ... I don't have the time for a hobby. I have a computer.

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Wilfred van Velzen on Wed Apr 10 00:40:33 2024
    I did another test.

    4:801/10 softsolutions.net.br:24554 177.23.233.122
    Error: WvV> Connection timed out

    I will notify the sysop.

    4:801/189 bsbbs.com.br:24554 179.180.145.169 Error: Connection timed out

    Ioram has been offline for quite a while, I will check with him.

    ... Running Windows is better than washing them!

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Ward Dossche@2:292/854 to Flavio Bessa on Wed Apr 10 09:47:53 2024
    I think that John has shut down his system... He is now travelling
    over South Africa and his BBS seem to be down.

    Well, then obviously his presence in the nodelist, of lack there-of, needs to be managed one way or the other ... Failing that Z4 will contain inactive regions with closed-down nodes and a ZC not dealing with it.

    Even in the closed ZCC-echo among ZCs the ZC4 is absent. Last sign of life Jan 22 2022. But I see Manuel on and of on Facebook.

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Flavio Bessa@4:801/188 to Ward Dossche on Wed Apr 10 11:13:38 2024
    On 10 Apr 2024, Ward Dossche said the following...

    Well, then obviously his presence in the nodelist, of lack there-of,
    needs to be managed one way or the other ... Failing that Z4 will
    contain inactive regions with closed-down nodes and a ZC not dealing
    with it.
    Even in the closed ZCC-echo among ZCs the ZC4 is absent. Last sign of
    life Jan 22 2022. But I see Manuel on and of on Facebook.


    You are right. Patricio from R88 replied me pretty quickly, but John did not; according to Facebook he is in Lesotho right now.

    I will drop a note to Manuel asking about it.

    ... Inside every cynical person, there is a disappointed idealist.

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Dan Clough@1:135/115 to Ward Dossche on Wed Apr 10 11:06:00 2024
    Ward Dossche wrote to Flavio Bessa <=-

    I think that John has shut down his system... He is now travelling
    over South Africa and his BBS seem to be down.

    Well, then obviously his presence in the nodelist, of lack
    there-of, needs to be managed one way or the other ... Failing
    that Z4 will contain inactive regions with closed-down nodes and
    a ZC not dealing with it.

    As I've said before, it's time to fire the asshole.

    Even in the closed ZCC-echo among ZCs the ZC4 is absent. Last
    sign of life Jan 22 2022. But I see Manuel on and of on Facebook.

    Tell him he's fired.

    Same with the RC above who's "shut down his system" without saying
    anything.

    Sometimes the rules (P4) need to go out the window.



    ... Post may contain information unsuitable for overly sensitive persons.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Fernando Toledo@4:902/26 to Dan Clough on Fri Apr 12 09:34:51 2024
    El 19/2/24 a las 13:07, Dan Clough escribió:
    Ward Dossche wrote to Michiel van der Vlist <=-

    Mv> If that fails there is the last resort of the impeachment procedure
    Mv> documented in P4 8.7.

    WD> I know about that but it has never been done and, my opinion,
    WD> it's not a good time to start doing that now.

    It's hard to imagine a scenario where there could be a better time.

    I mean, the ZC and 3 of the 4 RC's are not connectable? Why isn't that
    a "good time to start"? It needs to be done.

    I agree, we are all clear that it is a hobby, but it becomes a
    bottleneck if the ZC does not do simple tasks such as maintaining an
    updated nodelist or being in contact with the RCs (who are becoming
    fewer and fewer) so that everything It works, there is no participation
    in the votes, the Z4 became a limbo where some nodes remained connected
    but a minimum of organization
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Fernando Toledo@4:902/26 to Dan Clough on Fri Apr 12 12:07:15 2024
    El 22/2/24 a las 00:08, Dan Clough escribió:
    Ward Dossche wrote to Dan Clough <=-

    DC> It's hard to imagine a scenario where there could be a better time.

    WD> Let me try it another way, suppose as IC I would decide to
    WD> replace ZC1 just like that.

    That would be a whole 'nother situation, and that replacement would not
    be justified. The difference here, of course, is that the ZC in
    question has disappeared and is un-reachable. Seems like reasonable
    time and effort has been dispensed in *TRYING* to reach him. At what
    point does that unacceptable behavior (and Zone status) become something
    that needs decisive action to correct? Is it allowed to go on
    indefinitely? Seems stupid to allow that, as it clearly is not good for
    the health of FidoNet.

    Exactly, this is not a power dispute... we are just a few crazy nodes.
    It's a technical issue, I want the things to work.
    And when they don't work, they can be made to work and not expect that
    one person, because they are busy with other matters, will leave the
    entire area adrift.

    WD> How successful do you think I would be?

    Not very, for reasons discussed just above. There's no defend-able
    reason to replace that ZC, but there is for the other.

    WD> The IC is a toothless tiger ... that has been demonstrated in the
    WD> past.

    There's an old saying that I've heard (and used a few times): Sometimes
    it's better to ask forgiveness than to seek permission. I don't see how anyone in FidoNet would think this (replacing the AWOL ZC) is not a
    justified and necessary action. It's for the betterment of FidoNet.


    It is not necessary for the IC to change to the ZC, but rather the ZC
    must come clean and step aside, leaving others to continue holding the
    zone while he cannot do so.
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Dan Clough@1:135/115 to Fernando Toledo on Fri Apr 12 15:20:00 2024
    Fernando Toledo wrote to Dan Clough <=-

    El 22/2/24 a las 00:08, Dan Clough escribió:
    Ward Dossche wrote to Dan Clough <=-

    DC> It's hard to imagine a scenario where there could be a better time.

    WD> Let me try it another way, suppose as IC I would decide to
    WD> replace ZC1 just like that.

    That would be a whole 'nother situation, and that replacement would not
    be justified. The difference here, of course, is that the ZC in
    question has disappeared and is un-reachable. Seems like reasonable
    time and effort has been dispensed in *TRYING* to reach him. At what
    point does that unacceptable behavior (and Zone status) become something that needs decisive action to correct? Is it allowed to go on
    indefinitely? Seems stupid to allow that, as it clearly is not good for
    the health of FidoNet.

    Exactly, this is not a power dispute... we are just a few crazy
    nodes. It's a technical issue, I want the things to work.
    And when they don't work, they can be made to work and not expect
    that one person, because they are busy with other matters, will
    leave the entire area adrift.

    I agree. And if that person can't be reached, he gets replaced whether
    he likes it or not.

    WD> How successful do you think I would be?

    Not very, for reasons discussed just above. There's no defend-able
    reason to replace that ZC, but there is for the other.

    WD> The IC is a toothless tiger ... that has been demonstrated in the
    WD> past.

    There's an old saying that I've heard (and used a few times): Sometimes it's better to ask forgiveness than to seek permission. I don't see how anyone in FidoNet would think this (replacing the AWOL ZC) is not a justified and necessary action. It's for the betterment of FidoNet.

    It is not necessary for the IC to change to the ZC, but rather
    the ZC must come clean and step aside, leaving others to continue
    holding the zone while he cannot do so.

    Well, as I understand it, he cannot be reached, or will not respond. If that's the case he should be thrown out. If he will respond to you, I'd suggest you ask him to do just that (step aside) so that he can be
    replaced. It's been *WAY* longer than any reasonable person would think
    is enough time to fix his broken Zone.


    ... So easy, a child could do it. Child sold separately.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)
  • From Ward Dossche@2:292/854 to Fernando Toledo on Sat Apr 13 10:59:46 2024
    Fernando,

    It is not necessary for the IC to change to the ZC, but rather the ZC
    must come clean and step aside, leaving others to continue holding the
    zone while he cannot do so.

    While I respect everybody's point of view, mine is that it is not a duty for the IC to intervene inside a zone, it's not his mandate <period>.

    Actually, the situation is even worse, because that ZC is also an RC of the region 'Argentina' and within that region he is also twice an NC. That makes it fairly easy to assume RC- and NC-duties are also not performed for that area.

    The solution is pretty easy, there are a few options, but it's the zone that needs to deal with it:

    1) You (meaning Z4) need to shed R92 ... it is useless, always has been from the very beginning. He was one of those guys that pops-up out of nowhere, think they have all the answers, will save Fidonet, make it bloom again, claim to offer no-nonsense links to everything and everyone, run out-dated backbones, in doing so disrupt echomail distribution and netmail routing, whithin 6 months they drop from the radar having a VPN somewhere they forgot about. There is at least one otherone like that I can point to in the nodelist...

    2) Talk to the other live RCs/nodes and just decide amongst yourselves to appoint a new ZC4, I'm not talking about the P4 impeachment procedure which is very unpractical. Just do it. It implies also a new RC90, a new NC900 and a new NC902 because otherwise you will lose access to all those nodes. Don't forget, you are one of these nodes and while you feel commitment for change, perhaps you could be the next NC902?

    I can guarantee the other ZCs will work with that new ZC4 ... it's always fun to get something new up and going ...

    3) Create a new region and name it "America Latina", move all the existing nets 'as is' to that new region ... you just need to find a new NC900 ... and have that new region hosted in either Z1 or Z2, both make sense. Z1 because of geographical perception perhaps and then the zone could be renamed "The_Americas" per Dan Clough's suggestion, or Z2 because of the Spanish linguistic link. ZC1 and I already discussed it and whatever makes you happy, will make us happy and get our cooperation. I haven't mentioned it to Scott Little ZC3 but I'm certain he'll see the practicality of it too ... or maybe you could all become Australians... 8-)

    OK?

    These are the solutions and tools from how I see it. Please share your thoughts with us and let's get going General Patton's words in mind "Either lead, follow or get out of the way".

    Enjoy the week-end,

    (I'm sure someone will chime-in saying this is not the appropriate echo to discuss this)

    \%/@rd

    --- DB4 - 20230201
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Flavio Bessa@4:801/188 to Ward Dossche on Mon Apr 15 11:59:15 2024
    On 13 Apr 2024, Ward Dossche said the following...

    1) You (meaning Z4) need to shed R92 ... it is useless, always has been from the very beginning. He was one of those guys that pops-up out of nowhere, think they have all the answers, will save Fidonet, make it
    bloom again, claim to offer no-nonsense links to everything and
    everyone, run out-dated backbones, in doing so disrupt echomail distribution and netmail routing, whithin 6 months they drop from the radar having a VPN somewhere they forgot about. There is at least one otherone like that I can point to in the nodelist...

    Unfortunately,the fault is mine here. I usually scan the region for isolated systems and get them to join the zone - I was really excited to get an old region back online and it turned out not to be the case.

    I have requested Manuel over netmail to shed R92, let's see what he will do, usually the nodelist changes are published every Tuesday.

    2) Talk to the other live RCs/nodes and just decide amongst yourselves to appoint a new ZC4, I'm not talking about the P4 impeachment procedure which is very unpractical. Just do it. It implies also a new RC90, a new NC900 and a new NC902 because otherwise you will lose access to all
    those nodes. Don't forget, you are one of these nodes and while you feel commitment for change, perhaps you could be the next NC902?

    I do support that, but the problem is that we don't have 100% support on R90 to do this. I think we can find a negotiated solution, let's see how it goes.

    3) Create a new region and name it "America Latina", move all the
    existing nets 'as is' to that new region ... you just need to find a new NC900 ... and have that new region hosted in either Z1 or Z2, both make sense. Z1 because of geographical perception perhaps and then the zone could be renamed "The_Americas" per Dan Clough's suggestion, or Z2
    because of the Spanish linguistic link. ZC1 and I already discussed it
    and whatever makes you happy, will make us happy and get our
    cooperation. I haven't mentioned it to Scott Little ZC3 but I'm certain he'll see the practicality of it too ... or maybe you could all become Australians... 8-)
    OK?

    I believe that would be a last resort... I still think we can have a negotiated solution out of it.

    These are the solutions and tools from how I see it. Please share your thoughts with us and let's get going General Patton's words in mind "Either lead, follow or get out of the way".

    Let's see how things unfold. I am eager to see the results of R80 cleanup, R92 removal, and R88 back online as promised.

    Regards,
    Flavio

    ... There are three kinds of people: Those who can count, and those who can't

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Flavio Bessa@4:801/188 to Wilfred van Velzen on Wed Apr 24 11:50:14 2024
    On 19 Feb 2024, Wilfred van Velzen said the following...

    4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection timed out

    Can you please retest 4:88/0? System is back online now.

    ... If you can't make it good, make it LOOK good. -Bill Gates.

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Wilfred van Velzen@2:280/464 to Flavio Bessa on Wed Apr 24 18:17:22 2024
    Hi Flavio,

    On 2024-04-24 11:50:14, you wrote to me:

    4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error:
    Connection timed out

    Can you please retest 4:88/0? System is back online now.

    I did all of Z4:

    Nodelist for Wednesday, April 24, 2024 -- Day number 115 parsed, 29 IP-nodes processed (0.009 sec)
    4:4/0 momiabbs.no-ip.info:24554 181.229.55.28 Ok.
    4:80/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:80/1 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:88/0 mastodontbbs.hopto.org:24554 181.162.194.173 Ok.
    4:90/0 momiabbs.no-ip.info:24554 181.229.55.28 Ok.
    4:90/1 momiabbs.no-ip.info:24554 181.229.55.28 Ok.
    4:92/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:92/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:801/0 fido.rbt.net.br:24554 35.192.92.175 Ok.
    4:801/10 softsolutions.net.br:24554 177.23.233.122 Error: Connection timed out
    4:801/189 bsbbs.com.br:24554 179.180.145.169 Error: Connection timed out
    4:801/197 bbs.rclabs.com.br:24554 85.208.48.115 Ok.
    4:801/200 rmsbbs.ddns.net:24554 179.190.142.218 Error: Connection timed out
    4:801/202 baffa.zapto.org:24554 191.43.30.45 Ok.
    4:880/0 mastodontbbs.hopto.org:24554 181.162.194.173 No such AKA.
    4:880/1 mastodontbbs.hopto.org:24554 181.162.194.173 Error: Socket read error.
    4:900/0 momiabbs.no-ip.info:24554 181.229.55.28 No such AKA.
    4:900/100 momiabbs.no-ip.info:24554 181.229.55.28 No such AKA. 4:900/102 thevaultbbs.ddns.net:24554 190.111.203.94 Ok.
    4:900/107 darkgame.buanzo.org:24554 31.193.168.246 Error: Connection refused
    4:900/108 zooropabbs.ddns.net:24554 52.4.41.44 Error: Connection timed out
    4:902/0 momiabbs.no-ip.info:24554 181.229.55.28 Ok.
    4:902/7 reisub.nsupdate.info:24554 181.99.70.192 Ok.
    4:902/19 ferchobbs.ddns.net:24554 181.23.100.156 Error: Connection refused
    4:902/26 bbs.docksud.com.ar:24554 2803:9800:a015:831e:523e:aaff:fe0f:fb01 Ok.
    4:902/26 bbs.docksud.com.ar:24554 186.123.101.23 Ok.
    4:902/27 momiabbs.no-ip.info:24554 181.229.55.28 No such AKA. 4:902/100 momiabbs.no-ip.info:24554 181.229.55.28 Ok.
    4:920/0 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out
    4:920/1 gatofuego.synchronetbbs.org:24554 104.200.24.109 Error: Connection timed out

    Not everything is alright, but 4:88/0 is online, but needs to add some AKA's. Like Manuel also needs to do, and/or update the nodelist...


    Bye, Wilfred.

    --- FMail-lnx64 2.3.2.3-B20240423
    * Origin: FMail development HQ (2:280/464)
  • From Flavio Bessa@4:801/188 to Wilfred van Velzen on Wed Apr 24 17:36:34 2024
    On 24 Apr 2024, Wilfred van Velzen said the following...

    Not everything is alright, but 4:88/0 is online, but needs to add some AKA's. Like Manuel also needs to do, and/or update the nodelist...

    Thanks! I will check here and get these fixed.

    Regards,
    Flavio

    ... Light year: 1/3 less calories than your regular year

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)
  • From Fernando Toledo@4:902/26 to Flavio Bessa on Fri Apr 26 08:27:30 2024
    El 24/4/24 a las 11:50, Flavio Bessa escribió:
    On 19 Feb 2024, Wilfred van Velzen said the following...

    Wv> 4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error: Connection
    Wv> timed out

    Can you please retest 4:88/0? System is back online now.

    I see it offline.
    --- SBBSecho 3.20-Linux
    * Origin: Dock Sud BBS - https://bbs.docksud.com.ar (4:902/26)
  • From Wilfred van Velzen@2:280/464 to Fernando Toledo on Fri Apr 26 13:56:23 2024
    Hi Fernando,

    On 2024-04-26 08:27:30, you wrote to Flavio Bessa:

    Wv> 4:88/0 mastodontbbs.hopto.org:24554 181.162.198.58 Error:
    Connection
    Wv> timed out

    Can you please retest 4:88/0? System is back online now.

    I see it offline.

    I can confirm that. I now get a time out for the 4:88/0 system (and AKA's).


    Bye, Wilfred.

    --- FMail-lnx64 2.3.2.3-B20240423
    * Origin: FMail development HQ (2:280/464)
  • From Flavio Bessa@4:801/188 to Wilfred van Velzen on Sat Apr 27 17:47:52 2024
    On 26 Apr 2024, Wilfred van Velzen said the following...

    I can confirm that. I now get a time out for the 4:88/0 system (and AKA's).

    It is online again.

    ... Help! I can't find the "ANY" key.

    --- Mystic BBS v1.12 A48 (macOS/64)
    * Origin: Saturn's Orbit BBS - Back from the ashes (4:801/188)