Edge Systems Are the New Backend

Unknown — Wed, 11 Feb 2026 00:00:00 +0000

A request arrives at your system. In the next 50 milliseconds, before any application code runs, this happens: TLS termination, route matching, WAF inspection against 285 detection rules, JWT validation, rate limit evaluation, request body validation against a JSON schema, and trace context generation. The request either dies at the edge or arrives at your backend pre-authenticated, pre-validated, and pre-authorized.</p>

Five years ago, your backend did all of this. Every service validated its own tokens, enforced its own rate limits, ran its own security checks. Today, the backend might not even exist in the form you expect. It might be a static site served from edge nodes, a thin persistence API, or a headless CMS that publishes content to a CDN and never handles a user request directly.</p>

Something shifted. Not just at the edge. On both ends.</p>

The three-tier past</h2>
The architecture most of us learned was simple. Client, backend, database. The browser rendered HTML, maybe ran some jQuery. The backend did everything: authentication, authorization, business logic, rendering, validation, rate limiting, session management. The database stored state. Clean separation, one direction, easy to reason about.</p>
This model worked because the browser was dumb. It could render markup and submit forms. Any real computation had to happen on the server. The backend was fat by necessity, not by design.</p>
Microservices made it worse. Consider a typical setup: a user service, an order service, a payment service, a notification service, an inventory service. Each one needs to validate JWTs. Each one needs to enforce rate limits. Each one needs input validation, request logging, and error handling. That is five services times six concerns. Thirty implementations of logic that should exist exactly once.</p>
Now multiply. Real organizations have 15, 50, 200 services. Each team implements auth slightly differently. One uses a shared library, one copied the code two years ago, one rolled their own because the library did not support their token format. The rate limiting configurations drift. The logging formats diverge. A security patch to the JWT validation logic means PRs across every repository, coordinated deployments, and someone asking “did we get all of them?”</p>
┌──────────┬──────────┬──────────┐ │ Users │ Orders │ Payments │ │ Service │ Service │ Service │ ├──────────┼──────────┼──────────┤ Auth │ ✓ (v2.1) │ ✓ (v1.9) │ ✓ (v2.0)│ Rate limiting │ ✓ (lib) │ ✓ (copy) │ ✗ (none)│ Validation │ ✓ │ ✓ │ ✓ │ WAF/Security │ ✗ │ ✗ │ ✗ │ Logging │ JSON │ text │ JSON │ Tracing │ ✓ │ ✗ │ ✓ │ └──────────┴──────────┴──────────┘ </code></pre> Libraries helped. Service meshes helped more. But the complexity was still distributed across every service, in every team’s codebase, in every deployment pipeline. The mesh moved networking concerns to a sidecar. It did not move application-level concerns like auth, validation, or security inspection.</p> The edge was an afterthought. A reverse proxy. TLS termination. Maybe Varnish for caching. Maybe a CDN for static assets. It was infrastructure plumbing, not a place where decisions happened.</p> That model is over.</p> Two migrations, one hollowing</h2> Here is the thing I keep coming back to: business logic is migrating in two directions simultaneously.</p> Upward, to the edge. Infrastructure concerns like auth, WAF, and rate limiting now execute at the edge layer, before requests reach any backend. But it goes further than that. Edge Workers run actual application code. Containers deploy at the edge. Server-side rendering happens at edge nodes 50ms from the user, not in a data center 200ms away.</p> Downward, to the client. The browser is no longer dumb. WebAssembly runs near-native code. WebGPU puts the GPU to work on ML inference and image processing. Web Workers handle background computation. Service Workers intercept network requests and serve cached responses offline. CRDTs let the client own its data and sync when it feels like it.</p> The backend is caught in the middle. Squeezed from both sides. And what remains is not a “backend” in any traditional sense. It is a persistence layer. A place where data rests and syncs. The interesting work happens elsewhere.</p> What moved to the edge</h2>
Infrastructure concerns</h3>
The first wave was obvious. Cross-cutting concerns that every service needed are better handled once, at the point of entry.</p>
Authentication.</strong> Validating a JWT does not require application context. The token is self-contained: a signature, an issuer, an expiry, a set of claims. Parse it, verify the signature against a JWKS endpoint, check the expiry, extract the claims, attach them as headers. Done. The backend receives `X-User-Id: alice</code> and X-User-Role: admin</code> instead of a raw Bearer token it has to decode itself.</p>`
`This is not hypothetical. Here is what this looks like in practice:</p>`
agent "auth" { type "auth" grpc address="http://localhost:50051" events "request_headers" timeout-ms 100 failure-mode "closed" max-concurrent-calls 100 } </code></pre> That agent handles JWT, OIDC, SAML, mTLS, and API key validation. Every route behind it gets authentication for free. Every backend service trusts the edge to have done the work. The auth agent crashes? Failure mode is “closed”. Requests stop, but the proxy stays up.</p> Rate limiting.</strong> Token bucket algorithms with per-client keys. The edge layer sees every request before the backend does. It is the natural place to enforce rate limits because it can reject bad traffic before it consumes backend resources. A rejected request at the edge costs microseconds. A rejected request at the backend costs a database query, a connection slot, and whatever work happened before the check.</p> There are two flavors. Local rate limiting uses in-process token buckets. Fast, no network hops, but each edge node tracks its own counters. If you have 10 edge nodes and a limit of 100 requests per second, each node allows 100, so the effective limit is 1,000. For most use cases, this is fine. Abuse does not distribute itself evenly across your infrastructure.</p> Distributed rate limiting uses a shared store (Redis, typically). Accurate across nodes, but adds a network hop per request. The tradeoff is latency versus precision. I default to local rate limiting and switch to distributed only when the use case demands exact global limits, like API billing or token budgets for LLM inference.</p> Security inspection.</strong> WAFs used to be appliances. Expensive, opaque, binary. A request was either blocked or allowed. Modern WAFs use anomaly scoring. Each rule contributes a score, and the total determines the action:</p>Score 0-9: Allow Score 10-24: Log (warning, investigate later) Score 25+: Block </code></pre> This is a fundamentally different model than binary block/allow. It lets you tune aggressively without breaking legitimate traffic. I run 285 detection rules at the edge and process 912K requests per second on clean traffic. That is 30x faster than ModSecurity’s C implementation. The performance gap matters because it means WAF inspection can happen on every request, not just suspicious ones.</p> API validation.</strong> If your API has a JSON Schema, why validate request bodies in your application code? Validate at the edge. Reject malformed requests before they consume a connection, a goroutine, a database transaction. The backend receives only structurally valid payloads.</p> Observability.</strong> Trace context should originate at the edge, not at the application. The edge is where the request enters your system. It is where you assign a trace ID, start the clock, and record the first span. If you originate traces in your application, you miss everything that happened before: TLS negotiation time, WAF processing time, the fact that the request sat in a rate limit queue for 50ms. Starting traces at the edge gives you the full picture.</p> The isolation problem</h3> You cannot put all of this in a monolithic proxy. That is how you end up with nginx and 47 modules where nobody understands the interaction effects. A WAF bug should not take down your routing. A slow auth provider should not block rate limit checks.</p> The answer is process isolation. Thin dataplane, crash-isolated external agents. Each agent runs as a separate process with its own failure domain:</p> ┌──────────────────────────────────────────┐ │ Edge Proxy (thin dataplane) │ │ Routing │ TLS │ Caching │ Load Balancing │ └─────┬──────────┬──────────┬──────────────┘ │ │ │ ▼ ▼ ▼ [WAF] [Auth] [Rate Limit] process process process </code></pre> Each agent gets its own concurrency semaphore. A slow WAF cannot starve auth. Each agent has a circuit breaker. Three failures in 30 seconds and the circuit opens. Each agent has a configurable failure mode, and this is where the design gets interesting:</p> agent "waf" { type "waf" timeout-ms 100 failure-mode "closed" max-concurrent-calls 50 circuit-breaker { failure-threshold 5 success-threshold 2 timeout-seconds 30 } } agent "rate-limit" { type "rate-limit" timeout-ms 50 failure-mode "open" max-concurrent-calls 200 } </code></pre> The WAF fails closed. If it crashes or times out, requests are blocked. You lose availability to preserve security. Rate limiting fails open. If it crashes, requests are allowed. You lose rate enforcement to preserve availability. These are explicit choices per agent, not global defaults. The operator decides which tradeoff to make for each concern, and the decision is visible in the config, not buried in code.</p> Agents return decisions. The proxy merges them. A blocking decision from any agent wins. Otherwise, header mutations accumulate. The model is simple: agents advise, the proxy decides. No agent can override another agent’s block. No agent can force a request through. The proxy owns the final call.</p> This is not a workaround. It is the fundamental design choice. Complex logic lives outside the core, behind process boundaries. The proxy stays small, fast, and boring. The agents handle the interesting work in isolation. A bug in a Lua scripting agent does not corrupt the routing table. A memory leak in the WAF agent does not exhaust the proxy’s memory. The process boundary is the blast radius.</p> Edge Workers: business logic at the edge</h3> Infrastructure concerns were the first wave. The second wave is actual business logic.</p> Cloudflare Workers, Deno Deploy, Fastly Compute, Vercel Edge Functions. These are not just “serverless at the CDN.” They are full compute environments running at edge nodes around the world. V8 isolates spin up in under 5ms. Cold starts are measured in single-digit milliseconds, not seconds. Your code runs 50ms from the user instead of 200ms away in us-east-1.</p> The constraints matter, because they shape what belongs here. Typical Edge Worker limits: 10-50ms CPU time per request (not wall time, actual CPU), 128MB memory, no raw TCP sockets, no persistent file system. You get a request, key-value storage, and the ability to make sub-requests to origins. That is it. These constraints are not bugs. They are what makes sub-millisecond cold starts possible. V8 isolates are cheap because they are small and short-lived.</p> What fits within these constraints is surprisingly broad:</p> API routing and transformation.</strong> A request comes in for /api/v2/users</code>. The edge Worker rewrites it, fans out to two backend services (user profiles from one, preferences from another), merges the responses, and returns a single payload. The backend services are simple data sources. The edge Worker is the API layer.</li> A/B testing and feature flags.</strong> Read the experiment cookie, hash the user ID, assign a variant, route to the right origin or rewrite the response. No round trip to a feature flag service. The decision happens in microseconds at the node closest to the user.</li> Personalization.</strong> Look up the user’s segment in KV storage, inject the right content block, set cache headers accordingly. The backend generated all variants at build time. The edge picks the right one per request.</li> Server-side rendering.</strong> Render HTML at the edge node closest to the user. Frameworks like Next.js and Remix already support this. React Server Components run at the edge. The “server” in server-side rendering is not your server. It is an edge node in 300 locations.</li> Authentication and session management.</strong> Validate tokens, refresh sessions, set secure cookies. The auth flow never touches your origin. Cloudflare Workers KV or Durable Objects store session state at the edge.</li> </ul> The pattern: compute that depends on request context but not on deep application state moves to the edge. If you can do it with a request, a key-value lookup, and a response, it probably belongs here. If it needs a complex database query or a multi-step transaction, it does not.</p> Containers at the edge</h3> Edge Workers hit a ceiling when you need persistent connections, large memory, or long-running processes. For those workloads, containers at the edge.</p> Fly.io, Railway, and Lambda@Edge deploy containers or full processes to edge locations worldwide. Your application runs with real file systems, TCP connections, and whatever runtime you need. But it runs close to users, not in a centralized data center. Latency drops from 200ms to 20ms.</p> The interesting problem is data gravity. Compute is easy to distribute. Data is not. If your container runs in Tokyo but your database is in Frankfurt, you have not solved the latency problem. You have moved it from the user-to-server hop to the server-to-database hop. The solutions are still maturing: read replicas at the edge (Turso, Neon), embedded databases that sync (LiteFS, libSQL), and eventually-consistent stores designed for multi-region (DynamoDB Global Tables, CockroachDB).</p> This model makes sense when compute and data can be co-located:</p> Regional APIs</strong> that comply with data residency requirements. Run the container and the database replica in the same region. GDPR data stays in the EU. Japanese user data stays in Japan.</li> Real-time applications</strong> where 200ms round trips kill the experience. Collaborative editing, multiplayer, live dashboards. A WebSocket server 20ms away feels instant. One 200ms away feels sluggish.</li> Stateful edge compute</strong> where you need more than a request/response cycle. Background processing, scheduled jobs, long-running connections.</li> </ul> The line between “edge” and “origin” blurs. If your container runs in 30 regions and handles requests locally with a local database replica, is that an edge deployment or a distributed backend? The distinction stops mattering. What matters is that the compute and the data are close to the user.</p> What moved to the client</h2> The other half of the migration goes downward. The browser is not the thin client it used to be.</p> WebAssembly</h3> WASM runs at near-native speed in every modern browser. Not “fast for JavaScript.” Actually fast. Compiled from Rust, C++, Go, or any language with an LLVM backend. Sandboxed, portable, deterministic.</p> What this enables:</p> Image and video processing</strong> in the browser. No upload to a server, no round trip, no privacy concern. The pixels never leave the device.</li> Document parsing and transformation.</strong> PDF rendering, spreadsheet computation, file format conversion. Libraries compiled to WASM and running client-side.</li> Cryptographic operations.</strong> End-to-end encryption where the server never sees plaintext. Key derivation, signing, verification, all in the browser.</li> Compute offloading from the backend.</strong> This is the one that changes how you think about server sizing.</li> Full relational databases in the browser.</strong> This is the one that changes architectures.</li> </ul> I build on this pattern directly. Cyanea</a>, a bioinformatics platform, uses WASM to offload computation from the backend to the client’s browser. Sequence analysis, structure visualization, dataset filtering, these are CPU-intensive operations that traditionally require beefy server infrastructure. Instead, the computation runs right there on the researcher’s device. The backend stays thin: it stores datasets and coordinates collaboration, but the heavy lifting happens in the browser. This means I can run the platform on a modest server and still deliver real computational capability, because the “compute fleet” is the users’ own machines.</p> Archipelag</a> takes the same idea in a different direction. It is a distributed compute platform where users contribute their browser’s idle compute power via WASM. The workloads compile to WASM modules, ship to participating browsers, execute in the sandbox, and return results. The browser is not just a client consuming a service, it is a compute node in a distributed system. The WASM sandbox is what makes this safe: untrusted code runs in a constrained environment with no access to the host file system, network, or memory beyond what is explicitly granted.</p> SQLite compiled to WASM (via projects like sql.js, wa-sqlite, or the official SQLite WASM build) gives the browser a real relational database. Not a key-value store. Not IndexedDB’s awkward object store API. Actual SQL with joins, indexes, transactions, and triggers. Backed by the Origin Private File System (OPFS) for persistence, it survives page reloads and browser restarts.</p> The implications are significant. Your application can run complex queries locally. Filter, sort, aggregate, full-text search. All instant, all offline. The server becomes a sync endpoint. It ships a database snapshot down and accepts change sets back. The client does the querying. The server does the storing.</p> This pattern scales down elegantly. A note-taking app with SQLite-in-WASM needs no backend API for reads. A project management tool can filter and search 10,000 tasks without a network request. A CMS authoring interface can work fully offline and sync when the author reconnects. The read path is local. The write path syncs eventually.</p> WASI (WebAssembly System Interface) extends this further. It gives WASM modules controlled access to file systems, clocks, and network sockets outside the browser. WASM becomes a universal runtime: the same binary runs in the browser, at the edge (Cloudflare Workers use WASM under the hood), and on bare metal. Write once, deploy to every layer of the stack.</p> The pattern: anything that is CPU-bound, privacy-sensitive, or latency-sensitive is a candidate for client-side WASM. If the computation does not need server-side state, it should not round-trip to a server.</p> WebGPU</h3> WebGPU landed in Chrome in 2023, in Firefox and Safari shortly after, and it changes the math on what the client can compute. This is not WebGL with a new name. WebGL exposes a graphics pipeline. WebGPU exposes compute shaders. Direct, general-purpose GPU computation from JavaScript or WASM.</p> The immediate application is ML inference. Run a language model, an image classifier, or a recommendation engine on the user’s GPU. No server call, no API cost per token, no latency. The model weights download once (cached by the browser) and run locally. Privacy by default, because the data never leaves the device.</p> This is not theoretical. Stable Diffusion generates images in the browser via WebGPU. Small language models (Phi-2, Gemma 2B, Llama 3.2 1B) run at usable speeds on consumer hardware. MediaPipe runs pose detection, face tracking, and hand gesture recognition in real time. The trajectory is clear: models get smaller through distillation and quantization, consumer GPUs get faster, and the gap between “cloud inference” and “local inference” narrows every quarter.</p> Both Cyanea and Archipelag use WebGPU alongside WASM. In Cyanea, WebGPU accelerates molecular visualization and large-scale dataset operations, the kind of parallel computation that bioinformatics demands but that would be prohibitively expensive to run server-side for every user session. In Archipelag, WebGPU-capable nodes can take on GPU-accelerated workloads from the compute pool, turning a user’s idle GPU into a productive resource. The combination of WASM for general compute and WebGPU for parallel workloads gives the browser a compute profile that would have required dedicated server hardware five years ago.</p> But inference is not the only use case. WebGPU handles any parallel computation: physics simulations for games, signal processing for audio applications, particle systems for data visualization, and large-scale matrix operations. Anything you would reach for CUDA or Metal for on native can now run in the browser. The compute budget of the client just increased by orders of magnitude.</p> Web Workers and Service Workers</h3> Web Workers give you background threads. Heavy computation does not block the UI. Parse a large file, run a simulation, index a search corpus. All off the main thread, all without janking the interface.</p> Service Workers sit between the browser and the network. They intercept every fetch request and decide what to do: serve from cache, go to network, do both and race them. This enables:</p> Offline-first applications.</strong> The app works without a network connection. Data syncs when connectivity returns.</li> Background sync.</strong> Queue mutations while offline, replay them when online.</li> Push notifications.</strong> Wake the app without the user having it open.</li> Intelligent caching.</strong> Cache API responses, serve stale data while revalidating, pre-fetch resources the user is likely to need.</li> </ul> The Service Worker is the client-side equivalent of the edge proxy. It intercepts, caches, validates, and routes. It makes the client self-sufficient.</p> Local-first and CRDTs</h3> Here is where it gets interesting. If the client has compute (WASM, WebGPU, Web Workers) and storage (IndexedDB, OPFS) and offline capability (Service Workers), why does it need a server at all?</p> CRDTs (Conflict-free Replicated Data Types) answer the consistency question. Multiple clients can edit the same data independently, offline, with no coordination. When they reconnect, their changes merge automatically without conflicts. No server-mediated locking. No “last write wins” data loss. Mathematical guarantees that concurrent edits converge to the same state.</p> The architecture:</p> Client A (offline) Client B (offline) │ │ ├── Local edits ├── Local edits │ (CRDT ops) │ (CRDT ops) │ │ └──────┐ ┌────────┘ ▼ ▼ ┌──────────────┐ │ Sync service │ (thin, stateless) │ (persistence │ │ + relay) │ └──────────────┘ </code></pre> The sync service is not a backend. It stores operations and relays them between clients. It does not run business logic. It does not validate (the CRDT handles consistency). It does not transform (the merge function is built into the data type). It is a persistence layer with a WebSocket attached.</p> I build systems like this. The concrete model: a document is a flat HashMap<EntityId, Entity></code> where each entity holds CRDT-typed fields. The field types determine how concurrent edits merge:</p> CRDT type</th> Merge behavior</th> Use case</th></tr></thead> LwwRegister<T></td> Last writer wins (by timestamp)</td> Simple values: name, status, URL</td></tr> GrowOnlySet<T></td> Union of both sides</td> Tags, labels, immutable references</td></tr> ObservedRemoveSet<T></td> Add wins over concurrent remove</td> Collaborator lists, mutable collections</td></tr> MaxRegister</td> Higher value wins</td> Version counters, progress indicators</td></tr> MinRegister</td> Lower value wins</td> Earliest timestamps, priority values</td></tr> </tbody></table> Each field carries a hybrid logical clock (HLC) timestamp. The HLC combines physical time with a logical counter, so causality is preserved even when wall clocks drift. Two clients edit the same field at the “same” time? The HLC ordering is deterministic. Both clients converge to the same value without coordination.</p> The merge function has three properties that make this work: it is associative (grouping does not matter), commutative (order does not matter), and idempotent (applying the same operation twice has no additional effect). These are not implementation details. They are the mathematical foundation that makes server-free consistency possible. You can sync operations in any order, from any number of clients, through any number of intermediate relays, and every replica converges to the same state.</p> The client owns its data. The server is optional. When the server exists, it persists operations and relays them. It does not arbitrate, transform, or validate beyond authentication.</p> This is not a niche pattern for collaborative text editors. Any application where users create and modify data can benefit. Notes, task managers, project planning tools, CMS authoring, form builders. The question is not “should this be local-first?” The question is “does this need a server, and if so, for what?”</p> What the backend becomes</h2> If the edge handles infrastructure concerns and business logic that depends on request context, and the client handles computation, rendering, and local state, what is left for the backend?</p> A persistence layer.</p> The backend becomes the place where data rests between sessions and syncs between devices. Not an application server. A persistence layer.</p> Consider the spectrum of what “backend” looks like now:</p> Static sites.</strong> This site is an example. raskell.io is built with Zola. Markdown files compile to HTML at build time and deploy to edge CDN nodes. No application server. No database. No runtime process. The “backend” is a git repository and a CI pipeline. Content lives as files. Serving happens at the edge. The total monthly infrastructure cost is the price of a domain name.</p> This is not limited to blogs. Documentation sites, marketing pages, product landing pages, e-commerce storefronts with pre-rendered product pages. Any content that changes at author-time rather than request-time can be static. The headless CMS (Contentful, Sanity, Strapi, or just a git repo) publishes content. The static site generator builds HTML. The CDN serves it. The “backend” runs at build time, not at request time.</p> I take this further than most. All of my projects are CDN-first, even the ones with dedicated backends. The principle: if the backend goes down, the user should still see something useful. The static layer is the safety net.</p> Kurumi</a>, a local-first second brain app, is the purest expression of this. It is a Progressive Web App served entirely from CDN edge nodes with Service Workers handling offline capability. There is no backend server. Notes sync between devices through CRDTs when connectivity exists, but the app works fully offline. The entire “infrastructure” is a static deployment and an optional sync relay.</p> But the CDN-first pattern also applies to applications that have real backends. Cyanea has a Phoenix/Elixir backend that manages datasets, user accounts, and collaboration. But the public-facing surface, the landing pages, category pages, trending spaces and protocols and datasets, is statically generated. The backend exports JSON snapshots of its database objects on a timed interval. A static site generator picks up those snapshots and rebuilds the public pages: what labs are active, which protocols are trending, which datasets were recently published. The result is a set of HTML pages sitting on a CDN that stay current without depending on the backend being up at the moment a visitor arrives.</p> ┌──────────────────┐ JSON export ┌──────────────┐ │ Cyanea Backend │ ──── (interval) ────> │ Static Site │ │ (Phoenix/BEAM) │ │ Generator │ │ │ │ (Zola) │ │ - datasets │ │ │ │ - protocols │ │ → CDN edge │ │ - labs │ │ nodes │ │ - spaces │ │ │ └──────────────────┘ └──────────────┘ │ │ │ dynamic app static pages ▼ ▼ app.cyanea.bio cyanea.bio (logged-in users, (public, always up, real-time features) fast, no backend dependency) </code></pre> This is a genuinely resilient architecture. The backend can be down for maintenance, mid-deploy, or experiencing load, and the public site keeps serving. The static pages are never stale by more than one generation interval. For a site where “trending this week” is sufficient freshness, that interval can be hours. The CDN handles traffic spikes that would overwhelm a backend. The backend handles the dynamic work that requires real-time data.</p> Thin persistence APIs.</strong> For applications with dynamic data, the backend shrinks to a database with an API in front of it. Accept writes, serve reads, enforce schema constraints. GraphQL or REST over Postgres. No rendering. No business logic beyond data integrity. The API exists so that clients and edge workers have somewhere to store and retrieve state.</p> The interesting shift: even the persistence API is getting thinner. Services like Supabase, PlanetScale, and Turso expose the database directly over HTTP or WebSockets with built-in auth. Your “backend” becomes a hosted database with row-level security policies. No application code at all.</p> Sync relays.</strong> For local-first applications, the backend is even simpler. Accept CRDT operations from clients, persist them to durable storage, fan them out to other connected clients via WebSocket. No merge logic (the CRDT handles that). No transformation. No validation beyond authentication. The relay does not understand the data. It stores and forwards.</p> Event logs.</strong> Append-only storage. Clients sync by replaying events from their last known position. The log is the source of truth. Everything else (search indexes, analytics dashboards, recommendation models) is a materialized view built asynchronously. The hot path is the append. The read path is the replay. Both are simple.</p> Batch processors.</strong> The one place where traditional backend compute survives: jobs that require access to the full dataset. Analytics aggregation, report generation, search index building, ML model training. These run on schedules or triggers, not in the request path. They read from the event log or the database, compute, and write results back. The user never waits for them.</p> The common thread: the backend does not touch the hot path. User requests hit the edge and the client. The backend runs in the background, on its own schedule, when no one is waiting.</p> The architecture that makes this work</h2> Pushing logic to the edge and the client is not free. Both environments have constraints, and ignoring them is how you build fragile systems.</p> At the edge: bounded resources</h3> Every operation at the edge needs explicit limits. No open-ended computations, no unbounded queues, no surprise behavior. This is not just good practice. It is existential. The edge proxy sits between the internet and your infrastructure. If it behaves unpredictably, everything behind it suffers.</p> Concretely:</p> Resource</th> Bound</th> Why</th></tr></thead> Agent concurrency</td> Per-agent semaphore (default: 100)</td> Prevents noisy neighbor between agents</td></tr> Agent timeout</td> 100ms default</td> Prevents latency cascade</td></tr> Connection pool</td> Explicit max (default: 10K)</td> Prevents file descriptor exhaustion</td></tr> Request body</td> Streaming, not buffered</td> Prevents memory exhaustion</td></tr> Route cache</td> LRU with size limit</td> Prevents unbounded growth</td></tr> Rate limit queues</td> Bounded with max delay</td> Prevents request pile-up</td></tr> </tbody></table> If you cannot articulate the bound for every resource your edge system uses, you do not have an architecture. You have an accident waiting for load.</p> On the client: isolation and sandboxing</h3> The client has different constraints. Battery life, memory pressure, the user closing the tab at any moment.</p> WASM runs in a sandbox. No file system access, no network access, no shared memory (unless explicitly granted). This is the security model that makes client-side compute viable. Untrusted code (your own, running on someone else’s device) cannot escape the sandbox.</p> Web Workers run in separate threads with message-passing. No shared mutable state. No locks. No data races. The isolation is enforced by the runtime, not by programmer discipline.</p> Service Workers have a lifecycle managed by the browser. They can be terminated at any time to save resources. Your offline logic must handle graceful shutdown. This means: durable state in IndexedDB, idempotent sync operations, no in-memory state that cannot be reconstructed.</p> CRDTs provide consistency guarantees without coordination. But they are not magic. They consume memory (tombstones for deleted items, version vectors for causal ordering). They need garbage collection. They need careful schema design because not every data model maps cleanly to CRDT primitives. A counter works. A last-writer-wins register works. A rich text document with formatting, comments, and embedded media requires careful thought.</p> The trust boundary</h3> Here is the part most edge-computing articles skip: trust.</p> If the edge handles auth, the backend trusts the edge to have done auth correctly. If the client handles business logic, the server trusts the client to have computed correctly. These are real trust boundaries with real failure modes.</p> At the edge, trust is earned through:</p> Failure isolation.</strong> Agent crashes do not take down the proxy. Bad config is validated before activation.</li> Observability.</strong> Every decision is logged, metered, and traceable. If the WAF blocked a request, you can see exactly which rules fired and why.</li> Bounded behavior.</strong> No surprise modes. Every resource has explicit limits. Every failure mode is configured, not assumed.</li> </ul> On the client, trust is conditional:</p> Never trust the client for security decisions.</strong> Validate at the edge or the backend. Client-side checks are UX, not security.</li> Trust the client for its own data.</strong> If the user is editing their own document, the client is authoritative. CRDTs handle consistency. The server persists, it does not arbitrate.</li> Verify at the boundary.</strong> When client data syncs to the server, validate schema and authorization. Trust the merge, verify the input.</li> </ul> When not to do this</h2> Not everything belongs at the edge or on the client. Here is what stays in the backend:</p> Multi-service transactions.</strong> If an operation needs to read from three databases, check inventory, charge a payment, and send a notification, that is a backend workflow. Distributed transactions need coordination, and coordination needs a central authority.</p> Heavy data joins.</strong> If your query joins six tables with complex filters and aggregations, it runs next to the database, not at an edge node 200ms away from the data.</p> Regulatory requirements.</strong> Some industries mandate that data processing happens in specific locations, on specific infrastructure, with specific audit trails. Edge deployment may not satisfy these constraints.</p> Small teams with simple needs.</strong> If you have one backend, ten users, and no latency problems, this architecture is overhead. A Django app behind nginx is fine. Optimize when you have a reason to optimize, not before.</p> The edge handles cross-cutting concerns and request-context computation. The client handles local state and user-facing compute. The backend handles coordination, persistence, and anything that needs the full dataset. Know which is which.</p> Where this is going</h2> Five years ago, the stack was: browser (thin) renders server-generated HTML, backend (fat) runs everything, database stores state. The mental model was request/response, and the backend was the center of gravity.</p> The stack now:</p> ┌─────────────────────────────────────────────────────┐ │ Client │ │ WASM │ WebGPU │ Web Workers │ Service Workers │ CRDT │ │ (compute, render, offline, local state) │ └────────────────────┬────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────┐ │ Edge │ │ Proxy │ Workers │ Containers │ KV │ Durable Objects │ │ (auth, WAF, routing, SSR, API aggregation, policy) │ └────────────────────┬────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────┐ │ Backend │ │ Database │ Sync relay │ Event log │ Batch processing │ │ (persistence, coordination, async compute) │ └─────────────────────────────────────────────────────┘ </code></pre> The client is fat. The edge is fat. The backend is thin. The center of gravity moved to both ends simultaneously.</p> Every year, this accelerates. Models get smaller and run on consumer GPUs. WASM runtimes get faster and gain more system APIs through WASI. Edge platforms add durable storage, queues, and cron triggers. CRDTs mature from academic curiosities to production libraries. SQLite-in-the-browser goes from experiment to default architecture for offline-capable apps.</p> The backend will not disappear. Data needs to live somewhere durable, and cross-device sync needs a relay. Coordination problems need a central authority. Batch processing needs access to the full dataset. But the backend’s role is narrowing to exactly these things. It is becoming infrastructure, not application. Plumbing, not logic.</p> I find myself building systems where the most interesting engineering happens at the boundaries. A reverse proxy (Zentinel</a>) that inspects 912K requests per second through 285 WAF rules, authenticates with sub-millisecond latency, and routes with crash-isolated agents. A bioinformatics platform (Cyanea</a>) where the browser runs the computation and the backend exports JSON for statically generated pages. A distributed compute platform (Archipelag</a>) where users’ browsers are the compute fleet via WASM and WebGPU. A note-taking app (Kurumi</a>) that works fully offline with CRDTs and never touches a server for reads. Between all of them, a database, a sync relay, or just a CDN. Necessary and boring.</p> The backend is not dead. It is just not where the interesting work happens anymore.</p> References and further reading</h2> Edge platforms and proxies</h3> Cloudflare Workers</a> - V8 isolate-based edge compute</li> Deno Deploy</a> - Edge runtime built on the Deno JavaScript runtime</li> Fastly Compute</a> - Wasm-based edge compute platform</li> Vercel Edge Functions</a> - Edge compute integrated with Next.js</li> fly.io</a> - Container-based edge deployment platform</li> Pingora</a> - Cloudflare’s Rust framework for programmable proxies</li> Zentinel</a> - Security-first reverse proxy with crash-isolated agents</li> </ul> Client-side compute</h3> WebAssembly</a> - Portable binary instruction format for the web</li> WASI</a> - WebAssembly System Interface for running Wasm outside the browser</li> WebGPU specification</a> - W3C standard for GPU compute in the browser</li> MediaPipe</a> - ML inference framework running client-side via Wasm and WebGPU</li> SQLite Wasm</a> - Official SQLite build targeting WebAssembly</li> sql.js</a> - SQLite compiled to Wasm via Emscripten</li> Origin Private File System</a> - MDN reference for persistent browser storage</li> Service Worker API</a> - MDN reference for offline-capable web apps</li> Web Workers API</a> - MDN reference for background threads in the browser</li> </ul> CRDTs and local-first</h3> CRDTs: The Hard Parts</a> - Martin Kleppmann’s talk on practical CRDT challenges</li> Local-first software</a> - Ink and Switch research paper on local-first architectures</li> Automerge</a> - CRDT library for collaborative applications</li> Yjs</a> - High-performance CRDT framework for the web</li> A comprehensive study of CRDTs</a> - Shapiro et al., the foundational survey paper</li> </ul> Databases at the edge</h3> Turso</a> - SQLite-compatible database with edge replicas</li> Neon</a> - Serverless PostgreSQL with branching</li> LiteFS</a> - Distributed SQLite replication by Fly.io</li> CockroachDB</a> - Distributed SQL database designed for multi-region</li> Supabase</a> - Open-source Firebase alternative built on PostgreSQL</li> </ul> Projects referenced</h3> Cyanea</a> - Bioinformatics platform using Wasm and WebGPU for client-side compute</li> Archipelag</a> - Distributed compute platform with browser-based Wasm nodes</li> Kurumi</a> - Local-first second brain app with CRDT sync</li> Conflux</a> - Schema-aware CRDT engine for deterministic merge</li> </ul> Looking back on 2025 Unknown — Wed, 31 Dec 2025 00:00:00 +0000 I spent part of this year on the shores of Okinawa. The water there is something else entirely, this impossible azure that shifts to turquoise in the shallows, so clear you can see the coral formations from the surface. I found myself thinking about systems while I was there, the way you do when you’re floating in salt water with nothing pressing to attend to.</p> Between swims, I read Tim Berners-Lee’s “This is for everyone.” I’ve been building web software for over a decade now, and I thought I understood what the web was. But reading TBL’s words while watching that reef ecosystem do its thing, thousands of species in constant exchange, no central coordinator, just emergent complexity from simple rules, something shifted in how I saw it all.</p> The web TBL imagined was supposed to work like that reef. A commons. Many small nodes, each doing their own thing, connected through open protocols. Information flowing freely. The beauty of it wasn’t in any single node but in the connections between them, the way the whole became more than the sum of its parts. The same principle that makes a reef resilient makes a network powerful: diversity, redundancy, local adaptation.</p> What we built instead looks more like industrial aquaculture. Five platforms. Algorithmic monoculture. Content optimized for engagement metrics rather than usefulness. We took a system designed for decentralization and built the most centralized information infrastructure in human history.</p> I keep thinking about how that happened. The web itself never changed. HTTP still works the same way, HTML still does what it always did. What changed was the economics. Publishing became free, but being found</em> became expensive. The platforms positioned themselves as the gatekeepers of attention, and suddenly you couldn’t reach people without paying the toll, whether in ad spend or in algorithmic compliance or in the slow erosion of doing whatever it took to game SEO.</p> The thing about monocultures is they’re efficient right up until they’re not. A reef can lose a species and adapt. A monoculture gets one disease and collapses. We’ve been watching the web’s monoculture show stress fractures for years. The enshittification of platforms, the SEO content farms drowning out signal with noise, the way social media stopped being social and started being a feed of engagement-optimized content from strangers.</p> Then 2025 happened, and AI started breaking things in interesting ways.</p> The obvious take is that AI makes the content problem worse. And superficially, that’s true. If you thought SEO spam was bad before, wait until you see what happens when generating ten thousand pages of plausible-sounding garbage costs essentially nothing. The content farms went into overdrive. Social platforms filled with synthetic engagement.</p> But here’s the thing I keep coming back to: maybe that’s the fever that breaks the infection.</p> The old economics of the web depended on a particular scarcity. Human attention is finite, and the platforms controlled access to it. You wanted eyeballs, you played their game. SEO worked because Google was the gateway and you could optimize for what Google wanted. Platform distribution mattered because that’s where the people were.</p> AI disrupts this in ways that I think are genuinely interesting. When an AI assistant can synthesize information from across the web and deliver it directly to the user, the value of ranking first on Google diminishes. Why click through to a content farm when the answer is already in front of you? When AI agents can find and surface relevant content directly, you don’t need to be on the platform where the eyeballs gather. The middleman’s leverage starts to evaporate.</p> And crucially: when everyone can generate infinite content at zero marginal cost, content quantity becomes worthless. What matters is provenance. Accuracy. Usefulness. The things that are actually hard. The things that require a human perspective, or at least require being right</em> in ways that matter.</p> I find myself unexpectedly optimistic about what comes next.</p> If AI breaks the distribution stranglehold that platforms have, the economics of the web could flip in interesting directions. The old model needed scale because reaching people was expensive. But if AI handles discovery, finding relevant content and bringing it to users, then maybe you don’t need scale anymore. Maybe small becomes viable again.</p> Think about what this means concretely. A static site costs nearly nothing to run. No databases to scale, no servers to babysit, just files sitting on edge nodes around the world. If you don’t need to capture user data for ad-driven personalization, you don’t need the complexity of the surveillance stack. If you don’t need platform distribution, you don’t need to play platform games.</p> There’s another piece to this that I think most people are missing: edge computing changes what personalization can mean. The conventional wisdom is that personalization requires surveillance, that you need to know everything about a user to show them relevant content. But that’s only true if personalization happens in a centralized database somewhere. If personalization happens at the edge, at the moment of request, you can adapt content to context without ever needing to know who the user is. The edge function doesn’t need a profile. It just needs to know what was asked for and what context it’s being asked in.</p> This is the architecture I keep thinking about: static content at the origin, edge functions that adapt it anonymously, AI agents that find and surface it based on actual relevance rather than SEO gaming. No surveillance required. No platform dependency. No scaling costs that force you into growth-at-all-costs mode.</p> It looks more like a reef than a fish farm.</p> I don’t want to oversell this. The transition, if it happens, won’t be clean. The platforms aren’t going to quietly cede control. The incentives that built the current web are still operating. And AI itself could go in directions that make things worse rather than better. There are plenty of dystopian paths from here.</p> But when I think about what I want to build toward, it’s that reef model. Many small, specialized nodes. Interconnected through open protocols. Resilient because distributed. Sustainable because the economics work at small scale.</p> This site is part of that bet. Static content, no tracking, no platform dependencies. The tools I’m working on (Zentinel, Sango, Ushio) are all about making edge infrastructure more accessible, making it easier to build and operate systems that are distributed and independent.</p> 2025 was the year AI started breaking the old model. I don’t know exactly what grows in its place. But floating in that Okinawan water, watching the reef do what reefs do, I got a sense of what healthy systems look like. Diverse. Interconnected. Resilient. Not optimized for any single metric, but somehow working anyway.</p> That’s what I’m betting on.</p> References and further reading</h2> Tim Berners-Lee</a> - Creator of the World Wide Web and author of “This is for everyone”</li> Enshittification</a> - Cory Doctorow’s term for the pattern of platform decay</li> IndieWeb</a> - Community building the independent web with open standards</li> Zola</a> - Static site generator used to build this site</li> Zentinel</a> - Security-first reverse proxy for the open web</li> Sango</a> - Edge diagnostics CLI for TLS, HTTP, and security header analysis</li> Ushio</a> - Deterministic edge traffic replay tool</li> </ul> Mise ate my Makefile Unknown — Sun, 14 Dec 2025 00:00:00 +0000 I maintain around forty repositories across four GitHub organizations. Zentinel</a> alone accounts for over thirty: the core proxy, a Rust SDK, and a growing collection of agents for WAF inspection, auth, rate limiting, GraphQL security, and a dozen other edge concerns. Archipelag</a> spans an Elixir coordinator, a Rust node agent, Python and TypeScript SDKs, mobile agents in Kotlin and Swift, and infrastructure-as-code repos. Cyanea</a> is Elixir with Rust NIFs and a separate Rust bioinformatics library. Then there are the standalone tools: Conflux</a> (Rust CRDT engine), Sango</a> (Rust edge diagnostics CLI), Shiioo</a> (Rust agentic orchestrator), Vela</a> (Rust bare-metal deployment), Refrakt</a> (Gleam web framework), Kurumi</a> (Svelte local-first app), and this site you are reading (Zola).</p> The languages span Rust, Elixir, Gleam, Python, TypeScript, Kotlin, Swift, and whatever shell scripts accumulated over the years. Every project needs a toolchain. Most need task automation. All of them need to be approachable for a contributor who clones the repo for the first time.</p> The Makefile approach was breaking down. So was everything else I tried.</p> What was failing</h2> The standard setup for most of my Rust projects was a Makefile with targets for build</code>, test</code>, clippy</code>, fmt</code>, and release</code>. Simple enough for one repo. The problem surfaces when you maintain thirty of them.</p> GNU Make and BSD Make disagree on syntax in ways that cause silent failures. A Makefile that works on my Linux CI runner breaks on a contributor’s macOS laptop because of a conditional or a shell invocation difference. The fix is always “use GNU make,” but that means documenting it, adding a check, and fielding issues from people who forget.</p> Worse, Makefiles cannot declare tool dependencies. A Rust project needs a specific Rust version, maybe protoc</code> for gRPC, maybe cargo-watch</code> for development convenience. The Makefile assumes these tools exist. When they do not, the developer gets a cryptic error five minutes into their first build.</p> So projects accumulated scaffolding:</p> .rust-version .tool-versions Makefile scripts/setup.sh scripts/ci.sh scripts/release.sh .envrc </code></pre> Six files to express what amounts to: “this project uses Rust 1.83, needs protoc, and has five things you can run.” Multiply that by forty repos and you have a maintenance surface that nobody wants to touch. The scripts/</code> folder in particular had a way of growing silently. Someone adds a helper. Someone else copies it from another project with modifications. Six months later you have three slightly different versions of the same release script across three orgs.</p> The Elixir projects had it worse. Elixir needs Erlang/OTP at a specific version, then Elixir itself at a matching version, then Node for asset compilation in Phoenix, then possibly Rust for NIFs (Cyanea compiles Rust bioinformatics code into the BEAM release). Four tool dependencies before you write a line of application code. asdf</code> handled the version management, but slowly and without task automation, so you still needed a Makefile on top.</p> Why not Nix</h2> I gave Nix a serious try. The promise is appealing: declare your entire development environment in a single file, get reproducible builds, never worry about system state. The Nix shell concept is genuinely elegant.</p> In practice, the cost was too high for my use case. Nix’s learning curve is steep even for experienced engineers. The language is its own thing. The documentation assumes you already understand the Nix store model. When something breaks, the error messages point at derivation hashes, not at the thing you actually did wrong.</p> The bigger issue was onboarding. If a contributor wants to fix a typo in a Zentinel agent’s README, asking them to install Nix and understand flakes is a non-starter. The tool that manages your development environment should not itself become a project you have to learn. Nix solves a harder problem than I have. I do not need bit-for-bit reproducible builds across machines. I need “install Rust 1.83 and run the tests.”</p> Why not asdf</h2> asdf was my default for years. It handled the version management problem well enough. The plugin system meant I could manage Rust, Elixir, Erlang, Node, and Python versions with a single .tool-versions</code> file.</p> Three things pushed me away.</p> First, speed. asdf is shell scripts. Every invocation pays the cost of sourcing plugins, resolving versions, and shimming binaries. On a fast machine you barely notice. On CI, where you run asdf install</code> in a fresh environment, the overhead adds up. Mise is a compiled Rust binary. It is meaningfully faster at both installation and version resolution.</p> Second, no task automation. asdf manages tool versions. That is all it does. You still need Make or a scripts folder for project tasks. That means two tools, two configuration surfaces, two things to document.</p> Third, plugin quality varied. The core plugins for Node and Ruby were solid. Plugins for less mainstream tools could be stale, broken, or missing. Mise started as an asdf-compatible rewrite and inherited the plugin ecosystem, but its built-in backends for common tools (Rust, Node, Python, Go, Erlang, Elixir) are faster and more reliable than shelling out to plugins.</p> What mise actually does</h2> Mise</a> is a single Rust binary that combines tool version management and task running into one configuration file per project. It does asdf’s job and Make’s job in a single tool.</p> Here is this site’s configuration. The entire thing:</p> # mise.toml (raskell.io) [tools] zola = "0.19" [env] _.file = ".env" [tasks.serve] description = "Start the Zola development server" run = "zola serve" [tasks.build] description = "Build the site for production" run = "zola build" [tasks.check] description = "Check the site for errors without building" run = "zola check" [tasks.new] description = "Create a new article" run = """ #!/usr/bin/env bash if [ -z "$1" ]; then echo "Usage: mise run new <article-slug>" exit 1 fi SLUG="$1" DATE=$(date +%Y-%m-%d) FILE="content/articles/${SLUG}.md" cat > "$FILE" << ARTICLE +++ title = "" date = ${DATE} description = "" [taxonomies] tags = [] categories = [] [extra] author = "Raffael" +++ ARTICLE echo "Created $FILE" """ </code></pre> One file. Declares the tool (Zola 0.19), loads environment variables, and defines every task a contributor needs. mise install</code> sets up the toolchain. mise tasks</code> shows what is available. mise run serve</code> starts the dev server. No Makefile. No scripts folder. No documentation page explaining how to get Zola at the right version.</p> For a Rust project like Shiioo</a> (the agentic orchestrator), the configuration is larger but follows the same pattern:</p> # .mise.toml (shiioo) [tools] rust = "latest" [env] RUST_LOG = "info" RUST_BACKTRACE = "1" _.path = ["./target/release", "./target/debug"] [tasks.build] description = "Build all crates in release mode" run = "cargo build --release" [tasks.test] description = "Run all tests" run = "cargo test" [tasks.clippy] description = "Run clippy lints" run = "cargo clippy --all-targets -- -D warnings" [tasks.fmt] description = "Format code with rustfmt" run = "cargo fmt --all" [tasks.ci] description = "CI pipeline: format check, clippy, test" depends = ["fmt-check", "clippy", "test"] [tasks.dev] description = "Full development build and run" depends = ["fmt", "check", "test"] run = "cargo run -p shiioo-server" </code></pre> The depends</code> key is where mise replaces the one thing Make was genuinely good at: task dependency ordering. mise run ci</code> runs format checking, then clippy, then tests, in sequence. If clippy fails, tests do not run. It is not as expressive as Make’s file-based dependency graph, but for project automation tasks (as opposed to build tasks, which cargo or mix handle), it covers what I actually need.</p> For a multi-language project like Cyanea, the value is even clearer. The Elixir app needs Erlang, Elixir, Node, and Rust. One [tools]</code> section pins all four. One mise install</code> gets a contributor from zero to a working environment. Without mise, that setup involved installing asdf, adding four plugins, running asdf install</code>, then installing direnv for environment variables, then reading the Makefile to figure out how to run things. With mise, it is two commands: mise install</code> and mise run dev</code>.</p> The cross-project pattern</h2> The real payoff is not in any single project. It is the consistency across all of them.</p> Every repo in every org follows the same contract:</p> Clone the repo</li> Run mise install</code></li> Run mise tasks</code> to see what is available</li> Run mise run dev</code> or mise run test</code></li> </ol> That is it. Whether the project is a Rust reverse proxy with thirty modules, an Elixir Phoenix application with LiveView and a NATS integration, a Gleam web framework, or a static site built with Zola, the entry point is identical. The person cloning the repo does not need to know which build system the project uses internally. They do not need to read a CONTRIBUTING.md to find out whether it is make test</code> or cargo test</code> or mix test</code>. It is always mise run test</code>.</p> This matters more than it sounds. When you maintain projects across four orgs and multiple languages, the cognitive overhead per context switch is the actual bottleneck. I work on Zentinel (Rust) in the morning, switch to Archipelag (Elixir) after lunch, then fix something on this site (Zola) in the evening. Without a consistent interface, each switch means recalling which project uses which conventions. With mise, the interface is always the same. The implementation behind mise run test</code> differs (cargo, mix, zola check), but I do not care about that. I type the same command and the right thing happens.</p> For new contributors, the effect is more pronounced. Zentinel’s agent ecosystem has over twenty Rust repos. A contributor who submits a PR to the WAF agent and then wants to help with the auth agent does not need to learn a new setup process. Same structure, same task names, same workflow. The consistency compounds.</p> What mise handles that Make does not</h2> Environment variables.</strong> Mise loads environment from the config file or from .env</code> files, scoped to the project directory. When I cd</code> into a project, the right environment is active. When I leave, it deactivates. No direnv, no .envrc</code>, no source .env</code> in every shell session.</p> Tool installation.</strong> mise install</code> in a fresh clone gets every tool the project needs at the exact specified version. Make cannot do this. Make assumes the tools exist. That assumption breaks on new machines, in CI, and for every new contributor.</p> Task discovery.</strong> mise tasks</code> lists every available task with its description. Make has make help</code> patterns, but those are conventions, not built-in features. With mise, discoverability is the default.</p> File-based tasks.</strong> Any executable file in .mise/tasks/</code> becomes a task automatically. No registration, no config entry needed. For tasks that outgrow a one-liner in TOML but do not warrant a standalone script in scripts/</code>, this is the right middle ground. The task is discoverable through mise tasks</code> but lives as a normal shell script you can test independently.</p> What breaks</h2> Mise is not perfect. Honest assessment after running it across forty repos:</p> Dynamic dependencies.</strong> Make can express “rebuild this if that file changed.” Mise tasks are imperative: they run or they do not. If you need file-level dependency tracking, you still need a build system (cargo, mix, webpack). Mise orchestrates tasks. It does not replace the build tool.</p> Ecosystem maturity.</strong> Mise is younger than Make and asdf. The documentation is good but not exhaustive. Some features (like hooks and watch mode) are recent additions. The pace of development is fast, which means features arrive quickly but occasionally change between minor versions.</p> Team familiarity.</strong> Make is universal. Every engineer has encountered a Makefile. Mise is still relatively unknown. Introducing it to a team requires a short pitch, but the pitch is easy: “it is Make plus asdf in one tool, configured in TOML.”</p> Complex shell tasks.</strong> When a task grows beyond a few lines, the inline TOML string syntax gets awkward. The workaround is file-based tasks in .mise/tasks/</code>, which works well but means the task definition lives in two places (TOML for metadata and task list, shell file for implementation).</p> The migration</h2> If you are moving an existing project, here is the approach I settled on after migrating across all four orgs:</p> Add a mise.toml</code> (or .mise.toml</code>) at the project root. Start with just [tools]</code> to declare the required versions.</li> Move the most-used Make targets to [tasks]</code> one at a time. Keep the Makefile around until everything is ported.</li> Add [env]</code> entries to replace .envrc</code> or .env.example</code> files.</li> Move standalone scripts from scripts/</code> to .mise/tasks/</code> as file-based tasks.</li> Delete the Makefile last.</li> </ol> Do not try to migrate everything at once. Start with the three tasks developers use daily (usually dev</code>, test</code>, and build</code>). The rest can move incrementally. I also settled on a few naming conventions that help across projects: use clear verb-noun prefixes like db-reset</code>, cache-clear</code>, test-unit</code>. Consistent naming makes task discovery predictable even before you run mise tasks</code>.</p> The bottom line</h2> Mise is not a revolutionary tool. It does not do anything that was previously impossible. You could always install the right Rust version, write a Makefile, set up direnv, and maintain a scripts folder. What mise does is collapse all of that into a single file that is readable, portable, and consistent.</p> The compound effect is what matters. Forty repositories, four organizations, six languages, one pattern. Clone, install, run. No guessing which build system this particular project uses. No debugging a Makefile that works on Linux but breaks on macOS. No explaining to a contributor that they need asdf plus three plugins plus direnv plus GNU make before they can run the tests.</p> Every new project starts with a mise.toml</code>. Setup takes two commands instead of a page of instructions. Contributors do not message me asking how to run things. They run mise tasks</code> and figure it out.</p> That is the tool working.</p> References and further reading</h2> mise</a> - Official documentation and installation guide</li> mise source code</a> - GitHub repository and issue tracker</li> asdf</a> - The version manager mise was originally inspired by</li> Nix</a> - Reproducible builds and development environments</li> GNU Make</a> - The build tool mise replaces for task automation</li> TOML specification</a> - The configuration format mise uses</li> direnv</a> - Environment variable manager that mise’s [env]</code> section replaces</li> Shiioo</a> - Real-world mise configuration referenced in this article</li> mise-hx</a> - Example of a custom mise plugin (for the hx Haskell toolchain)</li> </ul> Disk space maintenance on Void Linux Unknown — Wed, 01 May 2024 00:00:00 +0000 Monday morning surprise</h2> As I spent most time doing stuff with my computer rather than configuring my beloved Linux distribution, Void Linux, I have developed the tendency to not really bother about Void at all until something crucial becomes unusable. After almost two years of having switched from Arch to Void, I have actually never encountered any major problem and felt I had made the right decision.</p> I checked my disk usage out of curiosity if the 250GB solid-state disk would be enough. And there came the surprise:</p> $ df -H Filesystem Size Used Avail Use% Mounted on devtmpfs 8.4G 0 8.4G 0% /dev tmpfs 8.4G 1.9M 8.4G 1% /dev/shm tmpfs 8.4G 1.4M 8.4G 1% /run /dev/nvme0n1p3 138G 117G 21G 85% / efivarfs 158k 85k 69k 56% /sys/firmware/efi/efivars cgroup 8.4G 0 8.4G 0% /sys/fs/cgroup /dev/nvme0n1p4 366G 34G 332G 10% /home /dev/nvme0n1p1 536M 152k 536M 1% /boot/efi tmpfs 8.4G 25k 8.4G 1% /tmp </code></pre> My root partition was full, way too full in my opinion. Did I miss something? Is Void not what I was looking for after all? I don’t enjoy baby sitting my OS du jour</em>.</p> The painless solution</h2> After a quick Brave search, I ended up finding what I was looking for. Some kind fellow software engineer from China didn’t shy away to make a blog post about his journey when he faced the very same problem. Out of annoyance of having to deal with that, I copy-pasted as quickly as possible, not minding what kind of side-effects I might run into, these three commands.</p> 1. Cleaning the package cache</h3> All the knowledge I was lacking was to be found with the man page of xbps-remove</code>.</p> # xbps-remove -yO </code></pre> The man page</a> of xbps-remove</code> tells us the -O</code> parameter takes care of cleaning the cache directory removing obsolete binary packages.</em> Obsolete binary packages? Good riddance! I was surprised this to learn that solely this step freed up almost half of my used root partition disk space.</p> 2. Removing orphaned packages</h3> # xbps-remove -yo </code></pre> Here the same man page</a> tells us that the -o</code> parameter takes care of removing installed package orphans that were installed automatically (as dependencies) and are not currently dependencies of any installed package.</em> As before, good riddance!</p> 3. Purging old, unused kernels</h3> This one is interesting. While I knew about the circumstance that the people behind Void had developed their own package management ecosystem, I hadn’t fully realized there were other utilities that came along with the upstream Void installation which were there for me to manage my beloved OS. So, apparently, one of these is a shell script</a> name vkpurge</code>, I must assume as a short name for Void's Kernel purging</code> tool. I like this type of naming heavily implying its functionality.</p> # vkpurge rm all </code></pre> It performed as expected. Old kernel files (and modules?) were indeed purged and freed up even more disk space. I should add that this step is optional as it is always useful to have some old kernels at hand when things hit the fan (which for me, they haven’t in a very, very long time).</p> Result</h2> I couldn’t be happier.</p> $ df -H Filesystem Size Used Avail Use% Mounted on ... /dev/nvme0n1p3 138G 45G 93G 33% / ... </code></pre> Renewal of faith</h2> Overall, why am I even writing this if some other fellow engineer already figured this out? Simply, because I would therefore be able to explain why I have enjoyed my journey with Void as my go-to Linux distribution. It keeps things simple. Some well-documented utilities. As simple that a simple Brave search suffices to find the answer to my problems.</p> This very aspect of Void is worthwhile highlighing. I remember more arcane Linux distributions that had me in their grip in figuring things out. Many Googles searches were necessary and even more trial and errors attempts to get simple things fixed.</p> Now back to my Monday morning.</p> References and further reading</h2> Void Linux</a> - Official project site</li> Void Linux Handbook: XBPS</a> - Official documentation for the XBPS package manager</li> xbps-remove(1) man page</a> - Manual page for package removal and cache cleaning</li> vkpurge source</a> - Shell script for purging old kernels on Void Linux</li> Void Linux FAQ</a> - Common questions about running and maintaining Void</li> </ul> ^{1</sup> Painting in header image is “Seaside” by Aleksandr Deyneka</p> </div>} All beginning is Haskell Unknown — Mon, 06 Mar 2023 00:00:00 +0000 This site is called raskell.io. That is not an accident.</p> I started learning Haskell because I liked mathematics and someone told me there was a programming language built on top of it. Not “inspired by” in the loose way that every language claims some mathematical foundation. Actually built on lambda calculus, category theory, and type theory, in a way where the math is not decoration but structure.</p> What I did not expect was how thoroughly it would rewire the way I think about building software. Not because Haskell is the best language for every task. It is not, and I write far more Rust than Haskell these days. But because Haskell teaches you to think about programs in a way that makes you better at everything else.</p> What Haskell actually teaches you</h2> Most introductions to Haskell talk about pure functions, immutability, and monads. They are not wrong, but they miss the point. The point is not any single feature. It is how those features combine into a way of thinking about programs as compositions of well-typed transformations.</p> In an imperative language, you think about sequences of steps. Do this, then that, then check a condition, then loop. The program is a recipe. In Haskell, you think about transformations. What goes in, what comes out, what shape does the data have at each stage. The program is a pipeline.</p> This sounds abstract until you see it in practice. Suppose you need to process a list of user records: filter out inactive users, extract their email addresses, and normalize them to lowercase.</p> In an imperative style, you write a loop with conditions and mutations. In Haskell:</p> activeEmails :: [User] -> [Email] activeEmails = map (normalize . email) . filter isActive </code></pre> One line. Read it right to left: filter active users, then map over the result, extracting and normalizing emails. The type signature tells you what goes in ([User]</code>) and what comes out ([Email]</code>). No mutation. No intermediate variables. No place for off-by-one errors or null pointer exceptions.</p> The type signature is not just documentation. It is a contract enforced by the compiler. If isActive</code> expects a User</code> and you pass it a String</code>, the program will not compile. If normalize</code> returns an Email</code> but you try to use it as a String</code>, the program will not compile. The compiler is your first reviewer, and it is tireless.</p> Types as design tools</h2> The deeper lesson is that types are not just error catchers. They are design tools.</p> When I design a system in Haskell, I start with the types. What are the entities? What are the relationships? What transformations are valid? The type system forces you to be precise about these questions before you write any logic. This precision surfaces design problems early, when they are cheap to fix.</p> Consider modeling a document that can be in one of several states:</p> data Document = Draft { content :: Text, author :: UserId } | UnderReview { content :: Text, author :: UserId, reviewer :: UserId } | Published { content :: Text, author :: UserId, publishedAt :: UTCTime } </code></pre> This is an algebraic data type. Each variant carries exactly the data that makes sense for that state. A Draft</code> has no reviewer. A Published</code> document has a timestamp. You cannot accidentally access a reviewer on a draft because the type system will not let you. The invalid state is unrepresentable.</p> This pattern, making illegal states unrepresentable, is perhaps the most valuable idea I took from Haskell. I use it in Rust constantly. Rust’s enum</code> with associated data is directly descended from Haskell’s algebraic data types, and the same design principle applies: encode your invariants in the type system and let the compiler enforce them.</p> The monad is not the point</h2> Every Haskell introduction eventually gets to monads, usually with a metaphor involving burritos or boxes. I will skip the metaphor.</p> A monad is a pattern for sequencing computations that carry some context. The IO</code> monad carries the context of interacting with the outside world. The Maybe</code> monad carries the context of possible failure. The State</code> monad carries the context of mutable state. The pattern is the same in each case: take a value in a context, apply a function that produces a new value in a context, get back a combined context.</p> lookupUser :: UserId -> IO (Maybe User) lookupUser uid = do conn <- getConnection result <- query conn "SELECT * FROM users WHERE id = ?" [uid] return (listToMaybe result) </code></pre> The IO</code> monad here sequences database operations. The Maybe</code> handles the case where no user is found. The types tell you both things at a glance: this function does I/O and might not return a result.</p> The point of monads is not that they are clever. The point is that they make effects explicit and composable. In most languages, a function can do I/O, throw exceptions, mutate global state, or launch missiles, and you cannot tell from its signature. In Haskell, the type signature tells you exactly what effects a function can have. Int -> Int</code> is pure. Int -> IO Int</code> does I/O. Int -> Maybe Int</code> can fail. The information is right there, enforced by the compiler.</p> This discipline, making effects explicit, changed how I design APIs even in languages that do not enforce it. When I write a Rust function that returns Result<T, E></code>, I am using the same pattern: making failure explicit in the type rather than hiding it behind an exception. Rust learned this from Haskell, and so did I.</p> Why I am still building Haskell tooling</h2> If Haskell taught me so much, why do I mostly write Rust?</p> The honest answer: Haskell’s ecosystem has gaps. The language itself is excellent. GHC is one of the most sophisticated compilers ever built. The type system is unmatched in its expressiveness among production languages. But the surrounding infrastructure, the package management, the build tooling, the deployment story, has not kept pace.</p> Dependency management in Haskell is fragmented. Cabal and Stack coexist with overlapping but incompatible approaches. Build times are long. Cross-compilation is painful. Setting up a Haskell development environment from scratch still involves more friction than it should in 2026.</p> This is why hx exists. hx is a Haskell toolchain CLI that I am building in Rust. The choice of implementation language is deliberate. Haskell’s tooling problems are partly caused by tooling that is itself written in Haskell, creating bootstrap problems and long compile times for the tools themselves. A Rust binary starts instantly, compiles to a single static executable, and cross-compiles trivially. The tool should not have the same dependencies as the thing it manages.</p> hx is distributed through mise</a> (naturally), as well as through AUR, Homebrew, Scoop, and Chocolatey. The goal is that setting up a Haskell project should be as frictionless as setting up a Rust project: one command to install the toolchain, one command to build.</p> On the other end of the spectrum, bhc (the Basel Haskell Compiler) is an experiment in taking Haskell in a direction GHC was never designed for: compiling Haskell for low-latency runtimes without a garbage collector. The target is workloads like tensor pipelines and real-time systems where GC pauses are not acceptable. bhc is early and ambitious, but it comes from the same conviction: Haskell’s ideas deserve better infrastructure than they currently have.</p> The Haskell in my Rust</h2> I write Rust the way Haskell taught me to think.</p> Rust’s ownership model is not the same as Haskell’s purity, but it serves a similar purpose: it forces you to think about data flow explicitly. In Haskell, you cannot mutate a value because the language will not let you. In Rust, you can mutate, but the borrow checker forces you to be explicit about who owns the data and who can see it. Both languages make you think before you write.</p> Conflux</a>, my CRDT engine, uses algebraic data types for its merge semantics. Each CRDT field type (LwwRegister, GrowOnlySet, ObservedRemoveSet) is an enum variant with associated data, exactly the pattern I described above. The merge function is associative, commutative, and idempotent. These are mathematical properties that I learned to care about from Haskell, where such properties are often expressed as type class laws.</p> Zentinel</a>, the reverse proxy, uses Rust’s type system to enforce that WAF decisions are handled in the correct pipeline stage. An AgentDecision</code> is either Allow</code>, Block</code>, or Modify</code>, and the proxy’s merge logic ensures that a Block</code> from any agent cannot be overridden. The pattern is a monoid (decisions combine associatively with Block</code> as the absorbing element), though nobody would call it that in the Rust codebase. The concept came from Haskell. The implementation is pure Rust.</p> Even Shiioo</a>, the agentic orchestrator, uses Haskell-influenced patterns. DAG workflows are compositions of typed transformations. Events are algebraic data types with exhaustive pattern matching. The event-sourcing model treats state as a fold over an event stream. foldl</code> in Haskell, Iterator::fold</code> in Rust. Same idea, different syntax.</p> Why “raskell”</h2> The name is a portmanteau. Raffael plus Haskell. I chose it because Haskell is where my engineering thinking started to take its current shape. Not the first language I learned, but the first one that changed how I think about all the others.</p> I do not believe you need to write Haskell to benefit from Haskell. But I believe that learning it, really learning it, not just reading about monads but building something real with algebraic data types and type classes and higher-order functions, will make you a better engineer in whatever language you actually use.</p> All beginning is Haskell. The rest is implementation.</p> References and further reading</h2> Learning Haskell</h3> Haskell Language</a> - Official site with documentation and community links</li> Learn You a Haskell for Great Good!</a> - Approachable illustrated introduction</li> Real World Haskell</a> - Practical Haskell for production use</li> Haskell Wiki</a> - Community-maintained reference and tutorials</li> Typeclassopedia</a> - Comprehensive guide to Haskell’s type class hierarchy</li> </ul> Type systems and theory</h3> Haskell Curry</a> - The logician the language is named after</li> Lambda calculus</a> - Alonzo Church’s formal system underlying Haskell</li> Hindley-Milner type system</a> - The type inference algorithm at the core of Haskell and ML</li> Making illegal states unrepresentable</a> - Yaron Minsky’s influential talk on using types for correctness</li> Algebraic data types</a> - Haskell wiki reference on sum and product types</li> </ul> Monads and effects</h3> Philip Wadler, “Monads for functional programming”</a> - The foundational paper on monads in programming</li> All About Monads</a> - Haskell wiki guide to monadic programming</li> </ul> Haskell tooling</h3> GHC</a> - The Glasgow Haskell Compiler</li> Cabal</a> - Haskell’s build and package system</li> Stack</a> - Alternative build tool with curated package sets</li> mise-hx</a> - mise plugin for the hx Haskell toolchain CLI</li> </ul> Projects referenced</h3> Conflux</a> - CRDT engine using algebraic data types for merge semantics</li> Zentinel</a> - Reverse proxy with monoid-based decision merging</li> Shiioo</a> - Agentic orchestrator using event-sourced state folds</li> </ul> My OpenBSD journey: Getting it virtualized with libvirt (1) Unknown — Mon, 06 Feb 2023 00:00:00 +0000 Void Linux as my daily driver</h2> Around six months ago, I decided to ditch my long in the tooth Arch-based setup on my belovest Thinkpad X1 Carbon. I’ve been very loyal over the years, and almost came to belive that Arch will be a constant in my adult life. While I kept up with upcoming technologies, I somehow lost track of the ever so diversifying landscape of Linux distributions. It took me a while of constantly coming across a generically named reference to what seemed to be yet another Linux distribution. That outwardly generic sounding name, Void Linux</a>, kept poking my curiosity by supposedly feeling like Arch Linux in the old days, while sharing some substantial DNA with the BSD operating systems. Yet, that’s another story I might tell another day, but to remain brief, the BSDs, in particular the infamous OpenBSD with its quite infamous lead developer Theo De Raadt, always were what I considered the endgame. The holy grail of Unix operating systems, so did I think over the decades, FreeBSD, NetBSD and OpenBSD, have always been on my personal radar and I felt I had to earn the intellectual capacity to be able to properly put them at use one day. Last year, when I made the (almost painless) switch from Arch Linux to Void Linux, the simplicity and especially the barebone experience of Void reignited the fascination and the admiration I always had for the BSD operating systems and their philosophy.</p> While I could write (and definitely will in the near future) about how my journey onto Void Linux and how it has been so far, I preferred to write down, in some like diary, and document every step on how one can approach and ultimately use OpenBSD</a> in 2023. Big disclaimer, I’ve yet to install OpenBSD on some baremetal server I ordered some days ago, but dabbled around in the meantime with OS-level virtualization in order to get it running. That’s what brings me to libvirt</em> and my surprise to learn that I wouldn’t need some full-fledged virtualization solution like the ones offered by VirtualBox or VMWare to efficiently run a virtualized OpenBSD machine. So, ok, let’s recap, so far we got the following bill of materials:</p> Void Linux as the host system</li> OpenBSD to be virtualized on that host system</li> libvirt as the glue that makes virtualization feel like black magic</li> </ul> From Void to OpenBSD</h3> Before I tell you more about the history of how things went down while setting up OpenBSD, let me give you some basic notions about both Void Linux, being one out of many Linux distributions for the sake of simplicity representing them all as it ended up being my distribution of choice, and OpenBSD. As already mentioned earlier, Void Linux and OpenBSD are both Unix-like operating systems, but they feature enough differences to make them noteworthy. Here are a few similarities and differences between the two:</p> What is similar:</p> Both are free and open-source operating systems.</li> Both use a package manager for software management. Void Linux uses XBPS, while OpenBSD uses pkg_add.</li> Both prioritize security and stability in their development and design.</li> Both feature a version control based package repository, meaning that changes in build definition are managed by pull requests from users.</li> </ul> What is different:</p> License: Void Linux is licensed under the MIT License, while OpenBSD is licensed under the ISC License.</li> Philosophy: OpenBSD prioritizes security and privacy, while Void Linux prioritizes simplicity and modularity.</li> Package Management: Void Linux uses the XBPS binary package manager, while OpenBSD uses pkg_add (also binary). OpenBSD additionally has a ports system for building from source.</li> Package Repository: Void Linux has a large and diverse repository, while OpenBSD has a smaller and more curated repository.</li> Init System: Void Linux uses runit as its init system, while OpenBSD uses rc. None uses the infamous systemd init system.</li> </ul> What is OpenBSD in a nutshell</h2> OpenBSD is a free and open-source operating system that focuses on security, standardization, and robustness. It is based on the Berkeley Software Distribution (BSD) Unix operating system and is developed by a global community of volunteers. OpenBSD aims to provide a secure platform for both personal and enterprise use by implementing strong security features, including access control mechanisms, encryption, and auditing.</p> Theo de Raadt</a> is the founder and lead developer of OpenBSD. His main objective with OpenBSD is to create a secure operating system that is free from backdoors, vulnerabilities, and other security weaknesses. He is committed to auditing the source code of the operating system and third-party software included with it, to identify and remove any potential security risks. De Raadt is also dedicated to improving the overall quality of the codebase and ensuring compatibility with a wide range of hardware and software.</p> What makes OpenBSD really special and stand out is that is developed a suite of tools that got adopted by other OSs like Linux, macOS or even Windows. One of the most famous instances of such adoption is the now de facto standard openssh suite. It actually emerged from within the development circle of the OpenBSD project. OpenBSD also implemented a wide range of OS features that are by now considered staples among other OSs, things like Linux-based OS-level containerization done via the means of cgroups, something that OpenBSD already pioneered and solved with a different spin many years before Linux with pledge and unveil. Go check out Why OpenBSD rocks</a> to get a feel what makes OpenBSD so unique and interesting.</p> Virtualization with libvirt</h3> So now, let’s get back to our virtualization endeavour where we would like to virtualize OpenBSD on a Void Linux installation. If you happen to be using another Linux distribution, most of the individual steps would be very similar. That brings me to the next technology we should explain a bit more here, and that is libvirt.</p> libvirt</a> is an open-source virtualization management library that provides a simple and unified API for managing virtualization technologies, including KVM, QEMU, Xen, and others. It aims to simplify the process of creating, managing, and migrating virtual machines, storage, and networks, and to make it easier for administrators to manage virtual environments.</p> To virtualize an operating system like OpenBSD with libvirt, you need to follow these steps:</p> Install libvirt and the virtualization technology you want to use, such as KVM.</li> Download the OpenBSD iso file and place it in a location accessible by libvirt.</li> Create a new virtual machine in libvirt with the OpenBSD ISO as the installation media. This can be done through the command line or using a graphical user interface such as virt-manager.</li> Configure the virtual machine, including the amount of memory, CPU, and disk space, to meet the requirements of OpenBSD.</li> Start the virtual machine and install OpenBSD as you would on a physical machine.</li> Once the installation is complete, you can configure the virtual network, storage, and other settings as required.</li> Finally, you can use the libvirt API or the command line to manage and control the virtual machine, including starting, stopping, migrating, and snapshotting.</li> </ol> Step-by-step guide</h3> Let’s first install the libvirt</code> package and some related packages which we need in order to connect via VNC. The VNC will provide us with the possibility to use the graphical interface of the running OpenBSD instance.</p> $ sudo xbps-install -S dbus qemu libvirt virt-manager virt-viewer tigervnc </code></pre> Now, we need to add our user, in my case raskell</code>, to the libvirt</code> group which got simultanously created with the installation of libvirt.</p> $ sudo usermod -aG libvirt raskell </code></pre> OpenBSD features a release cycle of six months. We would need to update our system every six month to keep up with the latest packages. During a given release, only security and bug fix patches are applied to the curated packages maintained by pkg_add. Therefore, in February 2023, we’re using the OpenBSD 7.2</a> release version. As I’m living in Switzerland, I chose to pull the iso image from a Swiss mirror, in this case from mirror.ungleich.ch/pub/OpenBSD</code></a> (check what mirror is closest to you to get the best download rate).</p> # cd /var/lib/libvirt/boot/ # sudo wget https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/install72.iso --2023-01-12 20:48:15-- https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/install72.iso Resolving mirror.ungleich.ch (mirror.ungleich.ch)... 2a0a:e5c0:2:2:400:c8ff:fe68:bef3, 185.203.114.135 Connecting to mirror.ungleich.ch (mirror.ungleich.ch)|2a0a:e5c0:2:2:400:c8ff:fe68:bef3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 583352320 (556M) [application/octet-stream] Saving to: ‘install72.iso.1’ install72.iso.1 100%[====================================================================>] 556.33M 7.11MB/s in 77s 2023-01-12 20:49:33 (7.19 MB/s) - ‘install72.iso.1’ saved [583352320/583352320] sudo wget https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/SHA256 --2023-01-12 20:47:38-- https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/SHA256 Resolving mirror.ungleich.ch (mirror.ungleich.ch)... 2a0a:e5c0:2:2:400:c8ff:fe68:bef3, 185.203.114.135 Connecting to mirror.ungleich.ch (mirror.ungleich.ch)|2a0a:e5c0:2:2:400:c8ff:fe68:bef3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1992 (1.9K) [application/octet-stream] Saving to: ‘SHA256.1’ SHA256.1 100%[====================================================================>] 1.95K --.-KB/s in 0s 2023-01-12 20:47:39 (742 MB/s) - ‘SHA256.1’ saved [1992/1992] # grep install63.iso SHA256 > /tmp/x # sha256sum -c /tmp/x # rm /tmp/x </code></pre> Before we can start the virtualization server and get running our OpenBSD instance, we need to define the configuraiton on how to virtualize and ultimately boot the system with. This is done with virt-install</code>. Noteworthy here is that we QEMU</a> as our emulation solution of choice, we allocate up to 4GB of RAM and 4 CPU cores to the machine.</p> $ sudo virt-install \ --name=openbsd \ --virt-type=qemu \ --memory=2048,maxmemory=4096 \ --vcpus=2,maxvcpus=4 \ --cpu host \ --os-variant=openbsd7.0 \ --cdrom=/var/lib/libvirt/boot/install72.iso \ --network=bridge=virbr0,model=virtio \ --graphics=vnc \ --disk path=/var/lib/libvirt/images/openbsd.qcow2,size=40,bus=virtio,format=qcow2 </code></pre> Once, it is up and running, we can use a vnc solution to connect to the running machine. In this case, I chose virsh</a> to do the job. virsh is a command-line interface tool for managing virtualization environments created with libvirt. It allows us to manage virtual machines, storage pools, and network interfaces, as well as other virtualization components, from the command line.</p> To establish a VNC connection with a running libvirt virtualized OpenBSD instance, you can use the following steps:</p> Start the virtual machine in libvirt: You can start the virtual machine using the virsh command virsh start <vm-name></code></strong>, where <vm-name></code></strong> is the name of the virtual machine you want to start.</li> Find the VNC display: Once the virtual machine is running, you can find the VNC display number for the virtual machine using the virsh command virsh vncdisplay <vm-name></code></strong>.</li> Connect to the VNC display: You can connect to the VNC display using a VNC client, such as vncviewer</code></strong>, and specify the IP address of the host running the virtual machine and the VNC display number. For example, if the host’s IP address is 192.168.0.100</code></strong> and the VNC display number is :0</code></strong>, the command to connect would be vncviewer 192.168.0.100:0</code></strong>.</li> Authenticate to the VNC server: You may need to enter a password to authenticate to the VNC server. The password is set when the virtual machine is created in libvirt.</li> </ol> With these steps, you can establish a VNC connection with a running libvirt virtualized OpenBSD instance and interact with the virtual machine’s graphical user interface.</p> $ virsh dumpxml openbsd | grep vnc <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> </code></pre> Like I did, most of you would like to interact with a graphical interface such as with X11. For that, we yet another tool, a so-called VNC viewer. A very simple implementation of such a vnc viewer is tigervnc</a> (simply install it with $ sudo xbps-install -S tigervnc</code>).</p> $ sudo virsh --connect qemu:///system start openbsd Domain 'openbsd' started </code></pre> References and further reading</h2> OpenBSD</h3> OpenBSD</a> - Official project site</li> OpenBSD FAQ</a> - Comprehensive installation and usage guide</li> Why OpenBSD Rocks</a> - Collection of OpenBSD innovations and features</li> OpenSSH</a> - The SSH suite that originated from the OpenBSD project</li> Theo de Raadt</a> - OpenBSD founder and lead developer</li> pledge(2)</a> - OpenBSD’s system call for restricting process capabilities</li> unveil(2)</a> - OpenBSD’s system call for restricting filesystem visibility</li> </ul> Void Linux</h3> Void Linux</a> - Official project site</li> Void Linux Handbook</a> - Official documentation</li> XBPS package manager</a> - Void’s binary package management system</li> </ul> Virtualization</h3> libvirt</a> - Virtualization management library and API</li> QEMU</a> - Open-source machine emulator and virtualizer</li> virsh(1)</a> - Command-line interface for managing libvirt guests</li> TigerVNC</a> - VNC implementation for remote desktop access</li> </ul> Guides</h3> [Guide] How to setup QEMU/KVM emulation on Void Linux</a> - Community guide on r/voidlinux</li> KVM virt-install: Install OpenBSD as Guest Operating System</a> - Step-by-step KVM installation guide</li> Auto-install OpenBSD on QEMU</a> - Automated OpenBSD installation on QEMU</li> </ul> Hello and outlook Unknown — Tue, 20 Sep 2022 00:00:00 +0000 Hello world</h2> Welcome to my tech blog! My name is Raffael and I am excited to share my musings about the state of tech, open-source, and the life as a software developer with you.</p> In this first post, I wanted to introduce myself and explain what you can expect to find on this blog. I have been working in the tech industry for several years, and I have experience with a variety of technologies, programming languages, and operating systems. I have a strong interest in open-source software and the principles of open collaboration and sharing that underpin it. Also, I have a passion for tech hardware and the functional restoration of discarded equipment. The freedom to express oneself with technology to make the world a more comfortable place is a strong focus of mine.</p> Outlook</h2> On this blog, I will be covering a wide range of topics related to technology in general, open-source, operating systems, programming, and tech hardware. Some of the things you can expect to find include:</p> My dabblings into new and bleeding-edge technologies in general</li> My experience in using Linux, BSDs, and embedded operating systems</li> Exploration of new and exciting open-source projects</li> Discussion of the latest technology trends and innovations</li> Personal musings and insights into the tech industry</li> </ul> I believe that technology has the power to change the world, and I am excited to be a small part of that change. I hope that this blog will serve as a valuable resource for anyone interested in technology, open-source, Linux, OpenBSD, and programming. I will be posting new content on a regular basis, so be sure to check back often.</p> In my next post, I will dive into a specific topic and share my knowledge and experience. I want to make sure that my readers will learn something new every time they visit my blog.</p> Thank you for visiting, and I look forward to connecting with you on social media or in real life.</p> References</h2> Void Linux</a> - My Linux distribution of choice at the time of writing</li> OpenBSD</a> - The security-focused BSD operating system</li> raskell.io source</a> - This site’s source code</li> </ul>

