Quake demos raytraced again

This is a follow-up to a previous post about raytracing Quake demos.

But first, the money shot:

e1m1 flat shaded e1m1 with textures

And flat shaded and textured videos. Youtube is Very Aggressive™ with its compression, so the quality there is not good. For pixel quality the above images showcase it better.

A new raytracer

One of my original reasons for creating the quake demo povray files is that it was a good source of data for 3D experiments. POV-Ray is a great raytracer, though entirely CPU (no GPU) and no longer state of the art.

POV-Ray has plenty of built in options, but takes forever to render the 30-60fps demos I want to play with.

Also POV-Ray is AGPL now, so nope nope nope nope nope. That’s a dead end.

Another AI detour

We live in interesting times. We could be living in a time when no two people are running the same email client, or music player, or shell. There used to be a barrier to writing these things custom. I know people who wrote their own shell and use it as a daily driver. I wrote my own email client, and use that.

There are many people out there, me included, who Continue reading

AI solving problems

I’ve been able to find some time, lately, to work on my project backlog. And because it’s 2026, I’ve been using AI as a diligent intern.

I’ve ranted before about seccomp, but still used it for a project or two. But then, rarely, it triggered an unexpected openat. That’s exactly the kind of I do want to detect and kill the binary for, so I don’t just want to allow it. I want to know where it’s coming from.

strace showed it’s trying to read /proc/sys/vm/overcommit_memory.

It’s certainly not my code. But just the Rust transitive dependency tree is quite a few crates:

$ cargo tree | sed -r 's/^[^a-z]+//;s/ .*//' | sort -u | wc -l
236

Step 1 was to run it in gdb, and reproduce the problem. But it’s a bit trickier than that, because seccomp fully kills the process, so no backtrace. And setting breakpoints requires a few more syscalls to work, just for the process to work under gdb (e.g. sigaltstack).

And turns out some calls fail with EINTR if running under a debugger.

Yes, I can fix all these things. But why not put the AI intern on it?

AI Continue reading

Scaling Security Insights: how we achieved a 10x increase in global scanning capacity

Security Insights provides actionable security recommendations for every Cloudflare account. To find these insights, we perform regular scans for all accounts, zones, and DNS records, looking for potential security risks and misconfigurations.

However, two key issues emerged. First, our scans were too infrequent. Scans were only being performed every week or two, and therefore newly introduced security risks could remain undetected for up to two weeks. Second, automatic scanning was opt-in for many free plan accounts – meaning lots of accounts weren’t being scanned at all.

The risks of infrequent or nonexistent scans are rising: as automated attacks accelerate, the window for detecting security misconfigurations is shrinking. Making sure that we’re finding these issues for all of our customers is crucial to our aim of building a better Internet for everyone.

We calculated that to increase our scanning frequencies and enable automatic scanning for all accounts, we would need to increase our scanning throughput by around 10x on average – from 10 scans per second to 100 per second. But our system was already struggling with its load: millions of events were filling up our backlog waiting to be processed; our API was frequently timing out; our processes were crashing. Continue reading

AI in Networking with Andrew Yourtchenko

I always wanted to find someone who is more positive about AI than I am, while having solid “can deliver working stuff at scale” credentials. Andrew Yourtchenko definitely fits the bill. I first met him (online) when he was still an engineer in Cisco TAC, and when we finally met in person, he was busy automating the deployment of Cisco Live networking infrastructure. He was also instrumental in bringing us closer to ubiquitous IPv6 deployment with Happy Eyeballs.

Cisco Live 2026 – Requiem For A Corner

Cisco Live US 2026 was an interesting ride this year. There was a lot of talk about AI. There was a big discussion about security and how we are protecting our software from the AI models on the horizon that are ready to uncover every bug ever conceived. And there was even more discussion about whether Cisco was ahead of the game or behind the curve on their support for everything from eBPF to the latest Mythos reports. I say there was a lot of discussion, but I’m not sure where exactly it was happening.

Social Desert

One of the biggest things I heard from my friends at the event was how light everything felt. Fewer people was a common theme. The reported number was around 22,000 but it felt closer to 20,000 to me. The World of Solutions felt very spread out this year, with most of the back side being Cisco booth space.

The other thing was the Social Hub. It had shrunk from last year. At least the couches were facing each other this year. And there were some cool stickers and some interesting puzzles to work on. But there were far too few tables for people Continue reading

Installing Dnsmasq in My Homelab

