标签：#net

Running AI agents on Kubernetes raises a key question: should each agent get its own Pod? The kagent project argues no—agents are bursty, short-lived, can spawn subagents, and may wait for human approval, making one Pod per agent wasteful. Agent-substrate adds a control plane to schedule logical “Actors” onto long-lived worker Pods. By Mark Silvester

Disney is interested in "price-sensitive" streaming customers.

I needed a VPS to run CyberPanel. Simple enough: 1 vCPU, 1 GB RAM, 10 GB SSD, IPv6 only. CyberPanel...

Microsoft and Uno Platform have released the first stable versions in the SkiaSharp 4 series, beginning with SkiaSharp 4.148.0 and followed shortly afterward by 4.150.0. A 4.151.0 prerelease line is also available, demonstrating the project’s new approach of aligning package versions and release cadence with upstream Skia milestones. By Edin Kapić

Ask Crysta — the AI agent on CrystaCode.ai — to switch the site to dark mode, and the site actually turns dark. Ask it to show the login popup, and the modal actually opens. The model doesn't just answer anymore; it operates the UI. But here's the thing: the LLM lives on the server , and the UI lives in the browser . A model can't click buttons. So how do you give a remote brain hands? The answer is a pattern we ended up calling the Client Driver Skill : function calling, with SignalR as the hand. The Problem The first version of our chat was a one-way street. The model could say "sure, I'll take you to the plans page" — and then nothing happened. The answer was text; the UI was deaf. You have two classic options: The client polls the server for commands (ugly, wasteful, feels like 2010) The server pushes commands to the client (real-time, instant, exactly what SignalR is for) We went with the push. The flow became: the model calls a function → the function runs on the server → the server pushes a typed command over SignalR → the client executes it. How It Works (The Full Loop) [Browser] [Server] | | | 1. "switch to dark mode" | | ---- InvokeAsync ---------> | | | 2. Brain runs, model sees | | the UpdateSiteTheme tool | | 3. Model calls the function | | (function calling) | | 4. Push to the exact tab: | <--- ChangeSiteTheme ------ | Clients.Client(connId) | 5. ThemeService flips it | | 6. "Site theme changed..." | 5b. return value re-enters | | the model's context | <--- chat answer ---------- | User types "switch to dark mode" → the Blazor client calls the hub The server session runs the brain; the model sees a tool called UpdateSiteTheme The model decides the user wants dark mode and calls the function The server pushes ChangeSiteTheme(DarkMode) to the exact browser connection The client applies the theme and re-renders The function's return value goes back into the model's context, so the AI knows the theme changed and confirms it in the chat 1) The Client Regist

Series: Platform engineering with Go | Topics: Go, Kubernetes, Cobra, client-go, metrics-server, Platform Engineering This is part of the Platform Engineering with Go series. This post builds on the Cobra CLI patterns from post 4 and client-go from post 3. Read post 4 first if you haven't yet. kubectl top tells you what's happening. It doesn't tell you how close to the edge you are. In post 3 and post 4 , we built a health reporter and learned how to structure a Go CLI with Cobra. Now we put both together into something with real operational value. kubectl top pods -n production NAME CPU ( cores ) MEMORY ( bytes ) go-api-7d6b9f8c4-xk2pq 240m 490Mi go-api-7d6b9f8c4-mn9rt 180m 210Mi go-api-7d6b9f8c4-p8wvz 200m 198Mi That first pod is using 490Mi of memory. Is that fine or is that a problem? Without knowing the limit, you can't tell. You'd have to run kubectl describe pod go-api-7d6b9f8c4-xk2pq , find the resources section, do the mental arithmetic, and repeat for every pod you care about. ferctl top does all of that in one command: ferctl top -n production NAMESPACE NAME CPU USE CPU REQ CPU LIM CPU% MEM USE MEM REQ MEM LIM MEM% STATUS production go-api-7d6b9f8c4-xk2pq 240m 250m 500m 48% 490Mi 256Mi 512Mi 95% !! CRITICAL production go-api-7d6b9f8c4-mn9rt 180m 250m 500m 36% 210Mi 256Mi 512Mi 41% OK production go-api-7d6b9f8c4-p8wvz 200m 250m 500m 40% 198Mi 256Mi 512Mi 38% OK One pod is at 95% of its memory limit. In production, that's a page waiting to happen. ferctl top catches it before it becomes an incident. What you'll learn How to extend the Cobra CLI structure from post 4 with a real subcommand How to query the metrics-server API using k8s.io/metrics How to correlate live metrics with pod specs to show usage vs limits How to implement configurable near-limit warnings How to format clean aligned output with tabwriter How to verify the tool against your real minikube cluster Prerequisites Posts 1–4 read; client-go patterns from post 3 , Cobra CLI structure from pos