References and further reading</h2>

Projects referenced</h3>

Zentinel</a> - Security-first reverse proxy built on Pingora</li>
Archipelag</a> - Distributed compute platform</li>
Cyanea</a> - Bioinformatics platform</li>
Claude Code</a> - AI coding tool used to build Vela</li> </ul>

What moved to the edge</h2>

What moved to the client</h2>
The other half of the migration goes downward. The browser is not the thin client it used to be.</p>

Looking back on 2025

Mise ate my Makefile

Disk space maintenance on Void Linux

All beginning is Haskell

References and further reading</h2>

Projects referenced</h3>

Conflux</a> - CRDT engine using algebraic data types for merge semantics</li>
Zentinel</a> - Reverse proxy with monoid-based decision merging</li>
Shiioo</a> - Agentic orchestrator using event-sourced state folds</li> </ul>

My OpenBSD journey: Getting it virtualized with libvirt (1)

References and further reading</h2>

Guides</h3>

[Guide] How to setup QEMU/KVM emulation on Void Linux</a> - Community guide on r/voidlinux</li>
KVM virt-install: Install OpenBSD as Guest Operating System</a> - Step-by-step KVM installation guide</li>
Auto-install OpenBSD on QEMU</a> - Automated OpenBSD installation on QEMU</li> </ul>

