witr: eine CLI, die beantwortet, warum ein Prozess läuft

witr ist ein Kommandozeilen-Tool und eine interaktive Terminal-Oberfläche (TUI) in Go, das eine einzige Frage beantwortet: „Warum läuft das?” Bei einem Prozess, einem Port, einem Container oder einer geöffneten Datei rekonstruiert es die exakte kausale Kette, die diese Instanz hervorgebracht hat — das Init-System, den Supervisor, die Sitzung, den Container oder den Cron — und stellt sie als menschenlesbare Ausgabe, JSON oder TUI dar. Stand 4. September 2026 hat das Projekt 22.073 Sterne.

Der Warteschlangeneintrag war fehlerhaft formatiert (129 127_pranshuparmar_witr); er lässt sich eindeutig auf das Repository pranshuparmar/witr auf GitHub auflösen, das einzige mit diesem Namen unter diesem Nutzer.

Ursprung

Das Repository wurde am 20. Dezember 2025 von Pranshu Parmar (pranshuparmar) erstellt, dessen E-Mail pranshu.parmar@gmail.com als Maintainer in der Release-Konfiguration (.goreleaser.yml) erscheint. Sechs Tage später, am 26. Dezember 2025, veröffentlichte Parmar den Beitrag „Show HN: Witr – Explain why a process is running on your Linux system” auf Hacker News (Thread 46392910), der 526 Punkte und 105 Kommentare erreichte.

Das README verlinkt eine Geschichte des Autors selbst auf Medium („witr: Why is this running”, von @pranshu.parmar) sowie den Hacker-News-Thread als Referenz zum Design-Kontext. In diesem Thread stellt der Autor den Umfang von Anfang an klar: witr will nicht Monitoring- oder Observability-Tools ersetzen, sondern deckt „jene Momente ab, in denen man sich per SSH auf eine Maschine einloggt und schnell verstehen muss, warum etwas läuft, ohne manuell Konfigurationen, Cron-Jobs oder Service-Bäume zu durchsuchen”.

