<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Open Source Projects on Daniel &#39;f0o&#39; Preussker</title>
    <link>https://f0o.dev/projects/</link>
    <description>Recent content in Open Source Projects on Daniel &#39;f0o&#39; Preussker</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 20 May 2026 16:10:47 +0000</lastBuildDate><atom:link href="https://f0o.dev/projects/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>cline-vertex-gw</title>
      <link>https://f0o.dev/projects/2026/05/cline-vertex-gw/</link>
      <pubDate>Wed, 20 May 2026 16:10:47 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2026/05/cline-vertex-gw/</guid>
      <description>&lt;p&gt;I love coding with AI agents, but my wallet absolutely hates it. If you have ever run Cline or other agentic loops, you know exactly what I mean. The token multiplier effect can turn a 20-minute debugging session into a three-figure cloud bill before you even finish your first coffee.&lt;/p&gt;
&lt;p&gt;To make matters worse, Google Cloud Vertex AI has incredibly cheap and reliable access to models like Claude and Gemini, but its REST API is completely different from the standard OpenAI or Ollama endpoints that most developer tools expect.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Oubliette</title>
      <link>https://f0o.dev/projects/2026/04/oubliette/</link>
      <pubDate>Sat, 18 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2026/04/oubliette/</guid>
      <description>&lt;p&gt;DDoS attacks are a massive pain for anyone trying to keep a service online, especially TCP SYN Floods with spoofed source IPs. Because some ISPs still do not implement BCP38 correctly, attackers can easily spoof source IPs with zero consequences, flooding targets until they fall over.&lt;/p&gt;
&lt;p&gt;To combat this without dropping a fortune on proprietary scrubbing hardware, I built &lt;strong&gt;Oubliette&lt;/strong&gt; — a high-performance, linerate DDoS scrubber that runs on semi-commodity hardware. By hooking directly into the NIC&amp;rsquo;s driver using eBPF and XDP (eXpress Data Path), it filters out malicious traffic before it can even touch the Linux kernel network stack.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Tor Relay Performance Datasets</title>
      <link>https://f0o.dev/projects/2025/06/tor-relay-performance-datasets/</link>
      <pubDate>Mon, 09 Jun 2025 06:36:18 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2025/06/tor-relay-performance-datasets/</guid>
      <description>&lt;p&gt;Analyzing performance characteristics of anonymity networks is notoriously difficult. In the Tor network, bandwidth measurements are traditionally concentrated within a few core directory authorities or testing agents.&lt;/p&gt;
&lt;p&gt;Because these measurement nodes are mostly located inside North American and European datacenters, the resulting performance metrics suffer from severe geographical bias.&lt;/p&gt;
&lt;p&gt;If you are a privacy researcher trying to analyze how well Tor relays perform in the Global South or the APAC region, existing public datasets are sparse, unreliable, and heavily skewed.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>PromCache</title>
      <link>https://f0o.dev/projects/2025/03/promcache/</link>
      <pubDate>Mon, 31 Mar 2025 10:25:56 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2025/03/promcache/</guid>
      <description>&lt;p&gt;Prometheus is a beast of a monitoring system, but Grafana dashboards can easily bring it to its knees. If you have ever set up a company-wide wallboard that auto-refreshes every ten seconds, or if you have multiple SRE teams querying the exact same raw metrics, you have probably seen your Prometheus CPU usage spike into a terrifying sawtooth pattern.&lt;/p&gt;
&lt;p&gt;The obvious solution is to slap an HTTP cache in front of it. But if you try doing that with a generic proxy like Varnish or Nginx, you will quickly realize it is completely useless.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Quickwipe</title>
      <link>https://f0o.dev/projects/2025/03/quickwipe/</link>
      <pubDate>Sun, 16 Mar 2025 15:11:03 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2025/03/quickwipe/</guid>
      <description>&lt;p&gt;Wiping old hard drives is a total drag. If you have ever decommissioned a server with a couple of high-capacity SATA drives, you know exactly what I mean. Scurrying to write randomized bytes across several terabytes of magnetic platters can easily drag on for seventy or eighty hours.&lt;/p&gt;
&lt;p&gt;If you try to run a naive &lt;code&gt;dd if=/dev/urandom of=/dev/sdX&lt;/code&gt;, you are bound to fail. Standard tool chains are throttled by the Linux page cache, buffer copying overhead, and CPU-bound random number generators.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>fn0rd.io Scanner</title>
      <link>https://f0o.dev/projects/2025/03/fn0rd.io-scanner/</link>
      <pubDate>Fri, 07 Mar 2025 09:11:18 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2025/03/fn0rd.io-scanner/</guid>
      <description>&lt;p&gt;Mapping the entire internet is a massive challenge. If you try to scan large blocks of IPv4 addresses from a single server, you will get rate-limited, blocklisted, or network-saturated almost immediately.&lt;/p&gt;