Hello and outlook

References</h2>

Void Linux</a> - My Linux distribution of choice at the time of writing</li>
OpenBSD</a> - The security-focused BSD operating system</li>
raskell.io source</a> - This site’s source code</li> </ul>

Raskell

Archipelag.io Is in Open Beta: Here's Why I Built It

How AI Makes Bare Metal Viable Again

Edge Systems Are the New Backend

Raskell

Archipelag.io Is in Open Beta: Here's Why I Built It

How AI Makes Bare Metal Viable Again

Process supervision</h3> Vela does not just start your app and walk away. It supervises it. If a process crashes, Vela detects the exit (via non-blocking try_wait</code> on the child process handle), logs it, and restarts from the stored launch configuration:</p>

References and further reading</h2>

Edge Systems Are the New Backend

What moved to the edge</h2>

What moved to the client</h2> The other half of the migration goes downward. The browser is not the thin client it used to be.</p>

Looking back on 2025

Mise ate my Makefile

The cross-project pattern</h2> The real payoff is not in any single project. It is the consistency across all of them.</p> Every repo in every org follows the same contract:</p> Clone the repo</li> Run mise install</code></li> Run mise tasks</code> to see what is available</li>

Disk space maintenance on Void Linux

1. Cleaning the package cache</h3> All the knowledge I was lacking was to be found with the man page of xbps-remove</code>.</p>

Result</h2> I couldn’t be happier.</p>

All beginning is Haskell

References and further reading</h2>

My OpenBSD journey: Getting it virtualized with libvirt (1)

Step-by-step guide</h3> Let’s first install the libvirt</code> package and some related packages which we need in order to connect via VNC. The VNC will provide us with the possibility to use the graphical interface of the running OpenBSD instance.</p>

References and further reading</h2>

Hello and outlook

What moved to the client</h2>
The other half of the migration goes downward. The browser is not the thin client it used to be.</p>