Dnsmasq is an application which has features like DNS caching, DHCP server, and so on. It’s useful as a DNS server in a homelab as it can reply to DNS queries for what’s in its database, and forward everything else to an authoritative server or recursive resolver. This is useful in my lab as I want to resolve for example gitlab.lostintransit.se locally, but lostintransit.se (my web server) or any other domains via recursive resolvers. Most DNS servers are authoritative for a zone or parts of a zone, but dnsmasq responds only to what it knows and forwards everything else, which is perfect for my needs.

First I’ll configure a static IP on the host by modifying the file in /etc/netplan:

sudo vi 50-cloud-init.yaml

The contents are now:

sudo cat 50-cloud-init.yaml 
network:
  version: 2
  ethernets:
    ens160:
      dhcp4: no
      addresses:
        - 192.168.128.53/24
      routes:
        - to: default
          via: 192.168.128.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

I’m using recursive resolvers for now but will update it later.

Then apply the configuration:

sudo netplan apply

The IP has been updated:

ip addr show ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP>  Continue reading

Five Principles of an Accountable AI Agent Network: How to Evaluate Any Governance Platform

The first post in this series argued that AI agent governance hasn’t kept pace with deployment. The second laid out the five pillars of accountability, and what is required. The third walked through why network policies, API gateways, MCP/A2A protocols, DIY security patterns, and Role-based Access Control (RBAC) each leave critical accountability gaps.

So what does good look like?

The five pillars define what AI agent accountability requires. The principles below define how a governance platform should deliver it. These are the architectural principles your team should evaluate any AI agent governance solution against, whether you build it, buy it, or assemble it from open-source components.

If a vendor pitches you a governance platform that fails any of these five, walk away.

What are the five principles of an accountable AI agent network?

Kubernetes Network Policies are essential for securing any cluster. They restrict which pods can communicate with which other pods at the network level, and they should absolutely be part of your security posture.

  1. Default-deny: No agent communicates unless a policy explicitly permits it.
  2. Attribute-based policy: Policies reference agent attributes, not agent names.
  3. Zero-trust identity: Every request authenticated, every identity verified.
  4. Audit by design: Every interaction produces a Continue reading

A field guide to the agents in your cluster

You know every service in your cluster by name. You know which team owns each one, what it talks to, how it scales, where its logs go. The agents are a different story.

That’s not a criticism, it’s an observation, and it’s one we keep running into. Every company we talk to is shipping agents of some kind, from scales of 10s to 1000s. Customer service bots that field tier-one tickets. Internal copilots that draft emails and summarise meetings and write the boring half of every PR. SREs that handle their own incidents at 2am while the team sleeps. What used to be a few experimental builds in a dev cluster is now dozens in some shops and hundreds in the biggest, growing faster than most teams are tracking.

That growth curve is the interesting part. Services tend to come into existence through a fairly heavyweight process. There’s a ticket, a design review, an owner, a runbook. Agents tend to arrive the way side projects do:

  • Somebody had an idea on a Tuesday.
  • By Friday it was in staging.
  • At some point nobody can quite remember when it became part of the actual business.

Who said it could do that?

Continue reading

Route public traffic to private applications with Cloudflare

For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks. We think that distinction is becoming obsolete.

Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet. Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit.

Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking. As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications.

Today, we're launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet. This allows Continue reading

Pinging Hosts Sequentially vs Concurrently in Python

I’m reorganizing some things in my homelab and wanted to check how many hosts are alive in a /24. The simple check, while not perfect, is to ping all the hosts and see who responds. I used Claude to generate some Python for me and noticed it used some tools I had not used before, to run code concurrently, which really speeds up things like scanning a /24 for alive hosts. In this post I’ll compare running sequentially vs concurrently and break down the code.

Running something sequentially means that every job, such as checking if an IP is alive, must run to completion before the next job starts. This is highly inefficient, of course, mainly for two reasons:

  • Work can’t be performed in parallel
  • Most of the time is spent waiting, rather than working

Especially when the job involves something like ping, we must give hosts a reasonable time to respond, so we’ll wait up to a second. We also can’t one-shot the ping because what if we have no ARP entry for the host we are pinging (assuming same subnet)? Then, a host that is alive could be reported as dead due to the missing ARP entry.

I’ll Continue reading

Goodbye, Leaf-and-Spine Networks?

A friend of mine sent me links to a new paper published by AWS engineers, and an associated LinkedIn post which claims:

We got lean, resilient, massive aggregation fabrics that provide 33% better throughput with 69% fewer routers, savings 27% of costs, cutting power usage by 40%, and reducing CO2 emissions.

The obvious question one should ask after reading the hyperventilated Radical Network Redesign blog post is thus: is this the end of leaf-and-spine networks? Of course not. Let’s go into the details.

1 2 3 3,877