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

标签:#opensource

找到 1341 篇相关文章

AI 资讯

Supracorona Login Gate: Simple Access Control for WordPress Sites

For internal websites, client portals, development environments, and WordPress projects that should not be publicly accessible. Not every private WordPress website needs a complete membership system. Sometimes there is no need to manage subscriptions, membership plans, payments, complex user roles, or dozens of content-access rules. Sometimes the requirement is much simpler: The website should only be accessible to logged-in users. That is the reason I created Supracorona Login Gate , a lightweight WordPress plugin that places a simple access gate in front of a website. When the plugin is enabled, logged-out visitors cannot browse protected site content. Instead, they are redirected to the standard WordPress login page or to a custom page selected by the site administrator. The plugin is now published on WordPress.org: Supracorona Login Gate The problem the plugin solves Many WordPress projects are not intended to be publicly accessible at every stage of their lifecycle. They may be: development or staging websites; internal company or organization websites; client portals; private knowledge bases; documentation websites intended only for team members; projects being prepared for launch; demo websites available only to selected users; websites temporarily closed during migration or reconstruction. WordPress provides privacy controls for individual posts, but that is not the same as restricting access to the entire website. Installing a full membership plugin is possible, but it is often far more than the project requires. Such systems may introduce additional database tables, large settings panels, custom profiles, login forms, subscription management, and complex rule engines that will never be used. Supracorona Login Gate has a much narrower responsibility. It is not intended to become a complete membership platform. It is intended to answer one clear question: Is the current visitor logged in? When the answer is yes, the website behaves normally. When the answer

2026-07-06 原文 →
AI 资讯

I built a daily Linux documentation site

I built a daily Linux documentation site I created this site because I've noticed that Linux documentation is generally confusing. What is xybss? xybss is a simple site that publishes Linux documentation every day. No ads No tracking No JavaScript Just plain HTML docs I add at least one new command every day. Who is it for? Beginners learning Linux Anyone who needs a quick reference People who want simple, clean docs Current content Right now, the site covers basic commands like ls and rm. More commands are added daily. Check it out 👉 https://xybss.github.io Feedback is welcome

2026-07-06 原文 →
AI 资讯

Your Terminal Has Amnesia. I Spent My Semester Trying to Fix That.

Your Terminal Has Amnesia. I Fixed it. Every terminal I've ever used has the same problem. You close it. You open it again. It has no idea what happened yesterday. It doesn't remember the command that finally fixed that weird Cargo error after two hours of debugging. It doesn't remember that you always use pnpm instead of npm . It doesn't remember the project you spent all week working on. Every session starts from zero. After a while I realized something strange. My terminal forgot everything. I was the memory. So I started building Luna. It didn't start as an AI project. It started as a frustration. I'm a Computer Science student, and like most developers, I spend a huge part of my day inside a terminal. Not because terminals are exciting. Because that's where software gets built. After a few months I noticed I wasn't struggling with commands. I was struggling with remembering everything around them. Google the same error. Copy the solution. Paste it. Forget it. Repeat three weeks later. Or I'd switch to another project for a few days, come back, and think: "How did I solve this last time?" The terminal had no answer. It never does. History only tells you what you typed. It never tells you why . So I asked a simple question. What if the terminal remembered? Not just command history. Actually remembered. Projects. Errors. Directories. Commands that worked. Commands that failed. Patterns in how I work. That question eventually became Luna. Before writing any AI code, I had to answer another question. What exactly is Luna? A shell? A wrapper? A plugin? A chatbot? I realized pretty quickly I didn't want another tool sitting on top of Bash. I wanted something that actually felt like its own terminal. So Luna became its own shell. Not a plugin. Not an extension. A standalone binary written in Rust. How Luna actually works At a very high level, Luna is surprisingly simple. You │ ▼ Natural Language Input │ ▼ AI Provider (Groq • Gemini • Claude • OpenAI • Ollama...) │ ▼ Sa

2026-07-06 原文 →
AI 资讯

Why Developers Don't Read READMEs

