标签：#net

You type www.google.com into your browser and hit Enter. The page loads in under a second. But stop and think about what just happened. Your browser didn't know where Google lives on the internet. It had to ask. And in that fraction of a second, a surprisingly elegant chain of lookups took place behind the scenes. That system is called DNS — the Domain Name System. Think of it as the internet's phonebook: it translates human-friendly names like www.google.com into machine-friendly IP addresses like 142.250.80.46 . Without it, you'd have to memorise numbers to visit any website. Let's walk through exactly what happens, step by step. Step 1: You Type a URL — But What Does It Mean? When you type www.bing.com , you're entering a domain name . Domain names have a structure — and reading them right-to-left tells you a lot: www . bing . com │ │ │ │ │ └── Top-Level Domain (TLD): category or country │ └──────── Second-Level Domain (SLD): the brand/org name └─────────────── Subdomain: a section of the site (optional) Some real examples: Domain TLD SLD Subdomain www.bing.com .com bing www news.bbc.co.uk .uk bbc news docs.github.com .com github docs TLDs indicate the type or origin of a site — .com for commercial, .edu for education, .in for India, and so on. Step 2: Your Browser Checks Locally First Before going anywhere on the internet, your browser does a quick local check — two of them, actually. 1. Browser cache Modern browsers cache DNS results from previous lookups. If you visited bing.com five minutes ago, the browser already knows its IP and skips the entire lookup process. 2. The hosts file Your operating system has a plain text file that maps domain names to IPs manually. On most systems it lives at: Windows: C:\Windows\System32\drivers\etc\hosts Mac/Linux: /etc/hosts It looks like this: 127 . 0 . 0 . 1 localhost 192 . 168 . 1 . 10 mydevserver . local Developers use this all the time for local testing — mapping a production domain name to a local IP to test before go

This article is part of the Comprehensive Guide to Microservices Architecture in .NET Core, Cloud and Azure series. Service Discovery in Kubernetes How Kubernetes DNS Works Kubernetes automatically creates DNS entries for services, enabling simple name-based discovery. A service named order-service in the production namespace becomes accessible at order-service.production.svc.cluster.local . For services within the same namespace, you can use the short name order-service . Service Definition: apiVersion : v1 kind : Service metadata : name : order-service namespace : production labels : app : order-service version : v1 spec : selector : app : order-service ports : - name : http protocol : TCP port : 80 targetPort : 8080 type : ClusterIP Native Service Discovery in .NET 9 .NET 9 introduces enhanced service discovery capabilities with improved configuration and resilience features. Basic Configuration: // Program.cs var builder = WebApplication . CreateBuilder ( args ); // Add service discovery with .NET 9 enhancements builder . Services . AddServiceDiscovery (); // Configure HTTP client with service discovery builder . Services . AddHttpClient < IOrderServiceClient , OrderServiceClient >( client => { // Use service name - discovery resolves to actual endpoint client . BaseAddress = new Uri ( "http://order-service" ); }) . AddServiceDiscovery () . AddStandardResilienceHandler (); // .NET 9 resilience patterns var app = builder . Build (); Advanced Configuration with appsettings.json: { "ServiceDiscovery" : { "Providers" : { "Kubernetes" : { "Namespace" : "production" , "RefreshPeriod" : "00:01:00" } }, "Services" : { "order-service" : { "Scheme" : "https" , "EndpointNames" : [ "http" , "https" ], "HealthCheckPath" : "/health" }, "payment-service" : { "Scheme" : "http" , "AllowAllHosts" : false } }, "AllowAllHosts" : true , "AllowedHosts" : [ "*.svc.cluster.local" ] } } Service-to-Service Communication Patterns Using Typed HTTP Clients: public interface IOrderServiceCli

