It's safe to say that any human capable of rotating that lego man, even just a single degree within his or her lifetime would cause the outer rim of the input gear to move at orders of magnitude beyond relativistic baseball[0].
I quote from your website: "Don't worry if you don't know what GitHub is, you only need to create an account." You don't appear to make any assumptions that your users understand that their notes will be published and readable by anyone on the internet.
Furthermore, your clarification: "Currently, Kobble stores all user data in secret GitHub Gists, under your account. Secret gists are not private." does not help because it does not explicitly state the fact that notes will be readable by anyone on the internet.
I can entirely sympathize with your comment here, but I'd like to try to quickly present a contrary perspective:
Indeed there are architectural trade-offs made by every monitoring system, and icinga2 makes some that we also have found to be frustrating: one such example that comes to mind for me personally is that icinga aims to maintain backwards compatibility with its historically-derived nagios configuration file syntax which is difficult to understand and hard to parse in an automated fashion.
On the other hand, there are exampls of architectural choices that I believe icinga gets right: It implements an approach to secure and authenticated metrics collection that virtually every other monitoring system leaves as an "exercise" for the user. It provides checks and alerts and notification thershholds by default, which many other monitoring systems don't.
We build monitor in a box to attempt to highlight one particular approach to using icinga 2 which we find works for us. We attempt to be systematic and through in our approach, aiming for a reproducible, Ansible based implementation that emphasizes modularity and code reuse. We invite everyone to try out our open source offering to decide for his or her self whether the benfits of running icinga 2 in this fashion outweigh the drawbacks.
The free version doesn't provide any visualizations other than what you see in the icingaweb dashboards. The icinga demo (not grafana) should give you an idea of what I mean: https://solutions.stacktile.io/demo
In the spirit of shameless self-promotion, I invite you to clone our git repo and see for yourself! :-)
Hi zbjornson, regarding your question about "Wondering what the free version uses if it doesn't include graphite for dashboarding": the answer is that free version just includes the icingaweb dashboards and not those implemented with grafana.
Also I'd like to clarify a possible misunderstanding: Monitor in a Box does not require that ansible be installed on all the servers. We only require that ansible be installed on the one machine that orchestrates the setup of Monitor in a Box.
Who else feels a sense of horrible dread and frustration that every minutiae of my (and your) online activity is recorded for eternity and exploited to the fullest extent?
“The thing we were terrified about when switching over to PC’s, was learning Windows, but it wasn’t as bad as we thought, especially because we spend the majority of our time in Adobe® Premier Pro and the interface is exactly the same.”
If you care at all about maintaining control over this kind of data, consider abstaining from facebook and running your own service e.g. owncloud or nextcloud.
Hi, Dan here again,
some of our visitors will hit our waiting queue today.
If it's any consolation, I can certainly appreciate the frustration some will experience due to this, but we're just bound by the reality of our wallet at the moment. We also mean no harm by inviting those in the queue to provide an email.
Since the purpose of our product is to give each user his or her own execution environment to freely explore the software that stacktile is helping to demonstrate, we need to give that user access to his or her own container.
Perhaps the confusion is coming from the fact that a stacktile workflow is more than "pre-known" static content -- it is markdown coupled to a an interactive, running shell process in which code can be executed.