Adriksh @Adriksh

Compiler engineers are playing a different game. They don't care if your code works. They care if your code is well-defined. If it's UB, they will delete it to save 2 cycles.

Writing lock-free code is easy. You just put memory_order_relaxed everywhere until production segfaults on ARM, then add a fence and hope the compiler doesn't reorder your will to live.

Every postmortem eventually comes down to one sentence: We assumed that couldn't happen. Most production incidents aren't caused by a single catastrophic failure. They're caused by one assumption quietly becoming less true over time until everything built on top of it starts to crack.

Strace @straceX

a day ago

One storage incident has stuck with me because of how ordinary it looked. A large SaaS company was chasing database corruption that only seemed to appear after the occasional power event. The investigation went on for months because nothing pointed in the right direction. The

keyboard_arrow_left Previous keyboard_arrow_right Next

6 2 30 3K 8

TCP offload engines trade observability for performance. You move work from a predictable CPU to firmware running inside a NIC. When something breaks, you can't strace it, you can't gdb it, and the usual answer is: update the driver, update the firmware, reboot.

keyboard_arrow_left Previous keyboard_arrow_right Next

One storage incident has stuck with me because of how ordinary it looked. A large SaaS company was chasing database corruption that only seemed to appear after the occasional power event. The investigation went on for months because nothing pointed in the right direction. The SSDs looked healthy, Smart wasn't reporting anything unusual, and there wasn't an obvious hardware failure to blame. Eventually the focus shifted to the enterprise NVMe drives. Enterprise SSDs often keep writes and internal mapping data in DRAM, relying on power-loss protection to preserve that state if power suddenly disappears. The supercapacitors used for that job don't last forever, and years of heat can reduce how much energy they can deliver. Modern enterprise drives are designed with a lot of protection around this, so failures are uncommon. But if power-loss protection no longer behaves exactly as expected, recovery can become far more complicated than a failed drive or a RAID rebuild. You can end up investigating the filesystem, the database, or even the application before storage becomes a suspect. What I find unsettling isn't that components wear out. Everything does. It's that a system can continue reporting itself as healthy while one of the assumptions you built your reliability around is quietly becoming less true every day.

keyboard_arrow_left Previous keyboard_arrow_right Next

C++ ABI stability is the single biggest thing holding back the language. We can't change std::string or std::regex to be fast because 20-year-old shared libraries expect the old, broken memory layout.

Lock-free programming isn't hard because of atomics. It's hard because of memory reclamation. C++26 standardizes Hazard Pointers, allowing you to safely defer deleting a node until all concurrent readers are done with it.

Every generation of computing solves one bottleneck and creates another. CPUs waited on memory. GPUs waited on bandwidth. AI now waits on data and power.

Hmm, similarly... Everyone quotes tokens/sec. Nobody talks about cost per correct token. If Model A generates 300 tokens/sec but needs three retries because it hallucinates and Model B generates 100 tokens/sec but gets it right the first time... Model B is actually faster in the real world. Maybe the benchmark should be: Cost per correct token.

LaurieWired @lauriewired

5 days ago

you’ll get mad at me for saying this…but cloud gaming is so obviously more economically efficient than physical hardware I think it’s going to be the default soon. your home console / pc is idle 90%+ of the day. meanwhile, data centers targets what, 5%, maybe at worst 10% idle.

3K 168 4K 3.3M 1K

If your C++ move constructor throws an exception, std::vector::push_back cannot guarantee the strong exception safety guarantee. It will silently fall back to a copy constructor. Always mark your move constructors noexcept if you want vector reallocation to actually move.

Intel didn't lose to AMD. Intel lost to TSMC. AMD stopped fabricating silicon and became a fabless design house. TSMC's relentless node shrinking outpaced Intel's internal foundry, rendering AMD's chips physically superior by default.

Linux memfd_secret creates an anonymous file backed by memory that is completely inaccessible to the kernel itself. even root cannot read it via /dev/mem or ptrace. It's the ultimate primitive for storing cryptographic keys in userspace.

The reason GPUs have thousands of cores isn't because individual cores are weak. It's because memory latency is brutal lol.

The hardest bugs to find are the ones where the code does exactly what you told it to do, but the hardware decided to reorder your memory operations because you thought x86-TSO semantics applied to your new ARM deployment.

fsync() doesn't actually guarantee your data is on disk. It guarantees the kernel asked the storage controller to flush its write cache. If the controller lies to the kernel (and consumer SSDs almost always do), a power loss still corrupts your database.

A junior dev said he'd fix the production database on the count of three. He opened the terminal, typed DROP TABLE users;, counted Uno, Dos... and then disappeared w/o a trace.

People say C gives you enough rope to hang yourself. C++ gives you a loaded gun, but the trigger is a template metaprogramming error and when you pull it, you accidentally shoot a dog in a different namespace.

why is no one talking about this?

The bug wasn't fixed. It just never met ARM64.

Profiling CPython with cProfile is useless for finding CPU bottlenecks. cProfile measures function call overhead, which is massive in Python. you just see that len() took 4 seconds. use py-spy or perf.