This shader is more than just a piece of fan art. I built this 4-Star Dragon Ball shader as a bridge between simple 2D shapes and complex 3D optics. If you’re looking for an introductory shader to study, this is a perfect playground because it moves past "drawing a box" and dives into how light behaves. What makes this unique as a case study is the Double March. We are treating the sphere as a physical lens. Once you hit the "glass," the shader calculates a bent path and starts a second march inside. It’s my attempt at playing with coordinate transformation.

1. Defining the Stars (2D SDFs)

The internal stars are defined using 2D Signed Distance Functions. an SDF is a function that takes a point in space and returns the distance to the nearest surface.

• If the distance is positive , you are outside the object.

• If the distance is negative , you are inside.

• If it is zero , you are exactly on the surface.

This allows us to define perfect geometric shapes without textures. The specific star logic used here, sdStar5, is a direct implementation of Quilez's formulas found in his 2D Distance Functions article.

// Helper to map the 4 stars in 2D
float map4Stars2D(vec2 p) {
    float offset = 0.22;
    float radius = 0.15;
    float d1 = sdStar5(p - vec2(offset, offset), radius, 0.45);
    float d2 = sdStar5(p - vec2(-offset, offset), radius, 0.45);
    float d3 = sdStar5(p - vec2(offset, -offset), radius, 0.45);
    float d4 = sdStar5(p - vec2(-offset, -offset), radius, 0.45);
    return min(min(d1, d2), min(d3, d4)); // Union of all four stars
}

2. Extrusion and 3D Modeling

To turn these flat stars into 3D geometry inside the sphere, we use Extrusion. By combining the 2D distance with the Z-axis, we create a volumetric shape. This technique, along with the rounding (beveling) seen in the code, is detailed in Quilez’s 3D Distance Functions article.

float mapStars3D(vec3 p) {
    float d2d = map4Stars2D(p.xy);
    vec2 w = vec2(d2d, abs(p.z) - 0.04); // abs(p.z) defines thickness
    return min(max(w.x, w.y), 0.0) + length(max(w, 0.0)) - 0.015;
}

3. The Raymarching Engine

How does the computer "see" these math functions? For a short intro think of it this way. Since we don't have triangles, we can't use standard rasterization. Instead, we use Raymarching.

Imagine firing a ray from your eye through every pixel. Instead of moving in tiny constant steps, the ray "leaps" forward by the distance returned by our SDF. Because the SDF tells us the distance to the nearest object, we know it's safe to move that far without hitting anything. We repeat this until the distance is nearly zero (a hit!) or we've gone too far (a miss).

For a full deep dive into the algorithm that powers almost every modern Shadertoy, read Quilez's Raymarching Distance Fields.

In our code, this is the loop that "steps" through space until it finds the sphere or the floor.

for(int i = 0; i < MAX_STEPS; i++) {
    p = ro + rd * dO; // Current position along the ray
    dS = map(p); // Distance to nearest object
    dO += dS.x; // "Safe" jump forward
    if(dO > MAX_DIST || abs(dS.x) < SURF_DIST) break;
}

4. Optical Physics: Refraction & Reflection

To simulate glass, we don't just "draw" it; we simulate how light behaves at the boundary of two materials.

• Fresnel Effect: We use the dot product of our view ray and the surface normal to decide if we see the interior (refraction) or the exterior (reflection).

• The Nested March: When the ray enters the sphere, it bends. The code then starts a new internal raymarch loop. This is what allows the stars to look magnified and distorted by the glass.

vec3 refractDir = refract(rd, n, 1.0 / 1.52); // Bending light into glass
// ... inside the sphere ...
float volumetricGlow = exp(-minStarDist * 18.0); // Creates that resin-like haze
refractCol += emissiveStar * volumetricGlow * 0.45;

5. Analytical Caustics & Chromatic Aberration

The glowing star patterns on the floor are caustics. Caustics are those dancing, wavy patterns of light you see at the bottom of a swimming pool or the bright "ring" at the base of a wine glass. They happen whenever a curved, transparent surface like water or a glass ball acts as a lens, grabbing scattered light rays and bunching them together into concentrated, glowing shapes.

I achieve this by using iSphere to project the floor's coordinates back into the star field.

To add realism, I implement **Chromatic Aberration **splitting the light into R, G, and B components by shifting the UV samples slightly.

Chromatic Aberration is a lens effect that creates a "rainbow fringe" around sharp edges. It happens because glass doesn't bend all colors of light equally; red light bends a little less than blue light. In a shader, you mimic this by "splitting" the image into its red, green, and blue components and shifting them slightly so they don't perfectly line up, giving the scene a realistic, cinematic look.

float shift = 0.015; 
float dR = map4Stars2D(distortedUV * (1.0 - shift));
float dG = map4Stars2D(distortedUV);
float dB = map4Stars2D(distortedUV * (1.0 + shift));
vec3 starShadow = vec3(smoothstep(0.03, -0.03, dR), ...);

The "Secret Sauce": Why This Works

The uniqueness of this shader lies in its **layered approach**. It isn't just one distance field; it’s a coordinate-space transformation. By distorting the UVs on the floor (distortedUV), I simulate the way a magnifying glass bends light, creating a dynamic caustic pool that responds to the pulsing of the internal emissive stars. I was really trying my best to simulate the below image.

Conclusion

Writing shaders is about translating the laws of physics into the language of mathematics. By combining Inigo Quilez’s SDFs with Raymarching, you can build complex, beautiful worlds with nothing but a few lines of GLSL.

References & Further Reading:

• Raymarching Distance Fields (Quilez)
• 3D Distance Functions (Quilez)
• 2D Distance Functions (Quilez)
• 4-Star Dragon Ball by Me (Noztol)
• noztol_shades instagram

First published 5/2/2026 on blog.farzon.org

For the last five weeks, I’ve been cleared to walk. My "North Star" for this comeback? VO2 Max. I’ve watched the numbers slowly climb back toward my peak, but it raised a nagging question: Can I trust the data? Since I can’t wear a clinical oxygen mask on my neighborhood rehab walks, I’m relying on my Apple Watch. I needed to know exactly how a wrist-worn sensor measures elite-level fitness when I’m barely breaking a sweat.

The Magic/Math on Your Wrist: ODEs and Neural Networks

The Apple Watch doesn’t just use a basic lookup table. According to technical breakdowns from Empirical Health and Apple’s 2021 Whitepaper, the watch utilizes a sophisticated blend of Ordinary Differential Equations (ODEs) and Deep Neural Networks.

