标签：#net

Microsoft has released a reference architecture for routing agent traffic on Azure Kubernetes Service. It breaks down the issue into three key choices: which model answers a call, how the call is managed, and which GPU replica handles it. By Claudio Masolo

Microsoft has released .NET 11 Preview 6 with several architectural and reliability improvements for .NET MAUI. The update brings the next-generation CollectionView implementation to Windows, moves Android Shell toward the handler model, improves Native AOT compatibility, and adds recovery support for interrupted media-picker operations. By Edin Kapić

Foreman is an agentic coder that runs as Kubernetes resources. You describe work as a Workload, it decomposes into tasks, agents running on your nodes pick them up, and a branch comes out the other end with something deterministic standing between that branch and your main. This is the walkthrough. Four objects to understand, an install, an agent, a verifier, and a real run. Every command and every output below is from a working cluster. The four objects Foreman is deliberately small. Almost everything you do is one of these. Agent is a worker definition: which model it talks to, which tools it may call, and what budget it gets. An Agent has a role , and the two that matter here are coder and verifier . Workload is the unit of work you actually author. It carries an intent, a repository, and which agents to use. AgenticTask is what a Workload decomposes into. You rarely write one by hand; you read them to see what is happening. FleetNode is a node that has advertised itself as able to run tasks. The scheduler matches a task's required capabilities against these. The shape of a run is: you apply a Workload, the controller synthesizes AgenticTasks, the scheduler routes each to a FleetNode whose agent can serve it, the agent runs the model in a loop with tools, and the result lands as a branch plus a verdict. The idea underneath it Worth stating plainly, because it shapes every design decision: the model is not trusted, and specifically its claim to have succeeded is not trusted. A coder agent finishes by calling a tool that says "I am done, verdict GO." Foreman treats that as a request, not a result. If the model says GO and produced no diff, the run is recorded as NO-GO. If the verifier's checks do not pass, the work does not land, no matter how confident the summary was. That is the difference between an agent that writes code and a system you can leave running. Everything else in this post is plumbing around that idea. Install Foreman ships as a Helm chart that dep

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project Overview Staxa is a multi-tenant deployment platform I am building solo under Stackforge Labs. The backend is a single Go binary ( staxad ) using the chi router, with about 60 API endpoints, running on K3s on a Hetzner CAX21 ARM64 server that costs around $11/month. Each tenant gets an isolated Kubernetes namespace with their own app container, a PostgreSQL 16 or MySQL 8 database, a subdomain with automatic SSL, and resource quotas. Container builds run through Buildah, and the frontend is Next.js (App Router) with shadcn/ui and Clerk for auth. Bug Fix or Performance Improvement The symptom: POST /api/v1/tenants/{id}/deployments/{depId}/rollback accepted a deployment ID in the URL path and then completely ignored it. Whatever version you asked for, you got the most recent successful deployment instead. The route was wired up correctly in internal/api/router.go:149 : r . Post ( "/tenants/{id}/deployments/{depId}/rollback" , srv . handleRollbackDeployment ) But handleRollbackDeployment never called chi.URLParam(r, "depId") . It read {id} for the tenant and stopped there. How I found it: I was auditing my published API docs against the actual handlers, endpoint by endpoint. When I got to the rollback entry I went to write down what {depId} did, went to the handler to confirm, and found nothing reading it. The docs described an ID that the code never looked at. The worst part is that it returned 202 Accepted and then performed a real, successful rollback. Just not the one you asked for. There was no error to notice, no failed request in any log. The frontend had been passing the deployment ID into the URL since it was written ( src/lib/api.ts ), so the UI always believed the parameter was honored. Root cause: the handler created a rollback deployment row with no reference to any target, and the worker independently decided what to restore. In internal/worker/pipeline.go , runRo

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-07/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols as logic — inputs, state, and branches — rather than as configuration examples. Every module points at one real Python file and asks you to read it the way you'd read any other code: what comes in, what mutates, where does control leave early. The source lives at github.com/pathvector-studio/protocol-in-code . Note: If you're newer to this and want to run things before you read things, start with Protocol Lab — the hands-on companion series that builds the muscle memory this one assumes. The question How does local import policy change or reject a path before best-path selection runs? That's the whole module in one line, and it hides a claim worth being suspicious of. Best-path selection in BGP is the famous part — the ordered tiebreaker list everyone half-remembers: highest weight, highest local_pref , shortest AS path, and so on. It's easy to treat that comparison as the decision point, as if routes arrive from peers and get ranked. They don't arrive and get ranked. They arrive, get rewritten , and then get ranked. Import policy is a function that runs between the wire and the comparison, and it has two powers: it can change the values the comparison reads, and it can make the candidate not exist at all. Which means the interesting question isn't "who won best-path" but "what did best-path actually receive." Read the code The file is src/protocol_in_code/bgp/import_policy.py . It's short enough to hold in your head all at once, which is the point — the shape is the lesson. Start with the policy object: @dataclass ( frozen = True ) class ImportPolicy : local_pref_override : int | None = None weight : int = 0 reject_next_hops : tuple [ str , ...] = () reject_invalid : bool = False Four knobs, and notice they're not four of the same thing. Two of them ( local_pref_overri

Microsoft has released .NET 11 Preview 6, with updates across C#, ASP.NET Core, .NET MAUI, and Entity Framework Core. C# adds extension indexers and built-in union support types. ASP.NET Core brings async validation, automatic CSRF protection, and OpenAPI 3.2 by default. MAUI extends CollectionView to Windows, and EF Core adds FULL OUTER JOIN translation. By Almir Vuk

The Go pod is running in production. CPU limit set to 2, metrics look reasonable. But under load, P99 latencies spike intermittently with no obvious cause. No errors, no goroutine leaks, just latency blowing up on traffic bursts. The root cause is usually invisible: GOMAXPROCS equals the number of CPUs on the physical node, not the container limit. Your Go app thinks it has 32 CPUs when it only has 2. The Linux kernel handles the gap in its own way — CFS throttling. What GOMAXPROCS reads (and what it ignores) By default, the Go runtime computes GOMAXPROCS via runtime.NumCPU() , which reads the number of CPUs available at the OS level. On a 32-core Kubernetes node, that returns 32 — regardless of what resources.limits.cpu says in your pod spec. Kubernetes CPU limits are enforced through Linux cgroups (v1 or v2). Cgroups are transparent to processes: a pod with limits.cpu: "2" doesn't see two virtual CPUs, it sees all the node's CPUs and gets suspended when it consumes too much. The Go runtime, historically, never read cgroups. It trusted the physical core count. package main import ( "fmt" "runtime" ) func main () { // Inside a pod with limits.cpu: "2" on a 32-core node fmt . Println ( runtime . NumCPU ()) // → 32 fmt . Println ( runtime . GOMAXPROCS ( 0 )) // → 32 } CFS throttling: how the kernel slows you down The Linux CFS (Completely Fair Scheduler) enforces CPU limits via two cgroup parameters: cpu.cfs_quota_us (allowed CPU time) and cpu.cfs_period_us (measurement window, 100 ms by default). A pod limited to 2 CPUs gets at most 200 ms of CPU time per 100 ms window. When Go spawns 32 OS threads for 32 parallel goroutines, those threads compete for physical CPUs. Once their combined usage exceeds the cgroup quota within the current window, the kernel suspends all threads in the cgroup until the next window starts. That's throttling: a complete application freeze lasting anywhere from a few milliseconds to several tens of milliseconds. A handful of these per second

Netflix has described the production lessons behind bringing LLM inference into its internal serving platform, including the challenges of supporting different model sizes, hardware requirements, and rapidly evolving inference engines. By Matt Foster

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Hello everyone! After publishing my Machine Learning with ML.NET series, I decided to turn the recommendation model into a complete application. In this new series, we build RockPlayer, a rock music player that combines modern software architecture, ASP.NET Core, Angular 22, Redis, and YouTube integration. Each article focuses on a different part of the project: 🎵 1. Introducing RockPlayer An overview of the project, its goals, and the overall architecture. https://devfullstack.net/blog/introducing-rockplayer 🔌 2. Adapters: Isolating the YouTube Provider Using the Adapter pattern to decouple the application from the YouTube integration. https://devfullstack.net/blog/adapters-isolating-the-youtube-provider ⚡ 3. No Database: Caching Lookups with Redis Using Redis to cache search results instead of storing external data in a database. https://devfullstack.net/blog/no-database-caching-lookups-with-redis 🅰️ 4. Angular 22 in Practice Applying modern Angular 22 features to build the user interface. https://devfullstack.net/blog/angular-22-in-practice 🚀 5. Building the RockPlayer API Building the API that orchestrates the application. https://devfullstack.net/blog/building-the-rockplayer-api ▶️ 6. The YouTube Adapter: Finding and Playing the Song Implementing the YouTube integration to search for and play songs. https://devfullstack.net/blog/the-youtube-adapter-finding-and-playing-the-song 🎧 7. RockPlayer in Angular 22: Onboarding Setting up the Angular application and organizing the project structure. https://devfullstack.net/blog/rockplayer-in-angular-22-onboarding 🎸 8. RockPlayer: Putting It All Together Bringing all the components together into a complete application. https://devfullstack.net/blog/rockplayer-putting-it-all-together I hope this series is useful for developers interested in software architecture, .NET, and Angular. See you there!

There's a delightfully literal answer to "Kubernetes with Docker": kind — Kubernetes IN Docker. Each node is a Docker container running a full Kubernetes node image. On an Ubuntu workstation it gives you a real, throwaway, multi-node cluster in about 30 seconds. It's my default for local dev and for CI. Prerequisites on Ubuntu You need Docker Engine and kubectl . If you don't have Docker yet: sudo apt-get update && sudo apt-get install -y docker.io sudo usermod -aG docker $USER && newgrp docker # run docker without sudo Install kind (single static binary): curl -fsSLo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64 chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind kind version A one-command cluster kind create cluster --name dev kubectl cluster-info --context kind-dev docker ps # you'll see a dev-control-plane container — that's your node kind wrote a kubeconfig context for you. Tear the whole thing down just as fast: kind delete cluster --name dev A realistic multi-node cluster Most bugs only show up with more than one node (scheduling, affinity, PodDisruptionBudgets). Define it in a config file: # kind-cluster.yaml kind : Cluster apiVersion : kind.x-k8s.io/v1alpha4 nodes : - role : control-plane kubeadmConfigPatches : - | kind: InitConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "ingress-ready=true" extraPortMappings : - containerPort : 80 hostPort : 8080 protocol : TCP - role : worker - role : worker kind create cluster --name dev --config kind-cluster.yaml kubectl get nodes The extraPortMappings bit is the trick people miss: it forwards a port from your Ubuntu host into the control-plane container, so an ingress controller inside the cluster is reachable at http://localhost:8080 . Loading a locally-built image (no registry needed) This is kind 's best feature for the Docker workflow. Build with Docker, push straight into the cluster's nodes — no registry round-trip: docker build -t myapp:dev . kind load docker-image myapp:dev --name

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-05/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols not as configuration examples but as logic with inputs, state, and branches — actual code you can read and run. The whole series lives here: github.com/pathvector-studio/protocol-in-code . If you're newer to this material and want a more hands-on, guided on-ramp first, start with the companion Protocol Lab series and come back. Today's module is from the BGP track, Session 05. The source file is src/protocol_in_code/bgp/policy.py , and it builds directly on the origin-validation logic from Session 04. The question to keep in your head Here's the one thing to turn over as you read: What happens after origin validation returns valid , invalid , or not_found — and why does the result still need routing policy before anything happens to the route? There's a piece of folk knowledge that says "RPKI invalid means the router rejects the route." It's the kind of statement that sounds like a rule of the protocol. It isn't. It's one possible policy decision built on top of a validation result . The whole point of this session is to separate those two things in your head, and the code makes the seam impossible to miss. Two layers, not one Validation answers a factual question: does this route's origin AS match what the ROAs say it should be? That's Session 04's job, and its output is a ValidationState . Policy answers a completely different question: given that fact, what do we do ? Drop the route? Keep it but make it less preferred? Accept it normally? That's a local decision — different operators configure it differently, and the same validation result can lead to different actions on different routers. The file models the second layer with three small pieces. First, the set of actions the router can take: class PolicyAction ( str , Enum ): ACCEPT = " accept " DEPRIORITIZE = " de

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-04/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols as logic — inputs, state, and branches — rather than as configuration examples. The full source, walkthroughs, and site lessons live in the repo: pathvector-studio/protocol-in-code . If you're newer to this and want to build the protocols hands-on before dissecting them, start with the companion Protocol Lab series instead. Today we're on the BGP track, session 04, reading a single small file: src/protocol_in_code/bgp/validation.py . It's about 40 lines. The idea inside it is one that trips up a lot of engineers who've been running BGP for years. The question to keep in your head BGP's best path selection already ran. It compared local preference, AS_PATH length, MED, and the rest of the tiebreak ladder, and it picked a winner. So here's the question this module wants you turning over: Core question: How do we decide whether the origin AS is authorized — even after BGP has already selected this route as the best path? The trap is the sentence "it was the best path, so it must be fine." Best and authorized are two different words, and in the code they are two different decisions made by two different pieces of data. Best path selection asks which of these routes do I prefer? Origin validation asks is the AS at the end of this path actually allowed to originate this prefix? A route can win selection and still be a hijack. RPKI origin validation is the mechanism that answers the second question, and the file we're reading is a toy model of exactly that. Two kinds of information The first thing to read isn't a function — it's the two dataclasses, because the whole session is really about keeping them apart. @dataclass ( frozen = True ) class BGPRoute : prefix : str origin_as : int @dataclass ( frozen = True ) class VRP : prefix : str max_length : int origin_as : int BGPRout

If you run GitOps with Flux, a broken manifest usually gets caught the slow way: it merges, the reconciler chokes, and you find out from a failing Kustomization. Flux Schema, the plugin that shipped with Flux 2.9, moves that check left into CI. It validates every YAML document against JSON Schema and CEL rules using the same evaluation logic as the Kubernetes API server, so a bad field fails the pull request instead of the cluster. Install and run it Flux Schema is a CLI plugin, not part of the core binary. Install it through the plugin system: $ flux plugin install schema $ flux schema --help Pin a version in CI so a new release never changes your gate's behavior mid-sprint: $ flux plugin install schema@0.5.0 Point it at a directory of manifests and it validates each document: $ flux schema validate ./manifests It ships with built-in schemas for Kubernetes, OpenShift, Gateway API, and the Flux CRDs, so a fresh install already knows your HelmRelease and Kustomization kinds without any setup. Strict validation flags unknown fields, wrong types, and missing required properties as hard errors, which catches the typos kubectl apply --dry-run=client quietly ignores. What CEL adds over plain schema checks JSON Schema catches shape problems: a string where an int belongs, a misspelled key. CEL rules catch logic problems. Because Flux Schema runs the x-kubernetes-validations rules embedded in CRDs through the same CEL engine the API server uses, a manifest that violates a cross-field constraint (say, a replica count that must stay below a limit, or two mutually exclusive fields both set) fails in CI with the exact message the cluster would have returned. You are testing against the real admission logic, not a stale copy of it. Wire it into a config file Drop a .fluxschema.yml at your repo root to control what gets checked. The file uses the schema.plugin.fluxcd.io/v1beta1 API and a Config kind: apiVersion : schema.plugin.fluxcd.io/v1beta1 kind : Config skipKind : - Secret s

Let's get the joke out of the way, because you're going to hear it within four minutes of telling anyone you're learning C#: "Oh, C#? Isn't that just Microsoft Java?" Yes. Kind of. A little. Here's the actual story. Back around 2000, Microsoft wanted a modern, garbage-collected, object-oriented language for their shiny new .NET platform. Java existed and was extremely popular. Microsoft had previously shipped their own version of Java, Sun sued them into the sea, and the whole thing ended in tears and lawyers. So Microsoft did the very sensible, very corporate thing: they hired Anders Hejlsberg , the man who built Turbo Pascal and Delphi, and said: "make us a Java, but ours, and don't get us sued." He did. And then he kept improving it for twenty-five years while Java spent a decade arguing about whether it should add lambdas. So calling C# "Microsoft Java" today is like calling a smartphone "a Microsoft telegraph." Technically, you can trace the lineage. It is also extremely funny to the person being insulted, which is the only thing that matters. So, what can you actually do with this thing? More than you'd think. Let's take the tour. First, the obligatory Hello World Every language tour is legally required to start here. C#'s has changed a lot, which tells you something about the language's whole vibe. The old way, circa 2005, was a ceremony: using System ; namespace MyFirstApp { class Program { static void Main ( string [] args ) { Console . WriteLine ( "Hello, world!" ); } } } Eleven lines to say hello. You needed a namespace , a class , a Main method with a specific signature, and the kind of static void incantation that makes beginners quietly close the tab and go learn Python instead. The modern way (C# 9 and later) is this: Console . WriteLine ( "Hello, world!" ); That's the whole program. The compiler quietly puts all the ceremony back for you behind the scenes. This is C# in a nutshell: it grew up in a buttoned-up enterprise suit, and over twenty years it

Most of us run kubectl apply -f dozens of times a day without thinking about the machinery it sets in motion. But when something breaks, a Pod stuck in Pending , a Service that won't route, a Deployment that never converges, understanding that machinery is the difference between guessing and debugging. In this article, I'll map the end-to-end flow onto the actual Kubernetes architecture, so you can see not just what happens, but which component is responsible at every step. The Architecture at a Glance Kubernetes is split into two planes: Control plane: the brain. It makes decisions: what should exist, where it should run, and whether reality matches intent. Worker nodes: the muscle. They run your actual workloads and report back. Here's the full picture, with the request flow numbered: (1) apply YAML → API Server (5) Kubelet asks runtime to start container (2) spec persisted in etcd (6) runtime pulls image & runs it (3) controller reconciles spec (7) CNI assigns Pod IP, joins network (4) scheduler assigns a node (8) Kubelet reports status back Now let's walk through the flow, component by component. Step 1: The Cluster Exists Before Your App Does A Kubernetes cluster is the combination of a control plane and a set of worker nodes. The control plane components (API Server, etcd, Controller Manager, Scheduler) can run on dedicated nodes or, in managed offerings like RKE2/EKS/GKE/AKS, be entirely abstracted away from you. Either way, they're always there, always watching. Step 2: You Declare Intent in YAML You don't tell Kubernetes how to run your app, you describe what you want. Typically that's a set of manifests: Deployment: how many replicas, which image, update strategy Service: a stable virtual endpoint in front of ephemeral Pods ConfigMap/Secret: configuration decoupled from the image This declarative model is the foundation of everything that follows. Kubernetes' whole job is to close the gap between your declared state and reality. Step 3: kubectl apply -f Hi

Amazon EKS has recently introduced support for Kubernetes version rollbacks, letting practitioners revert a cluster's control plane to its previous Kubernetes version within 7 days of an upgrade if issues arise. The feature reduces the risk of in-place cluster upgrades by giving teams a safety net to recover quickly from problematic updates. By Renato Losio

A product search, a filter list that kept growing, and a status code I hadn't seen in years. Filters went in the query string, the way they always do. That held up fine until someone saved a "filter set" with a few hundred SKUs in it and the endpoint started answering with 414. I rebuilt a small version of it to find the exact wall. Same search, filters as repeated ?sku= values, count going up in steps of a hundred: 1) GET with filters in the URL 100 filters | request line 1534 bytes | 200 OK 200 filters | request line 3034 bytes | 200 OK 300 filters | request line 4534 bytes | 200 OK 400 filters | request line 6034 bytes | 200 OK 500 filters | request line 7534 bytes | 200 OK 600 filters | request line 9034 bytes | 414 RequestUriTooLong Kestrel's default max request line is 8 KB, and the request line is the method plus the URL plus the HTTP version. Somewhere between 500 and 600 filters, my URL stopped being a URL. Every fix I knew was a compromise. A body on GET is undefined by spec and some proxies quietly drop it. POST works, but POST announces "this might change something", so caches skip it, gateways won't auto-retry it, and anyone reading your API docs has to guess whether POST /search is actually a search. Cramming the filters into a header is the kind of idea that sounds clever for about a day. The method that was missing RFC 10008 defines QUERY , and it's exactly the thing that spot in the matrix was waiting for. The body carries the query. The method is safe and idempotent, so it can be retried after a dropped connection without anyone panicking. Responses are cacheable, and the spec is explicit that the cache key has to be built from "the request content and related metadata". There's also a nice touch on the response side: Content-Location can point at a URL where those exact results can be fetched with a plain GET. The one-line version I keep giving people: it's a GET with a body, and that's the entire point. Wiring it up in ASP.NET Core 10 .NET 10 shi

Every five minutes or so, my entire Windows machine would drop off the network for a few seconds — not just WSL, the whole host. Browser tabs would stall, calls would drop, and it only happened while WSL2 was running. This is the story of finding that, plus the WSL memory-tuning landmines I hit right alongside it. The flapping The symptom was a host-wide network blip on a short, regular interval, correlated tightly with WSL2 being up. The cause: WSL2's default networking mode creates a virtual NAT switch on the Windows side, and on this machine that virtual switch was intermittently conflicting with the real network adapter — enough to cause the whole host to briefly renegotiate its connection. The fix was switching WSL2's networking mode entirely, via .wslconfig (on Windows, not inside the Linux filesystem): [wsl2] networkingMode = mirrored dnsTunneling = true autoProxy = true Mirrored networking makes the WSL2 interface share the host's actual network identity instead of sitting behind a separate virtual NAT switch. You can confirm it actually took effect (rather than just trusting the config file) by checking, from inside WSL after a full restart, that its network interface holds the same IP as the Windows host, that the default route points at the real LAN gateway rather than a private NAT range, and that loopback carries mirrored mode's marker address rather than a 172.x NAT address. If any of those don't match, the setting isn't actually active yet. Worth noting: this requires a reasonably recent WSL version and Windows build. If you're on an older one, mirrored mode may not be available at all. The memory landmines, found the hard way Separately — and this had actually caused full VM crashes, not just hangs, at one point — I'd been carrying a few .wslconfig settings that looked reasonable and were each, individually, a documented source of instability: An explicit kernelCommandLine override. Resizing swap past a few GB, which forces WSL to rebuild its virtual

Kalshi claims the trailer is “defamatory” and contains “both fabricated documents and false and misleading statements.”