This article is part of the Comprehensive Guide to Microservices Architecture in .NET Core, Cloud and Azure series. Asynchronous Messaging with Azure Service Bus Azure Service Bus provides enterprise-grade messaging infrastructure with advanced features for reliable message delivery, ordering guarantees, and complex routing scenarios. Service Bus vs Azure Queue Storage Azure Service Bus offers enterprise messaging capabilities including: Topics and subscriptions for pub/sub patterns Message sessions for ordered processing Transaction support across operations Dead-letter queues for failed messages Messages up to 100MB (premium tier) Advanced routing with filters and actions Azure Queue Storage provides: Simple FIFO queue operations Lower cost for basic scenarios Messages up to 64KB Best for simple point-to-point messaging When to Choose Service Bus Use Azure Service Bus when you need: Publish-subscribe patterns with multiple subscribers Guaranteed message ordering with sessions Transactional message processing Message size beyond 64KB Advanced routing and filtering Integration with hybrid or on-premises systems Implementation with .NET 9 .NET 9 introduces improved performance and simplified APIs for working with Azure Service Bus: // Producer using .NET 9 with improved performance public class OrderCreatedPublisher { private readonly ServiceBusSender _sender ; public OrderCreatedPublisher ( ServiceBusClient client ) { _sender = client . CreateSender ( "order-events" ); } public async Task PublishOrderCreatedAsync ( Order order , CancellationToken cancellationToken = default ) { var message = new ServiceBusMessage ( JsonSerializer . Serialize ( order )) { MessageId = order . OrderId . ToString (), Subject = "OrderCreated" , ContentType = "application/json" , // .NET 9: Better support for distributed tracing ApplicationProperties = { [ "CorrelationId" ] = Activity . Current ?. Id ?? Guid . NewGuid (). ToString (), [ "OrderDate" ] = order . CreatedAt . ToString ( "O" )

Porn music videos have circulated on the fringes of the internet for years. Featuring everything from narrative-driven stories to hypnosis, they are proliferating across X as “bate fuel” for gooners.

Environment And Situation Control room of an apartment Number of installed product : 3 (PC-based NVR, dual-LAN supported) Remote support : X (I actually went to the site and diagnosed) Reported Issue In viewer, when user changes play speed while playing back the recorded data, it randomly plays the data in hyper speed(almost 30x~60x) For example: 4x play means 4 seconds in video per a second. But in the site, it played 30~60 seconds per a seconds, showing the video stutturing. Diagnosis Checked the overall environment. System(CPU / RAM usage), network environment(bandwidth), resoulution, stream configurations, etc. -> Nothing suspicious. Some of the installed cameras had unusual fps and gop values Normally, fps and gop values are set to be equal(for exmaple, if fps is 30 then gop is also 30 so that iframe can appear every second) But the cameras' set up values were fps 15, gop 60(iframe per 4 seconds) Assumption Somehow the viewer keeps failing to find iframe to play. And it's maybe because iframe appears with a long gap. Quick note: iframe is kind of a key-frame. Since the viewer starts decoding from an iframe, it's necessary when it comes to playback. What I Tried Set all the cameras' gop value to 15(same as fps) Result Ran a test with data before changing the gop values and after. During interval before changing the gop, the issue occurred almost every time I tried. But after chaning the gop, the issue no longer occurred. Concolusion The issue was triggered by large GOP value (GOP 60 with FPS 15). With only one iframe every four seconds, the viewer sometimes failed to find an appropriate iframe after changing the playback speed, causing abnormal playback behavior. According to the viewer developer, this is likely related to the viewer's iframe searching logic, which is still under investigation. Keep This In Mind Check camera settings(especially gop and fps) first when it comes to playback issue. Always check before/after data to confirm assumption.

