• 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 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 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 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 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 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)
    kt message 1 屯 ZCC-PUBLIC 222/2 226/30 227/114
  • 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)
    kt message 2 屯 ZCC-PUBLIC 8 229/426 90/1
  • 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 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 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 DosPkt message 1 屯 ZCC-PUBLIC 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 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 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)