AI 资讯

Introduction Artificial intelligence is now much more advanced than chatbots. With little assistance from humans, modern AI systems are capable of reasoning, planning, using tools, remembering previous interactions, and carrying out complicated tasks. We refer to these systems as AI Agents. AI agents are quickly emerging as a crucial component of contemporary software engineering, from coding assistance to research automation and customer service systems. We'll look at what AI agents are, how they operate, and why they are influencing software development in the future in this post. Actually, What Is an AI Agent? An AI Agent is a system that can: Understand a goal Decide what actions to take Use available tools Remember relevant information Execute tasks Evaluate results Unlike traditional software,the AI Agents are goal-oriented rather than rule-oriented. AI Agents vs Traditional Chatbots Traditional chatbots primarily answer questions and respond to prompts. AI Agents go further by completing tasks, maintaining memory, planning actions, and executing multi-step workflows. A chatbot responds; an AI Agent acts. Core Components of an AI Agent Large Language Model (LLM) The LLM acts as the brain of the agent. Popular models include those from OpenAI, Anthropic, and Google DeepMind. The model understands instructions and generates decisions. Tools Agents become powerful when connected to tools such as: Web search Databases APIs Email systems Calendars Code execution environments Without tools, an agent can only generate text. With tools, it can take actions. Memory Memory allows agents to retain information. Short-Term Memory: Used during the current task, such as user preferences and conversation context. Long-Term Memory: Stores information across multiple interactions, such as historical data, preferences, and recurring workflows. Planning Planning enables agents to break large goals into smaller tasks. Example: Goal: Build a market research report. Plan: Collect da

MVCC, WAL, vacuum, and replication slots under sustained delete load - and how to delete billions of rows without your database noticing Most "how to delete a lot of rows" articles stop at "batch it and delete children before parents." That advice is correct, it's table stakes, and everyone already knows it. This article is about everything after that - the parts that actually decide whether your cleanup runs quietly in the background for a week or pages you at 3 a.m. with a full disk and a replica that's six hours behind. The thesis: at scale, your DELETE statement is the easy part. The adversaries are the subsystems a delete feeds - MVCC tuple versioning, the write-ahead log, autovacuum, and the replication machinery. Bulk deletion is really an exercise in flow control across those subsystems . Get the SQL right and the systems wrong, and you'll still take production down. We'll assume PostgreSQL (the internals are PG-specific), a live OLTP primary with at least one physical replica and one or more logical/CDC consumers, and a target of hundreds of millions to billions of rows across many related tables. The one paragraph of "basics," so we can move on: delete in dependency order (referencing rows before referenced rows); collect parent keys once; never rely on ON DELETE CASCADE for huge deletes because you can't throttle a cascade. Done. Now the real material. 1. What a DELETE actually costs A delete is not "remove a row." Under MVCC it's "mark a row version dead and write that fact everywhere." For each deleted tuple, PostgreSQL: Sets xmax on the heap tuple to your transaction id. The row is still physically present; it becomes a dead tuple once your transaction commits and no snapshot can still see it. Writes a WAL record for the heap change. If this is the first modification of that page since the last checkpoint, it also writes a full-page image (FPI) - potentially 8 KB of WAL for a single-row change. Touches every index. Index entries aren't removed at delet

Background I started daily driving Linux back in 2019. The start of that journey was rough, and I still deeply appreciate the help I received in those early days from the old guard who kept me moving forward. Early on, I quickly found my home with Linux Mint and its Cinnamon desktop. As the saying goes, "You don't choose a Linux desktop; the desktop chooses you." Built on top of a stable foundation with a rich package infrastructure, Cinnamon provided a familiar experience that bridged the gap from Windows. It also afforded me excellent customization options right out of the box, such as configuring custom keyboard shortcuts or setting up auto-login startup scripts, while always getting out of my way. No adverts, no pop-ups, just a fast and efficient desktop environment. I won't lie, though: I distro-hopped multiple times just to see if the grass was greener. Through those escapades, I quickly realized I am definitely not a GNOME person; I do not like polyfilling my desktop experience with a suite of extensions. And as much as I appreciate KDE Plasma, I learned that with great customization comes great responsibility because it was far too easy for me to break my environment with just a few theme toggles. This is not a dig at those desktop environments; it just means I am not wired for that kind of experience. As I continued my Linux journey, my priorities shifted. I wanted a predictable operating system that could act as a trusted companion, both for my daily life as a software developer and as a casual user wanting to watch Netflix on the weekends. This is what made me appreciate Linux Mint even more. It featured a predictable release cycle, a stable package base built on Ubuntu LTS, and Timeshift to guard against system breakage during upgrades. However, two major friction points always bothered me: Stable but Stale Packages: Linux Mint's software is incredibly stable, but it is rarely fresh. For example, the okular package is consistently several versions behind

