TIP: Click on subject to list as thread! ANSI
echo: fidonews
to: NICK ANDRE
from: TONY LANGDON
date: 2019-03-16 10:40:00
subject: Re: Fidonet = one unizon

-=> On 03-15-19 15:53, Nick Andre wrote to Robert Stinnett <=-

 NA> I agree there shouldn't be so many people, but it is what it is in
 NA> Fido. Technically-competent people are also hard to come by and are
 NA> valuable when we have them hanging around.

For technically competence, we should be encouraging others to learn the ropes.
 None of us are going to life forever, and some form of succession planning is
needed to ensure that the technical knowledge is (1) not lost, and (2) evolves
with the times.

 NA> I still do not quite understand how a 100% automated system will work,
 NA> how it gets decided what software to run, what server OS, what
 NA> virtual-machine environment, who gets access to it and if so by what
 NA> decisions is it made, who gets to vote on it, who is qualified and who
 NA> isn't.

An automated system should be based on standards.  Where standards don't yet
exist, create then document and release them, so other developers can implement
them.  Server OS shouldn't matter, except for specific implementations.  In an
ideal world, the server OS should be up to the server admin(s).  The system
should NOT rely on Windows, DOS or Linux, but be able to be ported to any OS
that someone cares to port it to. 

 NA> My system and Ward's are about as automated as it gets... I'd say 99%.
 NA> The 1 percent are segment errors or equipment failure, both extremely
 NA> rare.

But nodelist data maintenance is still concentrated in the hands of NCs, and
aggregated by RCs and ZCs.  Some of these roles could be replaced by a web
based front end, where individual sysops actually maintain their own nodelist
entries.  The interface would validate all fields, so that the nodelist data at
least conformed to standards (of course, there's still a degree of "GIGO", but
that goes for any human entered content ;) ).

And the system should have some sort of redundancy, so if hardware fails, a
backup system can keep nodelist processing happening.

In the longer term (because it would require software to be written), Internet
connected nodes could be able to access a DNS or DNS like "online nodelist"
that sysops have access to update their specific node entery (could be given
public keys for thos on admission to Fidonet).  A question that would naturally
arise is how to handle legacy software.  This is certainly a valid question,
and implies some form of nodelist is likely needed for those systems.  

I'm just thinking out loud for the purpose of stimulating discussion.

 > This production runs on a combination of custom-software I wrote for
 > MS-DOS and Windows because it is not possible to run a reliable operation
 RS>
 RS> Is this software available in the open-source world or under a license
hat
 RS> allows others to try and modernize it and bring it into the Linux world?

 NA> The MakeNL source I believe is open, but the rest is all custom to this
 NA> system, just as ZC2's software is specific for him, ZC3 and ZC4 etc.

Yes, I have the MakeNL source here that I compiled on my Pi.  I use MakeNL on
the Pi and x86_64 to generate my VLRadio nodelists.  Further processing by
another script generates my DNS zone file.  Along the way, scripts hatch the
nodelist and rebuild and hatch the infopack every week, including the latest
nodelist.  For various reasons, I require 100% automation to keep everything up
to date.

 NA> As soon as I say MS-DOS and Windows, the instant reaction is why not
 NA> switch to Linux, instead of understanding why I use what I use. I chose
 NA> an OS and a commercial-grade server system that is reliable and stable
 NA> and "just works" without experimenting or screwing around.

That has traditionally been the basis on what OS I select for a certain job. 
It does make sense to me.

 NA> Lets just say I want to be a fan of Linux... I really do. I administer
 NA> Linux servers as part of my job. But that OS is just not the right fit
 NA> for this system or its needs. I have had this discussion with others at
 NA> length and believe me its easier to stick with what works at this
 NA> point.

You've got me curious though, because I generally find Linux easier to make do
what I want than Windows, especially when a high degree of automation and
networking is needed.  What is it that DOS and Windows have that make them more
suitable?  I'm not picking, obviously I'm overlooking something that's
important to the system you use.

 RS> What happens, if it is a closed-source system, if that person dies or
ecid
 RS> they don't want to have anything to do with it anymore?

 NA> I'm confident I can be replaced if something were to happen to me. The
 NA> know-it-alls I've encountered would definately love an opportunity.

:)

 RS> Look, I'll be honest here, based on what I've seen, witnessed and read I
o
 RS> have much faith in the future of Fidonet.  That is a pretty harsh
tatement
 RS> make, but the politics nowadays seem 10x worse than they were back in the


 NA> Agreed. So much damage has been done. Believe me when I say its near
 NA> impossible for some to move on from the past. It affects the present
 NA> too much.

Sadly, you may be right.  I'd like to see everyone acknowledge the past then
move on, but I can't see that happening. :(


... Scepticism is the beginning of faith.
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.