Das Projekt hat organisch und community-getragen an Verbreitung gewonnen: Die Launch-Konversation brachte auf Wunsch des Autors selbst einen AUR-Eintrag hervor, den Vorschlag zur Nix-Unterstützung (PR #5, beigetragen von Nutzer sestep) und später die Aufnahme in Homebrew, conda-forge und offizielle Debian/Ubuntu-Repositorys. Die zuletzt konsultierte Version ist v0.3.3 (24. Juni 2026).

Ein Detail, das die Community aufgriff: Die Projektdokumentation offenbart, dass es mit KI-/LLM-Unterstützung (GitHub Copilot, ChatGPT und ähnliche Tools) entwickelt wurde, „überwacht von einem Menschen, der manchmal wusste, was er tat”. Im Launch-Thread stellte Nutzer zenoprax den Widerspruch infrage, während Vorfällen Vertrauen für ein mit KI-Unterstützung entwickeltes Tool zu verlangen; der Autor antwortete, diese Unterstützung senke die Aufwands- und Wissenshürde für den Bau des Tools.

Philosophie und Prinzipien

Das README verdichtet die Philosophie darauf, Kausalität explizit zu machen, im Gegensatz zu bestehenden Tools. Es erklärt, dass ps, top, lsof, ss, systemctl und docker ps Status und Metadaten offenlegen: Sie zeigen, was läuft, überlassen dem Nutzer aber, warum durch manuelles Korrelieren mehrerer Ausgaben zu erschließen. witr beantwortet stattdessen vier Fragen pro Ziel:

Was läuft?
Wie hat es angefangen?
Was hält es am Laufen?
Zu welchem Kontext gehört es?

Ein zentrales Prinzip ist, alles als Prozessfrage zu behandeln: Ports, Dienste, Container und Befehle werden letztlich auf eine PID aufgelöst, und auf dieser PID wird die kausale Kette aufgebaut. Die erklärten Ausgabeprinzipien sind: ein einziger Standardbildschirm (angemessener Aufwand), deterministische Reihenfolge, Erklärung im narrativen Format und Best-Effort-Erkennung mit expliziter Unsicherheit — das heißt, witr erklärt, wenn es sich nicht sicher ist, statt eine Ursache zu erfinden.

Das README definiert konkrete Erfolgskriterien: dass ein Nutzer „warum läuft das?” in Sekunden beantworten kann, dass es die Abhängigkeit von mehreren Tools reduziert, dass die Ausgabe unter Stress verständlich ist und dass der Nutzer ihm während Vorfällen vertraut.

Wie es funktioniert

witr identifiziert das Ziel (nach Name, PID, Port, Datei oder Container), löst die PID auf und baut die Abstammungskette auf. Die Standardausgabe gliedert sich in Abschnitte:

Target: was der Nutzer abgefragt hat.
Process: ausführbare Datei, PID, Benutzer, Befehl, Startzeit und Anzahl der Neustarts.
Why It Exists: die kausale Abstammungskette (z. B. systemd (pid 1) → pm2 (pid 5034) → node (pid 14233)). Das ist der Kernwert des Tools.
Source: das primäre System, das für das Starten oder Überwachen des Prozesses verantwortlich ist (Best Effort). Es wird nur eine primäre Quelle ausgewählt: systemd-Unit (mit Timer-Details), launchd-Dienst (mit Zeitplan), SSH-Sitzung (mit Remote-IP und Terminal), Docker-Container, pm2, Cron, interaktive Shell (erkennt tmux/screen) oder Snap/Flatpak-Sandbox.
Context: Arbeitsverzeichnis, Name und Branch des Git-Repositorys (wird vom Arbeitsverzeichnis aus aufwärts gesucht, bis .git gefunden wird), Container-Name/-Image, und ob die Verbindung öffentlich oder privat ist.
Warnings: nicht blockierende Beobachtungen, wie ein Prozess, der als root läuft, gefährliche Linux-Capabilities bei Nicht-Root-Prozessen, Lauschen auf einer öffentlichen Schnittstelle (0.0.0.0/::), mehrfache Neustarts, hoher Speicherverbrauch (>1 GB RSS), Laufzeit >90 Tage, eine gelöschte Binary oder Indikatoren für Bibliotheks-Injection (LD_PRELOAD, DYLD_*).

Interaktiver Modus (TUI): witr ohne Argumente oder mit -i auszuführen öffnet ein Echtzeit-Panel mit vier Tabs — Prozesse, Ports, Container und Sperren — mit einem Seitenpanel, das den Abstammungsbaum des hervorgehobenen Prozesses zeigt. Es erlaubt das Senden von Signalen (Kill, Terminate, Pause, Resume) und Renice aus der Oberfläche heraus (nur Unix), Mausnavigation, ein adaptives Hell-/Dunkel-Theme und Auto-Refresh mit adaptiver Kadenz (startet bei 3 s und verlangsamt sich unter Last).

Exit-Codes (dokumentiert für Skripte, CI und Monitoring):

Code	Bedeutung
0	Sauber: Prozess gefunden, keine Warnungen
1	Warnungen: Prozess gefunden mit einer oder mehreren Warnungen
2	Nicht gefunden: kein passender Prozess oder Dienst
3	Zugriff verweigert: unzureichende Berechtigungen
4	Ungültige Eingabe: fehlerhafte Argumente oder mehrdeutige Übereinstimmung
5	Interner Fehler: unerwarteter Fehlschlag

Plattform-Unterstützung (laut Matrix des READMEs): Linux (x86_64, arm64) mit vollständiger Unterstützung über /proc; macOS mit ps, lsof, sysctl, pgrep; Windows mit nativen Win32-APIs (ToolHelp32, PSAPI, Service Control Manager, ohne Abhängigkeit von PowerShell oder WMI); und FreeBSD mit procstat, ps, lsof. Container werden über Docker, Podman, nerdctl, K8s/crictl, Incus, LXC, LXD und FreeBSD-Jails erkannt.

Das Ökosystem

Repositorys des Autors. Neben witr (22.073 Sterne) pflegt pranshuparmar das Repository pranshuparmar/witr-pkgs (1 Stern), einen „selbst gepflegten” Paket-Container, der die Chocolatey-, npm-, Scoop- und winget-Definitionen mit automatischen Update-Workflows beherbergt. Die restlichen Repositorys des Nutzers sind kleinere persönliche Projekte (Three.js-Browserspiele wie neon-mayhem mit 2 Sternen und downhill-mayhem mit 11, yolovest, joke, sudoku-creator-solver), ohne funktionalen Bezug zu witr.

Community-Ports und -Neuimplementierungen (Sternezahlen laut GitHub-API in dieser Recherche):

rewrite-everything-in-rust/witr-rs — eine vollständige Rust-Neuimplementierung von witr, die Funktionsparität sowie zusätzliche Typsicherheit beansprucht; 14 Sterne, erstellt am 29. Dezember 2025.
bobozi-cmd/witr-py — eine Python-Neuimplementierung des Projekts (Slogan auf Chinesisch: „基于 witr 项目，使用 python 进行复刻”); 6 Sterne, erstellt am 4. Januar 2026.
supervoidcoder/win-witr — eine Windows-Neuimplementierung in reinem C++, als WIP markiert; 3 Sterne, erstellt am 1. Januar 2026. Der Autor erklärt, er habe damit begonnen, bevor der ursprüngliche Entwickler eine Windows-Version veröffentlichte.
dmitrymx/witr-gui — ein grafischer Client (Electron/React/Vite) für Windows, beschrieben als „Prozessmonitor und Sicherheitsanalysator” auf Basis von witr, mit auf Russisch dokumentierter Oberfläche; 2 Sterne, erstellt am 15. Mai 2026.

Das Repository hat 772 Forks angesammelt; die abgerufene Forks-Seite zeigt Kopien ohne wesentliche Unterschiede, sodass die vier obigen Projekte die sichtbaren nicht-trivialen Ableitungen sind. Das Projekt inspirierte zudem eine Hommage-/Parodie-Abspaltung, Fantastic-Computing-Machine/wtftr („Why the fuck is this running?”), ohne zusätzliche dokumentierte Funktionalität. Das README dankt Tim Colson (timcolson) und Rijurekh Bose (R-Bose) als Sponsoren.

Release-Werkzeuge. Die Releases werden mit GoReleaser (.goreleaser.yml) erzeugt, das Binaries, eine SHA256SUMS-Datei und .deb-, .rpm- und .apk-Pakete über nfpm produziert und Versions-/Commit-/Datumsmetadaten für witr --version einfügt.

Offizieller und halboffizieller Status

witr hat keine Unterstützung durch einen einzelnen großen Anbieter, hat aber im Ökosystem der Open-Source-Distribution bemerkenswerte De-facto-Adoption erreicht:

Offizielle Distributions-Repositorys: Das README dokumentiert die Installation mit sudo apt install witr aus den offiziellen Repositorys von Debian (sid) und Ubuntu 26.04+, sowie in Derivaten wie Kali, Devuan und Raspbian. Es findet sich zudem in Homebrew core (brew install witr, Formel witr 0.3.3), conda-forge (conda install -c conda-forge witr), MacPorts, FreeBSD ports (pkg install witr), GNU Guix und AOSC OS.
Windows: Manifeste bei winget (winget install -e --id PranshuParmar.witr), Chocolatey (choco install witr) und Scoop (scoop install main/witr).
npm: Paket @pranshuparmar/witr (Version 0.3.3).
Product Hunt: Das Projekt ist als Featured gelistet (Post 1211309) mit dem Slogan „ps, top and lsof tell you what is running. witr tells you why.”
Trendshift: präsent auf der Liste der Trend-Repositorys (Badge trendshift.io/repositories/18714).

In der Praxis bedeutet das, dass witr aus den offiziellen Katalogen der meisten wichtigen Plattformen installierbar ist, auch wenn das README warnt, dass Community-Pakete hinter der neuesten GitHub-Version zurückliegen können. Es gibt keine formale „Standard”-Bezeichnung, aber die durchgängige Präsenz in Distro-Repositorys und Paketmanagern positioniert es als De-facto-Referenz zur Beantwortung der Prozesskausalitätsfrage.

Schnellstart-Anleitung

Installation und erster Start

Voraussetzung: ein Linux-, macOS-, Windows- oder FreeBSD-System. Dokumentierte Optionen:

# Unix (Linux, macOS und FreeBSD) — erkennt OS und Architektur, installiert nach /usr/local/bin/witr
curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash

# Windows (PowerShell) — lädt das Zip herunter, verifiziert die Prüfsumme und installiert nach %LocalAppData%\witr\bin
irm https://raw.githubusercontent.com/pranshuparmar/witr/main/install.ps1 | iex

Nach Paketmanager:

sudo apt install witr                # Debian sid / Ubuntu 26.04+
brew install witr                    # Homebrew
conda install -c conda-forge witr    # conda-forge (auch mamba / pixi)
yay -S witr-bin                      # AUR (Arch)
npm install -g @pranshuparmar/witr   # npm (plattformübergreifend)

winget install -e --id PranshuParmar.witr   # Windows
choco install witr                            # Chocolatey
scoop install main/witr                       # Scoop

Aus dem Quellcode: go install github.com/pranshuparmar/witr/cmd/witr@latest. Unter Nix: nix run github:pranshuparmar/witr -- --help.

Beim ersten Start verifizieren witr --version und man witr die Installation. witr ohne Argumente auszuführen öffnet die TUI. Das README empfiehlt, bei Verwendung eines Paketmanagers auf diesem Weg zu installieren, um Updates zu erleichtern; andernfalls ist das Installationsskript der schnellste Weg. Es gibt zudem eine interaktive Browser-Demo (ohne Installation) unter https://pranshuparmar.github.io/witr/, die eine Linux-Maschine mit geführtem Tutorial und einem freien Modus simuliert.

Gängige Workflows

Nach Name verfolgen: witr node zeigt den Prozess, den Benutzer, den Befehl, wann er gestartet wurde, und die Kette systemd → pm2 → node, zusammen mit Arbeitsverzeichnis, Git-Repository und Sockets.
Einen Port auflösen: witr --port 5000 --short gibt die Kette in einer einzigen Zeile zurück, z. B. systemd (pid 1) → PM2 ... → python (pid ...).
Eine PID als Baum untersuchen: witr --pid 143895 --tree gibt den Abstammungsbaum aus und schließt bis zu 10 Kindprozesse ein, wobei das Ziel hervorgehoben wird.
Einen Container abfragen: witr --container redis durchsucht alle erkannten Laufzeitumgebungen (Docker, Podman, nerdctl, K8s/crictl, Incus, LXC, LXD, FreeBSD-Jails) nach Name, Image, Befehl oder Compose-Label; mit --verbose werden Mounts, Netzwerke und Compose-Metadaten hinzugefügt.
Gemischte Eingaben: witr nginx --port 5432 --pid 1234 zeigt die Ergebnisse sequenziell mit beschrifteten Trennlinien.
Nutzung im Skript: witr nginx --short; echo $? und je nach Exit-Code handeln (0 sauber, 2 nicht gefunden, 3 Berechtigungen usw.).

Wesentliche Konfiguration

witr verwendet keine persistente Konfigurationsdatei; die „Konfiguration” sind seine Flags, von denen ein neuer Nutzer zuerst diese anfasst:

-i, --interactive: öffnet die TUI. Wird auch automatisch ausgelöst, wenn keine Argumente oder Ziel-Flags angegeben werden.
-x, --exact: exakte Namensübereinstimmung (standardmäßig teilweise/fuzzy Übereinstimmung).
--json: maschinenlesbare Ausgabe zur Pipeline-Integration.
--no-color: deaktiviert Farbe (nützlich bei Umleitung in Dateien oder Logs).
--verbose: zeigt erweiterte Informationen (Mounts, Netzwerke, Compose-Metadaten usw.).

Alle Ziel-Flags (--pid, --port, --file, --container) sind wiederholbar und untereinander sowie mit Positionsargumenten kombinierbar. Shell-Completions werden mit witr completion bash|zsh|fish|powershell generiert.

Häufige Fallstricke und Lösungen

Fehlende Berechtigungen: witr untersucht Systemverzeichnisse, die erhöhte Rechte erfordern können. Dokumentierte Lösung: mit sudo witr [...] ausführen (Linux/FreeBSD) oder in PowerShell als Administrator (Windows).
Ein mit nohup abgekoppelter Prozess: Im Hacker-News-Thread wies Nutzer tatref darauf hin, dass ein abgekoppelter/nohup-Prozess mit PPID 1 (systemd) erscheint, was falsch war; der Autor bestätigte dies als ausstehenden Bug. Das ist eine bekannte Einschränkung der Abstammungsverfolgung in bestimmten Fällen.
macOS und SIP: Aufgrund der System Integrity Protection sind manche Systemprozess-Details selbst mit sudo nicht zugänglich.
Namensmehrdeutigkeit: Bei Abfrage eines Namens mit teilweiser Übereinstimmung listet witr die Treffer auf (z. B. nginx und ngrok) und bittet um erneute Ausführung mit --pid. --exact verwenden, um teilweise Übereinstimmung zu vermeiden.
Installation per curl: Mehrere Hacker-News-Nutzer (vzaliva) misstrauten der Installation einer Binary per curl. Der Autor antwortete, er habe es beim ersten Launch einfach gehalten und später offizielle Pakete hinzugefügt; heute gibt es .deb-, .rpm-, .apk-Pakete und Paketmanager als Alternative.
PID-Wiederverwendung in der Abstammungskette: Eine Product-Hunt-Rezension von Omri Ben-Shoham (31. Juli 2026) weist darauf hin, dass die Abstammungsverfolgung die Startzeit der Eltern-PID noch nicht validiert, was einen theoretischen Grenzfall der PID-Wiederverwendung offenlässt; laut der Rezension ist dazu bereits ein Issue eröffnet.

Integrationen und Migration

witr integriert sich über seine --json-Ausgabe und seine Exit-Codes in Skripte, CI und Monitoring-Tools. Das README zeigt ein Beispiel mit case $? zur Automatisierung. Der TUI-Modus spiegelt die Panel-Form für interaktive Nutzung. Zur Migration: witr ersetzt nicht ps/lsof/systemctl, sondern ergänzt sie; es kann als „Warum”-Schicht über den Statusinformationen genutzt werden, die das System bereits liefert. Die Web-Demo (docs/) dient als Äquivalent zu einem Tutorial, ohne die Binary zu installieren. Ports mit Socket-Aktivierung durch systemd oder eine Container-Laufzeitumgebung werden über einen Fallback via Docker-CLI aufgelöst.

Aktuelle Kennzahlen

Messung: 4. September 2026, GitHub-API.

Kennzahl	Wert
Sterne	22.073
Forks	772
Abonnenten	46
Commits	588
Offene Issues laut API	16
Hauptsprache	Go (676.496 Bytes); sekundär: Shell, PowerShell, Nix, Makefile
Lizenz	Apache-2.0
Erstellt	20. Dezember 2025
Letzte Metadaten-Aktualisierung	4. September 2026
Letzter Push	15. August 2026
Neuestes Release	`v0.3.3`, 24. Juni 2026

Top-Contributor laut API, nach Anzahl der Beiträge, waren pranshuparmar (398), claude (25), chojs23 (18), gaod (15), amerine (12), github-actions[bot] (11), ggmolly (10) und RikSmits06 (8). Der Wert 588 wurde aus dem Paginierungs-Header (rel="last" → Seite 588) des Commits-Endpunkts ermittelt. Die GitHub-API stellt open_issues_count bereit, das offene Pull Requests einschließen kann; daher sollte es nicht als reiner Issue-Zähler gelesen werden. watchers_count spiegelt die Sternezahl wider, daher wird subscribers_count separat als echte Abonnenten angegeben.

Community-Resonanz

Die gesammelten Belege stammen hauptsächlich aus dem Hacker-News-Launch-Thread (46392910), mit 526 Punkten und 105 Kommentaren, in dem der Autor selbst häufig antwortete. Die Begeisterung ist breit, und es gibt konkrete Kritik:

Anerkennung und Begeisterung:

dcminter: „This is very clever. I’ve often needed to figure out what some running process was actually for (…) but it never occurred to me that one could have a tool to answer that question. Well done.” Er fügte eine Ergänzung hinzu, die klarstellte, dass er fälschlicherweise dachte, es erkläre auch, was der Prozess tut.
properbrew: „This is extremely useful, will be added to the toolbox. Thanks for sharing.”
dontdieych: „Nice and installed then starred.”
scrame: lobte das Beispiel mit Port 3306 und sagte, „having a purpose to explain a purpose seems like a good pitch”.
Saris und canxerian: „This looks very handy to have around!” und „Great idea!”
techsystems: „I’m really loving this! ‘Responsibility chain’ will become a trendy phrase.”

Kritik und konkrete Einwände:

tatref wies auf einen echten Defekt hin: Die Verfolgung „only checks for the parent processes” und „a disowned/nohup process will show up as PPID 1 (systemd), which is not correct”. Der Autor antwortete: „Yes, this is a bug. Planning to fix it soon.”
darrenf stellte die Neuartigkeit infrage: „Is that not whatis?” Der Autor antwortete, dass whatis in diesem Fall helfe, er witr aber auf das Erklären von PIDs fokussiert halten wolle.
wyldfire argumentierte: „ps uaxf gives me pretty similar output.” Der Autor zählte die Unterschiede auf (wann es startete, welche Ports es nutzt, welcher Nutzer es startete, aus welchem Verzeichnis, --env-Flag, --json).
vzaliva wandte sich aus Sicherheitsgründen gegen die curl-Installation ein („doesn’t sit right with me”) und forderte .deb/Snap-Pakete; der Autor erklärte, es sei der erste Launch gewesen, und bestätigte später, dass Brew, AUR, deb/rpm/apk und Nix bereits vorhanden seien.
Ein Nebenstrang drehte sich um die GIF-Animation des READMEs: mh-, Neywiny, godelski und thaumasiotes baten darum, dass das Bild still stehe oder ein statischer Screenshot sei; der Autor antwortete, „already switched it to a static image”.
filterfish schlug vor, die Binary im Paketmanager (APT/dpkg) als zusätzliche Informationsquelle nachzuschlagen; ajb antwortete, dpkg -S erlaube das bereits.
klooney merkte an, dass systemctl status $pid bereits viel liefere, und jamescun schlug GoReleaser vor, das der Autor schließlich verwendete.
saidnooneever wandte ein, die Ausgabe zeige „wer es getan hat”, nicht wirklich „warum es gestartet wurde” (Service-Datei, Autorun, execve), da sie größtenteils nur die Eltern-PID als Ursache angebe, und empfahl, greppbare/JSON-Ausgabe standardmäßig für Automatisierung zu verwenden.
tototrains teilte eine Anekdote aus der Praxis: Claude Code fand mithilfe eines ähnlichen Tools einen Krypto-Miner, der auf einem aktuellen Windows-10-Rechner rund fünf Monate lang unentdeckt geblieben war, innerhalb von Minuten — eine individuelle Erfahrung, keine Projektkennzahl.

Jenseits von Hacker News. Das Projekt erscheint auch auf Product Hunt (Seite veröffentlicht am 30. Juli 2026) mit einer Bewertung von 5.0; eine dortige Rezension von Omri Ben-Shoham lobt, dass die Abstammungsverfolgung Container-Shims durchläuft bis zum tatsächlichen Host-Prozess, statt bei „Docker hat es gestartet” stehenzubleiben. Das Repository betreibt außerdem GitHub Discussions, mit Threads wie „Better README image needed!” (10 Kommentare) und einer TUI-Diskussion des Autors selbst (mit Verweis auf PR 59). Auf YouTube hat das Video „Stop Guessing. Debug Faster with WITR.” des Kanals Hack the Clown (27.700 Abonnenten) 8.170 Aufrufe.

In den konsultierten Quellen wurde keine Ankündigung mit breiterer Diskussion außerhalb von Hacker News gefunden, daher stammt die Bilanz aus diesem Thread, und es wird kein breiterer Konsens abgeleitet, als die Quellen zeigen.

Vergleich mit ähnlichen Projekten

Projekt	Verifizierbare Überschneidung	Verifizierbarer Unterschied
`ps`, `top`, `lsof`, `ss`, `systemctl`, `docker ps`	Native Tools, die Prozess-/Port-/Dienststatus offenlegen.	Das README erklärt, dass diese zeigen, was läuft, aber nicht warum; witr fügt die kausale Kette und den Kontext hinzu (Git, Container, Quelle).
`pstree`	Zeigt die Eltern-Kind-Hierarchie von Prozessen.	Auf Hacker News bestätigten `q2dg` und `mathfailure`, dass `pstree` „doesn’t answer the why” — es erklärt die Ursache nicht.
`whatis`	Erklärt, wozu ein Befehl gehört.	Der Autor erkennt es als nützlich für diesen spezifischen Fall an, aber witr fokussiert sich auf das Erklären von PIDs, nicht auf das Beschreiben von Utilities.
`rewrite-everything-in-rust/witr-rs`	Implementiert dasselbe Ziel (Abstammung verfolgen) in Rust neu.	Es ist eine Community-Neuimplementierung mit erklärter Parität, nicht das ursprüngliche Projekt.
`supervoidcoder/win-witr`	Implementiert witr für Windows in C++ neu.	WIP ohne den ursprünglichen Code; das ursprüngliche Projekt umfasst bereits Windows mit nativen Win32-APIs.
`dmitrymx/witr-gui`	Fügt eine grafische Oberfläche (Electron/React) über witr für Windows hinzu.	Es ist ein GUI-Client eines Drittanbieters, nicht Teil des offiziellen Repositorys.

Der nützlichste Vergleich: witr sticht hervor, wenn man die Ursache (nicht nur den Status) eines Prozesses oder Ports benötigt, portabel und mit programmierbarer Ausgabe. Native Tools bleiben das Rückgrat der Statusinformationen; Community-Ports (Rust, Python, C++, GUI) sind inoffizielle Varianten, die die ursprüngliche plattformübergreifende Binary nicht ersetzen.

Wie man beiträgt

Das Repository dokumentiert einen konkreten Prozess in CONTRIBUTING.md:

Aus dem Quellcode bauen: erfordert Go 1.25+; git clone, go build -o witr ./cmd/witr, und ./witr --help als schneller Test. Der -ldflags-Block injiziert Commit-/Datumsmetadaten für witr --version.
Fork-Ablauf: forken, den Fork klonen (git clone https://github.com/YOUR_USERNAME/witr.git), einen feature/your-feature-name-Branch erstellen und go mod download.
Entwicklung: dem bestehenden Stil folgen, gofmt, Unit-Tests schreiben und go test ./... sicherstellen.
Pull Request: Commits zu einem logischen Commit squashen, auf den staging-Branch rebasen (nicht main), den PR gegen staging öffnen, die PR-Vorlage ausfüllen, auf die Maintainer-Review warten und mit Squash and Merge mergen (strenge Richtlinie, um die Historie von main sauber zu halten).
Lokale PR-Validierung: test -z $(gofmt -l .), go vet ./..., go test -v ./... und Cross-Compilation-Prüfung (GOOS/GOARCH für linux/darwin, amd64/arm64), oder mit act (erfordert Docker): act -j validate, act -j build.

Die CI (.github/workflows/pr-check.yml) führt Lint mit golangci-lint auf den vier Systemen aus (linux, darwin, windows, freebsd), govulncheck für Schwachstellen, eine Prüfung, dass vendor synchron ist, Unit-Tests mit -race (auf Linux und macOS) und eine informative Coverage-Messung. Es gibt einen pr-title.yml-Workflow, der blockierend ist und semantische PR-Titel verlangt (amannn/action-semantic-pull-request). Das Commit-Nachrichtenformat folgt Conventional Commits (<type>(<scope>): <description>). Issues nutzen eine strukturierte Vorlage (bug_report.yml), die OS, Version und Architektur abfragt. Die Beitragslizenz ist Apache-2.0, und es gibt einen Verhaltenskodex.

Anwendungsfälle und wem dieses Repository helfen kann

Systemadministratoren und Operatoren, die sich per SSH auf eine unbekannte Maschine einloggen, können witr --port <port> oder witr <name> nutzen, um in Sekunden zu beantworten, welche systemd-/Supervisor-/Cron-/Container-Kette einen Dienst hervorgebracht hat, statt ps, lsof und systemctl zu korrelieren. Die „unter Stress”-Ausgabe und die Exit-Codes machen es für Vorfälle geeignet.
Wer eine Konflikt- oder Ressourcen-Port-Störung behandelt (z. B. EADDRINUSE), kann verfolgen, welcher Prozess einen Port belegt, wer ihn gestartet hat und aus welchem Verzeichnis/Git-Repo, und entscheiden, ob er gestoppt wird. Die TUI erlaubt das direkte Senden von Signalen (Kill/Terminate/Pause).
Engineering-/Sicherheitsteams können sich auf den Warnings-Abschnitt (Prozess als root, gefährliche Capabilities, öffentliches Lauschen, gelöschte Binary, LD_PRELOAD/DYLD_*-Indikatoren) für einen schnellen Angriffsflächen-Scan während einer Review stützen und --json in ihre Pipeline integrieren.
Entwickler, die debuggen, warum ein Prozess „nicht sterben will” oder von selbst startet, können den Supervisor sehen (pm2, cron, launchd, systemd-Timer), der ihn am Leben hält und neu startet, sowie den Container-Kontext (Docker/Podman/K8s/Incus/LXC).
Integratoren und Automatisierungs-Autoren können sich auf den --json-Modus und die Exit-Codes 0–5 verlassen, um witr in Skripte, CI oder Monitoring-Tools einzuketten.
Wer das Tool ohne Installation evaluiert, kann den Browser-Playground (https://pranshuparmar.github.io/witr/) nutzen, eine simulierte Linux-Box mit geführtem Tutorial, um sich mit den Ausgaben vertraut zu machen, bevor es übernommen wird.

Ressourcen

Repository: https://github.com/pranshuparmar/witr
Dokumentation / offizielle Website: https://pranshuparmar.github.io/witr/ (Browser-Playground, keine Installation)
Man-Page und CLI-Referenz: https://github.com/pranshuparmar/witr/tree/main/docs/cli
Installation: README (install.sh / install.ps1 / Paketmanager)
Ursprungsgeschichte (Medium): https://medium.com/@pranshu.parmar/witr-why-is-this-running-a9a97cbedd18
Releases: https://github.com/pranshuparmar/witr/releases
Community-Pakete: https://repology.org/project/witr/versions
Paketregister:
- npm @pranshuparmar/witr: https://www.npmjs.com/package/@pranshuparmar/witr (v0.3.3; ~78 Downloads im letzten Monat, ~17 in der letzten Woche laut npm-API zum Zeitpunkt dieser Prüfung)
- Homebrew: https://formulae.brew.sh/formula/witr (0.3.3, mit Bottle)
- conda-forge: https://anaconda.org/conda-forge/witr
- AUR: https://aur.archlinux.org/packages/witr-bin
- winget: https://winstall.app/apps/PranshuParmar.witr
Product Hunt: https://www.producthunt.com/products/witr
Hacker-News-Thread: https://news.ycombinator.com/item?id=46392910 (526 Punkte, 105 Kommentare)
Verwandte Community-Repositorys: rewrite-everything-in-rust/witr-rs, bobozi-cmd/witr-py, supervoidcoder/win-witr, dmitrymx/witr-gui

Methodischer Hinweis: Dieser Artikel stützt sich auf das README, die Release-Konfiguration und die Workflows des Repositorys, die GitHub-API, Paketregister (npm, Homebrew, AUR, conda-forge) und den am 4. September 2026 konsultierten Hacker-News-Launch-Thread. Stern-, Download- und Versionszahlen ändern sich mit der Zeit. Daten aus dem Medium-Artikel und die Upvote-Zahl von Product Hunt konnten in dieser Recherche aufgrund von Zugriffsbeschränkungen (HTTP 403) nicht im Detail gelesen werden, daher wird ihre Existenz zitiert, nicht aber ihre vollständigen Kennzahlen.