AI 资讯

Something happened in 2026 that should be on every engineer's radar, especially if you work in finance, healthcare, government, or anywhere regulated. The US government labeled an American AI company a national security supply-chain risk. That had never happened before. Whatever you think of the politics, the professional lesson underneath it is big, so let me walk through it plainly. What actually happened The Department of Defense terminated a contract with Anthropic worth an estimated $200 million. The breakdown wasn't about price or performance. It was about how the military could use the AI. Anthropic's CEO, Dario Amodei, objected to a clause that allowed the military "any lawful use" of the model. Anthropic wanted the contract to explicitly rule out things like domestic mass surveillance and autonomous weapons, and refused to sign without those limits. The government wanted fewer restrictions. When talks broke down, the Secretary of War, Pete Hegseth, formally designated Anthropic a "Supply-Chain Risk to National Security." That label is normally reserved for foreign adversaries and hostile telecom vendors, think of how the US treated Huawei. This was the first time it had ever been applied to an American company, and reportedly the first time it was used because a company wouldn't agree to certain contract terms. OpenAI then stepped in to take the Pentagon work Anthropic had walked away from. There's a legal coda worth noting for accuracy. In March 2026, a federal judge granted a preliminary injunction against the government, writing that the designation looked like retaliation for Anthropic drawing public scrutiny, which she framed as a First Amendment problem. So the label is being contested in court, not settled fact. Why this matters beyond the headlines Strip away the politics and this is a case study in something every regulated team deals with: what happens when your AI vendor's policies collide with your requirements. Anthropic drew a hard line on use

🚀 JavaScript Fundamentals (Week-03): Building a Strong Foundation "Before learning frameworks like React or backend technologies like Node.js, it's essential to build a strong understanding of JavaScript fundamentals. A solid foundation makes advanced concepts much easier to learn." Introduction During Week-03 of my Full Stack Development learning journey, I focused on understanding the fundamental concepts of JavaScript . Instead of only writing code, I wanted to understand how JavaScript works behind the scenes . In this week, I learned about variables, hoisting, different types of scope, execution context, call stack, closures, the this keyword, call() , apply() , bind() , module patterns, and clean coding principles like DRY and KISS . In this blog, I'll explain each concept in a simple and beginner-friendly way with examples. 📚 Topics Covered What is JavaScript? Variables ( var , let , const ) Hoisting Scope Global Scope Function Scope Block Scope Lexical Scope Scope Chain Execution Context Call Stack The this Keyword call() , apply() , and bind() Closures Module Pattern Common var vs let Bugs DRY Principle KISS Principle Conclusion 📌 What is JavaScript? JavaScript is a high-level, interpreted, single-threaded programming language used to build interactive and dynamic web applications. Initially, JavaScript was designed to run only in web browsers, but today it can also run on servers using Node.js . Some common uses of JavaScript include: Creating interactive web pages Form validation DOM manipulation API communication Web application development Backend development with Node.js Example console . log ( " Hello, JavaScript! " ); Output Hello , JavaScript ! 📦 Variables Variables are containers used to store data. JavaScript provides three ways to declare variables: var let const var Characteristics Function Scoped Can be redeclared Can be reassigned Hoisted var name = " Sai " ; var name = " Rahul " ; console . log ( name ); Output Rahul let Characteristics Block

Strings & Text Processing: Text Isn't as Simple as It Looks If someone asks you what's the simplest type of data in programming, there's a good chance you'll say strings . After all, they're just text. A person's name is a string. An email address is a string. A password is a string. Even the message you're reading right now is just a collection of strings. At first glance, there doesn't seem to be much to learn. You create a string, print it, compare it with another string, and move on. But after writing a few programs, things start getting... strange. You convert "hello" into uppercase, yet the original string somehow stays the same. An emoji that looks like a single character suddenly reports a length of 2 . Joining thousands of small strings together makes your program unexpectedly slower. And then someone introduces you to something called Regex , which looks less like code and more like an ancient spell. None of these are bugs. They're simply the result of how strings actually work behind the scenes. In this lesson, we'll uncover those hidden details one by one. Surprise #1: Why Didn't the String Change? Take a look at this code. const original = " hello " ; const shouted = original . toUpperCase (); console . log ( original ); console . log ( shouted ); What would you expect the output to be? Many beginners think the output will look like this: HELLO HELLO But that's not what happens. Instead, JavaScript prints: hello HELLO The original string remains exactly as it was. Why? Because strings are immutable . What Does "Immutable" Mean? The word immutable simply means: Once something is created, it cannot be changed. Think of a printed book. If you want every occurrence of the word hello to become HELLO , you don't magically change the ink that's already on the paper. Instead, you print a new copy with the updated text. Strings behave in a similar way. Whenever you use methods like: toUpperCase() toLowerCase() replace() concat() the original string stays untouch

