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

标签：#opensource

找到 2424 篇相关文章

AI 资讯

Learn Trapping Rain Water, Top K Frequent and Selection Sort with Step-by-Step Visualization in DSA View View 👀👀

Hoi hoi! I’m @nyaomaru , a frontend engineer who has been obsessed with ramen lately. 😸🍜 Have you used DSA View View already? 👀👀 I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀) Features a timeline to step backward mid-loop nyaomaru nyaomaru nyaomaru Follow Jul 15 I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀) # showdev # typescript # dsa # react 64 reactions 33 comments 7 min read DSA View View allows you to understand DSA by visualizing how your implementation actually runs. In the previous articles, we looked at problems like: Two Sum Binary Search Bubble Sort Valid Parentheses Reverse Linked List Maximum Depth of Binary Tree Number of Islands Invert Binary Tree Course Schedule Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort) Visualizing execution logic changes mental models nyaomaru nyaomaru nyaomaru Follow Aug 19 Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort) # dsa # typescript # opensource # learning 51 reactions 9 comments 7 min read Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in DSA View View 👀👀 Curated progression from stacks to recursion nyaomaru nyaomaru nyaomaru Follow Aug 26 Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in DSA View View 👀👀 # typescript # algorithms # opensource # dsa 77 reactions 5 comments 9 min read Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step Visualization in DSA View View 👀👀 Readers praise the recursive swap explanation nyaomaru nyaomaru nyaomaru Follow Sep 2 Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step Visualization in DSA View View 👀👀 # typescript # dsa # opensource # webdev 64 reactions 13 comments 12 min read This time, let's try three more problems: Trapping Rain Water Top K Frequent Elements Selection Sort Thes

2026-09-09 原文 →
AI 资讯

DeepSeek Harness (DSH) vs Pi Agent: Everything you need to know

DeepSeek released its own agent harness this August. It crossed 66k stars in about a day (yes, sir!) and went over 200k by early September. That is already pretty crazy for something that is still a developer preview. But while researching this post, I found something much more interesting. DeepSeek Harness actually uses Pi's model layer to connect to models outside DeepSeek. Yep. The new agent runtime from DeepSeek uses Pi under the hood for part of its model support. And Tianyi Cui , who leads the Harness project, has publicly said Pi is a favourite daily driver for many people at DeepSeek. Lol. That makes this comparison way more fun because they agree on quite a lot. Both think the harness matters, both are open source, both let you change a lot of the runtime, and both try to avoid locking you into one model. But they take the idea in very different directions. Pi gives you a tiny coding agent with four tools and lets you build from there. DeepSeek Harness gives you a full agent runtime where even the agent loop itself can be swapped. This is going to be an interesting one. Stick to it! TL;DR Category Pi DeepSeek Harness Winner Real tool use in our eval 21/30 passed 20/30 passed Pi Cost per shared success $0.031 $0.028 DeepSeek Harness Median time per task 362.9s 252.1s DeepSeek Harness Avg runtime tokens in our run 924,990 88,562, with a catch DeepSeek Harness Simplicity Four main tools and a tiny prompt Much larger runtime with 53 built in tools Pi Deep runtime control Powerful TypeScript extensions around a small core Even the agent loop can be replaced DeepSeek Harness Model support 25+ providers and very easy switching Broad support, partly through Pi's model layer Pi Local models Ollama, vLLM, and custom providers are well supported Possible, but needs more setup Pi Sandbox None in the core Three built in sandbox modes DeepSeek Harness Session inspection Very readable session tree Full append only trajectory and replay DeepSeek Harness Daily use Very smal

2026-09-09 原文 →
AI 资讯

Fail-open is the default failure mode of agent hooks

Fail-open is the default failure mode of agent hooks I'm the author of Handrail, a free, MIT-licensed hook pack for Claude Code and other agent-CLI hook systems. Handrail works with Claude Code and other agent CLIs in plain text only; it is not affiliated with, endorsed by, or a product of Anthropic. This post is about one specific design bug I keep finding in hook scripts, including early drafts of my own: they fail open. What "fail open" means here An agent-CLI hook is a small program the harness calls before (or after) a tool call — a shell command, a file write, a publish step — and asks, in effect, "should this be allowed?" The hook's job is to answer allow, ask, or deny. The interesting question isn't what the hook does when it works. It's what the harness does when the hook doesn't answer at all. Malformed JSON on stdin. An unhandled exception three lines into the script. A timeout because the hook shelled out to something slow. A config file that doesn't parse. In each of these cases, the hook process either exits with no usable decision, or crashes before it prints one. What happens next depends entirely on what the calling harness does with a hook that didn't answer — and a lot of hook scripts never think about that side of the contract, because the code path for "I don't know, so deny" is extra code nobody wrote until something forced the question. Independent write-ups on this exact gap describe it as a live, common problem across shared hook scripts, not a hypothetical (dev.to/redpa, "Your Claude Code hooks probably fail open — here's why that's dangerous," accessed 2026-09-08). The failure mode matters because of when it fires: exactly when the hook is under the most stress — weird input, a broken environment, a partial config — which correlates with exactly the moments a guardrail is most needed. The pattern: always answer, and the default answer is deny The fix isn't clever. It's structural: Wrap the whole hook body so that any uncaught error — parse

