Hector Martin

it's a really extreme level of "well actually", but you _can_ mmap a bunch of memory, write some code to it, mprotect it RX, map some space for a stack, then call clone() to start a new process running that code, without it ever having to exist as an executable on-disk

(which is ultimately very similar to how a JIT works, just, those usually create threads within an existing process, or have existing threads jump into the generated code, rather than creating a whole new process to run it)

also, SIGSTOP can't be blocked or have its handler overridden, just like SIGKILL

linux _can_ be configured not to expose /proc/X/cmdline to all users, but it's usually not so the advice is good regardless

2 processes _can_ write to the same file at the same time, but the writes aren't guaranteed to be atomic; bytes from one write can interleave between bytes from another! It's important to use some sort of locking mechanism when this isn't acceptable (pipes have _some_ guarantees)

a new process may not have its own command line: - If it's spawned with fork() and not followed with an exec[vpe](), it'll inherit its parent's - With exec[vpe]() and posix_spawn(), you can set a zero-length arg array …

... - in a process created with clone(), you _can_ unmap the argv space from the original process and then effectively have no args at all, though at that point if you try to do anything _normal_ again (like call libc functions) you're liable to have a bad time

these are always really interesting because when the answer to "can you do <wild ridiculous thing>" the answer is almost never "no", but instead "well technically you _could_ but it's a tremendously bad idea" and lead to me finding out about even more absurd linux features