The README already has a rather repugnant LLM-ish feel to it; lots of lists and verboseness, while saying very little.
Also, this is a perplexing choice (which also serves to illustrate the above point regarding verboseness):
White background with red center: 1-9 processes (some development servers)
White background with orange center: 10+ processes (many development servers)
Whenever I see a README or worse, PR description that was obviously generated by an LLM, my immediate response is "if you couldn't be bothered to write this, why should I bother reading this?"
What is "development process" ??? What is "business use case" of this tool? Such a big readme and no introduction to why I should be interested in this tool.
Which is perfectly fine and a fun thing to do. I personally use the terminal but such a little monitoring tool can be quite fun and we should embrace the fun in doing things more. People over here are so soaked up by the Open Source as a business model VC-Pitch that they can't believe it when someone builds a little hobby tool with no business plan for a multi billion dollar exit. You're doing it right buddy. Don't let these Crypto-SaaS-AI-Bros ruin the fun for you.
> Such a big readme and no introduction to why I should be interested in this tool.
This.
Why in the hell would anyone want to kill random processes that open a port in the tange 2000-6000? And why is this need so pressing as to require a full blown monitor integrated in a task bar?
Without context, this sounds like a complete random silly project that makes no sense and serves no purpose at all.
Without context, it sounds like something someone vibe-coded and git push-ed up to the internet. Which is fine, but it's just unusually precise and verbose for something that would end up being a shell alias for most developers.
Interesting idea ("manages development processes running on ports 2000-6000"), and props for hitting the front page though technically this is a "Show HN". Screenshot(s)?
a couple of prompts of claude code gave me this, works well enough, but while I agree that this is sometimes useful, it may indeed better served by a couple of aliases in the terminal
```
#!/bin/bash
# SwiftBar Port Monitor
# Monitors processes on TCP ports 2000-6000
if [ -z "$processes" ]; then
echo "No processes found on ports 2000-6000"
exit 0
fi
# Process each line
while IFS='|' read -r pid name port_info; do
if [ -n "$pid" ] && [ -n "$name" ] && [ -n "$port_info" ]; then
# Extract port number from format like :3000
port=$(echo "$port_info" | sed 's/.://')
# Menu item with port and process name
echo "[$port] $name | color=blue"
# Submenu items
echo "--Kill (TERM) | shell=kill param1=$pid terminal=false refresh=true"
echo "--Kill Force (KILL) | shell=kill param1=-9 param2=$pid terminal=false refresh=true"
echo "--Process Info | shell=ps param1=-p param2=$pid param3=-o param4=pid,ppid,user,command terminal=true"
echo "-----"
fi
Complaining about the number of dependencies is completely meaningless if you don't take into account what those dependencies do, and what the ecosystem looks like.
For example, `tray-icon` looks pretty useful for a lightweight app which basically is a tray icon: rewriting that library from scratch would be a massive waste of time.
On the other end of the spectrum, `log` and `serde` provide basic functionality which most languages will have in their standard library. Rust intentionally keeps a small standard library to avoid ossifying potentially bad ideas. The crates have tens of millions of users, rewriting that yourself would be stupidity.
It's very easy to criticize the length of their dependency list, but could you point to a specific one which you deem unnecessary? Which one do you consider to be a "leftPad", and what trivial code fragment would you replace it with?
I mean this entire thing is doable in a one-liner bash script. This tool has 10 deps (and every one of them also includes a big list of deps, so in practice i probably have over 200 deps).
Ports 2000 - 6000?
I know I am getting old but when did we stop running things on 8xxx? The more 8's the more dev it was. 8000, 8080, 8088, 8888
To me, 8xxx is for proxy servers.
On macOS i've this in my zshrc file:
`killport() { kill -9 $(lsof -t -i :$1 -sTCP:LISTEN) }`
i use it like killport 8000
Nice. I have this too. I wanted something more visual and expansive.
Yeah, I have a function `whoseport` which is just your subcommand. I usually manually type kill or whatever I want with `$(whoseport 3000)`
I'm not looking forward to the near future where it will become harder and harder to distinguish little projects like this from AI generated tools.
The README already has a rather repugnant LLM-ish feel to it; lots of lists and verboseness, while saying very little.
Also, this is a perplexing choice (which also serves to illustrate the above point regarding verboseness):
A lot of ReadMe's are generated with AI. Doesn't really mean anything.
You're right. A lot of words that don't really mean anything; and that's exactly why you should not do it if you want actual humans to read it.
Whenever I see a README or worse, PR description that was obviously generated by an LLM, my immediate response is "if you couldn't be bothered to write this, why should I bother reading this?"
Because it provides useful information, and is easier to read compared to reading the code directly.
Except, no it doesn’t.
In the case of a pull request, I am not about to trust some LLM that has no business context and can only pretend to guess at the “why” of a change.
To understand the “what” of a change, you have to actually read the code. This doesn’t belong in the pull request description most of the time.
> Quit: Exits the application
I would have never figured that one out, had to ask an LLM! Thank god for LLMs.
the ascii tree in "Project Structure" is a dead giveaway that AI is used in this project
Why would you need to do that?
To filter out the spam.
What is "development process" ??? What is "business use case" of this tool? Such a big readme and no introduction to why I should be interested in this tool.
It's just a tool I built for myself. There's no business case. It just helps me
Which is perfectly fine and a fun thing to do. I personally use the terminal but such a little monitoring tool can be quite fun and we should embrace the fun in doing things more. People over here are so soaked up by the Open Source as a business model VC-Pitch that they can't believe it when someone builds a little hobby tool with no business plan for a multi billion dollar exit. You're doing it right buddy. Don't let these Crypto-SaaS-AI-Bros ruin the fun for you.
can't a guy just create something anymore? :D They have to have a business model or a grand plan ?
> Such a big readme and no introduction to why I should be interested in this tool.
This.
Why in the hell would anyone want to kill random processes that open a port in the tange 2000-6000? And why is this need so pressing as to require a full blown monitor integrated in a task bar?
Without context, this sounds like a complete random silly project that makes no sense and serves no purpose at all.
Without context, it sounds like something someone vibe-coded and git push-ed up to the internet. Which is fine, but it's just unusually precise and verbose for something that would end up being a shell alias for most developers.
The author also posted it on Reddit. He used it for himself, but some people use it even though it’s bad practice.
If only I was on mac, something like this probably exists on windows I just need to find it. great idea however
Didn't expect to see the FSL for that kind of project :)
The part I'm interested in is the tray_icon crate but I'll look at the package directly https://docs.rs/tray-icon/latest/tray_icon/.
Interesting idea ("manages development processes running on ports 2000-6000"), and props for hitting the front page though technically this is a "Show HN". Screenshot(s)?
Not sure I can add images here, but if you check the repo, I'll be adding one shortly.
lsof is a bit heavy, I wouldn't want that running every 5 seconds to be honest.
Green -> Red -> Orange
That is an odd progression
Neat! There's also a raycast extension for this kind of thing for anyone who wants to go that route:
https://www.raycast.com/lucaschultz/port-manager
These would be good additions to SwiftBar/BitBar.
a couple of prompts of claude code gave me this, works well enough, but while I agree that this is sometimes useful, it may indeed better served by a couple of aliases in the terminal ``` #!/bin/bash
# SwiftBar Port Monitor # Monitors processes on TCP ports 2000-6000
# Menu bar title echo " Ports" echo "---"
# Get processes listening on TCP ports 2000-6000 processes=$(lsof -iTCP:2000-6000 -sTCP:LISTEN -n -P 2>/dev/null | awk 'NR>1 {print $2 "|" $1 "|" $9}' | sort -t'|' -k3 -n)
if [ -z "$processes" ]; then echo "No processes found on ports 2000-6000" exit 0 fi
# Process each line while IFS='|' read -r pid name port_info; do if [ -n "$pid" ] && [ -n "$name" ] && [ -n "$port_info" ]; then # Extract port number from format like :3000 port=$(echo "$port_info" | sed 's/.://')
done <<< "$processes"# Refresh option echo "---" echo "Refresh | refresh=true
This has 10 additional deps. 10! Rust is the new Javascript.
Complaining about the number of dependencies is completely meaningless if you don't take into account what those dependencies do, and what the ecosystem looks like.
For example, `tray-icon` looks pretty useful for a lightweight app which basically is a tray icon: rewriting that library from scratch would be a massive waste of time.
On the other end of the spectrum, `log` and `serde` provide basic functionality which most languages will have in their standard library. Rust intentionally keeps a small standard library to avoid ossifying potentially bad ideas. The crates have tens of millions of users, rewriting that yourself would be stupidity.
It's very easy to criticize the length of their dependency list, but could you point to a specific one which you deem unnecessary? Which one do you consider to be a "leftPad", and what trivial code fragment would you replace it with?
I mean this entire thing is doable in a one-liner bash script. This tool has 10 deps (and every one of them also includes a big list of deps, so in practice i probably have over 200 deps).
How is this acceptable?
Even if the app used the bash script as the backend, the UI would require dependencies (aka tray icon)
You dont need a UI for things like this.
Maybe you don't, but the author did/wanted one. It's a good thing your exact needs don't control how other people use their computer.
[dead]