Instead of just checking your heart rate at a specific pace, the algorithm is constantly predicting what your heart rate should be based on your workload. By measuring the "Prediction Delta"; the gap between your predicted and actual heart rate is how the neural network learns your exact cardiovascular efficiency.

The Data Diet

To calculate this, the "brain" on your wrist consumes three specific streams of data:

1. The Biometric Baseline: Your age, sex, and weight

2. Environmental Kinematics: GPS-tracked pace and distance combined with topography. The watch only validates data on relatively flat ground (under a 5% grade).

3. Physiological Telemetry: Continuous heart rate data from the photoplethysmograph (PPG) sensor.

The "Submaximal" Secret: Why Rehab Walks Count

The brilliance of Apple’s design is its focus on submaximal validation. Traditionally, wearables were terrible at estimating VO2 Max unless you were sprinting. But for someone recovering from an injury, high-intensity effort is off the table.

Physiologically, heart rate and oxygen consumption scale proportionately. Because this relationship is linear, the watch can track a brisk walk and mathematically project that trendline up to your theoretical maximum. You only need to hit an exertion threshold of 30% above your resting heart rate for the algorithm to "get enough" data to extrapolate your score.

Trusting the Data: What the Science Says

As a skeptic, I looked at the recent literature to see if the marketing holds up to peer review:

• The PLOS One Study (2025): Recent validation tests found the Apple Watch to be a highly reliable proxy for clinical cardiopulmonary testing, though it tended to slightly underestimate VO2 Max in highly fit individuals.

• The Nature Meta-Analysis (2026): A massive systematic review in npj Digital Medicine (covering 430,000+ participants) confirmed that while "edge case" heart rate data can vary, the Apple Watch maintains high reliability for core physiological metrics.

The takeaway for my rehab: The absolute number on my wrist might be off by a fraction of a point compared to a $10,000 lab cart, but the trend is highly accurate. And right now, the trend is all that matters.

Reverse-Engineering the Logic

Reading whitepapers is one thing; building the logic is another. To truly understand the "black box" on my wrist, I decided to spin up a Jupyter Notebook.

I wanted to see if I could recreate the watch’s logic using a simple Multi-Layer Perceptron (MLP) in Python to simulate my 20-minute rehab walks.

• Stay tuned for Part 2, where I will show how to export the data off of your iPhone's Apple Health App.

• And Part 3 where I break down the code and see if my DIY algorithm matches Apple's output.

References:

• Apple (2021). "Using Apple Watch to Estimate Cardio Fitness with VO2 max"

• Apple (223). "Empowering people to live a healthier day Innovation using Apple technology to support personal health, research, and care"

• Rory Lambe PLOS (2025) "Investigating the accuracy of Apple Watch VO2 max measurements: A validation study"

• Rory Lambre Nature (2026) "The accuracy of Apple Watch measurements: a living systematic review and meta-analysis"

First published 4/11/26 on blog.farzon.org

Our next major architectural pivot would have been using ChrootOnAndroid to host both the web server based fuzzer and Edge on one kernel. However, our prototypes hit three massive walls: Bionic libc , Filesystem Permissions , and the Bootloader Logic of Android itself.

The Theoretical Efficiency: Debian via Chroot

The logic was simple: If we could run our Linux-based test-case generators (the Producer) inside a Debian Chroot on the same Android-x86 VM running Edge (the Consumer), we could effectively double our scale again.

By utilizing ChrootOnAndroid , we would have gained zero-latency fuzzing and unified compute, but we ran into deep-level technical hurdles that made it unfeasible for a production security pipeline.

The Technical Blockers: Why We Didn't Ship

1. The Bionic vs. glibc Divide

Android uses Bionic libc , while Debian relies on glibc. This is a recipe for hitting "Linker Hell." Debian looks for /lib/ld-linux.so, while Android looks for /system/bin/linker. Getting them to coexist requires more effort than I had the resources to devote to this problem.

2. Filesystem Permission Paradigms

Debian follows a traditional Linux user model (Root=0), but Android uses a Sandbox model where every app has a unique UID. We found that the Debian fuzzer would try to write test cases to a shared folder, but Android would hit an EACCES (Permission Denied) error because the Android filesystem didn't recognize the Debian "user."

3. The Bootloader and the mmcblk0p3 Trap

Perhaps the most significant hurdle for our automation was the hardware's boot logic. To get a clean Debian environment, we often had to mess with kernel boot arguments via fastboot.

We spent days debugging errors related to /dev/mmcblk0p3. In Linux/Android, storage is represented as files. By passing root=/dev/mmcblk0p3, we were telling the kernel: "Ignore the standard Android system partition; look at Partition 3 of the internal eMMC for the Debian rootfs."

This failed for two reasons:

• Partition Drift: On modern devices, p3 is often metadata or info, not the actual rootfs. We had to use cat /proc/partitions just to find where we were.

• The "Live" Limitation: Using fastboot boot only loads the kernel into RAM. It doesn't persist. For a cloud-scale fuzzing fleet, we couldn't manually inject fastboot -c arguments every time a VM rebooted. Flashing the kernel permanently was too risky; if the Debian build wasn't perfect, the VM would enter a boot loop, killing our uptime.

Areas for Potential Research

While we didn't implement the "Single-VM" model, it remains a high-value optimization for mobile security research. Future efforts should focus on:

1. Namespace Isolation: Using Linux Namespaces rather than just a simple chroot to provide better isolation while maintaining a single kernel.

2. Permission Mapping: Implementing a custom FUSE mount to translate Android app UIDs to Debian-compatible permissions.

3. Bootloader Orchestration: Building automation that can handle persistent kernel argument injection without requiring a manual fastboot session every reboot.

Final Thoughts

Our pivot to Android-x86 was about cost constraints; the move to chroot would have been a nice to have optimization, but wasn't necessary. Fighting with fastboot for MultiMediaCard Block devies and Bionic linker errors just wasn't worth it for our team size, but that doesn't mean it couldn't be worth it for you.

First published 4/29/26 on blog.farzon.org

Traditionally, testing for macOS meant maintaining expensive dedicated hardware or spinning up slow, proprietary VM instances in the cloud. Today, I'm excited to share a follow-up on how we are applying the "Warf Way" to Apple's ecosystem using osx-cross for compilation and Darling for runtime testing. All packaged neatly inside Dockerfile.osx-cross

