Very, very awesome! I love the per process table. How does that work?
CBM was a fine tool [0]. I think it's been basically abandoned though. It does only do per interface, but it seems like an earlier simpler iteration of this type of tool. It works by reading the stat tables in /proc/net/dev
I'd just throw our something I wrote a long time ago called fsbm [1] (fucking small bandwith monitor) which was a rewrite of CBM without curses. useful for logging to a file or to something without NCURSES support. Along the way I added support for network namespaces and just general other stuff. I use it frequently. You can pump it into i3-bar for example or such and such
I'm not sure how it works beyond that it reads /proc, but whatever it does it uses a whole lot more compute than nethogs does (which also displays per process and also uses /proc as the information source). This is fine for most of my machines, but for lower-specced machines I'll probably have to stick with nethogs[1]
If it the popey from podcasts he used to work at Canonical. Actually looking at this confused, popey also came up with the snap removal tool that is handy https://github.com/popey/unsnap
Maybe he has a love hate relationship with snaps lol
Yeah I would strongly bet it is the same Popey from the JB podcasts. Last I heard him he was pretty pro-Snap and was Snapping different projects for people, so this is completely in-line with my expectations. Seems pretty unlikely to be a coincidence :-)
Agreed. TFA author either currently or previously worked for Ubuntu, so it makes sense to me that they are a big proponent of Snap. Personally, I would rather build from source than install a Snap.
The only thing I like about this is the idea of the bandwhich tool.
The rest of it is adding more mechanism than is required for such a utility. I see so much these days where people can't see the simplest path to the solution of the problem and build complicated Rube Goldberg machines around them. They do nothing other than serve the ego of the person.
Give me a static bin and the sha256.
Edit: oh wait, the upstream already do that! Why all this?!?!?!?!
I personally enjoyed it because it seems like a good guide to publishing a snap, which... is a thing people do (and I've never seen a write-up detailing the process from start to finish).
I admit the submission title probably emphasizes the wrong portion of the content, but if you're not interested in building a snap, this is just not the right post for you.
Similar to bandwhich, I recently created a snap of my own bandwidth monitor, picosnitch [1]. However I was only able to get it working with classic confinement due to there being no snap interfaces for fanotify or BPF kfuncs. Unfortunately this meant it couldn't be published on the store.
I already packaged it for nearly every distro, but unfortunately most don't have dash [2] in their repos so the user needs to install it separately, and I was hoping that snap would be an easier solution for that.
It's in the AUR. yay -S bandwich (I run a computer actually).
I deliberately ran it as my unpriv user account and it spat out an easy to understand summary of why it won't work and some great suggestions on how to fix it.
It looks lovely, does a job very well and goes straight into the toolbox.
I run luci-app-vnstat on my OpenWrt router, default config except that DatabaseDir is on a USB flash drive.
This doesn't provide device or app-level granularity, but I can see my network's total bandwidth usage for previous hours, days, and months, which is useful for avoiding Comcast's 1.2TB data cap.
C'mon, you know they're awful. You know it's not every package using up a loopback device... You know it's not little tricks like hiding apt-get install packages in snap. You know its' not me having a choice in the matter. Really, why is snap so crappy.
> Stopped reading at the "remove docker" line. Like, really?
Why so incredulous about removing docker?
Did you read the part right before about how the networking interferes with LXD? "remove docker" is a pretty damn good solution to those types of problems as Docker notoriously hacks iptables and screws up all sorts of other apps that rely on it to do networking work. I've had to do that on my desktop in order to get bridges working in kvm (I started using podman instead which plays nicely with kvm).
What alternative solution do you offer instead for fixing the LXD networking?
There's no need to be so defensive. HN has a lot of web developers and, for better or worse, docker is an integral part of their workflow. So any guide brushing off "yeah just remove docker" with no further explanation will naturally be met with incredulity...
CBM was a fine tool [0]. I think it's been basically abandoned though. It does only do per interface, but it seems like an earlier simpler iteration of this type of tool. It works by reading the stat tables in /proc/net/dev
I'd just throw our something I wrote a long time ago called fsbm [1] (fucking small bandwith monitor) which was a rewrite of CBM without curses. useful for logging to a file or to something without NCURSES support. Along the way I added support for network namespaces and just general other stuff. I use it frequently. You can pump it into i3-bar for example or such and such
[0] https://github.com/resurrecting-open-source-projects/cbm [1] https://git.ceux.org/fsbm.git/tree/fsbm.c