Better Dev Link

You’re sound asleep when the alarms go off. It’s 3 a.m. You wipe your eyes, check your phone. You know something is wrong. Very wrong. The website is down. Your application is broken. The only light in the room is coming from your computer monitor. The Gremlin in the system can be hiding anywhere, and it’s your team’s job to find it

Attempt to understand how Linux executables are organized, how they are executed, and how to make a program that takes an executable fresh off the linker and compresses it - just because we can.

To deal with synchronization, usually a set of primitives (mutexes, semaphores, monitors, and sometimes condition variables) are used to control read and write safely. It’s one of the most challenging, interesting, and (done right) fun. This book has the goal of identifying synchronization idioms and patterns that could be understood in isolation and then assembled to solve complex problems.

To measure scalability limit, a common approach is sending a bunch of GET/POST/PUT request to simulate production traffic. But this is only useful for API, with a normal webapp it becomes complicated. An alternate approach is the Utilization DRT (Disaster Recovery Test), with the goal of: Estimate the amount of headroom your service can handle in practice, Determine anomalies in behavior of your service when it’s overloaded.

The famous fast inverse square root is some mysterious code not written by programming legend John Carmack to calculate a fast approximation of 1/√x

Learn how clickjacking attacks implement visual tricks to capture users’ clicks, and how you can prevent them by applying client-side and server-side solutions

When you just want a simple mail server to receive incoming mail notification, this maybe very helpful. No fancy gsuite or zoho cuz that requires payment. A simple server would do that purpose. and it’s easier than it’s sound to receive your internal email such as devops/alert notification

There are two primary performance metrics for a task queue. Throughput is how many tasks are processed per time unit. Latency is how long a task waits in the queue before being processed. Throughput scales as you’d expect (2x workers ≈ 2x throughput) but latency is less intuitive. In this essay we will model a simple task queue and show how the latency is highly sensitive to our initial parameters.

This post contains a rough sketch of the life and death of a process on Linux. It is a first-order approximation only. A later post will refine this further and provide a more precise description, adding details about pid namespaces, obscure syscalls, and little known flags.

This part two of how to read a code. In the first post I asked how to make a change to an unknown code base with confidence. Knowing the architecture of it is a necessary but often not sufficient step. You can make changes. But I doubt it’s with confidence.