> 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.
This is great. Small, trivial suggestion: the gif that loops in the README should pause on the screen w/ the output for a few seconds longer - it disappears (restarts) too quickly to take in all of the output.
I would also argue it shouldn't be a gif. It's nice that it shows the command is fast I guess but it's one command that's still visible in the final frame. Not as bandwidth efficient and agreed I can't read it all in time
A quick note on scope: this is not meant to replace existing monitoring or observability tools. It’s designed for those moments when you SSH into a box and need to quickly understand “why is this running” without digging through configs, cron jobs, or service trees manually.
Happy to answer questions or adjust direction based on feedback.
This is very clever. I've often needed to figure out what some running process was actually for (e.g. because it just started consuming a lot of some limited resource) but it never occurred to me that one could have a tool to answer that question. Well done.
---
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
Looking up the binary in the package management system would also provide another source of useful information. Of course this would dramatically increase the complexity but would, I think, be useful.
If you could look it up using APT/dpkg first, that would be lovely :-)
Sounds like something I could use, but installing a binary via `curl` doesn't sit right with me. Next problem you have is "explain how this thing was installed on my system" followed "is it up to date (including security patches).
What does this means for context:
“Git repository name and branch”
Does this mean it detects if something is running from within a git repository folder? Couldn’t find the code that checked this.
> 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.
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 :-)
I hope they have deb package or snap some day.
CGO_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!
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.
'Responsibility chain' will become a trendy phrase.