HashiCorp has released a public beta of Vault Kubernetes key management, a KMS v2-compatible plugin that lets the Kubernetes API server delegate envelope encryption to Vault Enterprise, moving the key encryption keys that protect etcd data out of the cluster and into a separately governed trust domain. By Mark Silvester

Building an AI agent locally is an exciting first step. Running that same agent reliably in production is a different challenge. Once real users and external services are involved, the application needs more than working code. It needs repeatable deployments, secure configuration, health checks, monitoring, controlled updates, and a clear recovery process. This article is part of my MCP series. If you are new to the topic, start with my first article: Model Context Protocol (MCP) Servers Explained: A Complete Beginner’s Guide . In this article, I will outline a practical architecture for taking a Model Context Protocol, or MCP-based, AI agent from a local development environment to Kubernetes. This is a production architecture blueprint. The exact implementation will depend on the AI provider, MCP servers, cloud platform, and security requirements used by the application. What Is an MCP-Based AI Agent? The Model Context Protocol provides a standardized way for AI applications to connect with external tools, services, and data sources. An MCP-based agent may interact with: Internal APIs Databases File systems Search services Monitoring platforms Business applications Custom automation tools A basic implementation might work well on a developer's machine. In production, however, every dependency introduces operational questions: How will the application be deployed? Where will credentials be stored? How will failed requests be detected? Can the service handle additional traffic? How can a broken release be rolled back? What happens when an MCP server becomes unavailable? These are familiar DevOps and Site Reliability Engineering problems applied to a new type of workload. Target Architecture A practical delivery flow could look like this: Developer ↓ GitHub Repository ↓ GitHub Actions ↓ Container Registry ↓ Kubernetes Cluster ↓ MCP Servers and External Services ↓ Logs, Metrics, Traces, and Alerts Each component has a clear responsibility: GitHub stores the application

Every year, developers ask the same question: "Which programming language should I learn next?" And...

Originally published at wostal.eu . TL;DR : My Hetzner k3s lab quietly became a platform. Dozens of operators with leader-election leases hammered the default datastore — SQLite via kine — until compaction entered a death-spiral: 1.36M rows, a 13.8 GB WAL that wouldn't checkpoint, CPU pinned at 99%, load average 79 on 8 cores. I stopped the bleeding by truncating the WAL, then migrated the control plane to embedded etcd (7.5 GB SQLite → 313 MB etcd, load 79 → 5). This is the full postmortem — and the lessons. This is a war story, not a tutorial. It's about the moment a homelab stops being a homelab and starts behaving like production — without ever announcing it. The cluster in question, homelab , is the Hetzner k3s setup I wrote about previously . It started small. It did not stay small. In this post I'll cover: How an overgrown lab broke the default datastore — the kine/SQLite compaction death-spiral The firefight — measuring instead of guessing, and the fix that actually worked The permanent fix — migrating the control plane to embedded etcd, and the honest caveats The meta-lesson — how to recognize when your lab has become a platform A diagnostic runbook — so next time it's minutes, not hours There's a companion piece to this incident. The CI pipeline that ran this etcd migration was itself freshly — and badly — migrated, and debugging it cost me hours over a single missing newline. I split that into its own post: I Let an AI Re-Platform My CI Pipeline. Here's What Broke. Context: it's "just a homelab" — except it isn't homelab began like any homelab: one k3s node on Hetzner, a few things to play with. The problem is that over months it quietly became a platform . A single master node ( cx43 , 8 vCPU / 16 GB, untainted, and also carrying Longhorn and workloads) now runs: ArgoCD, Kargo, Crossplane/Upbound, CloudNativePG, EMQX, Longhorn, trivy-operator, kubescape, Gatekeeper, Goldilocks/VPA, VictoriaMetrics, Loki, OpenTelemetry, Argo Workflows/Events/Rollouts, kga