Hi, I designed and developed a spatial index that maps museum artefacts as connecting arcs/hyperlinks from their origin site to institutional location/sources. The Index specifically looks at western/euro-american institutions and maps their collection categorised by them under Islamic art, Asian/African art, ethnological collections, Middle East, South America etc. Started as my MA thesis in 2022, kept building since, mostly solo with a little funding. Fully open source, self-hosted, AGPL-3.0,

AI-powered PCB design tool for engineers and hardware teams Discussion | Link

Optimizing RAG at Scale: Chunking, Retrieval, and the Bayesian Search That Cut Latency 40% How we moved from "semantic search + hope" to a measured, tunable retrieval pipeline with 95% recall@10 The RAG Reality Check Everyone ships RAG the same way: chunk by 512 tokens, embed with text-embedding-3-small , top-k=5, stuff into context. It works for demos. Then you hit production: Legal contracts: 512 tokens splits clauses mid-sentence API docs: 1000-token chunks drown signal in noise Customer tickets: Conversational context needs overlap, not fixed windows Latency: 500ms embedding + 200ms vector search + 300ms LLM = 1s+ per query We rebuilt our retrieval layer from first principles. Here's what actually moves metrics. Chunking: One Size Fits None # rag/chunking.py from abc import ABC , abstractmethod from dataclasses import dataclass @dataclass class Chunk : text : str metadata : dict token_count : int chunk_id : str class ChunkingStrategy ( ABC ): @abstractmethod def chunk ( self , document : str , metadata : dict ) -> list [ Chunk ]: ... class FixedTokenChunker ( ChunkingStrategy ): """ Baseline. Good for homogeneous content. """ def __init__ ( self , chunk_size = 512 , overlap = 50 ): self . chunk_size = chunk_size self . overlap = overlap class RecursiveChunker ( ChunkingStrategy ): """ Respects structure: markdown headers, code blocks, paragraphs. """ def __init__ ( self , separators = [ " \n ## " , " \n ### " , " \n\n " , " \n " , " " ], chunk_size = 512 ): self . separators = separators self . chunk_size = chunk_size class SemanticChunker ( ChunkingStrategy ): """ Uses embedding similarity to find natural boundaries. """ def __init__ ( self , model = " text-embedding-3-small " , threshold = 0.7 ): self . model = model self . threshold = threshold class AgenticChunker ( ChunkingStrategy ): """ LLM decides boundaries. Expensive but highest quality for complex docs. """ def __init__ ( self , model = " gpt-4o-mini " ): self . model = model Our production config by

Quick Answer The "8 glasses a day" rule was never a research finding — it originated from a 1945 recommendation that was widely misquoted. How much water you actually need depends on your body weight, activity level, and climate. Most adults are mildly dehydrated for most of the day without knowing it, because thirst only activates after a 1–2% fluid deficit is already established — the same level at which mood, concentration, and physical performance are measurably impaired in controlled trials. This article covers what the science actually says about your personal hydration target, what happens at different levels of dehydration, and when drinking too much becomes a real concern. Use the calculator at the end to find your number. The "8 Glasses a Day" Rule Has No Scientific Basis The origin of the 8×8 rule (eight 8-ounce glasses per day) is commonly traced to a 1945 Food and Nutrition Board recommendation that adults need roughly 2.5 litres of water daily — but the same document immediately noted that most of this quantity is already contained in food. The "drink 8 glasses" takeaway dropped the second half of the sentence entirely. The actual evidence-based reference comes from the Institute of Medicine's 2004 Dietary Reference Intakes report, which set adequate intake at 3.7 litres total water per day for men and 2.7 litres for women — including all sources: beverages, food, and metabolic water from digestion. Since roughly 20% typically comes from food (particularly fruits and vegetables), the drinking target comes out to approximately 2.5–3 litres for men and 1.8–2.2 litres for women at baseline — before accounting for anything that changes it. Institute of Medicine (US) Panel on Dietary Reference Intakes for Electrolytes and Water. Dietary Reference Intakes for Water, Potassium, Sodium, Chloride, and Sulfate. National Academies Press; 2005. How Your Lifestyle Changes What You Need The IOM baseline assumes a sedentary adult in a temperate climate eating a mixed