Originally published at llmkube.com/blog/making-self-hosted-llm-agents-trustworthy . Cross-posted here for the dev.to audience. Running a single local LLM node is a solved problem. You write an InferenceService, the operator schedules it, llama.cpp or MLX serves it, and you get an OpenAI-compatible endpoint. We have been doing that for months. Running a fleet of them is where it stops being easy. My fleet is heterogeneous on purpose: CUDA pods in the cluster, and Apple Silicon Macs sitting off-cluster on the homelab network, each one running two separate agents (one for inference, one for the agentic coding harness). The day I shipped 0.8.4 to that fleet, I learned exactly how it does not scale. I updated each Mac by hand. The control plane had no idea what version any agent was running. And the launchd reload I used to restart an agent was a silent no-op on an already-loaded service, so the old binary kept running while I believed I had updated it. I found that out by hand-inspecting a process tree. Three machines made it annoying. Thirty would make it impossible, and the whole pitch for sovereign, on-prem AI is that you run a lot more than three. So the last stretch of work on LLMKube was not about a faster runtime or a bigger model. It was about making the fleet trustworthy : able to update itself safely, and unable to lie to the control plane about its own state. Here is what that took. Helm and brew for the edge The fix is a new cluster-scoped CRD, AgentRelease , and a self-update path in the agents themselves. You describe the release you want once, the operator rolls it out, and the agents pull and apply it. The design borrows directly from prior art that already solved this for Kubernetes nodes: Rancher's system-upgrade-controller, k0s autopilot's per-platform SHA-256 staging, and Teleport's outbound-only poll model. The properties that make it safe to leave running: Declarative and approved. An AgentRelease names the agent, the version, and the per-platform

A beautiful interface isn't created by random colors. The right color palette can increase usability, improve brand recognition, and guide users toward important actions. Here's a simple process I follow when designing products: ✅ 1. Start with Your Brand Personality Ask yourself: • Professional or playful? • Premium or affordable? • Modern or traditional? Examples: 🔵 Blue = Trust, security, professionalism 🟢 Green = Growth, health, sustainability 🟣 Purple = Creativity, innovation 🔴 Red = Energy, urgency, excitement Your primary color should reflect your brand's personality. ━━━━━━━━━━━━━━ ✅ 2. Use the 60-30-10 Rule A balanced interface often follows: • 60% Primary Background Color • 30% Secondary Color • 10% Accent Color This creates visual harmony and prevents color overload. ━━━━━━━━━━━━━━ ✅ 3. Limit Your Palette Many beginners use too many colors. A professional UI usually needs: • 1 Primary Color • 1 Secondary Color • 1 Accent Color • Neutral Colors (White, Gray, Black) Less is often more. ━━━━━━━━━━━━━━ ✅ 4. Think About Accessibility Your design should work for everyone. Check: ✔ Text contrast ✔ Button visibility ✔ Readability on mobile screens If users struggle to read content, even the most beautiful design fails. ━━━━━━━━━━━━━━ ✅ 5. Create a Consistent Color System Instead of random shades: Primary: • 50 • 100 • 200 • 300 • 400 • 500 Secondary: • 50 • 100 • 200 • 300 • 400 • 500 This makes scaling your product much easier. ━━━━━━━━━━━━━━ ✅ 6. Analyze Successful Products Study platforms like: • Airbnb • Spotify • Stripe • Notion Notice how they use color intentionally to guide user attention. ━━━━━━━━━━━━━━ 💡 Quick Formula Primary Color → Brand Identity Secondary Color → Support Content Accent Color → Call-To-Action Buttons Neutral Colors → Layout & Typography Good UI isn't about using more colors. It's about using the right colors in the right places. What's your favorite color palette for modern web applications? UIUX #UIDesign #UXDesign #WebDesign #Produc

In early 2026, Anthropic researchers ran an experiment with 52 junior developers. Half used an AI assistant to learn an unfamiliar Python library. The other half worked without one. Both groups finished the task. But when tested on how well they understood the code they had just written, the AI-assisted group scored 50% on a comprehension quiz - versus 67% for the unassisted group. That 17-percentage-point gap has a name: cognitive debt. It is one of the most important concepts in software engineering right now, and most developers are not paying enough attention to it. What Is Cognitive Debt? Cognitive debt describes the growing gap between the volume of code that exists in a system and the amount that any developer genuinely understands. It is not a new term, but it crystallized across multiple research streams in early 2026. Addy Osmani (Google Chrome) described it as "comprehension debt" - the hidden cost that accumulates when code becomes cheap to generate but understanding still requires deliberate effort. Margaret-Anne Storey (University of Victoria) formalized the concept in a March 2026 arXiv paper, framing it as a team-level problem and extending it into a Triple Debt Model: technical debt in the code, cognitive debt in the people, and intent debt - the missing rationale that both humans and AI agents need to safely work with code. Cognitive Debt vs. Technical Debt These two ideas are easy to conflate, but they are fundamentally different problems. Technical debt lives in the code - it shows up as slow builds, tangled dependencies, and failing tests. Cognitive debt lives in people - it surfaces as an inability to explain, debug, or extend code that the team themselves wrote. The critical difference: technical debt announces itself through friction. Cognitive debt breeds false confidence. Your tests are green, velocity looks fine, and nobody realizes the system is fragile until something breaks in production and the team cannot reason through why. What the

