@MrStickman

At Foxglove, we collaborated with Aditya Kamath, resulting in another blog post in his ROS 2 LeKiwi series, this time covering the integration of SLAM and Nav2. This blog post should be relevant to anyone wanting to integrate Nav2, even if they don't have a holonomic platform. If you find this kind of content useful, let us know, and we will keep it coming! submitted by /u/arewegoing [link] [Kommentare]

Nature: Outplaying elite table tennis players with an autonomous robot (Published: 22 April 2026): https://www.nature.com/articles/s41586-026-10338-5 YouTube Sony AI: Ace vs. Kihara | Pro Match Highlights | Sony AI Table Tennis Robot: https://www.youtube.com/watch?v=TwkDm2H6ft8 From 链上小财女 on 𝕏: https://x.com/Zoozo2025/status/2064998917394374930 submitted by /u/Nunki08 [link] [Kommentare]

Hey everyone, I am planning out a new open-source infrastructure project and want to get some brutal feedback on the architecture and use-case validity from people running high volume LLM workloads in production. The Problem: Python-based proxies/gateways introduce too much latency overhead for real-time streaming agent steps or fast UI completions. Additionally, centralized semantic caching still suffers from cross-region network latency (e.g., London to us-east-1), and enterprise API costs remain a massive bottleneck for repetitive/predictable user queries (like customer support or structured data extraction). The Proposed Architecture: Instead of a heavy centralized gateway, the goal is to build a lightweight, zero-dependency semantic cache running directly at the CDN Edge using WebAssembly (WASM) compiled from Rust. The flow looks like this: Inbound Prompt: Hits the edge node closest to the user (e.g., Cloudflare Workers / Fastly Compute). Edge Embedding: The Rust/WASM module intercepts the raw text prompt and instantly generates a vector using an edge-native lightweight model (e.g., bge-small-en-v1.5). Similarity Index Check: It performs a fast cosine similarity check against an edge vector database (like Cloudflare Vectorize) to find the nearest semantic neighbor. Cache Hit: If similarity >= threshold (e.g., 0.88), it pulls the full generated response text from an edge KV store and returns it in ~5ms. The main LLM provider is never billed or touched. Cache Miss: It proxies the streaming request to OpenAI/Anthropic/vLLM, streams it back to the client, and asynchronously updates the edge vector index and KV store. Why Rust/WASM? To achieve sub-millisecond execution overhead on the proxy itself, avoid garbage collection pauses, and maintain a tiny memory footprint suitable for edge runtime constraints where traditional databases or Python scripts cannot run. My Questions for the Community: For those running LLMs in production (especially customer support, internal RAG, or autonomous agents), what is your realistic semantic cache hit rate? Is the power law of repetitive queries high enough in your domains to justify this? What are the biggest footguns with semantic caching at the edge? (e.g., Cache invalidation strategies, handling system prompt updates, or drift in embedding models). Would you actually use a drop-in open-source template/CLI that lets you spin this up on your own edge account, or do you prefer centralized API gateways? submitted by /u/Real-Huckleberry-934 [link] [Kommentare]

One of our great triumphs and economic advantages is fading away

MCP standardizes how AI applications expose and call tools, but it does not solve tool relevance. As connected servers grow, tool definitions become a context tax that can hurt cost, latency, and accuracy.

Since Colossus 1 launched in August 2024, the record for the largest AI data center has doubled every seven months. Epoch AI's breakdown of single-site compute capacity trends through 2028.

We didn't evolve to live our lives as terminals of a digital hive-mind.

Just curious because everyone talks constantly about the bigger coins but there are absolutely opportunities in alt coins that have much larger short term gains compared to the whales of the market. submitted by /u/TartarusXTheotokos [link] [Kommentare]

Published Jun 11, 2026 Launching supso: the CLI for paid licensing with Supported Source A command-line tool for paid licensing, so project owners get paid Today we're introducing supso, the official command-line tool for Supported Source. Supported Source helps maintainers get paid, by selling paid licenses to their projects. But how will companies certify they bought a license? The answer is supso: companies can use supso to sync their license certificates from our website to their local file system. You can find it on GitHub at github.com/SupsoOrg/supso. What supso does Supported Source projects are commercial open source: hobbyists and evaluators can use them for free, but companies pay for a license. A license is just a certificate that cryptographically proves your organization is allowed to use a given project. supso is the tool that manages those certificates on disk and verifies them, so your projects work and your builds stay green. The mental model is simple: certs is what you have installed, projects is what you're licensed for, and verify is the scriptable yes/no gate you can drop into CI or a build script. Getting started supso ships as a single static binary, so installing it is a one-liner whichever way you prefer: brew install SupsoOrg/tap/supso # Homebrew cargo install supso # or from crates.io Once it's installed, sign in and pull your certificates down: supso login # sign in via the browser supso sync # pull your licensed certificates into ~/.supso supso certs # see what's installed After that, your licensed projects just work. You can also use supso verify to double check that the certs you've synced are verifying. Built for deploys Verification happens offline at runtime. When you ship a service that embeds a Supported Source project, the supso-project library checks the license certificate locally. There's no network call or login flow in production. You provision the certificate the same way you'd provision any other deploy secret, either by mounting it into a directory and pointing SUPSO_LICENSE_PATH at it, or by baking it into your build artifact: supso sync --dir ./.supso/license_certificates # at runtime: SUPSO_LICENSE_PATH=/app/.supso/license_certificates Because a certificate identifies your organization, you can treat it like your existing secrets. Just keep it out of public source control, and don't run the interactive login flow inside a deployed service. Why this matters The point of supso isn't really the certificates. It's what they make possible. Open source built the modern world, and it did so with almost no financial support. The people who maintain the libraries everyone depends on are, with very few exceptions, not paid for it. They do it on nights and weekends until they burn out and walk away, at which point the multi-billion-dollar companies depending on their work scramble to find someone else to do it for free. It's the tragedy of the commons, and it's a structural problem, not a personal one. Supported Source exists to fix that. Companies are happy to pay for software that's reliable, supported, and secure. They do it all the time. What's been missing is a good way to do that with their dependencies. Supported Source is the missing piece: it's how a company licenses a project, and it's how the revenue from that license flows back to the maintainer who built it. If you maintain a project that companies depend on, that means you can get paid for it. The license fees companies pay to use your project go to you, so the work everyone relies on is funded. This helps a project stay healthy because there's an actual business model behind it. If you maintain a project companies depend on, get in touch to see how we can help you get paid for it. Open source built the world. Supported Source helps the people who build it.