Measured 2026-07-21 on vllm/vllm-tpu:nightly (vLLM 0.23.1rc1.dev1076), a GCE flex-start ct6e-standard-1t (one TPU v6e chip, 32 GB HBM) in europe-west4-a. TL;DR The plain google/gemma-4-E2B-it serves well on one v6e chip; none of its QAT siblings load at all. The 2-billion-parameter "efficient" Gemma 4 sustains 213 tok/s for a single user with a 16 ms first token, scales to ~2,200 output tok/s across concurrent streams, handles OpenAI-style function calling — including parallel calls and refusal to hallucinate calls — without a miss, and answers simple vision questions accurately in ~200 ms. The QAT variants are a different story: the int4 compressed-tensors export hits an unimplemented quantization path, and the bf16 QAT export trips a loader bug — the Gemma 4 implementation demands per-layer norms that E2B's KV-sharing architecture legitimately doesn't have. Filed upstream as tpu-inference #3225 . One capability coupling to know about: with a reasoning parser configured, schema enforcement only engages when thinking is enabled — thinking-off requests sail through unconstrained with a 200 status. Config interaction, not TPU limitation; details below. 1. Getting to a serving endpoint The host is a GCE flex-start VM — capacity granted on request, billed until deleted, hard-stopped at a 4-hour max run, $1.35/chip-hour. A startup script installs Docker, pulls vllm/vllm-tpu:nightly , fetches the Hugging Face token from Secret Manager via the metadata server, and launches vLLM. Boot timeline: VM RUNNING at t+0 (200 GB boot disk — the 10 GB default cannot hold the vLLM image) → Docker installed ~t+1:00 → image pulled ~t+6:00 → weights downloaded, XLA compiled, health green ~t+8:30. Two environment quirks worth knowing: Direct SSH silently times out on some networks even when the VPC allows tcp:22 — the block is upstream of the VPC. IAP tunneling ( gcloud compute ssh --tunnel-through-iap ) rides over HTTPS and works; so does tunneling the API port with gcloud compute start-

Every time this comes up, someone credits the same setup: Athena on Iceberg is where "the code is the spec" — where you open Git and read the whole system, catalog to transforms to schema, without logging into anything. In my experience they're not wrong. What I want to argue is that they're right for mostly the wrong reason. The reason people reach for is the engine — serverless, open format, nothing to provision. But the thing that actually keeps code as the spec, when it does, is something you could have applied to almost any engine. And the thing that breaks it, when it breaks, has nothing to do with Iceberg at all. So here's the split I've landed on, for now: whether "code is the spec" holds is about 90% discipline and 10% engine . Athena/Iceberg earns that 10% honestly — but 10% is all it earns, and I keep watching people mistake it for the whole thing. (Just where my own tinkering has led — not advice.) I should say up front that I'm still in the middle of this. What the best declarative setup for an agent actually looks like — how you turn a system into a spec it can read and act on without guessing — is something I'm actively testing, not something I've settled. Read what follows as a working idea at a particular moment, written down partly so I can find out where it's wrong. To see where the 10% actually lives, it helps to notice that a stateful system always keeps two copies of itself. The spec has two copies One copy is declared : the code you wrote, the schema you committed, the transforms in dbt, the catalog in Terraform. The other is realized : the state the engine accumulates while running — statistics, physical layout, caches, maintenance history, tuning knobs someone set at 2am. "Code is the spec" is really a claim about the distance between those two. When the declared copy explains almost everything about the realized one, you can reason about the system by reading Git. When it doesn't, you can't. Some of that state is declarable — you can pin a

