yet - you still have to learn opaque crap. example
echo kill > /proc/123/ctl
Sure, that works if you know kill, but you cannot inspect ctl and understand the interface, its a write interface. so you can certainly RTFM, read the dev proc list, etc. it's not discoverable
so like /proc/net/stat or whatever, it means nothing to me... its gonna just be a TSV of bytes that mean something, unless you know it.
so for all the simplicity, it's what i would call, not very usable.
Ok, but there's nothing stopping from writing a "discoverable" GUI or TUI or CLI for this interaction.
To the user it doesn't matter.
To the developer, it makes a difference.
/proc/<pid>/ctl is not any more or less simple or discoverable for the end user than TerminateProcess or kill(2). It's all opaque esoteric stuff.
But for the developer /proc/<pid>/ctl is MORE discoverable than TerminateProcess or kill(2), since it's a file you can list, so you know it exists. Yeah, you still have to read the man page (you always have to read the docs as a developer), but you know there's a ctl file that probably controls some stuff about the process there. And you already know how to interact with it (the same IO interface as everything else).
I guess in theory there is nothing stopping the system from providing yet other files, like say "/proc/123/ctl/description" which provides a human-readable description of what "/proc/123/ctl" does, and "/proc/123/ctl/schema" which provides a standardized schema for interacting with the parent, akin to a XSD or JSON Schema.
echo kill > /proc/123/ctl
Sure, that works if you know kill, but you cannot inspect ctl and understand the interface, its a write interface. so you can certainly RTFM, read the dev proc list, etc. it's not discoverable
so like /proc/net/stat or whatever, it means nothing to me... its gonna just be a TSV of bytes that mean something, unless you know it.
so for all the simplicity, it's what i would call, not very usable.