I am the author of "what" and am very happy to hear people like this tool I made. :)
"what" was my first real attempt at rust, and I love the project very much.
That said, it is a hobby project - and so I will likely be a few days responding to all issues and contributions that came from this thread.
"what" has already received some great contributions that are major parts of the code base. I would be very happy for more (in the form of features, bug fixes, issues and packaging).
A note to those having issues installing: as mentioned in this thread, packaging for all the various linux distributions and mac is a great effort. I apologize that at the moment the installation is a little bumpy (especially for those not very familiar with rust).
A good first step for if "cargo install what" isn't working is to try to `rustup update` so you get the latest version of rust and cargo.
Other than that, I hope to support your setup in the future, and/or hear from you in the issues of the repo. Debug help for OSes I do not have access to would be greatly appreciated. :)
What are your thoughts on Rust so far? What primary language(s) did you come from?
I've been planning to learn Rust but haven't made the leap yet because I expect a big time commitment due to the learning curve. I poked around your source code and it was inspiring. Your code looks simple and straightforward compared to some of the other Rust projects I've examined.
That's high praise - thank you very much for saying so.
My major language in recent years has been javascript (and years before that perl). Rust was a breath of fresh air for me as I did not previously have "access" to system-level functionality.
I very much love the ease with which I can rely on other people's code (feels like home coming from node.js) - even though as mentioned in this thread it does have its downsides (eg. longer compiler times).
The learning curve is indeed challenging, but the tooling is amazing, the compiler has better error messages than I could even have imagined, and the community is incredibly friendly and welcoming. All in all, I'd say it's worth the effort. :)
My complaint about the name is that it would be hard to "google" it. This means if I don't bookmark it or remember where I found it, then a couple of years from now when my laptop needs to be rebuilt, I'll have the darndest time finding it to install it again.
I’m using multiple search engines more and more. Possibly this is due to me usually bypassing google to avoid the ad laden hits. A view with search results from a few sources comes to mind as a solution. Another back burner project.
You can do this with browser search engines, but as a DuckDuckGo user, I can !bang search_term (`!gh`, `!github` to search in github.) Now, I think DuckDuckGo is very lacking in terms of Zero-click searching, but if I know where to get information I can !bang to it (e.g., `!hn what`) or if you're feeling luck `\hn what` will open the first search result. Much better than spending an afternoon setting up search engines.
I just type in what I’m looking for and “news.ycombinator.com” at the end so that it links to a HN page. Sometimes I have to use site: to make sure it’s actually from HN, but works reasonably well.
Surf with chrome logged in? Will never happen. Hard no as long as my sanity remains.
Firefox, maybe, haven't looked into it and just the process of evaluating it isn't worth it. Mozilla doesn't have the track record that I want to blindly trust them with that either.
As search engines have gotten better over the years, I find my use of bookmarks is usually write-once read-never.
Part of that is due to the fact that iOS is now my primary consumption platform, and finding bookmarks in a complex structure is much more awkward than it should be.
Part of it is just laziness: trying to manage a complex bookmark folder is more work than I care to do when search engines give me 99% of what I need.
For what it's worth I had the same problem with folder/hierarchically structured bookmarks, but tag-based bookmarking (like del.icio.us used to provide) meshed very well with me and my workflow so I wrote https://savecrate.com (still a WIP and rough around the edges but functional enough to work for me)
Ever since I installed SQM on openwrt, I don’t really care what’s using the bandwidth anymore since it doesn’t impact any other users on the network. :) It’s true though that iftop is a very useful tool.
ksh as well. Found someone’s reference to various “what” type commands[1]:
> The whence command is a Korn Shell feature that tells how a name would be interpreted by the shell: it detects commands and aliases, and searches your path.
This is the main problem keeping me from using this right now. I don't like installing binaries that conflict with system package names because I'm tin foil about stability and the super small chance that some installation/config script for some other package I rely on references `what` and breaks.
@imsnif 2 questions:
1. Any chance you'd be willing to rename the package? I get it if not, but that would be so dope.
2. Would you consider putting this up as a cask on Brew? Brew is essentially the most popular package manager for Mac that I know of. This isn't as big of a deal for me honestly, but thought I'd ask.
A good name would be "nettop"; it's so good that several projects (on github alone) have already used it as the name of some network monitor. The shortened "ntop" is also taken. At least two projects have claimed "iptop".
This is one of the biggest problems I've had with any neat Rust thing posted up here. The language changes a lot. I have rust/cargo 1.37.0 installed (it's the latest marked stable in Gentoo) and adler32 v1.0.4 fails to compile with "`core::slice::<impl [T]>::len` is not yet stable as a const fn". I'm installing 1.40.0 from the unstable tree to see if that will build it.
I've had situations where I'm either not on the latest version of rust, or I'm on too current a version of rust, which deprecated/removed some feature needed for a dependency. I'm not sure if devs can define their min/max versions, but that kinda check should probably be done before cargo starts building packages.
Agreed, and I had the same problem. It seems like an easy fix to add a requires_rust_version thing in Cargo.toml, and devs could at least set it to "the version I'm currently using" so we know it's guaranteed to build on that.
It’s not that easy; the real world has a lot of complexity. That said, we finally did accept a design for this in October; it’s not clear when it’s going to land though.
Tons of stuff. Various aspects of dependencies, for example, should this affect resolution? Is this a semver range? A minimum version? Is whatever we choose reasonably forward compatible for any extensions we might pick in the future? Can you write `cfg` attributes based on versions? Many of the same questions apply there. Etc etc etc.
I also suspect that if the plan is to add this as an attribute that developers put in Cargo.toml then there will be a lot of packages that will have the value set to a higher version than need be.
Speaking for myself, I don't know in which exact version of Rust the features that I use was first introduced, and I don't think anyone else knows that either if they use a lot of different Rust language features.
So if I were to add a minimum required version to Cargo.toml for the crates that I put out, I would for sure end up putting the current stable version that I am using myself.
In practice I think that is probably fine, but also a bit unfortunate in a way, that anyone using an older version of Rust, such as those using distro packaged Rust will see Cargo tell them they can't build and run my crate, because I set minimum version to say 1.40.0, and they are using 1.37.0, but actually I might happen to not be using any features beyond what was available in 1.35.0 or whatever in some random crate of mine, but I don't know that and I don't wish to test every change I make to my crates in a bunch of older versions of Rust also because that would slow me down considerably.
On the other hand, if the Rust Team had the resources for it, could the crates.io service be made to detect minimum version of Rust needed based on the features used? Probably a lot of work I would guess. Doubly so when considering different feature flags and other cfg switches.
Again, I don't know the plans you have for how to do it so maybe you are already planning to do it that way but, you guys sometimes run builds on basically all of the crates on crates.io, don't you? Would it be feasible that the crates.io service runs a background service that builds each crate with a few different versions of Rust and records the build results and possibly test results into the meta data for the crates on crates.io? I think that would probably require a lot of server time, and therefore likely cost too much to be possible but it would have been really cool if it was doable.
I’m imagining that’s too much resources, yeah. It’s the same issue with anything that’s created by people; I’m sure that it’ll be fine over time. If and when we do LTS releases that’ll make it easier too...
There's no such thing as a "too current a version of rust". All Rust compilers (since 1.0) compile all previous versions of code and will continue to do so.
In the rare case you might hit something that was removed/modified because of a security exploit, but those are very very rare.
This is not true in practice. Old code has failed to compile for various reasons; off the top of my head, new additions to the prelude, and denied lints that became more restrictive. It's not super rare.
First, it’s really cool that their using trust-dns! Second, they probably want to upgrade to the 0.18 release. It’s interesting that the cargo.lock file didn’t restrict the package versions for this case.
Anyway, this tool should probably upgrade to the current 0.18 release now that it’s out, if possible.
More evidence that the best names are short, pronounceable, and meaningless, like Hadoop. Git almost qualifies, except for the fact it's a pejorative, so using a really obscure or off-the-wall word is almost as good.
Marketers were forced into this by trademarks, but it shouldn't take the threat of a trademark lawsuit to convince you that stepping too close to something else's toes is annoying for everyone.
(And don't be afraid to go with words that have negative meanings: Aside from git, MUMPS has been a successful medical records database environment for decades.)
The word “git” as a pejorative (calling someone unpleasant, e.g. “Linus Torvalds is such a git”) long predates the VCS. Linus himself chose the name for the VCS partly due to the meaning, sarcastically remarking that he was naming another project after himself (first Linux, then Git). See the Wikipedia entry for more detail: https://en.m.wikipedia.org/wiki/Git#Naming
Installation with yay/crate can be slow. This small tool took 4 minutes of compile time, the Rust crates seem to be very fine granular (like node.js vor example) and require much compile time. 204 crates needed to be compiled.
I found that, using yay or another aur helper on arch linux, having a few rust utilities installed that have regular updates, significantly slows down the average system upgrade time. I tend to avoid Rust programs for that reason.
That's the nature of these spare time one (wo)man side projects: packaging a piece of software for a wide variety of distributions and platforms is tedious and boring, so unless there's a large community (or money) involved, you have to compile it from source.
Of course, you can always package your favourite utility for your favourite distribution. I'm sure the author would be thrilled to endorse your package in the Readme.
Note also that Rust can compile to portable static binaries. This tool is available as such from the releases page on GH (it's in the readme)
The simplest way is to pass the —target flag with the musl target; that should work unless you’re also including C code, and then it may Just Work or may need you to do something special.
RPM and DEB packaging are going to help make it available to about 90% of Enterprise and cloud based Linux environments respectively. It's well worth the effort IMHO.
A bit unrelated but I wrote https://github.com/amir/hepccn to list TCP connections by domains rather than just IPs. It filters connections to port 443 and 8443, downloads the peer certificate and then extracts the subject name (pretty sure I learned this trick from an article on Julia Evans' website but can't find it now). I wanted to add more functionalities to it but I stumbled upon an issue and that's for when SNI is enabled. I guess there's no way for me to recover the hostname the client has sent at the start of the handshaking process without introducing MITM, right?
You won't be able to recover it after the fact, but the SNI is cleartext on the wire as part of ClientHello even in TLS 1.3. Work to encrypt this is an ongoing effort (called eSNI).
They are similar but they answer different questions.
By default, iftop will tell you "this network interface on your machine is talking a lot to ycombinator.com". But you don't necessarily know which processes are doing the most talking collectively.
This will tell you "Firefox process 4567 is talking a lot ycombinator.com" and you'll know whether 4567 is also one of the chattiest talkers right now.
> This will tell you "Firefox process 4567 is talking a lot ycombinator.com" and you'll know whether 4567 is also one of the chattiest talkers right now.
I find the --raw output more useful than the interactive one. it scrolls away but I have time to read what's going on. The other one just disappears and is replaced by something else, which could be ok except sometimes there are seconds of useless black screen when nothing is going on. I suggest to never have blank screens.
A suggestion for the raw output: add a timestamp at the beginning of the line. Probably HHMMSS is enough but YYYYmmdd would be handy for logging in background.
Seconded. It might be a good idea to have a separate "top-so-far" section that can build-up over time to show the top consumers (and also allow sorting this by hostname to avoid too much jumping).
.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-0.5.3/src/bytes.rs:121:18
|
121 | len: bytes.len(),
| ^^^^^^^^^^^
error: aborting due to previous error
error: Could not compile `bytes`.
warning: build failed, waiting for other jobs to finish...
It requires a very recent version of rust. Do a 'rustup update' to get the latest stable release. You can't use the distribution's packages for rust and cargo if you want to play new rust programs.
Thank you this is amazing. I have a bunch of virtual interfaces on my server and I have no idea what's using them or if they're even still in use what created them. This solved my problem instantly.
What's that have to do with anything (it being top front page)? are there guidelines for naming posts so that the language a software is written in is preferably in the title?
Parent is probably being a bit sarcastic and referring to the perception that HN zeroes in and upvotes submissions based on how trendy the implementation language is.
I'll take this moment to plug the tool 'origin', which plows through aliases and symlinks to find the executable behind a command: https://github.com/atorstling/origin
You're getting snark because your own snarky comment is the equivalent of saying "Why do I need Make to run it on the MacOS?" If you had asked instead, "What is cargo, and how do I install it?" you would get more helpful responses. Snark is met with snark.
And how people are supposed to know that it is a programming tool? I assumed that it is yet another package manager and googling about cargo brings results about logistics.
It took me a few tries before figuring it out. What worked was "Install cargo MacOS" and it was hard to tell if the results are not a scam to make me install some spyware.
Thank god for the name change! I saw this project this morning and it looked super interesting. I tried googling around for it to install it, but nothing worked haha "bandwith monitor what", "github rust what", etc. And this is coming from a hypocrite who's most popular project is named 'c'.
Running Catalina, with sudo I'm able to get the screen up and running, but at first data I get a panic:
thread 'display_handler' panicked at 'overflow when subtracting durations', src/libcore/option.rs:1185:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
I'm not surprised about OS X, recent OS versions have been making it more and more different from how the OS previously worked. For example GDB doesn't work anymore, and neither does valgrind.
Looking at how it does reverse DNS lookups to try and map backwards... is there such thing as a crowdsourced database that resolves the most common domain name(s) that resulted in a given IP address? Seems like this would be tremendously useful for any sort of network tooling, but I can’t find any references from a quick search.
You do realize that multiple domains may be hiding behind the same IP address? This is very common with CDNs (although the bigger players can afford a static CDN IP, I guess)
Very nice. I dream of the day our networking instrumentation is good enough that when I click on a link and my browser hangs doing nothing, I can switch to my monitor app and have it tell me exactly where the route is failing.
Among other features like process blocking, it has a process list not very different than this utility as well has bandwidth graphing over a period in time which is very useful in tracking down bandwidth hogs on a monthly capped DSL line.
https://www.netlimiter.com/docs/netlimiter-overview/features...
TcpView and built-in Resource Monitor come pretty close actually. Not the exact same feature set perhaps, but if the question is 'what is taking up bandwidth and to which address' then they do the job.
would this work with WSL...dont think it would with wsl2 since it runs in a virtual kernel. It could work with WSL though, very curious if anyone can get it to work
Is this the future? I am setting this up on my macOS, and before I could 'cargo add' anything I had to 'brew install rust'. Now it is downloading and compiling lots and lots of dependencies.
I am the author of "what" and am very happy to hear people like this tool I made. :)
"what" was my first real attempt at rust, and I love the project very much.
That said, it is a hobby project - and so I will likely be a few days responding to all issues and contributions that came from this thread.
"what" has already received some great contributions that are major parts of the code base. I would be very happy for more (in the form of features, bug fixes, issues and packaging).
A note to those having issues installing: as mentioned in this thread, packaging for all the various linux distributions and mac is a great effort. I apologize that at the moment the installation is a little bumpy (especially for those not very familiar with rust).
A good first step for if "cargo install what" isn't working is to try to `rustup update` so you get the latest version of rust and cargo.
Other than that, I hope to support your setup in the future, and/or hear from you in the issues of the repo. Debug help for OSes I do not have access to would be greatly appreciated. :)
Thank you all!