Happy to answer questions or adjust direction based on feedback.
---
Edit: Ah, ok, I slightly misunderstood - skimmed the README too quickly. I thought it was also explaining what the process did :D Still a clever tool, but thought it went a step further.
Perhaps you should add that though - combine Man page output with a database of known processes that run on various Linux systems and a mechanism for contributing PRs to extend that database...? Unlesss it's just me that often wants to know "what the fsck does /tmp/hax0r/deeploysketchyd actually do?" :P
If you could look it up using APT/dpkg first, that would be lovely :-)
New tools are always welcome, and having a purpose to explain a purpose seems like a good pitch.
> the gif that loops in the README should pause on the screen
The gif is adding no value. I already know what typing text into a terminal looks like.
svg-term --command 'cowsay hey there'
I hope they have deb package or snap some day.
systemctl status 1
sudo lsof +c 0 -i:22CGO_ENABLED=0 go build -ldflags "-X main.version=dev -X main.commit=$(git rev-parse --short HEAD) -X 'main.buildDate=$(date +%Y-%m-%d)'" -o witr ./cmd/witr
Call me old-fashioned, but if there's an install.sh, I would hope it would prefer the local src over binaries.
Very cool utility! Simple tools like these keep me glued to the terminal. Thank you!
However, I can’t use it in a production business environment for the same reasons other users mentioned earlier. A Debian or RPM package would be fantastic.
> This project was developed with assistance from AI/LLMs [...] supervised by a human who occasionally knew what he was doing.
This seems contradictory to me.
> supervised by a human who occasionally knew what he was doing.
seems in jest but I could be wrong. If omitted or flagged as actual sarcasm I would feel a lot better about the project overall. As long as you’re auditing the LLM’s outputs and doing a decent code review I think it’s reasonable to trust this tool during incidents.
I’ll admit I did go straight to the end of the readme to look for this exact statement. I appreciate they chose to disclose.
Have you tried it? Procfs trivialities is exactly the kind of thing where an LLM will hallucinate something plausible-looking.
Fixing LLM hallucinations takes more work and time than just reading manpages and writing code yourself.
But at the moment I feel like all that sounds suspiciously like actual work.
There's nothing wrong for a software engineer about using LLMs as an additional tool in his toolbox. The problem arises when people stops doing software engineering because they believe the LLM is doing the engineering for them.
You mileage may vary, though. Lots of software engineers love those time and effort tarpits.
Every IDE I've used just worked out of the box, be it Visual Studio, Eclipse, or anything using the language server protocol.
Having the ability to have things like method auto-completion, go-to-definition and symbol renaming is a net productivity gain from the minute you start using it and I couldn't imagine this being a controversial take in 2025…
Really? You don't know software developers that would rather futz around with editor configs and tooling and libraries and etc, etc, all day every day instead of actually shipping the boring code?
You must be working in a different industry.
https://github.com/pranshuparmar/witr/tree/main/internal/lin...
It should be the last option.
While that’s theoretically true in a security context, it feels like a 'perfect is the enemy of the good' situation. Unless the author is discussing high-stakes incident response on a compromised system, discarding /proc-based tools for debugging and troubleshooting seems like throwing the baby out with the bathwater. If your environment is so compromised that /proc is lying to you, you've likely moved past standard tooling anyway.
Do you have any qualms about me making an entry in the AUR for this?
My favorite thing about arch is how insanely quickly AURs pop up for interesting tools.
i see you support multiple output format including json thats nice. id recommend to assume automation (ssh script/commands) and make the default output really easily greppable , or json (jq) since itll be more appealing to parse (shouldnt reduce readability, for the default output it looks like just removing some linebreaks to make it parse more consistently. (maybe the lines are wrapped tho? unclear from the img)
to quote the top comment: just show a screenshot of its results, if its useful its fine, being fast is just gravy.
That's the good part of AI. Lowers effort and knowledge barrier and makes things possible.
Also I don't think this approach works correctly, because a disowned/nohup process will show up as PPID 1 (systemd), which is not correct
BTW any chance you would make MacOS version of this?