The Challenge: Apple's Walled Garden

Compiling for macOS from Linux is notoriously difficult due to the requirement of the macOS SDK and specific linker behaviors. Testing that code is even harder, as macOS binaries require a Mach-O compatible kernel.

WARF's Next Step: Declarative macOS Pipelines

The shift is subtle but important:

To solve this, we are using three powerhouse open-source projects:

• osx-cross: A toolchain that allows us to use Clang/LLVM on Linux to target macOS.
• Darling: A translation layer (similar to Wine) that allows macOS binaries to run natively on Linux by implementing the Darwin subsystem.
• macOS SDKs: We need the SDK, headers, and frameworks Mac Apps expect.

The Missing Link: Phracker's SDKs

The biggest hurdle to cross-compiling for macOS is the SDK. Legally and technically, you need the headers and frameworks found inside Xcode. Ordinarily, this involves downloading a 12GB Xcode image on a Mac and running an extraction script.

To make our Docker build truly portable and "headless", we rely on Phracker MacOSX-SDKs (no longer maintained). This project provides pre-packaged, compressed versions of the macOS SDKs. By pulling a specific version (like 11.3 or 12.3) directly into our build context, we can automate the entire toolchain setup without manual intervention.

The Solution: A Unified Dockerfile

1. Building the Toolchain

The Dockerfile.osx-cross starts by fetching build dependencies. Due to licensing, you'll need to package your own SDK, but once it's in the build context, osx-cross handles the heavy lifting:

# Extract from Dockerfile.osx-cross
FROM ubuntu:22.04 AS build

# Install dependencies for osxcross
RUN apt-get update && apt-get install -y \
    clang llvm-dev libxml2-dev uuid-dev \
    libssl-dev bash patch make cmake xz-utils python3

# Set up the SDK and toolchain
COPY MacOSX11.3.sdk.tar.xz /osxcross/tarballs/
RUN UNATTENDED=1 ./build.sh  

2. Integrating Darling for Testing

While osx-cross gets us a binary, Darling acts as the bridge, providing the Mach-O loader and basic Apple frameworks needed to execute command-line tools.

# Setup Darling for runtime tests
RUN apt-get install -y darling-dkms darling
ENTRYPOINT ["darling", "shell"]  

Verdict: Darling is incredible for CLI tools, though your mileage may vary if you need to test UI frameworks.

Why This Matters

• No device context switch: Compile and test for Linux, Windows (via Wine), and macOS (via Darling) on a single machine.
• Reduced Latency: No waiting for a Mac mini in a server rack. Tests run as fast as your Linux runner allows.
• Version Parity: Every developer uses the exact same SDK version and toolchain headers defined in the Dockerfile.

Conclusion

The industry has spent years treating platforms as places you log into or wait on. But platforms were always contracts. A set of assumptions about binaries, syscalls, and behavior. When composed correctly, those contracts can be reconstructed and containerized. If a platform can be modeled, it can be versioned. If it can be versioned, it can be reproduced. And if it can be reproduced, it no longer owns your pipeline.

First published 4/21/26 on blog.farzon.org

But even a calculator needs to count correctly on every platform. To ensure warfLang remains truly cross-platform, I needed a CI/CD pipeline that could verify its logic on Windows without the overhead of actually owning a Windows machine.

The Problem: Cross-Platform Logic is Tricky

Even for a high-level parser, moving from Linux to Windows introduces subtle behavioral risks and differences especially when you are compiling acros different compilers like CL, Clang, and GCC or different libC implementations.

Inspired by Gianni Milanesi’s post, I realized I didn't need a native Windows environment to find out. I just needed a containerized "Build Appliance."

Note this post will not be the promised part 5 of the Cross-Compiling series since we are using mingw-w64 and not clang.

The "Warf" Solution: Dockerizing the Toolchain

Instead of manually managing cross-compilers, I use a custom Dockerfile Dockerfile.mingw-cross. This encapsulates the entire MinGW-w64 suite, ensuring that the environment where I build warfLang today is the exact same one I'll use six months from now.

Why Docker makes it easy:

1. Zero Setup: A new contributor doesn't need to install binutils-mingw-w64. They just run the container.

2. Consistency: It's a container, it always the works the same thats the point.

3. The "Magic" Compiler: We get instant access to x86_64-w64-mingw32-gcc, which treats our C++ code as a native Windows project.

FROM ubuntu:latest
  
# Install MinGW for building and Wine for testing
RUN apt-get update && apt-get install -y \
 mingw-w64 \
 cmake \
 wine \
 && rm -rf /var/lib/apt/lists/\*

...

RUN cmake -S . -B build \
 -GNinja -DCMAKE\_BUILD\_TYPE=Release \
 -DCMAKE\_C\_COMPILER=x86\_64-w64-mingw32-gcc-posix \
 -DCMAKE\_CXX\_COMPILER=x86\_64-w64-mingw32-g++-posix \
 -DBuildTest=TRUE \
 -DCMAKE\_SYSTEM\_NAME=Windows -DCMAKE\_CROSS\_COMPILING=TRUE

Bundling Wine: Testing the Calculator

The real value of the "Warf" way is the inclusion of Wine. For a project like warfLang , testing is straightforward: I feed the parser an expression (like x = 5; x * 2;), and I expect a specific AST output. By bundling Wine in the Docker image, I can run the Windows version immediately after compiling it without having to context switch to a new device. This works the same on my local dev machines as well as in the CI.

Why this is vital for a "Toy" Language:

• It isn't: but it is fun 😂!
• Headless Validation: The real reason I did this no context switching for testing cross plat. Using wine ./warf_tests.exe in a headless Docker container gives me instant feedback if something works on windows without having to have a dedicated windows device.

Leveraging GitHub Actions

By using this crossPlat builder approach, my GitHub Actions workflow is faster and cheaper (see runner pricing). I pull a single Linux-based image, build the Windows .exe file, and run the test suite through Wine.

When I see the "Green Checkmark" now it proves that the "calculator" works on Windows, even though it was born and raised on Linux.

Conclusion

Whether you're building a massive compiler or a glorified calculator like warfLang , the "Warf" way combining Docker, MinGW, and Wine provides a professional, reproducible, and verifiable way to ship to Windows users without ever leaving the comfort of Linux.

Check out the implementation and play with the parser in the WarfLang WASM demo.

First published 4/19/26 on blog.farzon.org

