The osquery query packs are especially useful: https://osquery.io/docs/packs/
Here is an incomplete draft about a similar post:
For a quick global view I like atop, then if I need to drill in a subsystem, iftop, vmstat, free, etc...
And playing around with it, i find that it is more elaborate than i first anticipated. The menus can even be operated via the scroll wheel, and it is sensitive to where the mouse is hovering.
All in all i find myself pondering if more up to date console web browser is possible. Perhaps using the framebuffer rather than X to display sites (or maybe go all out and implement it using sixel).
Also- if you're on a Mac and you use tmux I just started trying out the tmux integration with iterm2. Pros and cons but it's interesting to see first class OS windows for tmux.
Edit: add missing iterm2 reference. https://gitlab.com/gnachman/iterm2/wikis/TmuxIntegration
There can be a lot of edge cases, and inevitability things will change in the future. Centralising the work of parsing /proc files goes a long way and helps keep things sane for maintenance.
Admittedly, probably rare. But why route through calls to `fopen()` and `read()` when you could just provide a function that returns OS-defined structs?
Or will operations on a file descriptor corresponding to an exited process fail?
The problem is that those old calls have immense, immense inertia. They are how people think of files. They are how almost all, if not actually all, higher level languages interact with files by default, saving the "correct" calls for external modules, if you even get that. In fact, many higher-level languages are actively inimical to correct file handling by trying to abstract away the "file handle" so you only have to deal with file names, but for correct handling you really need to consider the file handle the real file and the file name merely a transient method for obtaining a file handle, which is to be never used again once you have the handle.
Bear in mind the "crappy" API in question is probably older than you are, so it's not really that surprising that it has needed some work as our world has changed.
signalfd gets this bit right.
It didn't take much POSIX programming before I started to look at Windows in a whole new light...
I'd be careful saying that any API based around signals is "right". In general, signals are just horrible and I really wish that the UNIX history had played out differently.
And this is Unix, so you can't do anything without running a process ;) - and I think PIDs and threads share a namespace on Linux, too, so the chance of wraparound is even higher again. (I also don't think there's any guarantee that PIDs will be a simple incrementing counter in the first place! Though that's the most obvious thing to do, so you can probably indeed be pretty certain that's exactly what will happen..)
OS X has a 64-bit thread ID that promises to be unique across all threads for the uptime of the system. What a good idea! - no prizes for guessing whether this comes from the BSD part, or the Mach part...
(Even in a single core world I suspect you'd hit a lot of resistance in any method you could use to take an atomic state, for performance reasons. Even just telling the kernel to "stop doing everything else and give me a copy of all this information" is not going to go over well.)
The fact that you can't get that info easily on Linux makes a lot of tools harder to write than they should be, and often give misleading/incorrect information.
The OSX one, I don't know; I scanned over the docs and it went over my threshold for what I'm willing to poke through for a HN post.
In other words, this is exactly what I left myself an out for, and I see nothing that contradicts what I said for the Windows case.
...and there's a general history here:
The part that may be specific to Linux is Linux provides a text-based interface, whereas systems like Solaris provide a binary interface.
Also interesting is that early Unix systems (before v8) used `ptrace()` for gathering process information - the same system call programs like strace/ltrace use today.
As I said before, the only thing that's really Linux-specific is Linux chose to represent it as text instead of something machine-parsable.
There was interesting work happening on a proposed newer api though, "task_diag" https://lwn.net/Articles/685791/ https://criu.org/Task-diag.