11–20 of 45 posts
I'm not familiar with the Windows version of ProcMon, but judging by the Linux version, that looks like it's primarily replicating the function of `strace` in a CLI GUI. Worth reading Joe Damato's excellent article on strace: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...
I'm not familiar with the Windows version of ProcMon, but judging by the Linux version, that looks like it's primarily replicating the function of `strace` in a CLI GUI. Worth reading Joe Damato's excellent article on strace: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...
Yes, ProcMon is the Windows equivalent of strace, with some filtering capability built-in. It also shows you the stack involved with a particular event, which can be useful for diagnosing the otherwise black box that is Windows. Eg [1] [1]: https://github.com/msys2/MSYS2-packages/issues/138#issuecomm...
Something that is really cool about Sysinternals tools are that they have a pretty usable GUI (granted, once you need to understand what does each UI icon do). Mimicking this experience in the TUI/terminal would certainly be a challenge. I would love to have a Procmon and ProcessExplorer equivalent with the GUI on Linux and macOS.
without them, there was no real visibility into open file descriptors, network ports, command lines for running processes, thread trees for processes or any of the rest.
the gui was always just the windows way of presenting it. bringing a gui when the rich tools already exist on linux seems ... redundant?
(seeing this brings back nightmares from windows admins who refused to install sysinternals tools on production machines)
This seems to be using eBPF, so presumably your kernel will have to support that (only stating Ubuntu 18.04 is a bit unfortunate).
18 is already 3-4 years ago :)
Presumably it isn't, and the README should list the actual requirements (kernel versions, etc.), with a note to the effect of "packages are available for Ubuntu LTS releases since 18.04".
I'm not familiar with the Windows version of ProcMon, but judging by the Linux version, that looks like it's primarily replicating the function of `strace` in a CLI GUI. Worth reading Joe Damato's excellent article on strace: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...
Original ProcMon used ETW, Event Tracing for Windows; the analogous technology (although very different in style) on Linux is eBPF so that’s what this tool uses.
What are the differences between this and htop, by example? I know htop can strace processes with the "s" key.
Which useful feature does this tool have what htop does not have?
Let's say there is such a feature. Why did they not implement it in htop? Made a patch and offered it to upstream? This is why we have FOSS. To benefit from each other's work.
Something that is really cool about Sysinternals tools are that they have a pretty usable GUI (granted, once you need to understand what does each UI icon do). Mimicking this experience in the TUI/terminal would certainly be a challenge. I would love to have a Procmon and ProcessExplorer equivalent with the GUI on Linux and macOS.
i always thought of the sysinternals tools as like the missing tools that just ship with unix systems. without them, there was no real visibility into open file descriptors, network ports, command lines for running processes, thread trees for processes or any of the rest. the gui was always just the windows way of presenting it. bringing a gui when the rich tools already exist on linux seems ... redundant? (seeing th…
I haven't used Process Monitor/Process Explorer for a while, are they bringing anything to the table that's not covered by htop? With htop, I can even start tracing a process (using strace) or list the file opened by a process (using lsof) right inside htop. As might be obvious by now, I think htop has a fantastic TUI that also fits its use case very well.
Of course there are other tools that allow deep introspection into what's really going on aside from htop. Another favorite of mine would be perf top, which uses the sampling profiling mechanism to profile the entire system (including the kernel) on a symbol/instruction level. In other words, you don't just see that 30% of CPU time is spent in /usr/bin/cpu_hog, you also see that the time is spent in some_symbol and you can jump right in and see disassemble some_symbol (as long as cpu_hog is not stripped).