<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 3/8/19 7:08 AM, Axel Beckert wrote:<br>
    <blockquote type="cite"
      cite="mid:20190308150849.GH10429@sym.noone.org">
      <pre class="moz-quote-pre" wrap="">Hi,

On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote
community  contributions.
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I think you meant CVS instead of VCS. VCS (Version Control System) is
the general term for CVS, SVN, Git, Mercurial, etc.

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Git, specifically GitHub, has replaced SVN as the best thing to
promote community contributions, and I think it would be
beneficial if the official Xymon code repos are migrated to
GitHub.
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Definitely, but it's also not the only thing which is needed for
getting contributions from external contributors. It's also a social
thing.

Reviewing and accepting contributions — or maybe even giving
trustworthy contributors commit access is also necessary for a FLOSS
project. But as far as I can tell, this happens in the Xymon project,
although not on a daily base.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">but github would allow the community to report issues,
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
SF does allow that, too, it's just not enabled for the Xymon project
on SF. Example of an SF project where it is enabled:
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/nfsen/bugs/">https://sourceforge.net/p/nfsen/bugs/</a>

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">provide updates/patches via pull requests,
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Exists on SF, too, example: <a class="moz-txt-link-freetext" href="https://sourceforge.net/p/nfsen/patches/">https://sourceforge.net/p/nfsen/patches/</a>

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">and download either released versions via the tags
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Possible, too, example:
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27">https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27</a>

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">if necessary or the latest code via the 'develop' (or
whatever) branch.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master">https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master</a>
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk">https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk</a>

Don't get me wrong: I think SF degraded from once the best place to
host FLOSS to a website with tons of outdated trash and the most
horrible UI I ever saw from a code hosting site. Not to mention that
it is far too overladen with ads and popup.

My personal preference in VCS hosters is also GitHub as — from my
point of view — they currently provide the best user experience. OTOH
there might be some qualms about Github being not completely open
source and being owned by Microsoft.

And with regards to being dead or not: Development greatly sped up
when J.C. Cleaver took over release management, but it indeed seems to
have stalled a little bit again. Then again, IIRC J.C. mostly took
over release management so that Henrik can focus on long-time
development. And if there is not much to fix in the current stable
releases, not having a stable release every few months is not
necessarily "dead", but might also be "stable, no relevant open
issues".

(And yes, I'm still hoping and waiting for IPv6 support, too,
especially in xymonnet-based checks. Reporting to IPv6-only servers is
no issue though, if you anyways use stunnel to encrypt the
client-reporting traffic.)

                Kind regards, Axel
</pre>
    </blockquote>
    I've been using Xymon and it's predecessor BB, since 2002,
    administering *IX systems since the mid 80's and Linux since '93. <br>
    <br>
    Xymon is far from dead and is most definitely more useful, flexible
    and stable than most of the tools advocated by the kewl kids...
    Especially once extensibility via add-ons is factored in.  I'm not
    sure where the idea comes from that a tool has to be constantly and
    actively churning to be useful and current. <br>
    <br>
    IPv6... eh.  No matter how much people scream that "we gotta have
    it!!!", as has been mentioned, it's really not much used in real
    life.  And I think I can make that statement authoritatively... To
    pay my bills, I do enterprise level support for a major vendor.  I
    see hundreds of customer networks annually and see almost no ipv6
    and very little demand for it.  That said, it's most likely I good
    idea long term to get that kind of support into xymon.<br>
    <br>
    The politics of where to host repositories and what VCS to use... 
    ALL public hosting sites are a pain in one way or another and that
    is an entirely separate issue from the VCS technology used. <br>
    <br>
    GIT, CVS and SVN (to name only a few) inherently don't offer bug
    tracking. github does, gitlab does and so does sourceforge.  <br>
    <br>
    Much as a dislike what SF became, it tends to offer the most variety
    in the tools offered and we needn't mention the owner of github.<br>
    <br>
    Container monitoring, MIGHT be a good idea... If someone can say
    what specific things they want to be monitored/reported.... Not just
    holler they want monitoring.  <br>
    <br>
    When I can see something I need/want tracked and monitored, I do the
    following:<br>
    <br>
      1.)  Start from the assumption I'm neither the first only only one
    to do this -- Who else has done this before and what did they do? Is
    there something close to what I need? ( xymonton/deadcat anyone )<br>
      2.)  If I find I am a snowflake (not very often), then I look at
    what sort of test I need.  At this point, it's usually a VERY simple
    thing to test from a shell script.  Add that to $XYMONHOME/ext and
    the tasks file and I'm done.<br>
    <br>
    What I HAVE seen done around containers looks insane to me... 
    Something not too unlike strace on steroids and then passing the
    output to splunk like tools and things like graphite... Neither of
    which do I agree with especially for tools like Xymon.<br>
    <br>
    Given recent findings around security  of "off the shelf containers"
    that are loaded with insecure and unmaintained libraries, that LOOKS
    like something that might be a target... But it also makes me look
    with a very jaundiced eye at containers. If not the concept, then
    the practice and that's a whole different discussion.<br>
    <br>
  </body>
</html>