When you are staring at a buyout package on your own desk, you have a choice to make about how you frame your reality. You can view yourself as a victim of a collapsing market, and if you do, that will become your reality. You will see a tragedy, a corporate betrayal, and a door closing.

But there is a second option. You can choose to view this not as a funeral, but as a strategic opening. Your reality is dictated by how you frame this moment. If you are sitting in an existential waiting room right now, stomach in knots, let me offer the frame of the opportunist: Your career isn't over. In fact, if you play this right, you might be stepping into the most powerful strategic position of your life.

The Brutal Math: Software is Going to Zero

To understand the opportunity, you have to look at the undeniable economic reality driving these buyouts: The marginal cost of standard software engineering is rapidly dropping to zero.

For 50 years, code was a premium, scarce asset. We built our compensation models around being the highly paid gatekeepers of this complex resource. But now, we are staring down the barrel of swarms of specialized AI agents collaborating autonomously to write, test, and deploy entire architectures. Within the next 24 months, it is highly probable that autonomous systems will generate more code than all of humanity has in the history of computing.

You cannot out-work, out-hustle, or out-code a $2.52 trillion capital rotation into silicon. When a market is intentionally flooded with artificially cheap, AI-generated code, the premium value of raw human output collapses. This is the brutal math driving the layoffs and the buyout packages.

The Great Headcount Migration

For those that remain you need to understand Big Tech isn't "running out of money" they are aggressively migrating their human capital.

Companies like Google and Microsoft are moving their best minds out of teams like Gmail and Office and onto teams like Gemini and Azure AI. As they chase the AI infrastructure crown, they are leaving their core, "solved" products the platforms that fund this CapEx in maintenance mode.

IP Without Architects

The migration of human capital to new projects means Big Tech is currently sitting on mountains of intellectual property they no longer have the organizational focus to evolve. They have the IP, but they are losing the architects.

The Big Tech Pivot (And Their Strategic Gap)

This brings us to the most important strategic shift of our generation. Big Tech is no longer fighting to be the best pure-software provider; they are pivoting to become the foundational AI infrastructure layer for the globe. They want to sell the compute, the agents, and the LLMs.

But the pivoting into AI infrastructure also exposes a massive flank. As they pour hundreds of billions into server farms, the historical revenue drivers also become increasingly easier to replicate. This creates a strategic gap, leaving their core software products vulnerable to more agile competition.

The Silver Lining: The Great Equalizer

This is where you come in. Here is the beautiful, unintended consequence of Big Tech's pivot: By subsidizing the cost of AI infrastructure to capture the market, they have dropped your barrier to entry to zero. You don't need an army of 500 engineers to build a leaner, faster alternative to a Microsoft or Google product anymore.

You just need the exact same AI agents that your former employer spent billions to build and subsidize. You are not leaving your domain expertise behind. You built these systems. You know the architectural constraints and the underlying tech debt.

You know exactly where the friction points are for end-users. You can use Big Tech's own subsidized AI infrastructure to build focused, pure-software products that compete directly in the spaces they are currently deprioritizing. In a way it is kind like malicious compliance.

The Seed Funding Reframe

Let’s be honest: a buyout package isn’t life-changing money. It isn’t a VC war chest that will last you long. But calling it "seed funding" is a necessary psychological hack.

When you label it "severance," your brain chemistry defaults to fear and preservation. When you label it "seed funding," you move into optimism. It forces you to stop thinking like a discarded employee and start thinking like the builder you’ve always been. It is a grant that buys you the time to return to the craft on your own terms.

Conclusion: Choose Your Reality

Your reality is how you frame this moment. A buyout isn't a winning lottery ticket, but it is a release from the "existential waiting room." You are an insider armed with domain expertise, a laptop, and a subsidized AI toolkit that levels the playing field in ways that were impossible five years ago.

First published 4/26/26 on blog.farzon.org

MemGC was our architectural response: a garbage collector designed not just for performance, but as a hard security boundary. It was good enough that it recieved praise from Google project zero: "MemGC is an example of a useful mitigation that results in a clear positive real-world impact". I do love quoting this 😂.

The Core Idea: Turning UAF into a GC Problem

Before MemGC, we tried mitigations like Isolated Heap and Delay Free. They were clever "band-aids" that made exploitation harder but didn't solve the root cause. If a developer forgot to null a pointer after a free(), the door remained open.

MemGC changed the game by bringing the Concurrent Mark-Sweep (CMS) algorithm from the JavaScript engine (Chakra) into the heart of the DOM. We essentially built a safety net:

• Reference-based Lifetime: Instead of manual free() calls, objects were only reclaimed when the GC could prove no references to them remained.
• The Conservative Scan: We treated the stack and registers conservatively. If a value looked like a pointer to a MemGC object, we kept that object alive. This effectively killed "immediate" UAF exploits.

What it Was Good At: Structural Defenses

From a developer’s perspective, MemGC was incredibly successful at "Vulnerability Class Elimination."

1. Automation of Safety: It removed the cognitive load from DOM developers. The GC handled the cleanup of complex DOM nodes automatically.
2. Performance Balance: By using a concurrent mark-sweep, we kept the UI thread responsive while the GC did the heavy lifting on a background thread.
3. Heap Integrity: The data structures we used, like the HeapBlock32Map, allowed us to quickly determine if an address was a valid object start, preventing many "middle-of-object" pointer tricks.

Where it Failed: The "Blind Spots"

No mitigation is perfect. As developers, we had to confront the reality that hackers are just as creative as we are. One of the most interesting "failures" was a limitation in visibility between different engine components.

As detailed in the "Seeing Double" research, we discovered that having separate "Chakra" and "DOM" heaps created a blind spot. The Chakra recycler didn't always have visibility into allocations on the DOM heap, and vice versa. If a pointer to a Chakra object was stored in a buffer on the DOM heap, the Chakra GC might not "see" it, leading to a UAF despite the protection.

Furthermore, killing UAF simply pushed attackers toward Type Confusion. MemGC ensured the memory was there, but it couldn't ensure the memory was being interpreted as the correct type.

Lessons for Today’s Developers

If I were building a new engine today, what would I take from the MemGC era?

• Defense in Depth: MemGC works best when paired with modern mitigations like Control Flow Guard (CFG).
• The Precision Problem: Conservative scanning prevents UAF but can cause memory leaks. Precise GC is the gold standard for modern systems.
• Language Safety: MemGC was a heroic effort to make C++ safe. Today, we should look toward Rust for compile-time safety guarantees.

