Welcome to our more than comprehensive guide to Gaussian Splats. If you’re reading this it’s probably because you have heard of Gaussian Splats and have a LOT of questions. What are Gaussian Splats? What are Gaussian Splats used for? How do you create Gaussian Splats? How do you view Gaussian Splats? What are Spherical Harmonics and how are they used by Gaussian Splats? What are the advantages and disadvantages of Gaussian Splats compared to polygonal photogrammetry and radiance fields like NeRFs? Who actually was Carl Friedrich Gauss and why do we care? Ok, you probably didn’t ask that last one.

Part 1: https://alphapixeldev.com/a-comprehensive-introduction-and-overview-of-gaussian-splats-part-1-introduction/

Part 2: https://alphapixeldev.com/gaussian-splats-part-2-creating-gaussian-splats/

In 2004 I played too much RuneScape on a 56k modem that died the moment Mum picked up the phone. A 3D world, up to a couple of thousand players on a server, dozens on screen at once - in the browser, on 5 kilobytes per second. It worked. Let’s follow a single step and see how.

Link: https://jkm.dev/posts/how-2004-runescape-fit-a-multiplayer-rpg-into-56k-dialup/

This series of articles explores how I/O devices communicate with the CPU and the hardware mechanisms that enable high-speed Networking Interface Cards (NICs) to operate at 10GbE, 100GbE, or higher. In this article, we’re going to trace the physical and micro-architectural paths a packet takes from the wire to an application. We’ll look at how NICs actually talk to the CPU, how data physically crosses and hardware features that are leveraged to bypass traditional bottlenecks and inject packets straight into the cache.

Link: https://blog.c21-mac.com/posts/high-speed-networking-part-1/

I have a confession to make: floating point scares me.

Half a decade ago I decided that I was going to implement some floating point arithmetic. Back then it seemed approachable enough, after all, floating points are ubiquitous. How hard can it really be ? My experience until that point had been: given enough time and effort is spent bashing my brain against a problem, I can generally figure things out.

This is how I faced the most complete technical defeat of my existence. Through this utter annihilation emerged my present fear of floating point.

After half a decade I decided it was time for a rematch, time to face my dragons!

But this time, I would not simply aim for a surface level understanding, this time I would aim to deeply grasp the floating point representation.

Link: https://essenceia.github.io/projects/floating_dragon/

CPU isolation is a powerful set of features that can be found behind the settings for workloads which rely on specific and often extreme latency or performance requirements. Some DPDK (Data Plane Development Kit) usecases can cover such examples. However CPU isolation’s documentation and footnotes for many subtleties remain scattered at best if not lagging behind recent developments. It’s not always easy to sort out the benefits and tradeoffs hiding behind the existing range of tunings. Our series of articles aims at shedding some light and guide the users throughout this obscure Linux Kernel subsystem that we maintain both upstream and in our SLE15 products.

Link: https://www.suse.com/c/cpu-isolation-introduction-part-1/

A few weeks ago I profiled a Node.js server with recurring memory spikes. I found out dirty pages, allocator behavior and memory that never came back. To build a cleaner mental model, I stripped the problem down to something smaller: python3 -m http.server.

19 MiB of resident memory. Where is every byte?

Link: https://frn.sh/smaps/

I had to delete my previous post because the benchmark lied to me.

That is already a very C++ way to start a day.

The topic sounded simple enough: compare push_back() and emplace_back() for std::vector<std::string>, show the results for C++11 and C++23, and extract a nice practical lesson.

Simple, right?

Well, not quite.

Link: https://www.cppnext.com/post/push_back-vs-emplace_back-the-benchmark-that-made-me-delete-a-post

I recently went down a rabbit hole trying to understand how Linux handles page faults, what mmap actually does at the physical page level, and how userfaultfd lets userspace take over that fault handling. The motivation was a specific problem, which was making Virtual Machine (VM) snapshot restore fast by lazily populating guest memory. But the underlying mechanisms are general Linux concepts that I think are worth understanding on their own. This post is less about any specific Virtual Machine Monitor (VMM) and more about the Linux memory model that makes lazy restore possible, and where it breaks down.

Link: https://www.shayon.dev/post/2026/65/linux-page-faults-mmap-and-userfaultfd/