&lt;p&gt;To conduct community-driven security auditing without dropping thousands of dollars on enterprise hosting networks, we need a distributed approach. By dividing up the target IP space into manageable scopes and spreading the work across dozens of volunteer nodes, we can map systems safely and efficiently.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Looking Glass</title>
      <link>https://f0o.dev/projects/2024/04/looking-glass/</link>
      <pubDate>Sat, 20 Apr 2024 06:32:42 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2024/04/looking-glass/</guid>
      <description>&lt;p&gt;Most public looking glasses are outdated CGI or raw PHP scripts from 1997. They parse user inputs insecurely, lack any form of caching, and put a heavy CPU load on core routers during diagnostics. When core public routers go down, troubleshooting BGP route flaps at 3 AM becomes a nightmare.&lt;/p&gt;
&lt;p&gt;To solve this, I built &lt;strong&gt;Looking Glass&lt;/strong&gt; — a stateless, horizontally scalable, and secure diagnostic daemon built with Go, ConnectRPC, and Svelte 5. It manages a fleet of multi-vendor core routers over concurrent, isolated SSH sessions and streams real-time diagnostic outputs through a raw API, a neat CLI (&lt;code&gt;lg-cli&lt;/code&gt;), and a snappy web client.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Netbench</title>
      <link>https://f0o.dev/projects/2023/07/netbench/</link>
      <pubDate>Fri, 21 Jul 2023 08:03:57 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2023/07/netbench/</guid>
      <description>&lt;p&gt;Benchmarking network systems is usually a static affair. You spin up ApacheBench or wrk, tell it to run at a fixed fifty concurrent connections for two minutes, and look at the resulting average latency.&lt;/p&gt;
&lt;p&gt;But real-world traffic is never static. In the wild, servers face dynamic traffic surges, sudden micro-bursts, and predictable diurnal waves (like the slow ramp-up of users starting their workday followed by a quiet night-time dip).&lt;/p&gt;
&lt;p&gt;To test how my network infrastructure and auto-scalers handle these fluid concurrency transitions, I built &lt;strong&gt;Netbench&lt;/strong&gt; (written in Go, ofc). It is an high-concurrency network and HTTP traffic generator that dynamically scales its worker thread concurrency using real-time mathematical wave functions.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Cloudflare Runners</title>
      <link>https://f0o.dev/projects/2021/07/cloudflare-runners/</link>
      <pubDate>Wed, 07 Jul 2021 15:58:52 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2021/07/cloudflare-runners/</guid>
      <description>&lt;p&gt;Commercial CI/CD runners are expensive, and hosting your own GitLab runner fleet is a chore. You have to patch host OS kernels, manage Docker daemon storage, prune orphaned volumes, and keep an eye on monthly VM bills.&lt;/p&gt;
&lt;p&gt;What if you could run your entire CI/CD workload on enterprise-grade infrastructure completely for free, with zero servers to manage?&lt;/p&gt;
&lt;p&gt;Cloudflare Pages lets developers build and host Jamstack sites for free. On every git commit, Cloudflare spins up a fully functional, high-performance Linux build container to compile your frontend assets. I figured, since they are giving us a free Linux container with root privileges and outbound internet access, we might as well put it to work.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>prom_hosts</title>
      <link>https://f0o.dev/projects/2021/04/prom_hosts/</link>
      <pubDate>Wed, 28 Apr 2021 06:47:28 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2021/04/prom_hosts/</guid>
      <description>&lt;p&gt;Standard flat-file &lt;code&gt;/etc/hosts&lt;/code&gt; name resolution is ancient, but it is still incredibly common in local home labs, small environments, and custom Kubernetes ingress networks. It is simple, stateless, and gets the job done without the headache of provisioning a heavy authoritative BIND or Knot DNS infrastructure.&lt;/p&gt;
&lt;p&gt;Most modern networks run CoreDNS to manage internal name resolution, and CoreDNS has a built-in &lt;code&gt;hosts&lt;/code&gt; plugin to serve zones straight from flat &lt;code&gt;/etc/hosts&lt;/code&gt; files.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Guacamole PKI</title>
      <link>https://f0o.dev/projects/2019/10/guacamole-pki/</link>
      <pubDate>Thu, 03 Oct 2019 07:05:40 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2019/10/guacamole-pki/</guid>
      <description>&lt;p&gt;Managing TLS/SSL certificates at scale across multi-tenant cloud platforms is an absolute nightmare. In large deployments, you want every project and service to have its own isolated Certificate Authority (CA) namespace, but providing this capability without leaking private Root Keys or running into permission conflicts is incredibly difficult.&lt;/p&gt;
&lt;p&gt;While the OpenStack ecosystem has dedicated services for Compute (Nova), Networking (Neutron), and Key Storage (Barbican), it has long lacked a native, production-ready PKI-as-a-Service (PKIaaS) component.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Terranetes</title>
      <link>https://f0o.dev/projects/2019/08/terranetes/</link>
      <pubDate>Tue, 06 Aug 2019 15:53:32 +0000</pubDate>
      
      <guid>https://f0o.dev/projects/2019/08/terranetes/</guid>
      <description>&lt;p&gt;Deploying Kubernetes is usually a massive headache. You either suffer through opaque, hundred-line Ansible playbooks that fail halfway through, or you bind yourself to complex, vendor-locked managed services like EKS or GKE.&lt;/p&gt;
&lt;p&gt;If you are running on your own hardware or open cloud platforms like OpenStack, your options are even worse. You are left managing state across multiple detached tools: one to spin up the VMs, another to compile PKI certificates, and a third to bootstrap the cluster.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
