Live data from Hacker News

Snitch – A friendlier ss/netstat

github.com

81–90 of 109 posts

Re: Snitch – A friendlier ss/netstat

#81
I've gotten used to ss now, and I quite like it, I just wish there was an option to not show the send/recv numbers. I never use them and the width is already so wide that the output barely fits into most terminals when you have them split vertically on a laptop screen.

That said though, I'm not going to install snitch. The thing about ss is that it's already there, on every server I manage. And I definitely do not need a TUI for this.

Snitch is something you might install in your homelab, or your workstations. But ss is still the default when you provision a lot of servers.

Re: Snitch – A friendlier ss/netstat

#82
post #69

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

Re: Snitch – A friendlier ss/netstat

#83

An old classic powerful network tool; Netwox (i.e. Network Toolbox with more than 200 tools) and Netwag (Tcl/Tk GUI) - https://ntwox.sourceforge.net/ and https://ntwag.sourceforge.net/ Howto Guide - https://anto.online/mastering-netwag-guide/

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

Re: Snitch – A friendlier ss/netstat

#84
post #62

Earlier quoted context omitted.

Not what I meant. Systemd has been replacing a bunch of commands too. Not just the init system.

Those additional programs can be freely chosen by distros and/or users. So each of them has to stand on their merit. Though of course they do get some built-in credibility by coming from the systemd project. But for the most part, I think systemd software just tends to have competitive offerings with nice interfaces.

I'm annoyed at it replacing resolvconf. At reboot. At date. At logging. At cron. At ntpd. At network configuration scripts.

Some of these I'm sure make life easier for maintainers. Others just feel like change for the sake of change. Breaking workflows because someone wanted to design a better wheel.

Re: Snitch – A friendlier ss/netstat

#85
post #10

Nice! Couple of notes: 1. Can you highlight the currently selected row with a different background? 2. Maybe add optional reverse DNS lookups?

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

Re: Snitch – A friendlier ss/netstat

#86
post #51

Earlier quoted context omitted.

Yes, Apple, Windows, Amazon, Shell, Target, Dove, Ivory, Tide, Polo. (With help from Claude completing the list)

Remember the trademark fights between Apple Music (Beatles) and Apple Computer? Interesting history.

Sosumi!

Re: Snitch – A friendlier ss/netstat

#88
post #8

When I saw this headline I assumed it was Little Snitch an existing network monitor and firewall for Macs. Might need a different name. https://www.obdev.at/products/littlesnitch/index.html

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

Re: Snitch – A friendlier ss/netstat

#89

I've gotten used to ss now, and I quite like it, I just wish there was an option to not show the send/recv numbers. I never use them and the width is already so wide that the output barely fits into most terminals when you have them split vertically on a laptop screen. That said though, I'm not going to install snitch. The thing about ss is that it's already there, on every server I manage. And I definitely do not ne…

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.

Re: Snitch – A friendlier ss/netstat

#90
post #62

Earlier quoted context omitted.

Those additional programs can be freely chosen by distros and/or users. So each of them has to stand on their merit. Though of course they do get some built-in credibility by coming from the systemd project. But for the most part, I think systemd software just tends to have competitive offerings with nice interfaces.

I'm annoyed at it replacing resolvconf. At reboot. At date. At logging. At cron. At ntpd. At network configuration scripts. Some of these I'm sure make life easier for maintainers. Others just feel like change for the sake of change. Breaking workflows because someone wanted to design a better wheel.

Other than logging (journald is one of the few truly core systemd components), these are all basically independent programs chosen by your distro. As such, each is best evaluated independently. Let's give it an honest shot:

- resolv.conf: systemd-resolved is not unique here in providing a stub resolver and not just NSS functionality (it's been years, but isn't unbound often the same way?). And if you want to have systemd-resolved but not have its stub used in resolv.conf, you're free to do so! Just remove the symlink that is /etc/resolv.conf and replace its contents with whatever you choose.

- cron: systemd timers provide an alternative to cron. You're still allowed to create cron jobs and use cronie (or whatever traditional cron implementation) you like.

- ntpd: leaving aside the fact that most distros (I think?) nowadays use chrony rather than ntpd or systemd-timesyncd, you're likely free to switch to chrony or ntpd depending on your distro. Afaik, this isn't a daemon with deep system integration, and you should be able to plug-and-play without much issue.

- network configuration scripts: What're you comparing systemd-networkd to? NetworkManager? Debian's ifupdown scripts? RH-family's network-scripts? In any case, network management systems tend to be pretty pluggable (much like in the case of your cron daemon). You can even have them live side-by-side, managing different interfaces, e.g. have NetworkManager do WLAN, while systemd-networkd does Ethernet interfaces.

I don't know any of the story behind timedatectl, so I'll avoid opining on that one.

But generally, it really seems like each of these components is as pluggable and freely-choosable by a distro as one could reasonably hope for. And, like you acknowledge, they end up likely getting chosen because it's easier for distro maintainers. Which is kind of a big deal, imo. But if you don't like your distro's choice, it makes sense to complain to your distro.

In general, I think your suggesting that these new-ish (most of which are no longer very new) components were just made for the hell of it, I'd encourage you to look a little deeper into what they offer compared to the incumbents. For starters, they generally work together pretty cohesively, e.g. systemd-networkd and systemd-resolved do some mutual coordination stuff that's pretty nice. Systemd timers have numerous nice properties compared to cron. Etc.

Again, you (or your distro) are free to take or leave these components, since they can be picked on their own. But an analysis of "these new components from the systemd project 1) are forced on me, 2) exist primarily for the sake of change" seems both incorrect and uncharitable.

Post reply on HN