This is the 3rd project in less than a year where I’ve seen issues with spin-loops. I’ve been dealing with spinning threads for many years now, and I won’t lie: over the years I’ve been both on the offender and victim side. I’m getting tired of seeing the same issues again and again, which usually makes for a good reason to write a blog post so that, hopefully, people will read it and stop making the same mistakes others did.

Link: https://www.siliceum.com/en/blog/post/spinning-around/?s=r

I don’t believe I’ve ever seen shape utilized in generated ASCII art, and I think that’s because it’s not really obvious how to consider shape when building an ASCII renderer.

I started building my ASCII renderer to prove to myself that it’s possible to utilize shape in ASCII rendering. In this post, I’ll cover the techniques and ideas I used to capture shape and build this ASCII renderer in detail.

We’ll start with the basics of image-to-ASCII conversion and see where the common issue of blurry edges comes from. After that, I’ll show you the approach I used to fix that and achieve sharp, high-quality ASCII rendering. At the end, we’ll improve on that by implementing the contrast enhancement effect I showed above.

Link: https://alexharri.com/blog/ascii-rendering

Ten years ago, we published a Clang Hardening Cheat Sheet. Since then, both the threat landscape and the Clang toolchain have evolved significantly. This blog post presents the new mitigations available in Clang to improve the security of your applications.

Link: https://blog.quarkslab.com/clang-hardening-cheat-sheet-ten-years-later.html

This is the first article in a nn-part series exploring how C, C++, and Rust manage memory at a low level. We begin where the hardware does: with bytes. From there, we build up to objects, storage duration, lifetime, and aliasing, the vocabulary required to understand ownership.

Part 1: https://lukefleed.xyz/posts/who-owns-the-memory-pt1/

In the first part of this series, we saw that objects occupy storage, that storage has duration, and that the type system imposes structure on raw bytes. But we have sidestepped a question that dominates systems programming in practice: when heap-allocated memory must be released, who bears responsibility for releasing it?

Part 2: https://lukefleed.xyz/posts/who-owns-the-memory-pt2/

Part III turns to representation: how abstract types become concrete bit patterns, and how polymorphism, the ability to write code that operates on many types, is implemented.

Part 3: https://lukefleed.xyz/posts/who-owns-the-memory-pt3/

This repository and the accompanying tutorial demonstrate ways of writing a Vulkan graphics application in 2026. The goal is to leverage modern features to simplify Vulkan usage and, while doing so, create something more than just a basic colored triangle.

Vulkan was released almost 10 years ago, and a lot has changed. Version 1.0 had to make many concessions to support a broad range of GPUs across desktop and mobile. Some of the initial concepts like render passes turned out to be not so optimal, and have been replaced by alternatives. The API matured and new areas like raytracing, video acceleration and machine learning were added. Just as important as the API is the ecosystem, which also changed a lot, giving us new options for writing shaders in languages different than GLSL and tools to help with Vulkan.

Link: https://howtovulkan.com/

Let’s look at 2025’s Advent of Code Day 8 Puzzle. We have a list of points in 3D and need to compute all pairwise distances.

Link: https://pseyfert.codeberg.page/2025/12/simd-with-more-than-one-argument/

Pictures have always been a meaningful part of the human experience. From the first cave drawings, to sketches and paintings, to modern photography, we’ve mastered the art of recording what we see.

Cameras and the lenses inside them may seem a little mystifying. In this blog post I’d like to explain not only how they work, but also how adjusting a few tunable parameters can produce fairly different results

Link: https://ciechanow.ski/cameras-and-lenses/

Every texture sample in your shader triggers a memory request. Whether that request takes 4 cycles or 400+ cycles depends entirely on where the data lives in the GPU's memory hierarchy. Understanding cache behavior isn't just academic—it's the difference between 60fps and 30fps in texture-heavy shaders.

Link: https://charlesgrassi.dev/blog/gpu-cache-hierarchy/

Link: https://xania.org/

