91–100 of 109 posts
The README doesn't mention this, but on macOS it's also available via brew: `brew install snitch`
dont think this is in homebrew/core, brew install snitch may be a different package, could you paste brew info snitch output? if its not this project, i will add a note to the readme to avoid confusion. but i will be creating a homebrew cask soon
Earlier quoted context omitted.
Wow that's so nice, would there be an equivalent for PC? (Windows or Linux)
1. Linux → https://github.com/evilsocket/opensnitch 2. Windows → https://www.glasswire.com/ 3. Windows (open source) → https://github.com/henrypp/simplewall 4. Windows → https://safing.io/
it's weird that both lsof and ss defaults are so awful Like, ss without any options shows such arcane, rarely needed details as send/receive queue size but not the application socket belongs to . And omits listening sockets which is main use for such tools. I know picking the right defaults is hard ask but they managed to pick all the wrong defaults.
Don’t “netstat -utan” and “ss -utan” show basically the same thing?
When attempting to install through go: go install github.com/karol-broda/snitch@latest I get this error message: go: github.com/karol-broda/snitch@latest: version constraints conflict: github.com/karol-broda/snitch@v0.1.8: parsing go.mod: module declares its path as: snitch but was required as: github.com/karol-broda/snitch
i fixed it and created a release so building from @latest should work now
I wish there was a tool that also displayed current and accumulated transfer rate per socket/process. I use jnettop for this purpose, but I'm unhappy with its user interface.
I don't like the name but I like the TUI, connection monitoring is perfectly handled by a TUI!
Thanks for this! I can never remember the netstat arguments, and it's a bit crazy that it doesn't come with sane defaults, so this is going to be really useful.
I can't read as fast as your demo GIF. Just infuriating.
it's weird that both lsof and ss defaults are so awful Like, ss without any options shows such arcane, rarely needed details as send/receive queue size but not the application socket belongs to . And omits listening sockets which is main use for such tools. I know picking the right defaults is hard ask but they managed to pick all the wrong defaults.
Completely agreed. Not sure what the historical reasons for lsof and ss are, but unix tools are structurally in a hard place when it comes to having sensible defaults over the long term. Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time . New users and new use-cases come with time, and so what constitutes a "sensible default" changes. However (and this i…
however this breaks backward compatibility, as you noted. in the golden age of unix it was critical to maintain backward compatibility so that local tooling didn't magically break.
HP-UX seems to have an env var UNIX95 that affects XPG4 compliance in operation/output. Solaris always had a /usr/xpg[46] path (and /usr/ucb). GNU tools have POSIXLY_CORRECT. and so on.
I never liked using any of those because then you're on some other system, or in a break glass situation, and none of the tooling works as you expect. In the today world of a near monoculture of linux, it's fine I guess. And there's no reason today that complex commands like `ss` shouldn't be controllable via env var.
love your blog, thanks for the link.
Earlier quoted context omitted.
Completely agreed. Not sure what the historical reasons for lsof and ss are, but unix tools are structurally in a hard place when it comes to having sensible defaults over the long term. Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time . New users and new use-cases come with time, and so what constitutes a "sensible default" changes. However (and this i…
> change the defaults over time however this breaks backward compatibility, as you noted. in the golden age of unix it was critical to maintain backward compatibility so that local tooling didn't magically break. HP-UX seems to have an env var UNIX95 that affects XPG4 compliance in operation/output. Solaris always had a /usr/xpg[46] path (and /usr/ucb). GNU tools have POSIXLY_CORRECT. and so on. I never liked using a…
Thank you!
Configuring configuration via env var is a good historical example. I think that especially works nicely when you Buy An Operating System. You know, one that is created and provided by A Vendor. In principle, the vendor can architect a unified metaconfiguration system, e.g. one or several env vars that align behavior to a standard.
But I dunno if it would work so well to to hypothetically apply that tactic to a modern bazaar-based OS like Linux. Distros do amazing, valuable work to unify things, but modern Linux is basically a zillion software packages in a trench coat. So either the distro carries a zillion patches to have a few env vars, or the distro carries no patches and there are a zillion env vars. Either way, total cost of maintenance explodes.
Maybe when people say "text is the universal interface," they really mean that once you've released a textual interface, the interface becomes universal, unchanging for all time.