2026-09-09 原文 →
AI 资讯

Four problems you inherit the moment your SQL client runs on a server

A desktop database client makes two demands nobody writes down: every laptop has to reach the production network, and every laptop has to hold a copy of every credential. Move the client onto a server next to the data and both demands disappear. The credential lives in one place instead of sixty. The network path becomes a deployment topology instead of a VPN grant per person. That is the trade. This post is the invoice. Because the thing you just built is no longer a client. It is a multi-tenant network service holding every database connection your team owns, and it has four problems a desktop app never had. We hit all four building LibreDB Studio, and got two of them wrong on the first attempt. 1. The trust boundary moves inside your own process On a laptop the OS user is the authorization boundary. Server-side, one process holds every connection, and something inside it has to decide who is asking. The obvious answer is middleware: run before every route, verify the session cookie, redirect the rest. We have that. The part worth saying out loud is that it is not the boundary. Look at what a Next.js matcher actually is: export const config = { matcher : [ " /((?!api/storage/config|_next/static|_next/image|.* \\ ..*).*) " ], }; That .*\..* exempts any path containing a dot. It is there so static assets skip the pipeline, and it is a perfectly good optimisation. It is a terrible boundary. So every route that reaches a database or a model provider verifies its own caller again through one shared guard. The edge exists to make the common case cheap, not to be trusted. That distinction paid off the first time we designed a seam where something legitimate could not present a session. Our agent runtime has a callback that asks the server to resume a long-running query session. Its caller is a durable transport, not a person, so it has no cookie by construction. Nothing mints one in production yet, because no queue produces a drive delivery so far, and the credential exi

2026-09-09 原文 →
AI 资讯

My AI Remembered Everything Important. It Forgot What I Did Last Night.

I built an AI memory system inspired by one thing brains seem to do well: reinforce associations through use. Most AI memory is a notes file with search. It stores documents and retrieves them based on text similarity. I wanted something that behaved more like actual memory. I wanted paths that strengthen when you use them and fade when you do not. So mycelium stores memories as nodes with connections. This is not just a graph database. It is an active system. When you recall a few things together enough times, the link between them gets stronger. This is a Hebbian approach to storage. If two concepts appear in the same context repeatedly, the system assumes they belong together. Ignore a memory long enough and it decays. This decay is deliberate. Forgetting is a feature, not a bug. It keeps the system from becoming a static archive of everything you have ever typed. The core mechanism relies on SQLite with FTS5 for keyword matching. The connection graph lives on top of that. You might hear people talk about vectors for everything. Vectors exist as a secondary signal in mycelium. They are not the primary recall mechanism. The primary driver is this connection graph and the frequency of access. Recall is pattern completion. A query does not just match text against a document body. It fires the matching memories and spreads activation through their connections. A partial cue pulls back the whole cluster that tends to light up with it. The memories that win are the ones that are strongly connected and frequently accessed. I call those the hubs. Loading context at the start of a session deliberately returns the hubs. On average, the hubs are the load bearing knowledge. They are the concepts you have referenced most often. If you are building an agent that needs to know who you are, what you have been working on for weeks, or what your general preferences are, the hubs are the right answer. This is a feature. It is also the bug. I hit the issue during normal development

2026-09-09 原文 →
AI 资讯

TrustGraph 2.8: Async Infrastructure, Hybrid Retrieval, Structured Output, and a Plugin-Based Workbench

TrustGraph 2.8 is available now, with a major upgrade to the platform foundation for enterprise knowledge and AI systems. This release focuses on a practical problem: AI applications must remain reliable when they grow beyond a single demo, a single document library, or a small number of workspaces. That means scalable messaging, dependable retrieval, typed model outputs, observable services, auditable decisions, and an interface that can adapt to different domains. Async pub/sub: removing a scaling bottleneck TrustGraph has completed its migration from thread-per-consumer pub/sub to an asynchronous architecture. In the previous model, a deployment with many workspaces and flows could consume hundreds of threads. TrustGraph 2.8 replaces that design with configurable async receive and send pools. Async support now covers: Apache Pulsar through pulsar.asyncio.Client RabbitMQ through aio-pika Kafka through aiokafka The API gateway and reverse gateway For operators, this means a much stronger basis for multi-workspace deployments. For custom processor developers, it also means migrating extensions to the async model. Hybrid retrieval for Document RAG Document RAG now combines two complementary retrieval strategies: Vector similarity for conceptual relevance. BM25 keyword retrieval for exact terms, names, identifiers, and domain-specific phrases. TrustGraph merges the results with Reciprocal Rank Fusion (RRF). The first keyword-index implementation uses SQLite FTS5 and scopes indexes by workspace and collection. If keyword retrieval is unavailable, TrustGraph degrades gracefully rather than blocking retrieval entirely. Hybrid retrieval is especially useful for enterprise content, where a user might search semantically in one query and need an exact product code, legal term, technical error, or named entity in the next. Native structured LLM output TrustGraph 2.8 carries JSON schemas from prompt definitions through the completion layer into provider-native structured-outp

2026-09-08 原文 →
下一页 →