The blast radius of an API key is not "did it leak." It's "if the agent holding it does the wrong thing, how much of your stack goes with it." A secret scanner answers the first question. Nothing in your toolchain answers the second one before an incident. So I wrote 40 lines that do, offline, from the permission metadata you already have. In short: the blast radius of an API key is set by its permissions, not by whether it leaked: scope width × environment isolation × lifetime × revocability. blast_radius.py reads that metadata (never the secret value, never the network) and scores each key 0–100. In my run a broad prod token hit 91/100 CRITICAL; a scoped key, 14/100 CONTAINED. Stdlib, keyless, deterministic. AI disclosure: I wrote blast_radius.py with AI assistance and ran it myself before publishing. Every score in the output blocks below is pasted from a real run on a synthetic fixture I'll show you — no real keys exist in it; every value is a placeholder like sk-FAKE-… . The incidents I cite ($82K, 9 seconds, 2,863 keys, 93%) are other people's , and I link each source next to it. I label which is which. A token that could delete the database, used to manage domains On April 24, 2026, a Cursor agent running Claude Opus 4.6 dropped a production database, and the volume backups with it, in about 9 seconds, on one API call . The team behind PocketOS wrote it up. The agent hit a credential mismatch, went looking, and found a long-lived Railway CLI token sitting in an unrelated file. That token had been minted to manage domains. But it carried blanket authority over the whole Railway account, volumeDelete included. No scope tied to an environment. No read-only mode. Recovery took the weekend ( The New Stack, 27 Apr 2026 ; The Register, 27 Apr 2026 ). Read that again, because the lesson isn't "the agent went rogue." The lesson is the token . A domain-management task does not need volumeDelete . The key was over-scoped before the agent ever touched it. The agent didn'

Hermes Agent already has memory, and that matters. It keeps local context, it improves over time, and it works without forcing you into a cloud service. It also supports several external memory providers. I still built hermes-mempalace , because none of the existing options fit my setup quite right. I wanted something: local-first isolated by Hermes profile verbatim, not just extracted facts easy to inspect on disk simple enough to trust over time That last part is the important one. I did not want a memory layer that turns conversations into an opaque pile of embeddings or summaries you cannot really audit. I wanted actual transcripts, mined into a readable structure, with no hidden server in the middle. Why the existing options were not enough Hermes already gives you a few paths: built-in memory and session context external providers for different use cases enough flexibility to adapt, if you are willing to bend your workflow around them And to be clear, some of those options are good. But ... I run Hermes on a headless machine at home. And I use separate profiles for different contexts. And I do not want conversation content depending on a cloud API or a separate service unless there is a very good reason. So, the best fit had to check a few boxes: [x] no API key [x] no external server [x] no extra runtime I did not already want/install [x] storage isolated by HERMES_HOME [x] memory we can actually read later That let to MemPalace , or https://mempalaceofficial.com/ (hopefully, that's the right one!) What hermes-mempalace does hermes-mempalace wires MemPalace into the Hermes memory provider interface. It follows the same lifecycle as the rest of Hermes memory providers: system_prompt_block() adds a short memory reminder to the prompt. prefetch() can run a MemPalace search before the first model call. sync_turn() buffers completed turns without slowing the chat loop. on_session_end() writes buffered turns to markdown and mines them into the palace. shutdown() flu

Sometimes my son asks me 'why' questions that could be answered well by a kid-friendly philosophy article. But I don't know where to find those, so I ask Claude or ChatGPT, and have a specific workflow for getting the type of output I want. I figured other people might find those AI-generated articles helpful, so I put them here: https://philosophy.ocaho.com/ There's a search box at the top.

Claude Code activity, right where you want it. Discussion | Link

OpenAI launches the Partner Network, investing $150M to help global partners accelerate enterprise AI adoption, deployment, and transformation.

Startups are trying to "ride that SpaceX IPO wave."