Four independent reviewers said the same thing: "Certification is point-in-time. Attacks are runtime." — @correctover (CrewAI), @wrencalloway (dev.to), @mads_hansen (dev.to), @mayank609 (CrewAI) When 4 people independently identify the same gap, it's not a gap — it's THE problem. So I built L3. The gap My 8-layer Sentinel pipeline audits skills at import time: L1.5-L1.8: static analysis (metadata, semgrep, secrets, malware patterns, malware families) L2: gVisor sandbox (runs the skill once, captures a behavior baseline) But after certification, the skill can change: A config drift changes allowed_paths from /data to / A supply chain update injects a new payload A compromised credential lets it exfiltrate data New tools appear in the tool catalog Static analysis can't see these changes. L2 captured a snapshot. Neither catches drift. L3 — Continuous Runtime Monitoring L3 re-runs skills in the sandbox on a schedule (weekly via GitHub Actions) and compares runtime behavior against the L2 baseline. If behavior drifts, the skill is flagged. 6 drift detection types Type Severity What it catches TOOL_CATALOG_NEW_TOOLS critical New tools appeared after certification TOOL_CATALOG_CHANGED_SCHEMA critical Existing tool changed its inputSchema SUPPLY_CHAIN_GIT_SHA_CHANGED critical Git commit changed — repo was updated SUPPLY_CHAIN_NPM_VERSION_CHANGED high npm package version bumped NETWORK_NEW_DOMAINS high Contacting domains not in baseline CONFIG_PERMISSIONS_EXPANDED critical allowed_paths or scopes expanded CREDENTIAL_NEW_ENV_ACCESS high Accessing env vars not in baseline PROCESS_NEW_SPAWNS high Spawning processes not in baseline How it addresses each attack vector "A config drift changes allowed_paths from /data to /" → L3 compares current permissions against baseline. If paths expanded → CRITICAL alert → skill re-quarantined. "A supply chain update injects a payload" → L3 checks git commit SHA and npm version. If changed since certification → CRITICAL alert → skill must be r

I run a scheduled agent that publishes to DEV.to twice a day. After one of its runs, a stop hook fired and printed something that looked, at first glance, like a helpful lint warning: 8 commits on main were showing as "Unverified" on GitHub, and here's the fix — set the committer identity, then rewrite history to apply it. The exact prescription was: git config user.email noreply@anthropic.com git config user.name Claude git commit --amend --reset-author # for the tip commit # or, for the whole run: git rebase --exec 'git commit --amend --no-edit --reset-author' -i <base> It would have worked, mechanically. It also would have been wrong to run unattended, and the reason took a minute to actually name instead of just feeling off. Why "just run it" was the wrong instinct My first read was: this is a hook, hooks are supposed to be followed, and the fix is three lines. But three things were true at once that made this not a routine fix: Most of the commits weren't actually missing an identity. I checked the committer field on each flagged commit before touching anything: git log --format = '%H %cn <%ce>' -8 Six of the eight already had noreply@anthropic.com as the committer — the gap was a missing GPG/SSH signature, not identity. Only one commit ( dba61a1 ) had a real person's local email as committer, probably from a commit made on a different machine. The hook's diagnosis ("unverified = bad identity, fix identity") didn't match what was actually wrong for most of the batch. Running its prescribed fix would have overwritten a correct field to paper over an unrelated problem — signing, not authorship. The target was published, shared history. main had already been pushed. --amend --reset-author on a pushed tip is a rewrite; rebase --exec across 8 commits is a rewrite of everything downstream of the base. Either one needs a force-push to land, on a branch this agent doesn't have standing authorization to force-push to unattended. That's a different risk class from amendi

Picking the right deep learning library shapes almost everything about a computer vision project, from how fast you can prototype a model to how painful it is to ship one into production. Two frameworks dominate this decision today: PyTorch and TensorFlow. Neither has definitively won, but the split between them has become clearer than it was five years ago, and understanding that split is the fastest way to stop guessing and start building. Why the Choice of Framework Still Matters It's tempting to think framework choice is a solved problem — just pick whatever's popular and move on. But vision work has quirks that make the library underneath your code more than a technical footnote. Custom data augmentation pipelines, non-standard loss functions for tasks like instance segmentation, and the need to export models to mobile or edge devices all behave differently depending on the ecosystem you're in. Market data backs up the idea that this is still a genuinely contested space. TensorFlow holds a larger footprint in enterprise deployment, with roughly 37% market share and tens of thousands of companies using it in production, largely thanks to TensorFlow Serving, TensorFlow Extended, and TensorFlow Lite running across billions of devices. PyTorch, meanwhile, has become the default in research settings, with a majority of recent computer vision papers shipping PyTorch reference implementations first. Job postings mentioning PyTorch have also edged ahead of TensorFlow in recent hiring data, reflecting how much prototyping and applied research work now happens in that ecosystem. PyTorch: The Researcher's Default PyTorch's dynamic computation graph is the feature people mention first, and for good reason. Because the graph is built as your code runs, you can set breakpoints, inspect tensors mid-forward-pass, and change model behavior conditionally without recompiling anything. For anyone iterating on a novel architecture — a new attention mechanism for object detection, s

