For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more tarekmoz's commentsregister

Yeah we did not ship a plugin for e-mail alerting - the builtin plugins are : http://circus.readthedocs.org/en/latest/for-ops/using-plugin...

But writing a new plugin is very easy, see : http://circus.readthedocs.org/en/latest/for-devs/writing-plu...

We would be happy to add in the built-in collection new useful plugins contributed by the community


Author of Circus here.

Major differences:

* Circus uses ZeroMQ, Supervisor uses XML-RPC. * Circus is Python 3 compatible, Supervisor is Python 2 only * Circus will let you manage sockets - see http://circus.readthedocs.org/en/latest/for-ops/sockets/


Thanks for the clarifications. Just for the record it seems that Supervisor will roll out Python 3 support soon https://github.com/Supervisor/supervisor/issues/110. It's good to have it here and now though.


That's great to see Supervisor is moving forward on the Python 3 support.

Scott is actually the person who ported Circus to Python 3, so double kudos for him.


When I last compared them, circus looked more specific to managing something like wsgi workers while supervisord looked a little more "general-purpose".

This was probably a wrong or overly simplified conclusion, but I know supervisor and it hasn't let me down yet - so for now I see no compelling reason to switch. Maybe it's one of those "you just have to try it" moments? :)


Supervisor is solid and mature, that's for sure. If not for the sockets feature, I would say that you would want to move to Circus if:

- you need python 3 - you have a complex start/stop sequence where you need to add some custom code - you manage many servers and want to quickly jump from one to another in the same web dashboard / CLI.

Otherwise, they both provide roughly the same things I'd say


same here


The first app that comes to my mind is using those for a secured messaging protocol.


It's not listing Cobol.


That's because Cobol programmers probably make an order of magnitude greater income than on this chart. The only people who still write Cobol from my understanding are people who continuously update banking mainframe software. Government mainframes, etc. Usually these days you are apprenticed by someone with years of experience because of how difficult it is to obtain old documentation etc.


A vocational school here in Sweden recently started offering a 1 year Cobol degree, ostensibly after demand from the banking and insurance sector.


yeah that's why I mentioned it. Back in college, right before the year 2k, we had a special Cobol course they added just to get people some 2k jobs. I recall one guy who's still doing Cobol most of his time, working on old software like traffic lights systems (!)


It's off the chart.


If you speak french, this is way funnier: funny review about a giant swiss army knife - http://www.amazon.fr/Wenger-19201-Couteau-suisse-g%C3%A9ant/...


The UK version of this was going to be my recalled suggestion: http://www.amazon.co.uk/gp/aw/d/B000R0JDSI


I have been remote for 10 years. The secret not to get nuts is to interact online with colleagues as often as possible.

"From the employer’s perspective, you’re risking burning yourself out if you work 50-60 hours a week"

mmm... 50 hours is pretty common in the software industry, and being remote makes it easier not to burn out in fact because you're not losing time in commutes and in loud open spaces where you can't hear yourself coding.

In any case it's quite hard to define a number of hours per weeks. Building software is done by waves. You can spend a 70h week because of a production push that goes wrong, then a very calm week. So don't take those numbers/week too seriously imo.


50 hours is common in _startups_, not the industry as a whole.


50 hours a week is pretty common for companies that produce commercial software, startup or no. Some segments (games, for example) are more.


> I guess the idea here is to aggregate Circus events in a multiserver environment.

Yeah that's the basis for it. We're planning to add a cross-server feature, so a single CLI can handle processes across several boxes transparently

There's a branch but we've lacked of time to finish it yet. Soon I hope.


Whatever the python socket module supports, we can support.


Circus author here.

I am interested in any form of feedback on the issues you had. Falsely detecting a work crash sounds very weird and unprobable because Circus uses the system PID list to check on processes - so I wonder what happens in your case.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You