FTX held a diluted 7.84% stake in Anthropic, according to Reuters. Anthropic’s latest reported valuation is around $965B. That implies the former FTX stake would be worth about $75B before further dilution. FTX’s customer shortfall was roughly $8B to $9B. The estate sold the Anthropic stake during bankruptcy to repay creditors. Sources: https://www.reuters.com/technology/crypto-exchange-ftx-sell-shares-ai-startup-anthropic-2024-02-22/ https://www.reuters.com/technology/openai-files-us-ipo-after-

I have this vivid memory of walking to pick up my oldest from school in June of 2022. For a variety of reasons, I was in a very bad place mentally. And to make matters worse, it was brutally hot. I was depressed, angry with the world, sunburned, and soaked through with sweat. But as […]

This is a current list of where and when I am scheduled to speak: I’m giving a keynote at Cybernation 2026 in Berlin, Germany, on June 24, 2026. I’m speaking at the Potsdam Conference on National Cybersecurity at the Hasso Plattner Institut in Potsdam, Germany. The event runs June 24–25, 2026, and my talk will be the evening of June 24. I’m participating in a panel discussion at the Austrian Institute for International Affairs in Vienna on Thursday, June 25, 2026. I’m speaking at the Digital Humanism Conference in Vienna, Austria, on Friday, June 26, 2026...

Welcome back to TechCrunch Mobility, your hub for the future of transportation and now, more than ever, how AI is playing a part.

Hoping to catch some World Cup matches while spending as little money as possible? You have a few options for finding a few days of free streaming, although you may choose to eventually pony up some money. That, or get creative by combining multiple offers to make it through the whole tournament. We found a […]

So you built your stack on a hosted frontier model. Good throughput, clean API, your foreign-national engineers hit the same endpoint as everyone else. Then on June 12 the US government pulled Claude Fable 5 and Mythos 5 offline for the entire planet, three days after launch, and the reason is a compliance gap baked into how these things actually serve traffic. Here's the thing worth understanding as an engineer: the bug was narrow. The takedown wasn't. The gap between those two facts is where every team running a hosted model should be paying attention. What actually triggered it Commerce hit Anthropic with an order barring access to both models by any foreign national, anywhere, inside or outside the US, including Anthropic's own foreign-national staff. The stated trigger was a jailbreak: point the model at a codebase, ask it to find flaws. That's it. Anthropic reviewed the demo and watched it surface a handful of already-known minor vulns, the kind GPT-5.5 and other public models hand you with no bypass at all. So the capability wasn't exotic. It was automated code review on a Tuesday. The reason it went nuclear is the legal layer sitting on top, not the finding itself. The architecture problem: you can't gate on a passport you can't see Walk it through like any other access-control question. The restriction names a class of users: foreign nationals. Every one of them, globally. Now look at what a model API knows about a session at request time. restriction: deny any foreign national, anywhere session metadata: auth token, IP, usage tier NOT in session: verified nationality isolatable set: ∅ only compliant state: serve nobody An API session doesn't carry a verified passport. IP geolocation is trivially defeated by a VPN and tells you location, not citizenship anyway. There's no field in the request that maps to the restricted class. When you can't isolate the users you're forbidden to serve, the only provably-compliant state is serving no one. Off switch. Global.

Rust promises memory safety without garbage collection. That's why many of us dream of writing a kernel in it. After several years of building a from‑scratch operating system in Rust, I've collected the real — not theoretical — challenges that will make you question your life choices. Here are the five hardest problems, and the pragmatic solutions that actually work. 1. The unsafe Infection: Your Core is Not Safe The kernel's job is to manage memory, poke hardware registers, and handle interrupts. That means unsafe is not an exception — it's the norm. The problem : A single unsafe block can corrupt state that safe code depends on. In userspace, you isolate unsafe behind a small API. In the kernel, the entire bottom layer is unsafe . A bug in the page fault handler trashes everything. What doesn't work : Pretending that "only 5% of the code is unsafe ". In practice, the scheduler, the memory allocator, the interrupt handlers — they all need unsafe . You can't push it to the edges. What works : Treat unsafe as a capability . Every unsafe function must have a // SAFETY: comment explaining why it's sound. Use static assertions ( const_assert! ) to validate invariants at compile time. Isolate hardware access behind a hal crate where unsafe is contained, but don't cheat — the rest of the kernel still needs unsafe for core operations. Example — writing to a memory-mapped register: /// SAFETY: addr must be a valid MMIO address for this device, /// aligned to 4 bytes, and the caller must hold the device lock. pub unsafe fn mmio_write(addr: *mut u32, value: u32) { addr.write_volatile(value); } The comment doesn't make it safe — it documents the contract so the caller knows what they must guarantee. Memory Allocation Before alloc You want Vec, Box, Arc. But alloc requires a global allocator. The allocator requires a lock. The lock requires a working scheduler. The scheduler requires memory allocation. Classic chicken‑and‑egg. The problem: You can't allocate memory to create th