CompTIA PenTest+ / Ethical Hacking Certification Series Professional Reference Guide — GitHub Edition Covers: Passive Reconnaissance · OSINT · DNS · Social Media · Cryptographic Analysis · Shodan Table of Contents 3.0 Introduction 3.1 Performing Passive Reconnaissance 3.1.1 Overview 3.1.2 Active Reconnaissance vs. Passive Reconnaissance 3.1.3 The OSINT Methodology — How Professionals Think 3.1.4 OSINT Tools — The Complete Professional Arsenal 3.1.5 DNS Lookups — Deep Dive 3.1.6 DNS Reconnaissance — Advanced Techniques 3.1.7 Identification of Technical and Administrative Contacts 3.1.8 WHOIS Intelligence — Extracting Maximum Value 3.1.9 DNS Lookups — Lab-Level Practical Reference 3.1.10 Cloud vs. Self-Hosted Applications and Related Subdomains 3.1.11 Social Media Scraping 3.1.12 Employee Intelligence Gathering 3.1.13 Cryptographic Flaws 3.1.14 Finding Information from SSL Certificates 3.1.15 Company Reputation and Security Posture 3.1.16 File Metadata 3.1.17 Web Archiving, Caching, and Public Code Repositories 3.1.18 Finding Out About the Organization — Aggregation Techniques 3.1.19 Advanced Searches — Google Dorking and Beyond 3.1.20 Open-Source Intelligence (OSINT) Gathering — Frameworks and Automation 3.1.21 Shodan — The Search Engine for Everything Connected 3.1.22 Breach Data Intelligence — Leaked Credentials and Exposure Monitoring 3.0 Introduction Module Overview: Information Gathering and Vulnerability Scanning Module Objective: Perform information gathering and vulnerability scanning activities at a professional, senior-level standard. Before a single exploit is launched, before a single payload is crafted, every professional penetration tester invests significant time in a discipline that separates competent practitioners from exceptional ones: information gathering . The reconnaissance phase is the intelligence foundation upon which the entire attack strategy is built. The quality of your reconnaissance directly determines the quality of your attack. Why T

Every couple of weeks I need a twenty-line program. Find what's bloating a build agent's disk, dedupe a CSV, hash-check a folder. For fifteen years the honest answer to "which language?" was not C# — by the time I'd done mkdir , dotnet new console , and named yet another throwaway csproj, the moment had passed. So those little jobs went to bash or Python, and I grumbled quietly every time. .NET 10 removed the ritual. You write one .cs file and run it. I'd been meaning to check how well this actually holds up for real scripts, so this week I did — nothing fancy, one Linux container and a stopwatch. One file, no project Here's biggest.cs , a small utility that lists the largest files under a directory. The whole program is this one file — no csproj anywhere: # !/ usr / bin / env dotnet # : package Humanizer @ 3.0 . 10 using Humanizer ; var root = args . Length > 0 ? args [ 0 ] : "." ; var top = args . Length > 1 && int . TryParse ( args [ 1 ], out var n ) ? n : 10 ; var files = new DirectoryInfo ( root ) . EnumerateFiles ( "*" , new EnumerationOptions { RecurseSubdirectories = true , IgnoreInaccessible = true , AttributesToSkip = FileAttributes . ReparsePoint }) . OrderByDescending ( f => f . Length ) . Take ( top ) . ToList (); foreach ( var f in files ) { var size = f . Length . Bytes (). Humanize ( "#.#" ); var age = ( DateTime . UtcNow - f . LastWriteTimeUtc ). Humanize (); Console . WriteLine ( $" { size , 10 } { f . FullName } (modified { age } ago)" ); } Two lines are new. #:package Humanizer@3.0.10 is a NuGet reference written as a directive, right in the source. The shebang we'll get to in a minute. Everything else is the C# you already write, top-level statements and all. $ dotnet run biggest.cs -- ~/.dotnet 5 Top 5 files under /root/.dotnet: 37.6 MB .../FSharp.Compiler.Service.dll (modified 46 seconds ago) 18.7 MB .../Microsoft.CodeAnalysis.CSharp.dll (modified 46 seconds ago) 18.7 MB .../Roslyn/bincore/Microsoft.CodeAnalysis.CSharp.dll (modified 45 seconds

A discovery in a solar system 73 light-years from Earth is challenging definitions and “blurring the lines between stars, planets, and moons.”