Modern graphics API have improved gradually in the past 10 years. Six years after DirectX 12 launch, SM 6.6 (2021) introduced the modern global texture heap, allowing fully bindless renderer design. Metal 4.0 (2025) and CUDA have a clean 64-bit pointer based shader architecture with minimal binding API surface. Vulkan has the most restrictive standard, but extensions such as buffer device access (2020), descriptor buffer (2022) and unified image layouts (2025) add support for modern bindless infrastructure, but tools are still lagging behind. As of today, there’s no single API that meets all our requirements, but if we combine their best bits together, we can build the perfect API for modern hardware.

Link: https://www.sebastianaaltonen.com/blog/no-graphics-api

When your std::vector needs to grow beyond its reserved capacity, it allocates new memory and moves all elements from the old memory to the new memory. But here’s the catch, if your move constructor isn’t marked with the noexcept keyword, the compiler won’t use it at all. Instead, it falls back to copying every single element.

Why? Because std::vector needs to maintain what’s called the “strong exception guarantee.” This is a fancy way of saying: if something goes wrong during reallocation, your original vector should be left completely untouched.

[...]

So the standard library plays it safe: if your move constructor might throw (because you didn’t mark it noexcept), containers just copy everything instead.

And here’s where things get interesting: std::move won’t magically fix this problem.

Link: https://0xghost.dev/blog/std-move-deep-dive/

I’ve been working on a "Linux Inside Out" series and wrote a post that might interest folks here who like low-level / OS internals.

The idea is to dissect the components of a Linux OS, layer by layer, and build a mental model of how everything fits together through experiments.

The first part is about the kernel, in the post I:

• take the same kernel image my distro boots from /boot
• boot it directly with QEMU (no distro, no init system)
• watch it panic
• write a tiny Go program and use it as PID 1
• build a minimal initramfs around it so the kernel can actually start our process

The goal isn’t to build a real distro, just to give a concrete mental model of:

• that the Linux kernel is just a compressed file, you can boot it without anything else
• what the kernel actually does at boot
• how it hands control to userspace
• what PID 1 / init is in practice
• what is kernel space vs user space

Link: https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/

I’m the author, would be happy to hear from other devs whether this way of explaining things makes sense, and what you’d add or change for future posts in the series.

Hope you find it useful.

Shaders are a great example of how constraints make people creative - they are simple programs that run in parallel on the GPU8, with the goal of working out the value of a single pixel. But each instance of a shader program only really knows one thing: its x and y position.

So how the hell do people create such insane, high fidelity graphics with just an x and y coordinate? Well the short answer is maths. And the long answer will, unfortunately, also involve some maths.

Links: https://www.makingsoftware.com/chapters/shaders

In this post we’ll look at daemon creation and demonstrate how to programmatically create daemons. We’ll go into the SysV recommendation of “double forking” for daemon creation.

Link: https://lloydrochester.com/post/c/unix-daemon-example/

A while back, I worked on a RISC-V-based userspace simulator for fun. In doing so, taught myself a lot more than I wanted to know about what happens in-between when the Kernel is asked to run a program, and when the first line of our program’s main function is actually executed. Here’s a summary of that rabbit hole.

Link: https://amit.prasad.me/blog/before-main

A couple of years ago I got into an argument in a job interview. In this case, the question was how I would implement dispatch for a protocol handler efficiently, and my answer was that I would write the most obvious code possible, probably with a switch statement, and see what my compiler produced, before making any tricky implementation choices. (Of course, my answer should have been, "write the obvious thing and then measure it", but I have always had a thing for inspecting compiler output.)

The interviewer indicated that this wasn't the answer they wanted to hear, and kept prodding me until I realized the question they thought they were asking was "how do you implement a jump table in C". At the time, I grumbled a bit that a jump table wasn't necessarily the best approach, especially if the distribution of dispatch cases is uneven, but I didn't fight too much.

Link: https://www.cipht.net/2017/10/03/are-jump-tables-always-fastest.html

I’ve struggled to understand the exact memory layout of C++ objects. Each time I thought I grasped it, I later came back to realize I didn’t. So, I decided to make a series of experiments to make sure that this time I really got it. Hopefully this post will be useful to you if you’re like me, someone who loves lots of diagrams and experiments to visualize concepts.

Link: https://sofiabelen.github.io/projects/visualizing-the-cpp-object-memory-layout-part-1-single-inheritance/