Developers are the world's most efficient skimmers. When someone lands on your repo, they're running a rapid mental triage: What does this do? (5 seconds) Can I run it? (10 seconds) Should I trust it? (5 seconds) If they can't answer all three within 20 seconds, they close the tab and move on. They don't owe you a careful read. They're choosing between your project and ten others. Most READMEs fail the triage test because they're written from the author's perspective, not the reader's. The author knows how it works, so they explain how it works. The reader doesn't know if it works at all, so they need to know what it does first. That's the gap. Let's close it. The README That Passes the 20-Second Test Every high-performing README follows a version of the same structure. The order is not arbitrary — it mirrors the reader's decision-making process. 1. One-Line Description (Not Your Project's Name) The name is already in the repo title. The first line of your README should be a plain-language sentence of what this thing does . ❌ SuperCache v2.0 ✅ A zero-config in-memory cache for Node.js that cuts database eat time by 60%. If your one-liner doesn't tell me what problem you're solving, I'm already skimming toward the exit. 2. A 30-Second "Why This Exists" Paragraph Two to four sentences. What problem does this solve? Who is it for? Why this over the alternatives? This is not a marketing pitch. It's a fast filter. You want the right people to know immediately that this is for them — and the wrong people to know it's not. 3. Demo / Screenshot First — Before Installation This is the most skipped section in most READMEs. It shouldn't be. A GIF, screenshot, or three-line code output does more work than five paragraphs of description. Show me what success looks like before you tell me how to get there. If I can see that your output solves my problem, I'll read every word of your installation guide. 4. Installation — Zero Assumptions Assume your reader is smart but unfamiliar

2026-07-06 原文 →
AI 资讯

FROST 的治理哲学:为什么每个 Agent 系统都需要一部宪法

FROST 的治理哲学:为什么每个 Agent 系统都需要一部宪法 "细胞会死,但谱系会存续。Agent 会消亡,但宪法会传承。资产会永存。" 在 AI Agent 框架百花齐放的 2026 年,我们见证了一个有趣的现象:框架越来越多,治理却越来越缺失。LangChain 给了你工具链,CrewAI 给了你角色扮演,AutoGen 给了你对话——但没有人回答一个关键问题: 当你的 Agent 家族有十代、百代,谁来保证它们的行为不越界? 这就是 FROST 要解决的问题。 一、一个被忽视的问题:Agent 治理真空 想象这样一个场景:你构建了一个 Agent 系统,它帮你处理客户咨询、自动写报告、管理财务。一开始只有 3 个 Agent,你都能监控。三个月后,Agent 数量变成了 30 个——有些是你创建的,有些是 Agent 自己创建的。 问题来了: 某个 Agent 开始访问不该访问的数据 某个 Agent 创建的子 Agent 继承了一份不该继承的权限 某个 SOP 工作流在运行中被人悄悄修改了 这不是科幻场景,这是今天 Agent 系统正在发生的事。 根本原因 :现有框架的"治理"要么是提示词级别的软约束("请你不要访问这些数据"),要么是事后的日志审计。没有一个是代码级别、架构级别的硬约束。 FROST 的设计哲学是: 治理必须是架构的一部分,而不是补丁。 二、FROST 的宪法模型:四层治理 FROST 把治理拆解为四个层次,每一层都有对应的代码实现: 第一层:只读继承——权限的代码级强制 在大多数框架中,Agent 之间的数据共享靠的是"约定"。FROST 用的是 HierarchicalStore ——一种层级化记忆容器: class HierarchicalStore : """ 层级化记忆存储。 祖先 Store 对后代只读——后代可以继承,但不能篡改。 """ def __init__ ( self , data = None , parent = None , readonly = False ): self . _data = data or {} self . _parent = parent self . _readonly = readonly # 关键:只读标记 def save ( self , key , value ): if self . _readonly : raise PermissionError ( " 只读 Store 禁止写入 " ) self . _data [ key ] = value def load ( self , key , default = None ): if key in self . _data : return self . _data [ key ] if self . _parent : return self . _parent . load ( key , default ) return default 注意 readonly 参数。当一个 Agent 创建子 Agent 时,子 Agent 对父 Agent 的 Store 是 只读的 。这不是提示词告诉 Agent "请你不要修改",而是代码直接抛出异常。 这意味着 :即使 LLM 产生了幻觉,试图越权写入,代码层面也会拒绝执行。 第二层:SOP 宪法校验——工作流的可审计性 在 FROST 中,SOP 不是随便定义的步骤列表,而是经过祖辈审核的"宪法文本": def validate_sop ( ancestor_sop , descendant_sop ): """ 祖辈验证后代的 SOP 是否合规。 检查点: 1. 后代 SOP 的步骤不能超出祖辈定义的边界 2. 后代 SOP 不能调用未授权的 Skill 3. 后代 SOP 的数据访问不能超出权限范围 """ # 检查 1:步骤边界 for step in descendant_sop . steps : if step not in ancestor_sop . allowed_steps : raise SOPValidationError ( f " 步骤 { step } 超出祖辈定义的边界 " ) # 检查 2:Skill 授权 for skill in descendant_sop . required_skills : if skill not in ancestor_sop . authorized_skills : raise SOPValidationError ( f " Skill { skill } 未获授权 " ) return True 这意味着 :任何后代 Agent 想要执行的工作流,都必

2026-07-06 原文 →
AI 资讯

Sakana Fugu: How Collaborative AI is Changing the Game

# Sakana Fugu: The Multi-Agent AI System That Works Like a Team We’ve all been there: copy-pasting a prompt from ChatGPT to Claude, and then to Gemini, trying to find which AI gives the best answer. Different AI models have different strengths. Some are excellent programmers, some write beautifully, and others are master logicians. But constantly switching between them is slow and frustrating. Sakana AI has introduced a brilliant solution: Sakana Fugu . Fugu is a multi-agent AI system that bundles multiple frontier models into a single, seamless package. To you, it looks like a single chatbot. But behind the scenes, it acts as a project manager, coordinating a team of top-tier AI models to solve your task. What is Sakana Fugu? Sakana Fugu is a collaborative AI framework. Instead of relying on one massive AI model to do all the work, Fugu orchestrates a pool of specialized models (such as GPT-5, Claude Opus, and Gemini Pro). When you give Fugu a complex, multi-step prompt, it: Analyzes the task and breaks it down into steps. Assigns specialized roles (like researcher, coder, and editor) to different AI models. Passes the work back and forth between them until the final, polished result is ready. By working as a team, these models achieve far better results than any single AI could on its own. The Secret Sauce: Teamwork Over Size Fugu’s intelligent coordination is based on two core concepts presented at the ICLR 2026 conference: 1. The Manager (TRINITY) Think of TRINITY as the manager of the team. It is a compact coordinator model that assigns specific roles to the worker LLMs. For example, it might tell Gemini to generate the initial code, tell Claude to find the bugs, and tell GPT to write the user documentation. They collaborate seamlessly without needing to merge their code bases. 2. The Conductor The Conductor acts as the communication network designer. It figures out the best way for the worker AIs to talk to each other for your specific question. It writes cust

2026-07-06 原文 →
AI 资讯

CNTRL by Omnikon Org Selected for Elite Coders Summer of Code (ECSoC) 2026

🚀 CNTRL by Omnikon Org Selected for Elite Coders Summer of Code (ECSoC) 2026 Building an AI-first browser for developers—and taking the next step through ECSoC 2026. Open source has always been one of the best ways to learn, collaborate, and build software that makes a difference. Today, I'm excited to share a milestone that means a lot to our team. Our project CNTRL , developed by Omnikon Org , has officially been selected for Elite Coders Summer of Code (ECSoC) 2026 ! 🎉 This selection gives us an incredible opportunity to collaborate with contributors worldwide and continue building a browser that's designed from the ground up for developers. 💡 Why We Started CNTRL Every developer has experienced this workflow: Open documentation Search GitHub Ask an AI assistant Open Stack Overflow Copy code Switch back to the IDE Repeat... The browser has become the center of development, but it still isn't designed for developers. We wanted to change that. Instead of building another browser, we started building one where AI is part of the experience—not another tab. 🌐 What is CNTRL? CNTRL is an AI-powered browser built for developers. Our vision is to create a browser that understands how developers work and helps them stay focused. Some of the ideas we're working toward include: 🤖 AI-assisted coding 📖 Context-aware documentation 💬 Built-in developer assistant ⚡ Faster research workflows 🔌 Extensible architecture 🌍 Community-driven open source The project is still evolving, and ECSoC gives us the perfect platform to accelerate its development. 🏆 Selected for ECSoC 2026 Being selected for Elite Coders Summer of Code 2026 is a huge milestone for our organization. It means we'll have the opportunity to: Collaborate with talented contributors Improve the project's architecture Build exciting new features Learn from the community Grow CNTRL into an even better developer tool We're incredibly thankful to the ECSoC team for believing in our vision. 🌍 About Omnikon Org Omnikon Org is

2026-07-06 原文 →
AI 资讯

The LLM Cost Death Spiral (And How I Got Out of It)

There's a pattern playing out across indie hacker forums, engineering blogs, and Discord servers right now: a founder builds a product on GPT-4-class models, ships it, gets traction — and then opens a bill that makes them question the whole business model. LLM costs have a nasty habit of scaling linearly (or worse) with usage, right at the moment a product starts succeeding. In response, a growing body of developer tutorials is focused on one goal: keeping the intelligence, dropping the invoice. Think of it like the early days of cloud hosting. Companies over-provisioned expensive dedicated servers until autoscaling and cheaper commodity infrastructure made "pay for what you use, and use less of the expensive stuff" the default architecture. The LLM ecosystem is going through its own version of that shift right now, and DeepSeek has become the poster child for the "just as capable, dramatically cheaper" alternative to OpenAI's premium models. Migrating With Minimal Friction The first core question developers are wrestling with is deceptively simple: how do you swap out a model provider without rewriting your whole application? The answer that keeps surfacing is API compatibility layers . Many cost-effective providers, including DeepSeek, expose an API that mirrors OpenAI's own request/response format almost exactly. That means in a lot of codebases, migration isn't a rewrite — it's a find-and-replace of a base URL and an API key. # Before: pointed at OpenAI client = OpenAI ( api_key = " sk-openai-... " , ) # After: same SDK, same code, different provider client = OpenAI ( api_key = " sk-deepseek-... " , base_url = " https://api.deepseek.com/v1 " ) That's it, in the simplest case. Because the OpenAI Python SDK just talks HTTP under the hood, any provider that speaks the same "dialect" can slot in without touching your prompt logic, your function-calling schemas, or your downstream parsing code. The real friction shows up in the details: subtle differences in how mode

2026-07-05 原文 →