This article is part of the Comprehensive Guide to Microservices Architecture in .NET Core, Cloud and Azure series. API gateways serve as the entry point for client applications in distributed architectures, handling request routing, composition, and protocol translation. As systems grow more complex with multiple client types and backend services, choosing the right gateway pattern becomes crucial for maintaining performance, scalability, and developer productivity. This article explores two powerful API gateway patterns in .NET: the Backend for Frontend (BFF) pattern, which creates client-specific gateways, and GraphQL, which offers flexible, query-driven data fetching. Both patterns address the challenge of efficiently serving diverse clients while maintaining clean architecture and optimal performance. Backend for Frontend (BFF) Pattern Web BFF Implementation The web BFF returns detailed, enriched data suitable for desktop browsers with higher bandwidth and processing power: [ ApiController ] [ Route ( "api/web/[controller]" )] public class OrdersController : ControllerBase { private readonly IOrderServiceClient _orderClient ; private readonly ICustomerServiceClient _customerClient ; private readonly IInventoryServiceClient _inventoryClient ; [ HttpGet ( "{id}" )] public async Task < WebOrderDto > GetOrder ( Guid id ) { // Execute parallel calls to improve response time var orderTask = _orderClient . GetOrderAsync ( id ); var customerTask = _customerClient . GetCustomerAsync ( id ); var inventoryTask = _inventoryClient . GetInventoryStatusAsync ( id ); await Task . WhenAll ( orderTask , customerTask , inventoryTask ); return new WebOrderDto { Order = orderTask . Result , Customer = customerTask . Result , InventoryStatus = inventoryTask . Result , // Include additional rich data for enhanced web UI experience RecommendedProducts = await GetRecommendationsAsync ( id ) }; } } Mobile BFF Implementation The mobile BFF provides optimized, lightweight responses to min

🌟 开场白：你有没有这样的烦恼？ 小朋友们，有没有遇到过这种情况： 📱 手机里的照片太多， 装不下了 ！ 💻 电脑里的视频， 换了电脑就找不到了 ！ 👨‍👩‍👧 爸爸妈妈爷爷奶奶，想看同一个视频， 要互相发来发去 ！ 有没有一个地方， 所有人都能存东西、随时取东西 ？ 有！那就是 —— 🏠 NAS N etwork A ttached S torage 网络附加存储 （但老师觉得叫它 "家庭小仓库" 更好懂！） 🎒 第一课：NAS到底是个啥？ 先想象一个场景 👇 幼儿园有个 大储物柜 🗄️ 每个小朋友都有 自己的格子 在教室里、在走廊里、甚至在家里 只要知道密码，随时可以取东西！ 老师也可以把作业放进去，大家一起看 这个 "随时随地都能访问的大储物柜" ，就是 NAS ！ 👩‍🏫 老师比喻总结： 普通硬盘 NAS 只插在一台电脑上用 接在路由器上，全家都能用 只有这台电脑能访问 手机、平板、电脑都能访问 出门就用不了 出门在外也能访问 🌍 像你自己的小书包 🎒 像幼儿园的公共储物柜 🗄️ 🏗️ 第二课：NAS长什么样？ NAS其实就是一台 特别的小电脑 🖥️ 普通电脑 = 有屏幕、键盘、鼠标 NAS = 没有屏幕！没有键盘！没有鼠标！ 只有一个"装硬盘的盒子" + 网线插口 ┌─────────────────┐ │ NAS 小盒子 │ │ ┌───┐ ┌───┐ │ │ │硬 │ │硬 │ │ ← 装了好几块硬盘 │ │盘1│ │盘2│ │ │ └───┘ └───┘ │ │ 💡 小灯灯 │ └────────┬────────┘ │ 网线 │ 📡 路由器 / | \ / | \ 手机 电脑 平板 👩‍🏫 老师比喻： NAS = 一个 装了很多大肚子的小机器人 🤖 它不需要眼睛（屏幕）、不需要手（键盘） 它只需要 网线 ，就能默默给全家服务 💪 🤯 第三课：重点来了！ NAS 其实就是一个"网页操作系统"！ 小朋友们先回忆一下上次学的 👇 网页 = HTML骨架 + CSS衣服 + JavaScript动作 然后放在 服务器 上，用 浏览器 访问 现在老师告诉你一个秘密 🤫 NAS 本身就是一台服务器！ 你管理NAS，不需要接显示器 直接打开浏览器，输入地址 NAS就把它的"控制面板"当网页显示给你！ 就像这样 👇 你打开浏览器，输入：http://192.168.1.100 ↓ NAS的"网页控制面板"出现了！ 有文件管理、有设置、有相册... 跟用网站一模一样！ 👩‍🏫 老师比喻： NAS = 幼儿园的 全自动智能储物柜 🗄️✨ 你不用去柜子跟前 在家用手机扫一下 → 柜子的 控制屏幕传到你手机上 你在手机上点点点 → 柜子乖乖开门取东西 这个"控制屏幕"，就是NAS的 网页界面 ！ 🍳 第四课：前端和后端 —— NAS版本！ 还记得上次说的"大厨房"吗？ 你（浏览器）点菜 → 厨房（服务器）做好送来 NAS也是一样的，分成 前端 和 后端 两个部分！ 🎨 前端 —— 你看见的那一面 ┌─────────────────────────────────┐ │ NAS 网页控制台 │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │📁文件│ │🖼️相册│ │🎬视频│ │ │ └─────┘ └─────┘ └─────┘ │ │ ┌─────────────────────────┐ │ │ │ 这里显示你的文件列表 │ │ │ └─────────────────────────┘ │ │ [上传] [下载] [删除] │ └─────────────────────────────────┘ 这些你能看见的 = 前端 🎨 👩‍🏫 老师比喻： 前端 = 储物柜 正面的触摸屏 📱 漂漂亮亮的按钮、图标、列表 你能看见、能点的，都是 前端 ⚙️ 后端 —— 藏在里面干活的 你点击"上传文件" 👆 ↓ 前端说："收到！我去通知后端！" ↓ 后端收到指令 ⚙️： 1. 检查你有没有权限 🔐 2. 找到硬盘上空的位置 💾 3. 把文件存进去 ✅ 4. 告诉前端："存好啦！" ↓ 前端显示："上传成功！✅" 👩‍🏫 老师比喻： 后端 = 储物柜 里面的机械手臂 🦾 你在触摸屏上点"放东西进去" 机械手臂默默把东西码放整齐 你看不见它，但它一直在努力工作！ 🔄 前端和后端怎么说话？ 前端（网页） ←→ 后端（NAS系统） ↑ ↑ 你能看见的界面 藏在机器里的程序 它们用"API"互相说话 API = 两个人之间的"对讲机" 📻 👩‍🏫 老师比喻： 角色 NAS里是谁 幼儿园比喻 前端 网页控制台界面 储物柜的触摸屏 📱 后端 NAS的操作系统程序 里面的机械手臂 🦾 API 前后端通信接口 触摸屏和手臂之间的对讲机 📻

At the right point of the orbit and stellar cycle, the star's chromosphere brightens.

Netris provides software that runs on network switches, and offers a platform that helps neocloud operators reduce the time it takes to go live.

Modern cloud deployments involve many tools with different lifecycles, creating a heavy burden on engineers. The Kubernetes ecosystem offers a unified Control Plane approach. Sharing best practices through tech talks and inner-source collaboration can create an engaged community and drive adoption. By Ben Linders

It is clear that Vyshyvanka is more than just code — it is an ecosystem. The true power of an open-source workflow engine lies in its community. Today, we want to talk about how you can get involved, whether you are interested in pushing the boundaries of the core engine or building specialized solutions with custom plugins. The Core Engine vs. The Plugin Ecosystem A common question we get is: 'Should I contribute a PR to the core engine, or should I build a separate plugin?' The answer depends entirely on the scope of your contribution. When to Contribute to Core The core engine ( Vyshyvanka.Core , Vyshyvanka.Engine , Vyshyvanka.Api , Vyshyvanka.Designer ) should be reserved for changes that benefit every user of the platform. Good candidates for core contributions: Performance improvements to the execution pipeline New fundamental port types or expression functions Bug fixes in the engine, validation, or persistence layers Enhancements to the Designer UI (canvas, node editor, property editors) Improvements to the API surface (new endpoints, better error responses) Documentation improvements These changes require careful review and testing because they impact every installation. We encourage PRs here, but we also ask that you open an issue first so we can discuss the architectural impact. When to Build a Plugin Plugins ( ./plugins/ ) are the best way to extend functionality without increasing the maintenance burden of the core. Good candidates for plugins: Integration with a specific third-party SaaS tool (CRM, CI/CD, monitoring) Custom nodes specific to your industry or use case Experimental node behaviors that are not yet ready for core Proprietary integrations you want to keep separate from the open source project Plugins are independent, versionable, and can be maintained outside the core release cycle. They empower you to solve your specific problems immediately without waiting for a core release. Project Structure at a Glance Understanding where things live i

According to a new site, 24% of the most popular websites in the world don't offer support for passkeys, which are considered the most secure way to log in to apps and services.

"Operation Endgame" simultaneously disrupts two widely used crime tools.

Google's GKE Labs has introduced OpenRL, an open-source project that provides a self-hosted API for post-training and fine-tuning Large Language Models (LLMs) on standard Kubernetes clusters. By Sergio De Simone

Every identity migration guide eventually reaches the same paragraph, and it's always a little apologetic: "users will need to reset their passwords." It gets treated like a law of nature. It isn't. It's a choice, usually forced by a tool that didn't want to do the harder thing. The harder thing is verifying your users' existing password hashes in place, so they sign in after the move with exactly the credentials they had before and never notice anything happened. Whether you can do it comes down to one question: can you get the old hashes, and can the new system verify them? Password hashes are more portable than people think A password hash isn't a secret algorithm. bcrypt is bcrypt. A bcrypt hash carries its own cost factor and salt inside the string, so anything that implements bcrypt can verify a hash any other bcrypt system produced. The same is true of the PBKDF2 format ASP.NET Identity uses: documented, versioned, self-describing. If you know what you're holding, you can check a password against it without ever knowing the password. So a migration that preserves logins doesn't need the plaintext (nobody has it) and doesn't need to re-hash everyone up front. It needs to obtain the stored hashes and verify against them on sign-in, upgrading each one to its own format quietly the first time a user logs in. That last part is lazy migration: carry the old hash, verify it once, replace it transparently. Over a few weeks of normal logins your user table re-hashes itself and the legacy formats age out, with zero resets and zero support tickets. The dual-path bit The wrinkle is that different sources hand you different formats, and a good importer verifies both: From self-hosted Duende / ASP.NET Identity: the V3 PBKDF2 hashes (and any legacy bcrypt) verify natively and rehash on first sign-in. This is the easy case, because it's the same scheme the destination already uses. Most teams are surprised it's that clean. From Auth0: bcrypt hashes verify verbatim. The catch

Data-Oriented Design in C#: Why Objects Are Slowing You Down In my previous article, we talked about starving the Garbage Collector by moving away from heap-allocated class types and leaning heavily into struct , Span<T> , and ArrayPool<T> . That’s a critical first step, but it only solves half the problem. You’ve stopped the GC from pausing your app, but you might still be leaving massive amounts of CPU performance on the table. Why? Because of how your data is structured. It’s time to talk about Data-Oriented Design (DoD) . The Object-Oriented Trap We are taught from day one to model our code after the real world. If you are building a social network graph, you might write something like this: public class UserNode { public int Id { get ; set ; } public string Name { get ; set ; } public List < Edge > Connections { get ; set ; } } public class Edge { public UserNode Target { get ; set ; } public int Weight { get ; set ; } } This makes perfect logical sense. A user has connections, and those connections point to other users. But modern CPUs don't care about your logical models. A CPU only cares about reading data from memory into its L1/L2 caches as fast as possible. When a CPU reads a byte from RAM, it doesn't just read that one byte; it pulls a whole 64-byte "cache line" under the assumption that you will probably want the neighboring bytes next. When you loop through a List<UserNode> , traversing from object to object, you are jumping randomly across the heap. The CPU pulls a cache line, reads your data, and then has to go fetch a completely different block of RAM for the next node. This is called pointer chasing , and the resulting cache misses are devastating to performance. Enter Data-Oriented Design: Struct of Arrays (SoA) Data-Oriented Design says: Stop modeling the real world. Model the data the way the hardware wants to consume it. Instead of an Array of Structs (AoS) (or an array of objects), we invert the architecture to a Struct of Arrays (SoA) . If we

At this year's Microsoft Build 2026, Microsoft unveiled a broad set of enhancements to Azure Kubernetes Service (AKS) aimed at making Kubernetes a first-class platform for AI training, inference, and large-scale cloud-native applications. By Craig Risi

There's a version of dogfooding that's a slogan, and a version where your own employees can't ship code until the bug is fixed. We run the second kind. The Authagonal staff console, the one we use to manage every tenant, authenticates through Authagonal itself: SAML single sign-on from our Entra directory, with SCIM deciding who gets in and what they can do. There is no separate admin password table. We deleted it. If our own SAML is broken, we are locked out of our own product. That's uncomfortable in exactly the useful way. It turns "SSO is an enterprise feature we support" into "SSO is the only way the people who built this get to work today." Here's what being our own customer caught. A trimmed build that broke signature verification We publish the auth server trimmed, to keep the image small. Trimming aggressively deletes code it can't prove is used, and reflection hides usage from it. .NET resolves its XML-signing crypto algorithms by name, reflectively, through CryptoConfig . The trimmer couldn't see those types were needed, removed them, and SignedXml quietly came back unable to build the algorithm. SAML signature verification, the step that proves the login is real, threw a null reference at runtime. The unit tests passed, because they ran against the untrimmed build where the types still existed. Only the trimmed production artifact failed, and it failed at the exact moment a human tried to sign in. We ship the auth server untrimmed now, with a healthy distrust of trimming anything near reflection-based crypto. If we only supported SAML rather than living on it, this is a customer's incident report instead of ours. Provisioning is the actual login Authenticating a user is the easy half of SSO. The hard half is deciding what they're allowed to do and keeping it in sync as people join and leave. We drive that with SCIM: Entra group membership maps to roles, resolved at the moment a token is issued, not copied once at account creation. Add someone to the righ

I have written some version of "never hardcode secrets, store them in Key Vault instead" in at least five of my last nine posts on this blog. I never actually stopped to explain what that means in practice. This post fixes that, using the real secrets this very blog depends on: a database connection string, an admin panel password, and a set of GitHub deployment credentials. What Azure Key Vault Actually Is Azure Key Vault is a managed service for storing secrets, encryption keys, and certificates securely in the cloud. Instead of a password sitting in a configuration file or a public GitHub repository where anyone with read access can see it, the password lives in Key Vault - encrypted, access-controlled, and logged every single time it is read. Picture your code as a house with see-through walls - anyone looking at the repository can see everything inside, including any password left lying on the kitchen table. Key Vault is a bank vault a few streets away. Your code does not hold the password directly; it holds a key card that lets it walk over and request the password at the exact moment it is needed. Lose the key card, and you still cannot get into the vault without proper identity verification on top of it. Three Things Key Vault Stores Secrets are plain string values - passwords, connection strings, API keys, tokens. Keys are cryptographic keys used for encrypting and decrypting data, or for signing and verifying it. Certificates are X.509 certificates used for TLS or client authentication between services. Most applications, including this one, primarily use the Secrets feature. An Honest Admission About TechStackBlog's Own Setup This blog does not actually use Key Vault directly today. The database password lives in Azure App Service Configuration. The admin panel password and deployment credentials live in GitHub Secrets. For a single-application personal project, this is a perfectly reasonable and secure setup. Key Vault earns its place once you have multi

Cross-posted from the LLMKube blog . A local 27B coding model, running on hardware in my house, is a coin flip. Some runs it nails the fix in twenty minutes. Some runs it edits the wrong file, writes a test that passes no matter what the code does, and tells you it's done. The bet behind LLMKube's Foreman was never that I would find a local model good enough to trust. It was that I could build a harness I trust more than any single model's output. This weekend tested that bet harder than any benchmark could, because the harness spent the weekend building its own guardrails. Here is the short version of what happened across 0.8.12 and 0.8.13. My local coder built three new gates for itself. One of them shipped with the exact flaw it was written to catch, and the review caught it. Three new contributors sent four clean pull requests while the machines worked. The same model ran on an AMD box and an Apple Silicon Mac, and the Mac quietly won a round nobody expected. And not one byte of any of it touched a cloud API. The thesis, stated plainly Trust the harness, not the model. A coding agent on a local model produces output of wildly variable quality, and no amount of prompt tuning makes a 27B as reliable as a frontier model. So Foreman does not ask the model to be reliable. It wraps the model in a pipeline that is : the coder works in a cloned workspace, a fast in-workspace gate runs gofmt, vet, build, lint, and the unit tests for the packages it touched; a reviewer reads the diff against the issue; and a clean-room Kubernetes Job re-runs the full suite before anything is allowed to call itself a GO. Around all of that sit deterministic rails: scope checks, edit-free-streak detection, repo-map context. The model is a stochastic component inside a system whose job is to make the system's verdict trustworthy even when the component is not. The interesting question is never "is the model good." It is "does the harness catch the model when it is bad." This weekend gave me