Does a nice job explaining how the scheduling can be investigated from outside the kernel. It is a good introduction on the topic.

Interesting dive into an heisenbug... Definitely not easy to debug.

Very nice article on the Wikipedia success. Or why being boring and the ultimate process pettiness became the crucial part of the formula. This community really developed a fascinating culture which so far resists to mounting political pressure... But will the editors morale hold?

Interesting ways to look at processes and their outcomes. Depending on the mental model you won't ask the same questions when investigating incidents.

Looks like an interesting little profiling tool. The article explains quite well how it's been done. Can be a nice blueprint to make other such tools.

This is too often underestimated. This article shows nice uses of job control.

Interesting deep dive in where the PIDs seen in user space come from. And also yes, there is something matching PID 0 which can be traced back to early UNIX systems.

Interesting results. It's especially nice to see how sched-ext allows to easily iterate and experiment with process scheduling strategies.

Definitely a recent and lesser known to interact with other processes. Could be useful in some cases.

Interesting article, shows quite well the complexities of D-Bus and Polkit. Unsurprisingly such complexity easily leads to mistakes which can compromise security. This then hints to interesting things to keep in mind when you have to deal with D-Bus and Polkit.

Interesting API for running subprocesses and interact with files.

Interesting, I didn't know that user space schedulers were coming to Linux. It opens the door to exciting experiments.

I like this kind of rabbit holes. This gives a few interesting information on how forking processes behaves on Linux.

Looks like a good resource for someone who needs to get into IPC mechanisms on UNIX flavors.

Unfortunately seems to subscribe to the 10x programmer myth at least partly while trying to debunk another one... apart from that, it was very insightful, shows well how it's a team sport and how you want people to complete each other. The whole "rockstar developer" thing is a recruitment marketing scheme.

Lots of good advices about processes and organizations. It's nicely points out that friction is not necessarily wrong... if you get something out of it.
Also neat reminder in there that code review are here to complete work which is already socialized somehow. If you can't find reviewers it's a sign of an organizational problem when the work started.

A good reminder that there is not a one size fits all solution in the tech world. Also be skeptical of the silver bullets that "obviously" everyone should use. Project context matters above all.