Off topic: for those thinking it was a programming language optimized for a phone (like I did) the only one I’ve seen come close to being usable is J (APL derivative). I’ve been able to solve quite a few advent of code challenges this way:
I suspect inherited sockets across forks don't exhibit this, if a test done by Nicholas Grilly described on the haproxy mailing list [0] is to be believed (no code though, but shouldn't be hard to reproduce).
One thing that makes doing this in haproxy difficult is that there is not really any shared state between the parent and child processes, so the child doesn't have a good way to know which file descriptor maps to which listening endpoint in the configuration, since the child pretty much throws its entire state away and reads the config file anew. It's not that there can't be any shared state, but that's not how it's been architected. Finding out the endpoint via something like getsockname(2) might be doable, but the mapping of listening endpoints to listen configuration blocks isn't one-to-one, so it's actually "safer" (from an amount of code standpoint) to use SO_REUSEPORT and let the OS handling the shared listening.
Seems that, unlike Sidekiq, this starts as a heavily commercial solution, and it shows. Landing page has a pretty big "Buy Pro" call-to-action button. Features like support for notifying slack/etc I'd expect to be present in a free version. Open source feels more of an afterthought. I don't feel comfortable using even the free version, simply because if the project fails financially, it is likely to be dropped altogether.
The fact that there is a commercial version is proof that mperham wants and expects the project to continue sustainably.
That said, the open source version provides more than Monit in a better, easier to deploy package. I think that right there is incentive enough to use it. Plus, if you want to fork it and add your own specific notification channels, here's the source:
I agree that ease of use is the strongest reason to use this.
Just because mperham wants the project to be sustainable doesn't guarantee it. However, if sidekiq Pro would have failed, Sidekiq would easily survive simply because of huge open source community. With inspeqtor it's not so clear.
"Route alerts to your team chat room" is listed as a Pro feature. Any PR implementing it is unlikely to be merge in. And creating a separate fork for a relatively small feature should not really be an answer to an open-source project.
Long story short: I'm new to Go and wasn't sure how to manage the codebases for both an OSS product and commercial product together so I built the two in tandem to work out the kinks. Since the commercial product was already written, why not sell it from day one?
The OSS product is targeted to small teams, individuals and hobbyists. Pro was designed to target larger teams and the features they would need.
