• Re: This vs That - taking the pulse.

    From Avon@21:1/100 to Alterego on Fri Nov 29 12:57:23 2019
    On 28 Nov 2019 at 09:23a, Alterego pondered and said...

    Not sure I'd use the term bottleneck as it implies restriction, unles that's what you're meaning? But what I think you are saying is watch for single point dependency - am I right? Just checking so I clarify understanding of your thoughts.

    So I was coming from the angle after I read your message that said "I havent done this, because I'm doing that". You've said that a couple of times now.

    Sure.

    Doing "this" could be something fun that you want to do, but you cant
    get to it, because of all the "that" things that you need to do.

    OK thanks for clarifying... yep, I get erm that :) The vexing thing is what
    is this and that can interchange at times on a given day or even within an
    hour or so. But my take out from what you are saying is 'where I choose to spend my time / efforts vs where I don't' and 'what gives me joy (this is not leading to a house clean up BTW :)) vs what does not'.

    Running a network has a lot of "that" things, and in FSX they all depend
    on you.
    Joining games, getting connected, debugging (the infrastructure)
    problems, etc.

    I don't agree it all depends on me but yes there are some things that do
    while others involve others to help setup nodes at hubs, help to debug
    stuff at hubs or more widely across the network between nodes etc. But I understand the points you're wanting to make :)

    I know one of the "this" you wanted to do is build these servers you picked up a while ago - so I'm guessing that has been/was pre-empted by "that" things related to FSX and "that" things related to Avons personal life outside of BBSing.

    Yes, and some of the 'that' fsxNet things are in the area of supporting nodes with issues that are often bespoke. I don't mind doing those 'that' things.
    I'm not (yet) at the point where I feel that the joy from it has all gone.
    But I do agree my time seems to be more occupied with helping current and new nodes than it seems to feel it was say a year ago. Not totally sure why that is.

    Thus the downside is, folks are waiting on you, the chores build up and
    it wears away at the fun.

    I think this is about expectations and what people are prepared to accept and what they think is taking too long etc. I think it's also about perceptions.
    By this I mean you're framing the 'thats' in this discussion as 'chores' but from my point of view I don't really see them as that. To me they part of the fun stuff I get to do as part of my BBSing hobby which is (in part, well to
    be fair a large part) focused on supporting fsxNet and new and current nodes/sysops etc. involved in it.

    I do agree if I perceive some of those tasks as a chore then yes it will detract from my fun of it all. But what (let's say) you think is a chore
    and/or perceive as taking too long or taking about the right level of time
    etc. is a really subjective personal thing. I'm not trying to discount your
    (or anyones) point of view about this.. just to say it is personal and subjective..as it's not like we have service level agreements in place that (and I'm just making this up on the fly) a new node will be contacted and connected within 24 hours of emailing for a node number etc...

    So if there were 2 or 3 or 4 "Avons", then things might get done quicker (thus the end user experience benefits), and you get more time for
    "this".
    And when it gets to the size of FN (I always think big) - then you can look back and say - I started "this".

    At the heart of this discussion are a few things/points/questions you are raising. Here's my take on what those are.

    - what things are being done now that are (for want of a better term) network related admin that could be done not just by me but by others?

    - is this happening now in any shape/form?

    - is this seen as desirable / necessary, by whom, and why?

    - what does an acceptable level of service look like for all this stuff?

    - are we trying to fix something that is viewed as not broken, or is it
    broken? (I may be a bit harsh in my terminology using broken but you get the idea)

    - where to next?

    I'm more than happy to have that discussion in public with you and the wider community. I'm not sure of all the answers to the above. I'm equally not sure there is a problem per say but I do understand and appreciate your desire to see the network grow and thrive and do so in a way that perhaps one day may rival Fidonet of old. Not sure that will ever happen in this crazy world we live in but hey, it's been around four years since this network was started
    and it certainly has exceeded any initial expectations I had when it was started. :)

    Best, Paul

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)
  • From Oli@21:1/100 to Avon on Sun Dec 1 18:19:12 2019
    On Fri, 29 Nov 2019 12:57:23 +1300
    "Avon -> Alterego" <0@101.1.21> wrote:

    So if there were 2 or 3 or 4 "Avons", then things might get
    done quicker (thus the end user experience benefits), and you
    get more time for "this".
    And when it gets to the size of FN (I always think big) - then
    you can look back and say - I started "this".

    At the heart of this discussion are a few things/points/questions you
    are raising. Here's my take on what those are.

    - what things are being done now that are (for want of a better term) network related admin that could be done not just by me but by
    others?

    Is there anything that can't be done by others?

    The most important task is updating and distributing the nodelist.

    Then you are the first contact for new nodes. It seems that you are spending quite some time in helping people to setup their BBS / FTN connectivity.

    - is this happening now in any shape/form?

    I don't believe so, but I'm not sure.

    - is this seen as desirable / necessary, by whom, and why

    I don't see any reason why the nodelist cannot be updated collaboratively. E.g.
    use a private SVN / Git / Mercurial / Fossil repository and give every network
    write access.

    - what does an acceptable level of service look like for all this
    stuff?

    Level 8 would be nice ;)

    - are we trying to fix something that is viewed as not broken, or is
    it broken? (I may be a bit harsh in my terminology using broken but
    you get the idea)

    At the moment it is bus factor 1-ish, but as long as Avon is not broken and keeps updating the nodelist, I wouldn't call it broken. It depends on the criteria you have. If the criteria were scalability and fault-tolerance, you could call the current process broken. On the other hand, even if Avon would shutdown all his nodes without any warning, the network would not cease to exist.

    @Alterego: I'm not sure if fsxnet should be seen as the successor to Fidonet. Maybe it would also make sense to start a new Fidonet in a truly decentralized and collaborative fashion?

    ---
    * Origin: (21:1/151)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)
  • From Avon@21:1/100 to Oli on Mon Dec 2 12:42:15 2019
    On 01 Dec 2019 at 06:19p, Oli pondered and said...

    At the heart of this discussion are a few things/points/questions you are raising. Here's my take on what those are.

    - what things are being done now that are (for want of a better term) network related admin that could be done not just by me but by
    others?

    Is there anything that can't be done by others?

    Answering a question with a question bakes my brain :) If we could talk specifics that would enable me (at least) to give a more informed reply.

    Then you are the first contact for new nodes. It seems that you are spending quite some time in helping people to setup their BBS / FTN connectivity.

    I am first point of contact for a node application at the moment yes, but
    then allocation of a node number, and setup / liaison with the node is handed off to the HUB admin. I do spend time helping others, often it can be someone who has been a member of this network or an othernet for quite some time and then something comes up and they ask for help. I mention this as it's not
    like all my 'helping others' efforts are based around brand new nodes these days. That 'helping others' stuff ebbs and flows also.. hard to predict when
    it will occur.

    - is this happening now in any shape/form?

    I don't believe so, but I'm not sure.

    Hopefully the above info / reply will help clarify :)

    The most important task is updating and distributing the nodelist.

    [snip]

    I don't see any reason why the nodelist cannot be updated
    collaboratively. E.g. use a private SVN / Git / Mercurial / Fossil repository and give every network write access.

    If we were to run with the established practices of NETs supplying a nodelist segment for compilation into a nodelist then this may address your comments about collaboration in this area? Is it needed - unsure. Could it be done - yep. I do have some ideas around decentralized nodelist management but it
    would take some dev work to implement them.

    - what does an acceptable level of service look like for all this stuff?

    Level 8 would be nice ;)

    I'm not an IT person by trade but I'm guessing this good - right? :)

    - are we trying to fix something that is viewed as not broken, or is it broken? (I may be a bit harsh in my terminology using broken but you get the idea)

    At the moment it is bus factor 1-ish, but as long as Avon is not broken and keeps updating the nodelist, I wouldn't call it broken. It depends
    on the criteria you have. If the criteria were scalability and fault-tolerance, you could call the current process broken. On the other hand, even if Avon would shutdown all his nodes without any warning, the network would not cease to exist.

    I don't think anything is really broken either. I think if it were then new nodes would not be coming in / others coming off. Chatter in the ehcos would
    be nil etc.. and that's plainly not the case right now... so if broken were
    to be the absence of activity etc.. then yep, were *not* broken :)

    That all said, there will be different, probably better ways to do things,
    but all dependent on what is agreed success / ideal state looks like. I can't help but think we should be kicking that topic around some more and fleshing out that bit first before jumping to solutions. My 2 cents..

    @Alterego: I'm not sure if fsxnet should be seen as the successor to Fidonet. Maybe it would also make sense to start a new Fidonet in a
    truly decentralized and collaborative fashion?

    I'm more than happy for fsxNet to take the lead in experimenting with approaches to decentralization and collaboration. It's really an area of interest to me and others. I also am keen on how we can better implement encrypted mesh networking ideas into this discussion. But to do so we need agreement on what that means by all involved. I think I may have already said that :)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)
  • From Oli@21:1/100 to Avon on Mon Dec 2 11:24:43 2019
    On Mon, 2 Dec 2019 12:42:15 +1300
    "Avon -> Oli" <0@101.1.21> wrote:

    I'm more than happy for fsxNet to take the lead in experimenting with approaches to decentralization and collaboration. It's really an area
    of interest to me and others. I also am keen on how we can better
    implement encrypted mesh networking ideas into this discussion. But
    to do so we need agreement on what that means by all involved. I
    think I may have already said that :)

    Could we create a dedicated echomail area for this (and all the things that were mentioned in the thread)? FSX_NETWORK, FSX_OPS, FSX_META or FSX_FTN, ...?

    I find it hard to follow the discussions in FSX_GEN and I really would prefer a
    low-traffic area. It also would work much better as an archive.

    ---
    * Origin: (21:1/151)

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)
  • From Avon@21:1/100 to Oli on Tue Dec 3 12:15:17 2019
    On 02 Dec 2019 at 11:24a, Oli pondered and said...

    Could we create a dedicated echomail area for this (and all the things that were mentioned in the thread)? FSX_NETWORK, FSX_OPS, FSX_META or FSX_FTN, ...?

    I find it hard to follow the discussions in FSX_GEN and I really would prefer a low-traffic area. It also would work much better as an archive.

    More than happy to do this, and good idea. I'll work on something over the
    next 24 hours. Once set up I'll forward the older messages from this thread into the new echo. Hopefully that will set us up nicely to discuss, plan and expand on the topics being mooted.

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: fsxNet HUB (21:1/100)
  • From Vk3jed@21:1/109 to Oli on Fri Dec 6 16:15:00 2019
    On 12-01-19 18:19, Oli wrote to Avon <=-

    I don't see any reason why the nodelist cannot be updated
    collaboratively. E.g.
    use a private SVN / Git / Mercurial / Fossil repository and give every network
    write access.

    Or MakeNL, it is designed for distributed nodelist maintenance. :)

    At the moment it is bus factor 1-ish, but as long as Avon is not broken and keeps updating the nodelist, I wouldn't call it broken. It depends
    on the criteria you have. If the criteria were scalability and fault-tolerance, you could call the current process broken. On the
    other hand, even if Avon would shutdown all his nodes without any
    warning, the network would not cease to exist.

    I think Avon just needs to be careful that burnout doesn't sneak up on him, and distributing some tasks might be prudent. Also, what happened to the Amateur Radio 44net (44.x IP allocations and network) is a lesson. If something should happen to Avon (I hope not!), how can we ensure network continuity?

    Background: What happened on the 44net was that Brian Kantor, who looked after many key functions passed away suddenly and unexpectedly last week. While there was some work begun on delegating various administration tasks, it was early in development, and a number of things are on hold, while they sort out what to do.


    ... If you want a place in the sun be prepared for a few blisters.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)