Been writing a ptracer, playing pwnable.kr, and played Google CTF a few weekends back.
man pages for process_vm_writev, process_vm_readv, memfd_create, and ptrace
__WALL in wait - if you use O_TRACECLONE and you want to trace all the threads of your traced process and its children, you need to use __WALL in the flags to wait/waitpid. Otherwise your tracer won't be notified properly of events in non-main threads of your tracees. This may no longer be necessary for newer kernels, but it sure is on older ones.
SIGSTOP on launch - immediately after your tracee calls ptrace with PTRACE_TRACEME, it should raise SIGSTOP. Otherwise there is a race, where your tracee can exec and do whatever it pleases for a while before your tracer gets around to attaching to it.
Don't trust PTRACE_GETEVENTMSG's exit status for the tracee during a PTRACE_EVENT_EXIT on 4.9 kernels - if your tracee is exiting due to a signal, geteventmsg reports the exit status as positive rather than negative (for example, during an exit due to a segmentation fault, the process will actually exit with status -11, but geteventmsg will say that it is exiting with status 11... which makes it very difficult to tell if the tracee is actually dying with a signal, or just exiting with a weird return code). It also returns 1 instead of -1 for SIGHUP on a 3.13 kernel. Don't trust it.
Network Science, chapter 8 - this is really what I started this book for in the first place. After setting it aside for six months, I determined to cut to the meat and then work my way backwards. It was actually a very interesting chapter - some of his conditions for cascade failures sound a lot like the mechanism of action for neural networks (flow over a network, and each node has a local breakdown rule that determines whether it rebroadcasts the cascade). The inherent tradeoffs between resistance to random failures and resistance to targeted attacks were also unexpected and worthwhile.
T.E. Lawrence's Evolution of a Revolt. Also interesting in terms of successful adversarial thinking; enumerate enemy weaknesses in terms other than the obvious targets for attrition.
Brooks' No Silver Bullet. Much of what he says on the essential difficulty of software still rings true; much of his pessimism on the popular emerging technologies of his time has been vindicated. I'm a little skeptical today of "buy instead of build", because my experience so far has been that external dependencies are also full of bugs and in the worst-case, a high-priority bug in an external dependency will take longer to fix than in an internal one (but on the converse, they do enable force multiplication in the average case, by increasing the effective total labor available. It's just less immediately allocable). I think incremental development and "grow software instead of building it" is mostly-correct, though a somewhat missed point. My perception of the industry today is that the two primary metaphors for software are building software (more on the enterprise side) and cooking software (more on the devops side), and that the biological metaphor has been lost and certainly hasn't won. Definitely something to keep in mind in my own practice. Finally, on great designers, I think he's mostly right, that great software is the product of one or a few minds, rather than committees (conceptual integrity). I do find it curious that he commits the common error of misinterpreting Peopleware's results on productivity, claiming that the gap between average and peak is 10x, whereas Peopleware argued that the gap between the very worst and the very best was 10x. Perhaps he had other sources. Finally, I am saddened that I have zero career development plan, with anything resembling apprenticeships or opportunity for advanced study outside of my daily duties.
Ran into some bugs related to SIGHUP recently, ended up reading The TTY Demystified and found it quite useful.