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

标签：#rust

找到 309 篇相关文章

开源项目

🔥 Zackriya-Solutions / meetily - Privacy first, AI meeting assistant with 4x faster Parakeet/

GitHub热门项目 | Privacy first, AI meeting assistant with 4x faster Parakeet/Whisper live transcription, speaker diarization, and Ollama summarization built on Rust. 100% local processing. no cloud required. Meetily (Meetly Ai - https://meetily.ai) is the #1 Self-hosted, Open-source Ai meeting note taker for macOS & Windows. | Stars: 13,224 | 132 stars today | 语言: Rust

2026-07-02 原文 →
AI 资讯

Agent memory and context that never leaves your machine

Most "agent memory" and "agent context" tools today require sending your data to someone else's cloud. If you operate in a regulated, air-gapped, or simply privacy-conscious environment, that rules them out before you've even tried them. I build the opposite: two MIT-licensed, local-first MCP servers that do this work entirely on your own hardware. The problem Agent memory and context assembly are converging on a cloud-only default. That's a non-starter for defense, healthcare, finance, legal, and any team that can't or won't let agent context leave their VPC. It's also just slower and less deterministic than it needs to be: agents re-discover the same facts about your repo and services every session, burning tokens and turns before doing any real work. Mimir: persistent memory, fully offline Mimir is a single ~8MB Rust binary. It encrypts everything at rest with AES-256-GCM, and it works with no API key, no model download, and no network access at all, because the embeddings used for dense search are bundled directly into the binary. It's bi-temporal: every fact carries a validity window, so you can query memory "as of" any past point and supersede facts without deleting history. 43 MCP tools, SQLite + FTS5 hybrid search under the hood. One honest tradeoff worth naming: the FTS5 index needed for fast keyword search currently sits over plaintext, even though the underlying record is encrypted at rest. We're upfront about this in the docs rather than overstating the encryption story. Perseus: compile-before-context Perseus takes a different approach to context than runtime tool-call discovery. Instead of letting an agent rediscover your git state, running services, and test status through a chain of tool calls every session, it compiles all of that into a ready briefing the moment a session starts. The result is deterministic and byte-stable: the same repo state always produces the same compiled context. Honest, reproducible benchmarks On paraphrased queries, Mimir's

2026-07-01 原文 →
AI 资讯

Can you build observability ingestion on S3 alone — no Kafka, no disks, no coordination layer?

TL;DR — A Kafka + Flink + OTel ingestion pipeline cost us ~$700–800/month at 10 MB/s. We rebuilt it as a single binary where the data, the write-ahead log, and the Iceberg catalog all live in S3 alone — no Kafka, no local disks, no coordination service — for ~$100/month . Here's the design. Self-hosted observability sooner or later runs into the problem of storing state. Query load, CPU, and data volume can all be handled by scaling out, but the stateful layer is something you have to operate by hand. At first it's almost unnoticeable: a disk degrades here, replication falls behind there, a recovery hangs somewhere else. As the data grows, incidents stop being one-offs and start to recur. At some point your observability stack - whether it's Grafana Loki, Elastic, or ClickHouse - starts demanding the same attention as a full-blown database that you're on the hook for. Kubernetes operators cover some of these cases, but operating the state is still on you. Managed solutions take that burden away and bring their own: rising costs, ingestion-pipeline constraints, and limits on retention and cardinality. But if you'd rather not sign up for the constant operational grind - or live with the constraints of managed solutions - it's worth asking: can we take the stateful part out of operations entirely? Storage and format The first candidate for offloading storage responsibility is Amazon S3. S3 gives you what local disks can't: fault tolerance and practically unlimited scale, with no storage to manage yourself. It isn't free, though: data-access latency goes up, and you pick up separate costs for API operations. For OLTP workloads that's a dealbreaker. For observability workloads - which are dominated by sequential writes and analytical reads - these trade-offs are often acceptable. At first glance, this problem is already solved. Loki , for example, uses S3 as its primary storage. But according to Loki's public documentation (v3.6.x) at the time of writing, Loki doesn't re

2026-07-01 原文 →
AI 资讯

Galfus Script MVP is complete

Galfus Script has reached its first MVP milestone. Galfus is an experimental programming language written in Rust, designed around a typed VM-first execution model, compact .gfb artifacts, deterministic module/workspace resolution, and an ownership model based on anchors, edges, and weak observers. The MVP goal was not to build a full ecosystem yet. The goal was to prove the complete local execution pipeline: txt .gfs source -> lexer and parser -> resolver -> type checker and semantic analyzer -> ownership check -> MIR lowering -> bytecode emitter -> Galfus Module Image -> .gfb serialization -> VM interpreter execution https://github.com/vulppi-dev/galfus-script/discussions/10

2026-06-29 原文 →
AI 资讯

Presentation: Million PDFs: Building a Modern Document Infrastructure with Rust and Typst

Erik Steiger discusses the operational pain of legacy PDF generation in regulated banking and manufacturing. He explains how transitioning from resource-heavy engines like Puppeteer and LaTeX to a serverless Rust architecture powered by Typst can drop render latencies below 2ms. He shares how applying Git and Docker concepts to template registries ensures ironclad compliance and rapid debugging. By Erik Steiger

2026-06-29 原文 →
AI 资讯

Introducing Crawlberg v1.0.0

We're upgrading Crawlberg to a new version: Crawlberg v1.0.0. It builds on the previous kreuzcrawl. It declares the public API frozen under the new project name. All technical features below shipped in v0.3.0 (2026-06-23); v1.0.0 is a stability declaration and rename, not a new feature release. The four production-facing changes most likely to require operational action: Package and env var rename - every artifact identifier has changed; see the migration table. SSRF defense is now on by default - internal crawl targets (localhost, RFC 1918, cloud metadata) will fail without CRAWLBERG_ALLOW_PRIVATE_NETWORK=1 . CrawlError::WafBlocked is now a struct variant - exhaustive match arms will not compile until updated. max_retries semantics changed - off-by-one fixed; max_retries=3 now produces exactly 3 retries. Precompiled binaries cover Linux (x86_64/aarch64), macOS (ARM64 and x86_64), and Windows x64. Homebrew bottles and Docker images on GHCR are also available. What Is Crawlberg? Crawlberg is a web crawling engine written primarily in Rust that exposes a single consistent API across 14 language runtimes. It handles HTTP transport, JavaScript rendering, robots.txt compliance, per-domain rate limiting, SSRF safety, and structured extraction. Extension points ( Frontier , RateLimiter , CrawlStore , EventEmitter , ContentFilter , WafClassifier , ProxyProvider ) are injectable traits; wire in your own frontier, storage backend, or proxy pool without forking the engine. A single scrape() call returns text, metadata, links, images, assets, JSON-LD, Open Graph tags, hreflang, favicons, headings, response headers, and clean HTML→Markdown. When a site requires JavaScript, the optional headless browser tier handles it transparently. v1.0.0 promotes v1.0.0-rc.2 and freezes the public API under the new project name. The features described in the sections below represent the platform that 1.0.0 declares stable; they shipped in v0.3.0. What v1.0.0 Declares Stable These capabilities

2026-06-29 原文 →
← 上一页 下一页 →