今日已更新 160 条资讯 | 累计 24117 条内容
关于我们

标签:#X

找到 798 篇相关文章

AI 资讯

TeamLab 那片會跟著你走的花海,原理拆解 DIY

TeamLab 那片會跟著你走的花海,原理拆解+DIY 先看這張圖 這是 TeamLab 在東京台場的《呼應燈之森林》。當你走過去,附近的燈會慢慢亮起;你離開後,燈又慢慢暗下去,像是真的森林一樣。 還有另一個作品《花與人的共存》,花叢會跟著你移動——你站的地方,花就開在你腳邊;你離開,花就凋謝。 這兩件作品的核心邏輯是一樣的。這篇文章就來拆解它。 原理一:偵測位置 TeamLab 的互動裝置需要知道「你在哪裡」。 最常見的方法有兩種: 紅外線感應 :在地面下方埋紅外線接收器,你走過時阻擋光線,系統就知道有人在這個位置。缺點是只能測「有沒有人」,不能測「人在哪一個方向」。 深度相機(RealSense / Kinect) :像 Xbox 的體感相機,透過紅外線測量每一個點到你相機的距離,生成一張「深度地圖」。軟體在深度地圖裡找出人體的位置,然後算出座標。 DIY 版本 :一塊 Arduino + 超音波感測器(HC-SR04,大約 60 元)就能做到基本的「有人靠近」偵測。 原理二:控制回應 知道你在哪裡之後,系統要決定「要做什麼回應」。 TeamLab 的做法是 :不是「觸發」,而是「強度變化」 。 傳統的感應燈:感應到人 → 燈全亮 → 人離開 → 燈全滅。 TeamLab 的邏輯:感應到人 → 燈慢慢變亮(0.5 秒)→ 人持續在 → 維持亮度 → 人離開 → 慢慢變暗(2 秒)。 「慢慢」是關鍵。瞬間變化讓人注意到「科技」;緩慢變化讓人以為「這個空間有生命」。 這就是「驚奇設計」的核心: 時機對了,物理反應看起來像生物反應。 原理三:集體行為 最後一個秘密:TeamLab 的裝置很少只有一個「回應」。 通常會有 100-500 個元素(燈、花、光點)。每個元素各自計算自己與你的距離,決定自己的亮度或顏色。 當 500 個燈各自以稍微不同的速度亮起和暗下,你看到的不是「一個燈亮了」,而是「一片森林在你腳下呼吸」。 心理錯覺 :你把「一群各自輕微不同步的簡單反應」,詮釋成「一個整體有意志的生物」。 用 Arduino 自己做一個迷你版 材料: Arduino Uno(大約 200 元) 超音波感測器 HC-SR04(大約 60 元) LED 燈 x 3(大約 15 元) 麵包板和杜邦線 原理很簡單: 超音波感測器偵測距離 距離越近,LED 越亮(用 PWM 訊號控制) 距離越遠,LED 越暗 int trig = 7 ; int echo = 6 ; int led = 9 ; void setup () { Serial . begin ( 9600 ); pinMode ( trig , OUTPUT ); pinMode ( echo , INPUT ); pinMode ( led , OUTPUT ); } void loop () { digitalWrite ( trig , LOW ); delayMicroseconds ( 2 ); digitalWrite ( trig , HIGH ); delayMicroseconds ( 10 ); digitalWrite ( trig , LOW ); long duration = pulseIn ( echo , HIGH ); long distance = duration * 0.034 / 2 ; // 距離越近,LED 越亮 int brightness = map ( distance , 0 , 100 , 255 , 0 ); brightness = constrain ( brightness , 0 , 255 ); analogWrite ( led , brightness ); delay ( 50 ); } 這不是 TeamLab,但這是你自己做的「會呼吸的燈」。每個 maker 都是從這裡開始的。 庭庭:這個看起來很難 真的沒有你想的那麼難。 需要的東西全部可以在蝦皮買到,全部加起來大約 300 元。網路上有超多 Arduino 教學,關鍵字搜「Arduino 超音波 LED」就有幾十篇中文教學。 你不需要懂電子,只需要跟著步驟做,做完會有「哇,我自己做出了一個會亮的東西」的感動。 如果你想更進一步 TeamLab 的進入門檻其實不是技術,是「你要把技術藏在美學後面」。 推薦兩個方向可以繼續研究: p5.js + webcam :用 p5.js 讀取你的 webcam 影像,偵測顏色或移動。相當於用軟體做到 Kinect 的效果,零硬體成本。 Processing + 投影機 :把電腦畫面投射到牆上或地面上,加上感測器,就是一個簡單版互動投影。投影機在蝦皮一兩千元就有。 今日概念 :TeamLab 的魔法不是魔法,是三個原

2026-06-28 原文 →
科技前沿

為什麼那個會「注意你」的展品,反而讓你更想靠近

為什麼那個會「注意你」的展品,反而讓你更想靠近 博物館互動設計的隱形槓桿 東京。 teamLab 展覽入口。 地面是一整片黑色的水面,倒映著數位花朵。 你踏進去。 花朵在你腳步周圍散開,隨著你的移動一圈一圈地綻放和飄落。 你停下來,花也停下來。 你開始走,花就跟著你。 你以為是感應。但仔細看——延遲了大概 0.3 秒。 不是「立刻反應」,是「好像在觀察你,然後才決定」。 你站在那裡又多看了三秒。 你第一個「對」 讓我問你一個問題。 你去過那種「互動博物館」嗎?牆上寫著「請觸摸」,但你碰了之後什麼都沒發生——或者是那種「語音導覽機」,你對著它說話,它說「請靠近一點」。 然後你就失去興趣了。 現在讓我想另一個場景。 一個會動的恐龍骨骼。你站在它面前的時候,它頭轉過來看了你一眼。 你知道這是感應器。你知道工程師設計了「檢測到人」的時候讓它轉頭。 但你還是覺得—— 「它在看我。」 兩種互動,哪一個讓你停留更久? 你第一個「咦」 這裡有一個秘密。 讓人停留更久的,通常不是「立刻反應」的互動。 是那種「 好像在決定要不要理你 」的互動。 為什麼? 因為「立刻反應」讓你確認了——「這是機器」。 但「好像在決定要不要理你」讓你的大腦進入了一個不確定的狀態—— 「它真的知道我來了嗎?」 「它在決定什麼?」 「我想看看它決定什麼。」 這個「我想看看」就是互動設計裡最重要的瞬間—— 參與者的好奇心,被啟動了。 玉樹真一郎在《任天堂的體驗設計》裡,分析了一個現象: 《超級馬里奧》裡,當玩家靠近一個問號磚塊,頂了它,沒有任何東西掉下來。 玩家不會覺得「這個遊戲壞了」。 玩家會想:「 為什麼這次沒有? 」 然後再頂一次。 為什麼「沒有東西掉下來」沒有讓玩家放棄? 因為設計師在玩家心裡創造了一個「 還沒發生的確定事件 」。 玩家知道「遲早會有東西掉下來」。所以他們願意等待、願意再試一次。 博物館的互動設計也應該這樣。 不是立刻給答案。是讓你相信「答案快來了」,然後讓你一直站在那裡等。 你最後「我要改變做法」 讓我說一個失敗的設計。 一個科技博物館有一面「觸控牆」。牆上有很多按鈕,碰了就會播放影片、發出聲音、變色。 一開始很多小孩去碰。 但大概十五分鐘之後,那面牆就沒人碰了。 為什麼? 因為碰了 100 次,沒有任何一次比另一次更「值得等待」。 每一次都是立刻發生,每一次都是同樣的結果。 沒有任何一件事需要「決定」。 現在讓我說一個成功的設計。 同一個博物館的另一區,有一面「情緒牆」。 你站在牆前,系統會掃描你的臉——不是真的分析情緒,而是給你一個顏色。 每個人的顏色都不太一樣。 但顏色不是立刻出現的。 大概等了兩秒——然後它慢慢浮現出來。 在這兩秒裡,每個站在牆前的人都沒有動。 他們在等。 他們相信顏色一定會出現。但他們不確定會是什麼顏色。 三個馬上可以用的方向 第一:不要立刻給回饋。 加入一個 0.3 到 2 秒的「思考時間」。 讓互動看起來像「系統在決定」,而不只是「系統在檢測」。 壞掉的燈 vs 正在決定的燈——後者讓人更想站在那裡等。 自己試試看:30 行做出「延遲反應」的燈 // p5.js — 試試延遲回饋的感覺 let lights = []; const DELAY = 12 ; // 幀數延遲(約 0.2 秒) function setup () { createCanvas ( 400 , 400 ); for ( let i = 0 ; i < 5 ; i ++ ) { lights . push ({ history : [], lit : false }); for ( let j = 0 ; j < Math . max ( DELAY , 1 ); j ++ ) lights [ i ]. history . push ( false ); } } function draw () { background ( 30 ); let hovered = floor ( mouseX / 80 ); for ( let i = 0 ; i < lights . length ; i ++ ) { lights [ i ]. history . push ( hovered === i ); if ( DELAY > 0 ) lights [ i ]. history . shift (); lights [ i ]. lit = DELAY > 0 ? lights [ i ]. history [ 0 ] : ( hovered === i ); } // 畫燈泡 noStroke (); for ( let i = 0 ; i < lights . length ; i ++ ) { fill ( lights [ i ].

2026-06-28 原文 →
AI 资讯

I Started Building a Premium Template Marketplace — Week 1 Progress, Stack & What's Coming

I've been thinking about this problem for a while. Developers and businesses need quality websites fast — but the options are either overpriced custom builds, outdated templates, or starting from scratch every single time. So I decided to build the solution myself. Softchic is a premium template and ready-made website marketplace — production-ready, built on modern stacks, designed to actually look good. This is Week 1 of building it in public. Why Softchic The market exists. Developers need templates. Businesses need websites. But most template stores are either bloated, outdated, or built on stacks nobody wants to touch in 2026. Softchic is different — every template ships with: Modern stack (Next.js, TypeScript, Tailwind CSS v4) Clean, production-ready code Premium design out of the box The name went through 25+ candidates across multiple languages before landing here. Clean, available, memorable — Softchic. The Stack Framework: Next.js 14 (App Router) Language: TypeScript Styling: Tailwind CSS v4 Components: shadcn/ui Payments: Lemon Squeezy (international) + Paystack (Nigeria) Email: Resend Deployment: Vercel Design language: dark and premium — #0D0D0D background, #2563EB blue, #F97316 orange accents. Week 1 — What Got Built ✅ Waitlist page — designed and ready to deploy ✅ Navbar — responsive, dark-themed ✅ WaitlistForm — wired to Resend for email capture ✅ Brand system — colors, typography, full design identity locked ✅ Payment architecture — Lemon Squeezy + IP-based currency detection via ipapi.co with PPP pricing for global fairness The waitlist goes live very soon. Follow me here on Dev.to — I'll drop the link the moment it's live. Early subscribers get first access when the store launches. The launch goal: 200 waitlist subscribers before opening the store. That's the benchmark. No exceptions. What's Next Waitlist page goes live 🚀 Product listing page Template preview system First upload — a SaaS landing page template The Real Talk Building a marketplace fr

2026-06-28 原文 →
AI 资讯

Anthropic, Google, and Microsoft just built a shared security team for open source. AI is why.

AI can now scan major open-source projects and surface a batch of real, exploitable vulnerabilities in a single pass. That's a defensive win — until you remember attackers have the same tools. Anthropic, Google, Microsoft, OpenAI, AWS, and 15 other organizations aren't waiting for that race to get worse. On Thursday they launched Akrites under the Linux Foundation — a coordinated body built specifically for AI-era vulnerability discovery, remediation, and disclosure in critical open-source software. What actually changed A shared Security Incident Response Team (SIRT) replaces the fragmented model where multiple orgs independently scan the same libraries, file duplicate CVEs, and bury maintainers in noise Patch first, publish second — findings are held under strict confidentiality until a fix is ready and tested Fallback maintainer coverage — if a project has no active maintainer, Akrites steps in so fixes still reach downstream users Funded by Alpha-Omega , an OpenSSF project with $7M+ annual budget backed by the same founding members Three membership tiers — Premier (critical infra operators), General (contributing orgs), Associate (OSS foundations, free) The name comes from the Akritai — Byzantine soldiers who guarded the empire's outermost borders. The places most exposed, most frequently attacked, and most dependent on whoever showed up to defend them. The problem it's actually solving The current coordinated disclosure model was designed around a world where finding vulnerabilities took weeks of expert work. AI has collapsed that timeline. Endor Labs CEO Varun Badhwar put a number on it: thousands of validated open-source vulns surfaced by AI in recent months, with fewer than 5% patched. And the old model makes it worse — every org independently sitting on knowledge of an unpatched flaw is another leak risk before a fix exists. "For years, we have believed finding vulnerabilities was never the hard part. Fixing them was. AI has made that gap impossible to igno

2026-06-27 原文 →
AI 资讯

THE KNOWLEDGE ATOM // Writing for Machines That Read

The Knowledge Atom: Writing for Machines That Read The Hoarder's Reflex Everyone is learning to feed the machine. Bigger context files. Paste the whole document. "Give the AI all the context it needs." The entire industry has converged on a single instinct: when in doubt, add more. It's the wrong instinct. A context window is not a hard drive. It's a desk. And a desk piled with every document you own is not a well-informed desk — it's an unusable one. The model doesn't read better because you gave it more. It reads worse, because the one line that mattered is now buried under a thousand that didn't. Knowledge an AI can't find is knowledge it doesn't have. Knowledge it always carries is weight it always pays. The Two Failures There are only two ways to get this wrong, and almost everyone commits one of them. The first is the dump . You take everything you know and pour it inline — into the system prompt, the master config, the one document to rule them all. It feels thorough. It is the opposite. Every token you add dilutes every token already there. Signal drowns in completeness. The model now has all the knowledge and none of the focus. The second is the orphan . You did the disciplined thing. You wrote a clean, perfect note, in its own file, out of the way. And then nothing pointed to it. No index, no trigger, no path back. The note is immaculate and invisible — which is worse than never writing it, because you believe the knowledge is in the system when in fact it is dead. Both failures share one root: confusing having knowledge with retrieving it. Same Pattern, New Sauce Watch the field long enough and you'll see the same thing return, repainted each time. The "Ralph Wiggum" loop becomes "the agentic loop." Agent teams that talk to each other become a single orchestrator, and then an agent that makes other agents talk to each other. Every cycle sells itself as the breakthrough. Every cycle is a re-skin of the last. Underneath the churn, only one thing actually ch

2026-06-27 原文 →
AI 资讯

The Case for Standardizing the Design of Websites

People complain that websites are all starting to look the same. They are not entirely wrong. A lot of modern websites do look alike. They have familiar navigation bars, predictable layouts, large hero sections, cards, and responsive grids. Buttons look like buttons. Forms look like forms. But, I would argue that's a good thing. Software is supposed to feel familiar. A website is not a painting. It is not a brand mood board. A website is usually a tool that someone is trying to use to accomplish something. They want to read, buy, search, compare, book, or solve a problem. And when people are trying to get something done, originality is not always a virtue. Familiarity Is a Feature Jakob's Law says: Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. Users do not arrive at your website as blank slates. They bring expectations from every other website and app they have used. They expect the logo to link home. They expect navigation to be near the top or side. They expect search to look like search. They expect account settings under an avatar or profile menu. They expect mobile navigation to collapse into a menu. When your site follows those expectations, users can spend their mental energy on the task instead of the interface. That is the point. Good design reduces cognitive load. It does not force users to relearn basic interaction patterns just because a company wanted to look different. Different Is Not Automatically Better There is a common mistake in web design: confusing distinctiveness with quality. A site can be visually unique and still be frustrating to use. It can win design awards while annoying the actual people who need to navigate it. Novelty has a cost. Every unusual layout, hidden interaction, custom scroll behavior, strange menu, or clever visual metaphor asks the user to stop and figure out what is going on. If you are building a portfolio, an art proje

2026-06-27 原文 →
AI 资讯

nginx Event Loop — Complete Lifecycle Reference

nginx Event Loop — Complete Lifecycle Reference A precise, bottom-up reference covering every buffer, syscall, interrupt, and data movement from the moment a TCP packet hits the NIC to the moment a response is sent back. Two concurrent users are used throughout as a concrete example. Table of Contents Foundations — fd and Socket Hardware Layer — NIC, DMA, Interrupts Kernel Structures and All Buffers epoll — How the Worker Waits Efficiently nginx Startup Sequence Complete Request Lifecycle — Two Concurrent Users What Happens While Worker is Busy All Buffers — Master Reference All Syscalls — Master Reference Failure Modes 1. Foundations 1.1 Everything is a File Linux's core philosophy: every I/O resource — files on disk, network connections, pipes, terminals, devices — is represented as a file. This means one unified API ( read , write , close ) works on all of them. The kernel manages the actual resource. Your process holds a token. 1.2 File Descriptor (fd) A file descriptor is just an integer . It is a per-process token that refers to a kernel-managed resource. The kernel maintains a table per process called the fd table — a simple array where the index is the fd and the value is a pointer into the kernel. Process fd table: ┌─────┬───────────────────────────────┐ │ fd │ points to │ ├─────┼───────────────────────────────┤ │ 0 │ stdin │ │ 1 │ stdout │ │ 2 │ stderr │ │ 3 │ listen socket (nginx) │ │ 5 │ User A client connection │ │ 6 │ User B client connection │ │ 12 │ backend connection for User A │ │ 13 │ backend connection for User B │ └─────┴───────────────────────────────┘ 0, 1, 2 are always pre-assigned. Application fds start from 3 upward. The fd is meaningless on its own. It only means something when passed to a syscall — the kernel uses it to look up the real resource. 1.3 Socket A socket is the kernel's internal data structure representing one end of a network connection. Created when your process calls socket() . Lives entirely in kernel RAM. Your process nev

2026-06-27 原文 →
AI 资讯

Network Fingerprinting: Analyzing Default ICMP Structures and Payload Mimicry

Research Context "In advanced network observability, understanding the default behavior of various operating systems is vital for traffic profiling. This article explores the structural differences in ICMP Echo Requests across different OS environments and analyzes how 'Traffic Mimicry' can be used to evaluate the accuracy of Network Intrusion Detection Systems (NIDS)." 1. The Anatomy of an ICMP Signature A standard ICMP Echo Request is not just a simple signal; it carries a specific "fingerprint" based on the operating system that generated it. These fingerprints consist of: Total Packet Size TTL (Time to Live) values Default Payload Content 2. Cross-Platform Discrepancies (Linux vs. Windows) When a system sends a "ping," the default data size ($D$) and the total packet length ($L$) vary significantly between architectures. Feature Linux (Typical) Windows (Typical) Data Size ($D$) 56 Bytes 32 Bytes ICMP Header ($H$) 8 Bytes 8 Bytes Total ICMP Length ($L$) 64 Bytes 40 Bytes Default Payload Timestamp + Data abcdefg... The Linux Signature In most Linux distributions, the ping utility sends 56 bytes of data. When combined with the 8-byte ICMP header, it totals 64 bytes. A key characteristic of Linux ICMP traffic is that the first few bytes of the payload are often occupied by a high-resolution timestamp, used to calculate RTT (Round Trip Time) with microsecond precision. The Windows Signature Windows systems default to a 32-byte data payload. The payload content is static and follows a predictable alphabetical sequence: abcdefghijklmnopqrstuvwabcdefghi. This static nature makes Windows ICMP traffic easily identifiable during deep packet inspection (DPI). 3. The Concept of Traffic Mimicry Traffic Mimicry is a research method used to test the resilience of network filters. By aligning custom communication protocols with the default signatures of a specific OS, researchers can evaluate whether a security appliance is biased toward certain traffic patterns. For example, wh

2026-06-27 原文 →
AI 资讯

Solving IP Endianness in x64 Assembly: A Single-Pass Algorithm

Research Context When doing low-level network programming in Assembly, you experience firsthand the immense chaos running behind the scenes of operations we solve with a single line in high-level languages (Python, C, etc.). While developing the Nested-ICMP-Communication Analysis project, specifically an Encapsulated ICMP framework, I hit exactly this kind of wall: extracting an IP address from a packet header and printing it to the screen in the correct format. Sounds simple, right? However, when x86 architecture and network protocols are involved, seeing 5.1.168.192 instead of 192.168.1.5 on your terminal is extremely common. So why does this happen, and what kind of algorithm did I develop to overcome this issue during the debugging process? Let's dive into the background. The Endianness Problem in Network Headers When you capture a packet coming over the network and read the source/destination IP address inside the sockaddr_in structure, the data arrives in Network Byte Order (Big-Endian) format. This means the most significant byte is stored at the lowest memory address. However, the x86/x64 processor architectures we use rely on Little-Endian (Host Byte Order). When the processor pulls this 4-byte IP data into a register, the reading direction is effectively reversed for our purposes. The result? A packet that arrives as 192.168.1.5 appears scrambled if we try to naively print it from memory. The inet_ntoa() function in high-level languages handles this conversion in the background. But if you are writing a custom sniffer in pure Assembly, you must do this conversion byte by byte yourself. Debugging Hell: The Problems Encountered While writing this conversion, I encountered a few critical issues that cost me hours in GDB (GNU Debugger): Register Clashes: While separating each octet (byte) of the IP address and converting it to an ASCII character (string), you must use the AX register for division operations (DIV). If you don't carefully manage your remainders

2026-06-27 原文 →
AI 资讯

Framework-Specific Env Patterns

Your schema is portable. But each runtime loads environment variables differently. CtroEnv adapters bridge the gap — same validation logic, different data sources. Node.js: process.env + .env Files The @ctroenv/node adapter loads .env files and wraps process.env : import { defineEnv , string , number } from " @ctroenv/core " import { loadEnv } from " @ctroenv/node " const env = defineEnv ( schema , { source : loadEnv () }) loadEnv() resolves files in order: .env — shared defaults .env.{NODE_ENV} — environment-specific ( .env.development , .env.production ) .env.local — local overrides (gitignored) Later files override earlier ones. process.env takes precedence unless override: true . Monorepo Root loadEnv ({ path : " ../.. " }) // look up two directories for root .env Native Node 22+ Node 22 has built-in process.loadEnvFile() . Use native: true to delegate: loadEnv ({ native : true }) // uses process.loadEnvFile() if available Falls back to the custom parser on older Node versions. System Fallback By default, only file values are returned. With system: true , missing keys fall through to process.env : loadEnv ({ system : true }) Standalone Parser Use parseEnvFile() directly for custom file loading: import { parseEnvFile } from " @ctroenv/node " const content = readFileSync ( " .env.custom " , " utf-8 " ) const vars = parseEnvFile ( content ) Handles quotes, multiline values (backslash continuation), interpolation ( ${VAR} ), comments, and export prefix. Vite: Build-Time Validation The @ctroenv/vite plugin validates during the build: // vite.config.ts import { ctroenvPlugin } from " @ctroenv/vite " export default defineConfig ({ plugins : [ ctroenvPlugin ({ schema : " ./src/env.ts " }), ], }) If DATABASE_URL is missing, the build fails — no broken artifacts shipped. Schema Options Pass a file path or inline definition: // File path — imports the module, looks for `schema` export ctroenvPlugin ({ schema : " ./src/env.ts " }) // Inline definition ctroenvPlugin ({ schem

2026-06-27 原文 →
AI 资讯

VERCEL_EXPERIMENTAL_DEV_SKIP_LINK: Stop Dev Link Hangs

TL;DR If the Vercel CLI keeps trying to open a dev link against your Vercel project during local next dev runs, set VERCEL_EXPERIMENTAL_DEV_SKIP_LINK=1 in the shell that launches the dev server, or add it to .env.local at the project root, and restart the process. The flag is opt-in, all-uppercase, and only affects local CLI behaviour. It never reaches your deployed build, and the production runtime on Vercel does not read it. If the CLI still tries to link after a restart, scroll to Debugging when the skip link isn't working for the version-compatibility and process-tree checks that catch the cases the basic setup misses. I have shipped this flag in three production monorepos and the same four mistakes account for almost every "I set it and it did nothing" report I see. What VERCEL_EXPERIMENTAL_DEV_SKIP_LINK actually does VERCEL_EXPERIMENTAL_DEV_SKIP_LINK is an opt-in environment variable the Vercel CLI honours when it runs alongside a local Next.js dev server. Its job is narrow: tell the CLI to skip the step where it would normally reach out to Vercel and create or refresh a dev link against your Vercel project. A "dev link", in the Vercel sense, is a local connection record that lets vercel dev and some Vercel-only local emulators (KV, Postgres, Edge Config) pull real values from a Vercel project. It is useful when you want production-shaped data during development, and a real annoyance when you do not — for example in CI sandboxes, offline laptops, monorepo workspaces that share a single project, or any time you want next dev to behave like a plain Node process without the CLI wrapping it. The variable is shipped under the VERCEL_EXPERIMENTAL_ namespace, which Vercel uses to mark features that can change between CLI versions. That has two practical consequences: the name must be uppercase with underscores, and you should not build production logic on top of it. I treat it like a local-dev knob, set per shell session, and never check it into CI as a hard dependen

2026-06-27 原文 →
AI 资讯

Security Profiles Operator hits v1 with stable APIs and a hardening pass

After several years carrying a beta tag, the Kubernetes Security Profiles Operator went 1.0.0 on June 26, freezing eight CRD APIs and clearing a third-party security audit with no criticals. For cluster admins, the practical effect is small but consequential: the syscall and LSM profile a workload runs under is now declared on APIs that will not move under your feet. The release was announced by Sascha Grunert of Red Hat on the CNCF blog. SPO is the Kubernetes operator that manages seccomp, SELinux and AppArmor profiles as cluster-scoped objects, then attaches them to pods. Until now the value proposition was good and the API was provisional. v1.0.0 nails the second half down. What's actually stable All eight CRDs graduated to v1, including SeccompProfile , ProfileRecording , SelinuxProfile , RawSelinuxProfile , and the AppArmor profile type. Conversion webhooks ship with the release, so a cluster running earlier API versions can roll forward without scheduling downtime. The older versions remain available and are slated for removal in a future release. The migration is on the clock, not on fire. The audit pass came with some shape changes that are worth reading before you upgrade. SelinuxProfile swapped its boolean permissive field for a mode enum with Enforcing and Permissive values, which means any GitOps templates that hard-coded permissive: true need a rewrite. RawSelinuxProfile is now gated by an enableRawSelinuxProfiles configuration flag and a validating admission webhook, so the most privileged path through the operator is off by default. AppArmor inputs run through strict regex validation, raw policy payloads are capped at 500 KB, and the eBPF profile recorder picked up explicit resource limits. Why a cluster team should care The point of an operator like this is to take the profile out of the host's filesystem and into the API. That changes the blast radius of "we shipped a container with no profile at all." With SPO and a workload-attached profile, the r

2026-06-27 原文 →
AI 资讯

Vercel Introduces Eve, an Open-Source Framework for Building AI Agents

Vercel has released Eve, an open-source framework for building, deploying, and operating AI agents in production. The framework uses a filesystem-based project structure to organize agent instructions, tools, skills, subagents, communication channels, and scheduled tasks, enabling developers to define agent behavior while reducing the amount of supporting infrastructure they need to implement. By Daniel Dominguez

2026-06-27 原文 →