From https://github.com/evilsocket/opensnitch/wiki/Why-OpenSnitch...:

> Why OpenSnitch does not intercept application XXX

>

> tl;dr

>

> - because we don't use eBPF.

> - a process is opening connections too fast (nmap for example, firefox sometimes...).

> - the system has a high load and we're unable to find the process in time.

> ...

They're both pretty bad for something so simple. Tons of dependencies, complexity that shouldn't be there and perplexing code.

evilsocket/opensnitch is worse but EBPFSnitch could also be a lot better.

If they're both "pretty bad for something so simple"... then it seems like a classic example of a problem that you could just release a solution for; then there would be a non-sucky solution available!

Unless it's actually not that simple?

You could at least make constructive criticism instead of just dismissively saying that all solutions suck. ("Tons of dependencies", "complexity", and "perplexing" are not actionable criticisms... they're highly subjective opinions.)

> Unless it's actually not that simple?

Recognising that given sufficient domain knowledge you could minimise and optimise dependencies and actually having that domain knowledge for this specific field are not the same thing. For the former, you just need to be a professional. For the latter, you need to be in luck for this specific subject.

You don't fix that by being snarky. Ironic, because in the last paragraph you do ask for constructive criticism! The least you could do is materially reciprocate in doing so.

I don't know anything about this project, but it's okay to criticize large dependency trees and complexity. It sounds like you're looking for suggestions on how to fix that or the other. Neither of those things is trivially fixable, they're pretty fundamental problems. Sometimes a rewrite can do it.

evilsocket/OpenSnitch is one of the cleaner code bases I have seen, especially for the functionality it implements. What other complexity are you alluding to?