Every RAG tutorial I've read makes the same two assumptions: you have a GPU, and you can call a cloud API. For the environments I build for, both assumptions are wrong. I work on health information systems in the public sector. The stack has to run inside institutional infrastructure — no data leaves the network — and the hardware I get is whatever the procurement cycle produced two years ago. In practice that means Windows Server, CPU only, and open-weight models running locally. So I built a RAG stack that runs entirely on-premise, no GPU, no cloud, no Docker. It's open source at github.com/psychohub/rag-onpremise : ASP.NET Core 9 for orchestration, Ollama for local inference, Qdrant for vectors, Python for the ingest pipeline, Mistral 7B as the LLM, nomic-embed-text for embeddings. Getting it into production took longer than the design did, because five things broke that no tutorial had warned me about. This is the field report. The environment, and why it matters Before the lessons, it's worth being precise about the constraint, because it changes what "good" looks like. The stack has to run on a Windows Server, not a Linux workstation. Docker is not available on many of the target machines — either because it wasn't approved, because GPO policies restrict it, or because ops teams already run everything as Windows services and adding a container runtime is a new operational surface nobody wants to own. GPUs are aspirational. In the meantime, you have CPU inference and you have to make it work. None of this is exotic. It's the default reality in a lot of public sector, healthcare, and legacy enterprise environments. It's also the reality most RAG content on the internet quietly assumes away. The overall shape of the system: Documents (PDF / Word / Excel) │ ▼ [ Python ingest ] ├─ Text extraction (pdfplumber, python-docx, openpyxl) ├─ Chunking (500 tokens, 50 overlap) ├─ Embeddings (nomic-embed-text via Ollama) └─ Store (Qdrant, cosine similarity) │ User query │ │

If I need to upgrade .NET 8 to .NET 10 , I treat the work as an API contract migration, not a project-file edit. A service can compile, pass unit tests, and still surprise consumers with a changed JSON shape, status code, authentication response, or OpenAPI document. That risk matters now because Microsoft has confirmed that .NET 8 and .NET 9 reach end of support on November 10, 2026 . .NET 10 and C# 14 are the current stable releases, and .NET 10 is the supported LTS destination. Why the deadline changes my upgrade order My first step is inventory, not retargeting. I list every deployable project, test project, global.json , container base image, CI SDK pin, and Microsoft package reference. dotnet --list-sdks shows what a machine can build; dotnet --info shows what the current environment actually resolves. If that inventory needs more detail, my older guide to dotnet sdk check is a useful starting point. For APIs still on .NET 8, the broader Web API setup and security checklist can help identify behavior worth protecting before the move. I then separate the migration into three changes: SDK and target framework, NuGet dependencies, and runtime infrastructure. Keeping those changes visible makes a failure easier to locate. A giant dependency-refresh commit may be quick to create, but it is hard to diagnose. Upgrade .NET 8 to .NET 10 behind contract tests Before changing net8.0 , I add a small set of tests around the endpoints consumers cannot tolerate changing. I care about observable behavior: status codes, content types, required JSON names, and authentication boundaries. I avoid asserting an entire serialized string because harmless property ordering can make that test noisy. Here is a focused xUnit test for a Minimal API: using System.Net ; using System.Text.Json ; using Microsoft.AspNetCore.Mvc.Testing ; using Xunit ; public sealed class ProductContractTests ( WebApplicationFactory < Program > factory ) : IClassFixture < WebApplicationFactory < Program >> { [

I Learned Go in 3 Weeks. Yesterday, My Code Merged into k9s. From zero Go experience to a...

Some group with no modern descendants contributed a lot to our genomes.