Final Thoughts

MemGC was a milestone in browser security. It forced attackers to abandon their favorite exploits and move into much more difficult territory. For those of us who built it, it remains a proud example of weaponizing computer science for defense.

References:

• MSRC: Triaging Exploitability in the MemGC Era
• ZDI: Seeing Double - Exploiting a Blind Spot in MemGC

First published 4/24/26 on blog.farzon.org

If I had listened to the conventional wisdom of the time, I would have pivoted. I would have cut my losses, updated my resume to reflect a safer trajectory, and moved on. For a time I did do just that and pivoted to computer security. But I realized it would be better to dig my heels in and commit to the career I wanted. Today, I have that career. But let’s be entirely clear: it wasn’t the institution or the degree that got me here. It was sheer, unadulterated stubbornness.

Looking back on that journey, there are a few hard truths about goals, higher education, and the absolute necessity of refusing to compromise.

The Danger of Being "Rational"

Throughout my life, I have developed a deep resentment for the advice to "be rational." We are constantly told to temper our expectations, play the percentages, and have a pragmatic fallback plan.

Here is the reality: in a world of eight billion people, rationality is just a mathematical formula for settling. To truly believe that you deserve to occupy a highly specific, fiercely competitive niche, you cannot be rational. You have to be deeply irrational. You need to possess a healthy streak of delusion to look at the impossible odds, the closed doors, and the saturated markets and decide, “Yes, that spot still belongs to me.” Rationality protects you from disappointment, but it also completely insulates you from your own potential.

The Illusion of the Academic Pipeline

We also need to have an honest conversation about the current state of higher education. It is time to acknowledge that much of academia has evolved into a heavily institutionalized enterprise that frequently extracts far more financial and temporal value from its students than it returns. It has become a systemic sinkhole, operating on a timeline fundamentally disconnected from the velocity of modern industry.

If you are relying on a core curriculum to prepare you for the cutting edge, you are already years behind. Too much of the standard coursework is a parade of outdated concepts and irrelevant syllabi that no longer apply to the real-world demands of tech or art. Ironically, the only classes reflecting the true, current state of the field are the "Special Topics", the seminars, and the elective. The very courses that the university administration rarely allows to count toward your actual degree requirements.

Learning is still essential, but we must recognize it for what it truly is: the continuous act of self-creation. Today, LLMs and Youtube can deliver raw information far more efficiently than a lecture hall, which means your intellectual evolution must be self-authored. A syllabus offers no armor against the future. The only real measure of a course's worth is whether it permanently alters the architecture of your thinking.

The Saving Grace: Research

There is one major caveat to this critique. The beating heart that keeps the academic body alive and the only reason it is still worth navigating is the research.

My saving grace in graduate school was securing a Graduate Research Assistantship (GRA). That was where the real education happened. Away from the archaic lectures and standardized rubrics, research is where you actually touch the boundary of what is possible. It is the one space left in the university ecosystem where discovery and innovation are prioritized over bureaucracy. If you are going to go to grad school, go for the research. Everything else is just noise.

Stubbornness as a Strategy

I didn't get my career because a piece of paper guaranteed me a spot in computer graphics. I got it because I refused to let an empty job market dictate my trajectory. The system is not designed to hand you your dream; it is designed to process you.

If you have a vision for your life, guard it fiercely against the "rational" advice of the masses. Take the research experience, absorb the uncredited special topics, and leave the bureaucratic friction behind. At the end of the day, your success won't be a product of the institution. It will be a testament to your refusal to quit.

First published 4/23/26 on blog.farzon.org

But I’ve spent my career building cathedrals in sinking cities, and if there is one thing I’ve learned, it’s that the most brilliant code in the world cannot save a product whose time has passed or one that never found its timing at all.

The Chakra Paradox: Winning the Wrong Race

During my tenure on the Chakra JavaScript compiler team at Microsoft, we did the "impossible." We went toe-to-toe with Google’s V8 and, by the metrics of the Octane, jetstream, & sunspider benchmarks, we won.

We built a world-class engine a feat of JIT optimization and memory management that could have defined the next decade of the web. Chakra was ahead in ES6 conformance and had elegant security mitigations like MemGC that even got the praise of Google project zero :

"It is also interesting to observe the effect of MemGC, a use-after-free mitigation in Internet Explorer and Microsoft Edge. When this mitigation is disabled using the registry flag OverrideMemoryProtectionSetting, a lot more bugs appear. However, Microsoft considers these bugs strongly mitigated by MemGC and I agree with that assessment. Given that IE used to be plagued with use-after-free issues, MemGC is an example of a useful mitigation that results in a clear positive real-world impact. Kudos to Microsoft’s team behind it!"

But while we were winning the technical battle, the war was already over. Microsoft had split the browser’s soul in two, drifting between the legacy of Internet Explorer and the fresh start of Edge. We were optimizing a masterpiece while the gallery was being demolished. It didn’t matter that our tech was superior; the market had moved, the trust had eroded, and the remaining market share was evaporating.

The Lesson: You can be the best in the world at something that no longer matters.

The Patent Trap: Groundbreaking vs. Market-Ready

I saw the same ghost appear again at Ionic Security. We weren’t just building another app; we were creating groundbreaking security infrastructure. I have the patents to prove it. I have tangible evidence of innovation in its purest form. We solved problems others hadn't even identified.

Yet, a startup is a race between discovery and exhaustion. We had the breakthrough, but we couldn't find the "problem-shaped hole" in the market to fit it into. We had a solution in search of a customer base that wasn't ready to change. Again, I found myself holding a piece of "superior" technology that was destined to sit on a shelf.

The Philosophy of the "Clean Exit"

When you pour your life into a compiler or a startup, "giving up" feels like a betrayal of your own craft. We fall into the Sunk Cost Fallacy, believing that if we just optimize one more path or secure one more patent, the world will finally wake up and see the merit.

But there is a profound difference between failing and being a failure. Here is the framework I've adopted:

• The Code is Ephemeral, the Engineer is Permanent: Chakra and Ionic were just containers for my growth. The containers leaked, and eventually, they broke. But the liquid, the expertise, the resilience, the ability to solve the "unsolvable" is still mine. I'm reminded of Bruce Lee "Be like water my friend."
• Context is King: You can write the most efficient loop in history, but if the power is cut to the building, the loop doesn't run. Moving on isn't an admission of poor quality; it’s an admission of changing context.
• Meaning vs. Utility: Just because a project didn't achieve market dominance doesn't mean it wasn't meaningful. The patents exist. The benchmarks were hit. The bridge was built perfectly; it’s not the engineer’s fault if the river changed course.

