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 is a drum I like to bang[0]), because unix tools only deal in usually-text bytestreams without any higher level of abstraction, consumers of those tools end up tightly coupled with how output is presented. Without any separation between data and its representation, the (default) representation is the tool's API. To change the default representation is to make a backwards-incompatible API change. A good example of this is how ps aux truncates longer than like 7 characters.

[0] https://www.cgl.sh/blog/posts/sh.html

"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."

IMHO this would be one of the many arguments in favor of compiling from source rather than using "binary packages"^1

https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2...

   (
   printf '/int state_filter = 0;/a\\\n'
   printf 'state_filter = (1 << SS_LISTEN) | (1 << SS_CLOSE);\\\n'
   printf 'show_processes++;\\\n'
   printf 'show_queues = 0;\\\n'
   echo
   echo "s/dhalBet/q&/"
   printf '/switch (ch) {/a\\\n'
   printf "case 'q':show_queues=1;break;\\\n"
   echo
   )|sed -i -f/dev/stdin misc/ss.c

It also adds adds a -q option to display the queues

1. IMHO this is also an argument against "cloud computing", i.e., using someone else's computers where pre-installed kernels and binary packages are the norm

> I know picking the right defaults is hard

I think we understand that UX problem much better now than developers did back in the 70s. In general, not just for ss/lsof

I think the same applies for many of the new breed of command line applications like fd and ag/rg.

Being able to use them intuitively trumps ubiquity, speed or features.

Don’t “netstat -utan” and “ss -utan” show basically the same thing?

There's also a Linux clone of little snitch, OpenSnitch.

Seems like a fine name. Why would little snitch existing necessitate a name change?

i am not sure if this would need a different name, you may just have this association because you are using little snitch, but they have completely different use-cases. for now this will just be a way to display ss/netstat data in the terminal in a nice way

Wow that's so nice, would there be an equivalent for PC? (Windows or Linux)

I immediately thought of that too. The names these people come up with are so embarrassing. And I'm not even talking about the meaning of 'snitch'. But you already have a tool within the same IT area that is basically named the same. Why the hell would you do that? Aren't there other words in the dictionary?

thanks :), havent really seen this much in other projects

Are they as accessible as GUI though (genuine question)

UI libraries have a lot of features for allowing people with disabilities to “read” and interact with the screen in efficient ways

thanks! snitch is closer to an ss/netstat replacement (sockets + processes) than a traffic monitor. traffic monitoring is planned, but not implemented yet.

fair point. ss stays the default on servers because it is already installed. snitch is for workstation/homelab debugging when i want quicker filtering and selection. also, i do not show send/recv yet, but if i add it later it will be optional (compact mode / toggle) so it fits in split panes.

this is supposed to be an actually maintained terminal utility for viewing ss/netstat data

thanks, but what don’t you like about the name?

They declared their module with just their package name without a URL, it got fixed a few hours ago.

I find it a bit interesting that Go even allows you to declare `module barename` in go.mod even though it loves breaking so many things if you do so. I sometimes try doing it for completely private projects but I always just declare some URL in the end, it's a weird anti-pattern in my opinion.

They fixed it 6 hours ago, but it's not in a release yet: https://github.com/karol-broda/snitch/commit/7fdb1ed477894f1...

i fixed it and created a release so building from @latest should work now

At the very least, these tools should not parse /proc to obtain information of processes or connections. It should be the last option.

Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc functions like readdir(), open(), stat(), etc. kernel rootkits can hide whatever they need, but the common functionality is also to hide data from /proc.

That's why netstat, ps, *top or lsof are not reliable tools if the system is compromised. ss is a bit different and is a bit more reliable.

In this case, snitch is written in Go, which doesn't use the libc functions, so probably it'll be able to obtain information from /proc even if hidden by a LD_PRELOAD rootkit.

Another option would be to compile the binary statically.

Anyways, these tools are not meant to unhide malicious traffic or processes, so I think detecting beacons, inspecting traffic, etc, is out of the scope.

Resources:

https://github.com/gustavo-iniguez-goya/decloaker

User-space library rootkits revisited: Are user-space detection mechanisms futile? - https://arxiv.org html/2506.07827v1

The Hidden Threat: Analysis of Linux Rootkit Techniques and Limitations of Current Detection Tools - https://dl.acm.org/doi/10.1145/3688808

https://matheuzsecurity.github.io/hacking/bypass-userland-ho...

https://ops.tips/blog/how-is-proc-able-to-list-pids/

agreed on the limits. snitch isnt aimed at adversarial detection; its a local debugging/inspection tool. a competent attacker can blend in by design, so this isnt meant to be a standalone security control

Tools like these aren't really intended for adversarial environments, and pure network tools that are designed for real adversaries have a really spotty track record (good search: [bro vantage point problem]).

was thinking of adding more customizable theming, like highlighting the background and reverse dns resolution was released earlier

I've just connected this to some other thought on Android app marketplaces.

Even in operating systems as distant as Android, we still have the phenomenon of using proper_names instead of natural names.

If you want a taxi or a cab, you don't ask your OS to get you a taxi or cab, you ask it to use the Uber binary.

In the 2000s it wasn't clear that this was going to be the case, the famous example of the pets.com domain was a wrong bet that natural names would somehow be important.

Instead natural names are only important when used through an obscure privately controlled algorithm like Google or StackoverFlow or ChatGPT, if you want to say "flights to Greece" instead of "Oobloo greece", you need a magical black box in the middle.

that actually is planned for a future version

yea i was kinda fed up

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

it’s all code, if you want you can make a pr with adjustments to the demo

Ironic choice of example…

Before systemd presented a generalised interface, there were significant differences in the init and service management systems between the popular Red Hat and Debian families of distros.

No-one is stopping you from using netstat.

What’s with the hostility of someone making something that’s useful for themselves and sharing it with others?

That's not a feature that the developer has control over. All they can do is try to develop a good tool.