Kubernetes Interviews Are Broken When Trivia Matters More Than Real Skill Kubernetes interviews often fail when they test whether a candidate can recall obscure implementation details instead of showing how that person diagnoses failures, reasons through tradeoffs, and learns under pressure. Certifications can prove useful baseline knowledge, but neither a certificate nor a perfect whiteboard answer reliably proves that someone can operate a production cluster. The frustration becomes obvious when an interview demands a kernel level explanation of what happens when traffic reaches an ingress controller in a Cilium based, proxyless setup, while the actual role may involve changing a CPU request from 500m to 550m. The contrast is funny because it feels painfully familiar. Candidates prepare for architecture, networking, controllers, scheduling, and troubleshooting, then get judged on a detail they could verify in seconds during real work. That does not mean deep technical knowledge is useless. Some roles genuinely require it. The problem begins when interview difficulty becomes disconnected from job difficulty, and when memorization is treated as a shortcut for measuring engineering judgment. Why Kubernetes interview questions feel disconnected from the job The strongest complaint in the discussion was not that Kubernetes is too difficult. It was that many interview questions appear designed to establish superiority rather than measure readiness for the role. One example captured the problem perfectly: the interview asks for a detailed explanation of kernel behavior, ingress traffic, Cilium, eBPF, and proxyless networking. The work itself turns out to be a minor resource adjustment. That gap creates distrust because candidates are being filtered through a standard that the daily job may never require. A technical interview should reflect the decisions the engineer will actually make. If the job involves operating clusters, useful questions might examine how the candid

Your GitOps Hub Will Become the Bottleneck Long Before Cluster Count Tells You GitOps hub bottlenecks are usually predicted more accurately by watched object volume, reconcile queue depth, and controller memory growth than by cluster count alone. Large-scale testing described in the discussion showed Argo CD application controllers hitting out-of-memory failures around 15,000 to 20,000 cached objects per hub, while sharding and tuning delayed the limit without removing the underlying memory cost. The most important lesson was uncomfortable because it challenged the usual instinct to keep tuning the existing platform. At very large scale, architecture mattered more than configuration. Hydrated manifests helped. More replicas helped. Dynamic sharding helped. None of them changed the fact that a centralized reconciliation model still had to hold and process a huge amount of state. The testing was not presented as a universal benchmark or as proof that one tool always beats another. It was a record of one setup, built through dozens of iterations over several months, and the failures were as valuable as the successful runs. That is exactly why the results matter. They show where teams should look before the hub becomes the thing taking the fleet down. Cluster count is the wrong first metric A fleet with 1,000 tiny clusters may place less pressure on a GitOps control plane than a much smaller fleet containing thousands of applications and deeply expanded resource trees. The number of managed clusters is visible and easy to report, but it does not describe the controller’s actual workload. The more useful mental model is objects over clusters. Each application contributes desired state, live state, cached trees, reconciliation work, and queue activity. A cluster that runs a few small addons may be cheap to manage. Another cluster with many applications and large manifest sets may consume far more memory and reconciliation time. That means two fleets with the same cluster

Por que usar o Cloudflare em vez do DNS padrão do seu registrador Escrevi esse texto depois de um perrengue aqui na empresa onde trabalho. Precisei registrar uns subdomínios, entrei no painel da Cloudflare esperando achar os registros lá e não tinha nada, fui atrás do time para entender onde aquilo estava apontando e a resposta foi que tudo passava direto pelo provedor de domínio. Quando você registra um domínio na GoDaddy, Namecheap, Registro.br ou qualquer outro provedor de domínio, ele já vem com um par de nameservers configurados por padrão. Funciona, mas "funcionar" e "ser a melhor opção para produção" são coisas diferentes, e trocar esses nameservers pelos da Cloudflare é uma das mudanças de maior custo-benefício que dá para fazer em um projeto. O que muda ao trocar os nameservers Um provedor de domínio só precisa resolver DNS: publicar seus registros A, CNAME, MX e afins, e responder consultas. A infraestrutura por trás disso varia muito de provedor para provedor e raramente é otimizada para latência global ou resiliência a ataques, porque não é o produto principal deles. A Cloudflare constrói a rede em torno de DNS, CDN e mitigação de DDoS como núcleo do negócio, e isso aparece em números concretos: a rede anycast cobre mais de 330 cidades, então uma consulta DNS ou uma requisição HTTP é respondida pelo ponto de presença fisicamente mais próximo do usuário, não por um servidor central do outro lado do mundo. Hoje a Cloudflare responde por algo em torno de 23% de todos os sites da internet. Vantagens técnicas O anycast é a base de tudo. Não existe "o servidor DNS" que pode cair: se um ponto de presença fica indisponível, o tráfego é roteado automaticamente para o mais próximo, o que reduz latência de resolução e risco de indisponibilidade. A mesma arquitetura, combinada a TTLs baixos, também acelera a propagação de mudanças: um registro DNS alterado costuma valer em minutos, enquanto em boa parte dos provedores de domínio tradicionais não é incomum esperar ho