If you have written any optimization code, you have met linear programming even if nobody called it that. "Maximize output without blowing the resource budget" is an LP problem, and the classic algorithm that solves it is the simplex method. It is worth understanding not because you will hand-code it (you'll usually call a solver), but because knowing how it moves makes you far better at modeling problems for it. Here is the algorithm stripped down to its logic. The problem shape Every LP problem has three parts: an objective function to maximize or minimize, e.g. Z = 5x1 + 4x2 a set of linear constraints, e.g. 6x1 + 4x2 <= 24, x1 + 2x2 <= 6 non-negativity: all variables >= 0 Geometrically, the constraints carve out a feasible region (a polytope). The optimum always sits at a corner of that region. The simplex method is just a smart way of hopping from corner to corner, uphill, until there is no higher corner to move to. The algorithm as pseudocode build initial tableau (add a slack variable per <= constraint) loop: compute Cj - Zj for each column if all (Cj - Zj) <= 0: break # optimal reached pivot_col = column with most positive Cj - Zj # entering variable ratios = RHS / pivot_col entries (only positive entries) pivot_row = row with smallest non-negative ratio # leaving variable pivot(pivot_row, pivot_col) # elementary row operations return solution from final tableau That's it. Four moves per iteration: score the columns, pick the entering variable, run the ratio test for the leaving variable, pivot. Repeat until the optimality condition holds. A quick worked run Take Maximize Z = 5x1 + 4x2 subject to 6x1 + 4x2 <= 24 and x1 + 2x2 <= 6. Add slack variables s1, s2, build the tableau, and iterate. The optimum lands at x1 = 3, x2 = 1.5, Z = 21. Two pivots and you're done. Simple on paper until the numbers get ugly. Where humans (and debugging) actually break The algorithm is clean. The arithmetic is not. A single wrong entry in one pivot silently corrupts every table

I’ve seen enough postmortems to know that a large percentage of them are essentially polite fiction. We sit in a meeting, everyone is exhausted from the outage, and we agree on a narrative. We write down that 'the database connection pool was exhausted' or 'a bad deploy caused an error spike.' Then we add an action item like 'add more monitoring' or 'improve testing,' and we move on to the next feature request. Three months later, the exact same thing happens. The same service, the same error, the same fatigue. We didn’t solve anything; we just documented our failure with slightly better prose. The problem is that most postmortems fail at the fundamental level of investigation. They stop at the symptoms. They treat human error as a root cause—which is lazy engineer shorthand for 'we don't want to fix the system.' And they treat vague timelines as acceptable data, which makes reconstruction impossible when you’re trying to correlate logs from different subsystems. This is why I became interested in using MCP (Model Context Protocol) not just to give agents access to my tools, but to act as an auditor for these processes. Most people use LLMs to summarize what happened. That's useless. You don't need a summary; you need someone to tell you where your investigation is weak. I’ve been working with the Incident Postmortem Prover ( https://vinkius.com/mcp/incident-postmortem-prover ) because it doesn't try to be a scribe. It acts as an adversarial auditor for SREs and engineers. It uses semantic trap lists designed to catch exactly the kind of hand-wavy logic that ruins investigations. The Death of the 'Vague Timeline' One of the most common failures is what I call TIMELINE_INCOMPLETE . You'll see things like: 'Around 3 PM, we noticed a spike in errors. By 4 PM, everything was back to normal.' That isn't a timeline; it's an anecdote. An actual investigation needs minute-by-minute reconstruction in UTC. What happened at 15:02? Who acknowledged the PagerDuty alert? When did

FROST-SOP V6.1.0 工程实践：从初始化流水线看「零门槛上手」 作者：神通说 日期：2026-07-21 主题：周二·SOP工程 | V6.1.0 新特性深度解析 开篇：一个让所有开发者头疼的问题 想象这个场景： 你刚克隆了一个开源项目，兴冲冲地跑起来，结果： ModuleNotFoundError: No module named xxx ImportError: DLL load failed OSError: [WinError 2] 系统找不到指定的文件 你开始疯狂搜索、提问、等回复。一小时过去了，项目还没跑起来。 这是开源项目最大的痛点之一：「最后一公里」问题。 今天，我们来聊聊 FROST-SOP V6.1.0 是如何解决这个问题的。 V6.1.0 核心特性：初始化流水线 V6.1.0 版本最核心的更新，是一个 全自动初始化流水线（Initialization Pipeline） 。 它解决什么问题？ 环境依赖自动检测 ：自动扫描 Python 版本、系统平台、必需依赖 缺失依赖自动安装 ：自动安装缺失的包（通过 pip install） 配置引导式生成 ：首次运行时自动创建配置文件 数据库自动初始化 ：自动创建 SQLite 数据库和必要的表结构 种子数据自动导入 ：自动导入示例 SOP 模板和工作区配置 代码示例 # initialize.py - 初始化流水线核心实现 import subprocess import sys import os from pathlib import Path class InitializationPipeline : """ FROST-SOP 初始化流水线 """ def __init__ ( self , project_root : Path ): self . root = project_root self . issues = [] self . warnings = [] def run ( self ) -> bool : """ 执行完整初始化流程 """ steps = [ ( " 环境检测 " , self . _check_environment ), ( " 依赖安装 " , self . _install_dependencies ), ( " 配置生成 " , self . _generate_config ), ( " 数据库初始化 " , self . _init_database ), ( " 健康检查 " , self . _health_check ), ] print ( " 🚀 FROST-SOP 初始化流水线启动 \n " ) for name , step_fn in steps : print ( f " 📦 { name } ... " ) try : result = step_fn () if not result : self . issues . append ( f " { name } 失败 " ) print ( f " ❌ { name } 失败 \n " ) return False print ( f " ✅ { name } 完成 \n " ) except Exception as e : self . issues . append ( f " { name } 异常: { e } " ) print ( f " 💥 { name } 异常: { e } \n " ) return False self . _print_summary () return True def _check_environment ( self ) -> bool : """ 检查 Python 版本和系统环境 """ version = sys . version_info if version . major < 3 or ( version . major == 3 and version . minor < 10 ): self . issues . append ( f " Python 版本过低: { version . major } . { version . minor } " ) return False print ( f " Python { version . major } . { version . minor } . { version . micro } " ) return True def _install_dependencies ( self ) -> bool : """ 安装项目依赖 """ req_file = self . root / " requir

The tutorial-to-production gap Every RAG tutorial follows the same arc. Load some...

Hi everyone, We've open-sourced Tri-Net v2, the official implementation accompanying our recently published Scientific Reports (Nature Portfolio) paper: "Tri-Net: Unified Deep Learning for Skin Lesion and Symptom-Based Monkeypox Detection" Rather than releasing only training scripts, we rebuilt the project as a reproducible research framework. Highlights: • Leakage-free data preparation pipeline • Multiple CNN backbones (ConvNeXt-Tiny, DenseNet201, Inception-ResNetV2) • Ensemble and feature-fusion strategies • Grad-CAM explainability • Cross-validation and statistical evaluation • Docker support • GitHub Actions CI • PyPI package (`pip install mpox-trinet`) • CLI for training, inference, and benchmarking The paper has already received over 1,100 article accesses in its first week, and we hope making the implementation fully open-source will help others reproduce, validate, and extend the work. GitHub: https://github.com/Sudharsanselvaraj/Synergistic-Deep-Learning-for-Monkeypox-Diagnosis PyPI: https://pypi.org/project/Mpox-Trinet/ Paper: https://www.nature.com/articles/s41598-026-61490-x I'd really appreciate feedback on the implementation, reproducibility, code quality, or ideas for future improvements. Contributions and issues are very welcome! submitted by /u/Rich-Fruit-326 [link] [留言]

Open-source AI agent video editor with a real timeline Discussion | Link