Knowing the Hour

The hardest skill to learn in tech isn't a new language especially with LLMs these days; it’s the ability to look at a "perfect" piece of work and realize it’s time to walk away. We often stay too long because we want the world to validate our effort. We want the market share to reflect our IQ.

The world doesn't owe our code a living. When you realize the ship is split in two, or the customers aren't coming, the most logical thing you can do is take your tools and find a new shore.

You aren't abandoning your work. You are preserving your talent for a place where the wind is actually blowing. I have suffered from sticking around too long in the past. My rule for the last few years is give everything 18 months. If its still fun and you are seeing success stick with it. If you feel stuck move on.

First published 4/22/26 on blog.farzon.org

For the longest time, when we needed to alter the dimensions of these matrices to fit a new screen, we relied on the blunt tool of scaling and cropping. We would amputate the edges, or we would stretch the matrix, mathematically interpolating and distorting the very subjects we sought to preserve. It was an approach devoid of nuance.

But there is a far more elegant approach. It is a method that treats the image not as a static grid, but as a dynamic, topological surface. It is known as seam carving and it is one of my favorite algorithms I ever learned.

Instead of treating the image as a static grid, seam carving asks a deeply profound question: What in this image is essential, and what is merely space? By analyzing the gradient of the image. It identifies the features that draw the human eye. Then, it searches for a "seam"; a contiguous path of pixels stretching from one edge of the image to the other, winding its way exclusively through the lowest energy areas.

When I set out to engineer my implementation of this algorithm in C++, my goal was to build an engine that deeply understood the anatomy of the data it was processing. I wanted to write a tool that could algorithmically discern the structural anchors of an image from the expendable, low-information expanses between them.

The Topography of Light: Calculating the Gradient

The first step in seam carving is a profound shift in perspective. We must teach the machine to stop looking at color, and start looking at structural energy.

In physics and mathematics, energy often reveals itself in the transitions. In an image, importance is dictated by contrast. It is where a dark shadow abruptly meets a bright cheekbone, or where the sharp geometry of a building cuts into the sky. To find these boundaries, we must apply the principles of calculus to our digital matrix. We must find the derivative.

I implemented this by converting the image to grayscale and passing it through Sobel filters. This computes the gradient magnitude of the image, essentially generating a topographic map where high structural energy forms mountain peaks, and smooth, uniform areas form deep, quiet valleys.

cv::Mat SeamCarving::computeGradientMagnitude(const cv::Mat &frame) {

cv::Mat grayScale;
cv::cvtColor(frame, grayScale, cv::COLOR\_RGBA2GRAY);
cv::Mat drv = cv::Mat(grayScale.size(), CV\_16SC1);
cv::Mat drv32f = cv::Mat(grayScale.size(), CV\_32FC1);
cv::Mat mag = cv::Mat::zeros(grayScale.size(), CV\_32FC1);

// Calculate the partial derivative in the X direction
Sobel(grayScale, drv, CV\_16SC1, 1, 0);
drv.convertTo(drv32f, CV\_32FC1);
cv::accumulateSquare(drv32f, mag);

// Calculate the partial derivative in the Y direction
Sobel(grayScale, drv, CV\_16SC1, 0, 1);
drv.convertTo(drv32f, CV\_32FC1);
cv::accumulateSquare(drv32f, mag);

// The final energy map is the magnitude of the gradient vector
cv::sqrt(mag, mag);
return mag;
}

The Path of Least Resistance: Dynamic Programming

Once we have mapped the energy manifold of the image, the next mathematical challenge arises: how do we navigate it? We must find a "seam"—a contiguous thread of pixels stretching from the top of the matrix to the bottom, winding entirely through the paths of lowest energy.

This cannot be solved effectively with a greedy algorithm; choosing the lowest energy pixel at each immediate step often traps the path in a local minimum, missing the true optimal route. Instead, I utilized the profound elegance of Dynamic Programming.

The algorithm cascades down the matrix row by row. It does not just look at the present; it calculates the optimal historical path for every single node. For each pixel, it looks at the three adjacent pixels directly above it, finds the one that carries the lowest cumulative energy from the top, and incorporates it.

// Within computePathIntensityMat:

// The intrinsic energy of the current pixel
float pixelIntensity = rawEnergyMap.at<float>(row, col);

// Retrieving the cumulative minimum intensity from the three possible upstream paths
float p1 = intensity(pathIntensityMap.at<float>(row-1, col-1), col - 1, pathIntensityMap.cols);
float p2 = intensity(pathIntensityMap.at<float>(row-1, col), col, pathIntensityMap.cols);
float p3 = intensity(pathIntensityMap.at<float>(row-1, col+1), col + 1, pathIntensityMap.cols);

float minIntensity = std::min(p1, p2);
minIntensity = std::min(minIntensity, p3);

// The new cumulative energy is recorded
pixelIntensity += minIntensity;

By the time the calculation reaches the final row, the entire matrix has been evaluated. The algorithm simply selects the absolute minimum value at the bottom boundary and traces the mathematical path of least resistance back up to the origin.

Bare-Metal Architecture: Memory Manipulation

Identifying the optimal seam is a triumph of mathematical logic, but executing its removal requires the brutal efficiency of computer science. To achieve real-time performance—allowing a user to dynamically scrub a slider and watch the image collapse and expand—high-level abstractions had to be discarded.

In my removePixel and addPixel functions, the code drops down to the bare-metal reality of pointer arithmetic and raw memory manipulation. Rather than copying arrays index by index, I calculate the exact byte offsets and use memcpy to shift entire contiguous blocks of memory, physically overwriting the data where the seam once existed.

But removing a seam leaves a mathematical discontinuity. To preserve the visual integrity of the matrix, the algorithm acts as a digital surgeon, averaging the raw byte values of the adjacent pixels to heal the seam:

// Snippet from removePixel showcasing the blending of the numerical values

int leftPixel = minCol - 1;
int rightPixel = minCol + 1;
  
// ... memory block shifting omitted for brevity ...
  
// Calculate the mean value of the surrounding bytes to close the gap gracefully

