[HN Gopher] Snitch - A friendlier ss/netstat
___________________________________________________________________
Snitch - A friendlier ss/netstat
Author : karol-broda
Score : 305 points
Date : 2025-12-23 01:03 UTC (21 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| coppsilgold wrote:
| I always wondered how useful such tools are against a competent
| adversary. If you are a competent engineer designing malware,
| wouldn't you introduce a dormancy period into your malware
| executable and if possible only talk to C&C while the user is
| doing something that talks to other endpoints? Maybe even choose
| the communication protocol based on what the user is doing to
| blend in even better.
| tptacek wrote:
| 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]).
| entrop wrote:
| That search did not come up with much. Can you elaborate?
| alwa wrote:
| Not tptacek, but my search yielded this which seems
| relevant (to the network monitoring tool once named Bro,
| now Zeek):
|
| https://www.icir.org/mallman/pubs/APT07/APT07.pdf
|
| > _The "SH" state indicates that the remote peer sent a SYN
| followed by a FIN--however, the monitor never recorded a
| SYN-ACK from the local peer. At first glance, this would
| seem to indicate a scanner that is trying to make
| connection attempts look as real as possible in the hopes
| of not triggering an alarm. However, such connections can
| also indicate a vantage point problem whereby the monitor
| is not observing outgoing traffic from some hosts. While in
| general the monitor placement at LBNL can observe both
| incoming and outgoing traffic, there were periods of time
| where the traffic for some LBNL hosts would partially
| bypass the monitor. From a measurement perspective this is
| clearly undesirable._
| karol-broda wrote:
| 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
| ashtakeaway wrote:
| With a name like Snitch, it should be aimed at adversarial
| detection.
|
| Just my two snitches.
| gus_ wrote:
| 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/
| jcgl wrote:
| What makes ss different?
|
| In any case, interesting to think of shared libraries
| (specifically shared libc) as a risk here. Makes sense, but I
| hadn't thought about it before.
|
| That said, I'm having a hard time doing a threat model where
| you worry about an attacker _only_ setting LD_PRELOAD but not
| modifying PATH. The latter is more general and can screw you
| with all programs (doesn 't cover shell builtins, but it's
| not like those would just be one more step).
| gus_ wrote:
| ss obtains the connections information via netlink directly
| from the kernel (besides parsing /proc):
|
| https://manpages.debian.org/bookworm/manpages/sock_diag.7.e
| n...
|
| https://github.com/vishvananda/netlink/blob/main/inet_diag.
| g...
|
| Not many rootkits tamper the netlink channel, so in most
| cases it's a bit more reliable.
| jcgl wrote:
| Okay yeah, sure. So it's not intrinsically more reliable
| or anything, it's just not specifically vulnerable to
| LD_PRELOAD. And it's not clear to me why LD_PRELOAD would
| be a particularly interesting attack vector, but maybe
| that's just my ignorance.
| themafia wrote:
| It looks nice, and I don't see anything wrong with it, but I've
| been using iptraf-ng since forever and I think it has a slight
| edge here.
|
| Is it possible I've missed something from the demonstration video
| on that page?
| karol-broda wrote:
| thanks! snitch is closer to an ss/netstat replacement (sockets
| + processes) than a traffic monitor. traffic monitoring is
| planned, but not implemented yet.
| mikeryan wrote:
| 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
| wkat4242 wrote:
| There's also a Linux clone of little snitch, OpenSnitch.
| zormal wrote:
| There's also https://github.com/snitch-org/snitch with the
| AUR package name 'snitch'.
| stressback wrote:
| Seems like a fine name. Why would little snitch existing
| necessitate a name change?
| charcircuit wrote:
| Because it's potentially trademark infringement because it
| could confuse people.
| cretinoid wrote:
| Exactly right.
| consp wrote:
| Can you actually trademark a common word? (Serious
| question)
| janzer wrote:
| Yes, Apple, Windows, Amazon, Shell, Target, Dove, Ivory,
| Tide, Polo.
|
| (With help from Claude completing the list)
| satiated_grue wrote:
| Remember the trademark fights between Apple Music
| (Beatles) and Apple Computer? Interesting history.
| kalleboo wrote:
| Sosumi!
| Angostura wrote:
| Yes, but only for a fair tight class of business
| cretinoid wrote:
| 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?
| inejge wrote:
| > The names these people come up with are so embarrassing.
| And I'm not even talking about the meaning of 'snitch'.
|
| They should call it "rat" and be done with it.
|
| Besides, "snitch" works for Little Snitch -- I've always
| found it somehow endearing, although the bare word is
| unflattering.
| monster_truck wrote:
| It's not even a friendly word
| mrjay42 wrote:
| Wow that's so nice, would there be an equivalent for PC?
| (Windows or Linux)
| guessmyname wrote:
| 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/
| hwj wrote:
| I've been a long time Litte Snitch user. However, these
| days I'm just using LuLu: https://objective-
| see.org/products/lulu.html
| teruakohatu wrote:
| Why did you switch? Price? OSS? Or does LuLu have
| compelling features?
| hwj wrote:
| It's a mix of everything (in no particular order):
|
| - the author of LuLu is a security researcher; he also
| wrote "The Art of Mac Malware"
|
| - I already bought two versions of Little Snitch and
| wasn't willing to pay for the third one
|
| - contacting their support left a bitter aftertaste
| mrjay42 wrote:
| Thank you <3
| westurner wrote:
| dotfiles/scripts/netstatpsutil.py: https://github.com/westurn
| er/dotfiles/blob/develop/scripts/n...
|
| Textual or similar for a top-like mode would be cool someday
|
| scripts/lsof.sh does lsof from /proc/*: https://github.com/we
| sturner/dotfiles/blob/develop/scripts/l...
| karol-broda wrote:
| 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
| cyberax wrote:
| Nice! Couple of notes:
|
| 1. Can you highlight the currently selected row with a different
| background?
|
| 2. Maybe add optional reverse DNS lookups?
| karol-broda wrote:
| was thinking of adding more customizable theming, like
| highlighting the background and reverse dns resolution was
| released earlier
| fulafel wrote:
| The demo recording-as-code seems cool (in
| https://github.com/karol-broda/snitch/tree/master/demo)
| karol-broda wrote:
| thanks :), havent really seen this much in other projects
| aos wrote:
| I love the recent increase in TUI-based tooling. This looks cool
| - will check it out!
| mabedan wrote:
| 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
| 4gotunameagain wrote:
| Accessibility is a great thing to have and strive for, but it
| cannot be the number one design principle.
|
| Imagine if everything around us would be designed for blind
| people.
| austinjp wrote:
| I suspect blind people imagine that a lot.
|
| The idea is to design for all (or as many as feasible),
| it's not a binary either/or.
| 4gotunameagain wrote:
| You cannot design a lot of TUI for all. Should we abandon
| TUI entirely ?
| TZubiri wrote:
| Not necessarily designed for, but accessible to.
|
| Additionally in sysadmin, blind-users are not just some
| random group, the ability not to use one's eyes is central
| to the Command Line Interface. You could always in theory
| get by with just a keyboard and a TTS that reads out the
| output, it's all based on the STDIO abstractions that are
| just string streams, completely compatible and accessible
| to blind, and even deaf users. (Unlike GUIs)
| WhyNotHugo wrote:
| TUI tools are generally as accessible as the terminal on
| which they run.
|
| GUI apps are much trickier. They require that the developer
| implement integration with accessibility frameworks (which
| vary depending on X11/Wayland) or use a toolkit which does
| this.
| jcgl wrote:
| How are TUI tools just as accessible as the terminal? Take
| a visually-simple program like neomutt or vim. How does a
| vision-impaired user understand the TUI's layout? E.g.
| splits and statusbar in vim, or the _q:Quit d:Del..._
| labels at the top of neomutt. It seems to me like the TUI,
| because it only provides the abstraction of raw glyphs, any
| accessibility is built on hopes and dreams. More
| complicated TUIs like htop or glances seem like they would
| be utterly hopeless.
|
| When it comes to GUIs, you have a higher level of
| abstraction than grid-of-glyphs. By using a GUI toolkit
| with these abstractions, you can get accessibility (
| _relatively_ ) for free.
|
| Open to having my mind changed though.
| hombre_fatal wrote:
| GUI kits like AppKit or GTK have built-in accessibility
| features like standard components (input fields, dropdown
| boxes) and view hierarchy that interact with accessibility
| tools for free. It's the main upside of a GUI.
|
| TUIs are tricky.
|
| I think TUI accessibility generally involves rereading the
| screen on changes (going by macOS VoiceOver). It can
| optimize this if you use the terminal cursor (move it with
| ansi sequences) or use simple line-based output, but pretty
| much zero TUIs do this. You'd have to put a lot of thought
| into making your TUI screenreader friendly compared to a
| GUI.
|
| The thing going for you when you build a TUI is that people
| are used to bad accessibility so they don't expect you to
| solve the ecosystem. Kind of like how international
| keyboards don't work in terminal apps because terminal
| emulator doesn't send raw key scans.
| rockskon wrote:
| I just want a single tool that has a known, generalized set of
| capabilities on just about every distribution.
|
| Systemd's obsession with remaking every single wheel in Linux has
| been aggravating enough. Please don't do it again.
| Underphil wrote:
| No-one is stopping you from using netstat.
| beaudidly wrote:
| What's with the hostility of someone making something that's
| useful for themselves and sharing it with others?
| hn_throw2025 wrote:
| 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.
| rockskon wrote:
| Not what I meant. Systemd has been replacing a bunch of
| commands too. Not just the init system.
| jcgl wrote:
| 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.
| rockskon wrote:
| 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.
| jcgl wrote:
| 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.
| winternewt wrote:
| That's not a feature that the developer has control over. All
| they can do is try to develop a good tool.
| stressback wrote:
| prettyneat.gif
|
| Thanks for sharing
| poemxo wrote:
| I don't like the name but I like the TUI, connection monitoring
| is perfectly handled by a TUI!
| karol-broda wrote:
| thanks, but what don't you like about the name?
| wittjeff wrote:
| I can't read as fast as your demo GIF. Just infuriating.
| karol-broda wrote:
| it's all code, if you want you can make a pr with adjustments
| to the demo
| PunchyHamster wrote:
| 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.
| petepete wrote:
| 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.
| mr_mitm wrote:
| Depends on the use case.
|
| If used in scripts, ubiquity and speed can be important. Then
| again, the output of ss is not ideal for script processing.
| PunchyHamster wrote:
| That's the problem, it's not good for humans, it's not
| great for scripts
| PunchyHamster wrote:
| But it's not tradeoff! You can make default view useful
| without trading versatility.
|
| Another annoying part is not supporting json or even CSV.
| Some tools got modernized with it (like iproute2 tool set),
| but for these you might as well do /proc scraping yourself...
| sureglymop wrote:
| That's true in general. But default view is still
| subjective. The challenge probably lies in recognizing the
| larges subset of your user base that would like it to be a
| certain consistent way.
| fn-mote wrote:
| Very curious what is wrong about the rg defaults.
|
| The only one I change is to add `--no-ignore`.
| jcgl wrote:
| 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
| ycombiredd wrote:
| Hah yes, I've come to unashamedly - by muscle memory since
| the 1990's - find myself always typing 'ps auxw[w...]', where
| [w...] is some arbitrary number of w's depending on how heavy
| my index finger feels at the moment of typing.
| jiveturkey wrote:
| > 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 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.
| jcgl wrote:
| > love your blog, thanks for the link.
|
| 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.
| laserbeam wrote:
| > 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
| ectospheno wrote:
| Don't "netstat -utan" and "ss -utan" show basically the same
| thing?
| mzi wrote:
| "utan" means "without" in Swedish, so I use the more flowery
| "-tulpan" as my mnemonic. It means tulip.
| TZubiri wrote:
| One aspect of sysadminship that I find cute (but suboptimal) is
| how we memorize this strings of commands that were clearly not
| quite designed to be used in that manner. A slightly related
| example is how our intents in our mind end up having commands
| that don't resemble at all what we actually want, creating a map
| between intent and command that is almost exclusively arbitrary
| except for some obsucre etymological origin that might or might
| not help you remember the command in a time of need.
|
| For example:
|
| Intent: "create a file"
|
| Command: "touch $FILE"
|
| As it happens, touching a file doesn't mean to create, it was
| supposed to touch to modify the last access date, like a null op.
| But now if you want to create a file you do that.
|
| Intent: "Print a file contents to screen" Command: "cat $FILE"
|
| Is this a reference to a feline? some slang for printing or
| reading? No it's short for concatenate, but if you pass just one
| argument instead of 2, it prints the concatenation of 1 file and
| nothing.
|
| Even something as simple as
|
| Intent: "Rename a file" Command: "mv $FILE"
|
| Of ocurse there's the fact that moving a file and renaming the
| file are very similar if not identical in most FS/OS, but also,
| the slight change from a word to a proper-name style command
| already creates a style of command line interaction that was very
| natural in the 80s, but is now being reinvented with the advent
| of more powerful language decoding technology. So even:
|
| Intent: "Copy a file" Command: "cp $FILE"
|
| Now to the topic, you can see how my relationship with ss is the
| mapping:
|
| Intent: "See a list of open ports" Command: "ss -tulnp"
|
| Which I remember mnmemotecnically because it is close to -tulip.
| This is similar to ps -aux in that the command includes a set of
| options and I remember it mnemotecnically ("auxiliary" or
| "auxilio"), and I use the options even when I don't need them,
| modifying the options from that baseline if needed, like removing
| "a" to get just the current user's processes.
|
| That said. I don't know if the future is going to be "better"
| alternatives to old tools, but rather deconstructing or making
| use of the concept of "binary":"command", running man and --help
| has never been an optimal solution, and let's be honest, kids
| nowadays are googling, stackoverflowing and chatgpting their
| intent in order to get a magical command.
|
| No easy way to improve upon this at the userspace level, the OS
| model of delegating control to binaries based on a hierarchical
| command structure is sensible, and "magic", or sharing commands
| across binaries without a clear ruleset would be too opaque. But
| I feel that creating new tools while barely revolutionizing the
| way they work is too small an incremental change, it adds more
| noise, I'm not sure that ss2 or network-manager instead of
| wpa_supplicant is a better outcome, now you are just linearly
| increasing the cognitive demand of new sysadmins linearly with
| time.
|
| Sorry to be a bummer.
| TZubiri wrote:
| 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.
| pdimitar wrote:
| 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
| Melonai wrote:
| 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.
| PhilippGille wrote:
| They fixed it 6 hours ago, but it's not in a release yet:
| https://github.com/karol-broda/snitch/commit/7fdb1ed477894f1...
| karol-broda wrote:
| i fixed it and created a release so building from @latest
| should work now
| reimuwu wrote:
| Would you consider vendoring dependencies? It would be
| helpful for offline builds, especially when writing packaging
| scripts :D
| hashstring wrote:
| Name can be friendlier, tui looks nice!
| stavros wrote:
| 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.
| karol-broda wrote:
| yea i was kinda fed up
| hwj wrote:
| The README doesn't mention this, but on macOS it's also available
| via brew:
|
| `brew install snitch`
| karol-broda wrote:
| 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
| emaro wrote:
| I didn't verify anything, but used the brew install and the
| installed cli at least looks and behaves like I expected from
| this HN post.
| rramadass wrote:
| 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/
| karol-broda wrote:
| this is supposed to be an actually maintained terminal utility
| for viewing ss/netstat data
| coolbean wrote:
| 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.
| karol-broda wrote:
| that actually is planned for a future version
| INTPenis wrote:
| 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.
| karol-broda wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-23 23:01 UTC)