if (rightPixel < width) {
  int byte1R = rawOrig[originRowStart + rightPixel \* channels];
  // ...
  rawOutput[newRowStart + minCol \* channels] = (unsigned char)((byte1 + byte1R) / 2);
}
  
if(leftPixel >= 0) {
  int byte1L = rawOrig[originRowStart + leftPixel\*channels];
 // ...
 rawOutput[newRowStart + leftPixel\*channels] = (unsigned char) ((byte1 + byte1L)/2);
}

When you compile and run this code, you are watching a beautiful translation of concepts. You are watching calculus define the structural anchors of human perception. You are watching dynamic programming solve an immensely complex topological maze. And you are watching C++ manipulate raw memory with breathtaking speed to physically collapse the mundane spaces of the digital canvas, leaving only what is truly essential.

In more concrete words, seam carving finds the quiet spaces. The empty walls, the unbroken skies. And then, pixel by pixel, it delicately removes that single, imperceptible thread. The image shrinks, but the subjects remain untouched, their proportions perfectly preserved. It is resizing achieved through subtraction. Algorithms like this are a reminder that computer science is not just about making things faster or smaller; it is about finding the underlying truths of a system. Seam carving is a testament to the idea that the most profound solutions in science are those that do not fight against the nature of the data, but rather, understand it intimately, finding the path of least resistance to achieve something beautifully pristine.

First published 4/18/26 on blog.farzon.org

We will look at how this is done using Clang and LLVM-Cov, which provides highly accurate source-based coverage.

The Foundation: Clang and LLVM-Cov

To understand the automation, we first need to look at what is happening under the hood. Unlike GCC, which traditionally uses gcov, Clang utilizes "Source-based Code Coverage." This method is generally more precise because it maps coverage directly to the Abstract Syntax Tree (AST).

To enable this, we use two critical compiler flags:

• -fprofile-instr-generate: Tells the compiler to insert counters into the code to track how many times each block is executed.
• -fcoverage-mapping: Adds metadata to the binary that associates these counters with specific source code locations.

(Note: If you are migrating to Clang or want to understand how these flags interact with tools like CTest, Kaspar Giger’s guide on Clang Coverage is an excellent primer).

Step 1: Configuring the Build in GitHub Actions

In the coverage-report.yml workflow, the first step is configuring CMake to use Clang and apply these flags.

cmake \(GITHUB_WORKSPACE -DCMAKE_BUILD_TYPE=\)BUILD_TYPE \
  -DCMAKE_CXX_FLAGS="-fprofile-instr-generate -fcoverage-mapping" \
  -DCMAKE_C_COMPILER=clang \
  -DCMAKE_CXX_COMPILER=clang++

It is crucial to remember that the linker also needs the -fprofile-instr-generate flag to ensure the final executable is capable of writing the coverage data at runtime.

Step 2: Generating .profraw Files

When you run a binary compiled with these flags, it doesn't output a readable report immediately. Instead, it produces a .profraw (Profile Raw) file. This is a highly efficient, compact binary format that contains the raw counter data.

The warfLang workflow uses the LLVM_PROFILE_FILE environment variable to explicitly name the output file so it isn't overwritten:

LLVM_PROFILE_FILE="warfLang.profraw" ./build/test/warfLang_TEST

If you are curious about what exactly is happening inside these binary files, Leo Di Donato wrote a fascinating deep-dive demystifying the .profraw format, explaining how the headers, function hashes, and execution counters are structured.

Step 3: Merging into .profdata

Because a project might involve multiple test runs (e.g., unit tests, CLI tests, integration tests), you often end up with multiple .profraw files. To create a unified report, you must merge them using llvm-profdata.

llvm-profdata merge -sparse warfLang*.profraw -o warfLang.profdata

The -sparse flag is a useful optimization that reduces the size of the output .profdata file by omitting empty or zero-count blocks.

Step 4: Creating the HTML Report

Once we have the merged .profdata, we use llvm-cov show to generate the actual visual report. This step requires the original binary because the mapping between the counters and the source code is still stored within that executable.

llvm-cov show -output-dir=build/out/report -format=html \
  -instr-profile=warfLang.profdata \
  -object=build/test/warfLang_TEST \
  build/src/cli/warfLang src

• -object : Specifies the binary files to look in for coverage mapping.
• -format=html : Generates an interactive website.
• src : Tells the tool which directory contains the source code to be mapped.

Step 5: Publishing to GitHub Pages

The final piece of the puzzle is making the build/out/report directory accessible online. The warfLang workflow achieves this by initializing a new git repository inside that directory, committing the HTML files, and force-pushing it to a dedicated branch (gh-pages-coverage).

- name: Force push to destination branch
  uses: ad-m/github-push-action@master
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    branch: gh-pages-coverage
    directory: ${{github.workspace}}/build/out/report

By pointing GitHub Pages to the gh-pages-coverage branch, the report becomes live at farzon.org/warfLang/coverage/. This creates a seamless CI/CD loop: every push to the master branch triggers a build, runs tests, generates a new report, and updates the public-facing coverage site automatically.

Resources for Deeper Learning

If you want to explore the underlying tools and mechanics further, these articles provide excellent context:

• Code Coverage with Clang by Kaspar Giger: A great overview of the Clang compiler flags and how to integrate them cleanly using CMake.
• Demystifying the profraw format by Leo Di Donato: A technical deep-dive into the LLVM source code to explain exactly what is written into a .profraw binary file.
• Code coverage with llvm-cov by Anastasiia: A practical, step-by-step tutorial on local coverage generation, merging, and setting up CMake for GoogleTest.

First published 4/17/26 on blog.farzon.org

If you are a student developer interested in compilers, developer tooling, or graphics programming, this is a unique opportunity to contribute to the LLVM ecosystem and improve the lives of thousands of shader developers.

What is HLSL and Clangd?

HLSL (High-Level Shader Language) is the primary language used for GPU shader programming in DirectX and Vulkan via SPIR-V environments. Currently, there is a massive effort underway to bring first-class HLSL support directly into Clang.

Clangd is the language server (LSP) that provides IDE features like code completion, go-to-definition, and refactoring for C++. Since HLSL is built on the C++11 standard, clangd already "mostly" works, but it struggles with HLSL-specific constructs. This project aims to close that gap.

The Project Goal

The objective is to move from "semi-functional" to "holistic" support. This isn't just about writing code; it’s about understanding the nuances of a domain-specific language and designing how tools should interact with it.

The Roadmap

1. Survey: Identify exactly where clangd breaks when handling HLSL.
2. Architect: Write an RFC (Request for Comments) to propose how clangd should handle these unique language constructs.
3. Implement: Begin the groundwork and implementation to fix these gaps.

Project Details

• Size: Medium (~180 hours)
• Difficulty: Medium
• Mentors: My teammates Finn Plummer and Ashley Coleman
• Required Skills: Intermediate C++, an understanding of LSPs, and a hunger to learn the HLSL specification.

Why apply?

By taking on this project, you’ll be mentored by two bright engineers who are deeply involved in the LLVM and HLSL space. You will gain hands-on experience with the LLVM codebase which is one of the most influential open-source projects in the world and your work will directly improve the developer experience for gpu compilers.

How to Get Involved

If you’re interested in applying, we encourage you to join the conversation early!

• Official LLVM Project Listing
• Discussion Thread

Feel free to reach out on the LLVM Discourse or Discord to introduce yourself and ask questions. We can’t wait to see what you’ll build!

First published 4/17/26 on blog.farzon.org

The Problem: Architectural Evolution

The existing BRW backend has been the workhorse of Intel's Linux drivers for years. However, it was designed for a different era of hardware. Over time, as GPUs moved toward more complex, "scalar" architectures, the legacy backend became increasingly difficult to extend.

• The Core Issue: Modern shaders speak a language called NIR (New Intermediate Representation). BRW, being older, requires significant translation logic to understand NIR, which adds complexity to the driver.
• The Solution: Jay is built to be native to NIR. By speaking the same language as the rest of the Mesa stack, it removes unnecessary translation layers and provides a direct path to the hardware.

Strategic Context: A Fresh Perspective

The project is being led by Alyssa Rosenzweig, known for her work on the Asahi Linux and Honeykrisp GPU drivers. Her involvement brings a specific engineering philosophy to the table: building lean, "domain-specific" compilers.

This follows a successful industry blueprint. Much like Valve’s ACO compilersignificantly improved AMD’s Vulkan performance on Linux by providing a specialized alternative to general-purpose tools, Jay is designed to give Intel hardware a high-speed lane optimized specifically for gaming and modern compute.

Why not just use LLVM?

It’s a fair question Intel’s Windows drivers use an LLVM-based stack and there are many GPU backends supported in llvm like DirectX, SPIR-V, AMDGPU, and NVPTX. However, as Phoronix recently detailed, the Linux ecosystem is built differently:

1. Streamlined Pipeline: Converting NIR --> LLVM IR --> Machine Code adds extra steps. Jay keeps everything "in-house," ensuring that optimizations aren't lost in translation.
2. Swift Compilation: LLVM is a massive, multi-purpose framework. Jay is a precision tool designed to do one thing—generate Intel machine code—with as little latency as possible.

The Technical "Flare"

What makes Jay actually exciting for the end user?

• Snappier Gaming: Early testing suggests Jay can be up to 3x faster at compiling shaders than the old backend. In the world of modern gaming, this is the difference between a smooth launch and a stutter-filled first five minutes of gameplay. Does this perhaps mean Intel can ride the Linux Gaming wave Steam started? Time will tell.
• SSA: Jay remains in SSA (Static Single Assignment) form much deeper into the compilation process. This allows it to make incredibly "smart" decisions about where data lives, leading to more efficient execution on the GPU.
• Future-Proofing: A clean-slate codebase means Intel can bring support for new architectures, like Xe2 and beyond, to the Linux community much faster.

The Bottom Line

Jay isn't a new driver; it’s a high-performance engine inside the existing driver stack. By trading legacy baggage for a design that fits the modern Mesa architecture, Intel is ensuring its Linux stack remains fast, lean, and ready for the next generation of hardware.

First published 4/16/26 on blog.farzon.org

When Apple moved to its own silicon, they shocked the industry with a solution that could transparently translate x64 binaries to Aarch64. You could take an old program, compiled years ago for an old CPU, and it just ran at high speed on a totally different architecture. It proved that code doesn't have to be a static snapshot of the past.

The Magic of Rosetta 2: Why Was It So Fast?

Translation layers were once synonymous with "sluggish." Rosetta 2 changed that narrative by marrying hardware and software in a way we hadn't seen before. As researcher Dougall Johnson noted, the secret was a unique hardware-level support for Total Store Ordering (TSO).

By building x86-style memory logic directly into the M-series chips, Apple eliminated the massive performance "tax" that usually kills translated apps. Combined with Ahead-of-Time (AOT) recompilation, and SSE2 to NEON emulation Rosetta 2 effectively "re-authored" software at the moment of installation, ensuring that even ancient binaries felt like native, modern apps.

The Rise of the "Living Binary"

The true legacy of Rosetta 2 is the realization that software binaries don't have to be static.

Historically, developers have been forced to target "generic" CPUs; essentially a lowest-common-denominator approach to ensure their apps run on everything from a 2015 laptop to a 2026 workstation. The result? Modern CPUs have "fancy" features that software never uses. Developers lack the incentive to constantly re-optimize for every new chip iteration, and "old" software rarely benefits from "new" hardware features. This is a problem Apple does not have especially after two Instruction Set Architecture (ISA) migrations.

While Rosetta 2 did not pioneered this idea, it did prove that on-the-fly recompilation is a workable solution to take advantage of all the new silicon features. This idea is now being adopted by the rest of the industry. We are entering an era where the hardware manufacturer takes over the job of optimization.

Intel iBOT: The Idea Lives On

We are seeing this philosophy manifest in tools like Intel’s iBOT (Intel Binary Optimization Tool). Much like Rosetta 2, iBOT optimizes x64 binaries on the fly, taking advantage of more modern and performant instructions that the original developer never targeted.

• Free Performance: Recent reports show an average 8% performance boost on popular games just by using these optimization layers.
• Breaking the Generic Bottleneck: Instead of running generic code, the processor "re-writes" the binary to use the specific, powerful features of the latest silicon.
• Software Longevity: Your software is no longer "stuck" in the year it was compiled; it evolves to match the system it's running on.

The "Invisible Engine" Legacy

As Apple begins to phase out Rosetta 2, its legacy is secured. It killed the idea that a binary is a finished, unchangeable product. It taught the industry that the best way to handle the gap between old code and new chips is to build a system smart enough to optimize itself.

Rosetta 2 is leaving the stage, but the "Living Binary" era it inspired is just beginning to run.

First published 4/15/26 on blog.farzon.org