Show stories

I built an MCP server that gives any local LLM real Google search and now vision capabilities - no API keys needed.

  The latest feature: google_lens_detect uses OpenCV to find objects in an image, crops each one, and sends them to Google Lens for identification. GPT-OSS-120B, a text-only model with
   zero vision support, correctly identified an NVIDIA DGX Spark and a SanDisk USB drive from a desk photo.

  Also includes Google Search, News, Shopping, Scholar, Maps, Finance, Weather, Flights, Hotels, Translate, Images, Trends, and more. 17 tools total.

  Two commands: pip install noapi-google-search-mcp && playwright install chromium

  GitHub: https://github.com/VincentKaufmann/noapi-google-search-mcp
  PyPI: https://pypi.org/project/noapi-google-search-mcp/

How I reverse-engineered Google Analytics and built my own analytics service for personal projects.

We needed a JS-first WYSIWYG DOCX editor and couldn't find a solid OSS option, most were either commercial or abandoned.

As an experiment, we gave Claude Code the OOXML spec, a concrete editor architecture, and a Playwright-based test suite. The agent iterated in a (Ralph) loop over a few nights and produced a working editor from scratch.

Core text editing works today. Tables and images are functional but still incomplete. MIT licensed.

Hi HN,

AI agents that can run tools on your machine are powerful for knowledge work, but they’re only as useful as the context they have. Rowboat is an open-source, local-first app that turns your work into a living knowledge graph (stored as plain Markdown with backlinks) and uses it to accomplish tasks on your computer.

For example, you can say "Build me a deck about our next quarter roadmap." Rowboat pulls priorities and commitments from your graph, loads a presentation skill, and exports a PDF.

Our repo is https://github.com/rowboatlabs/rowboat, and there’s a demo video here: https://www.youtube.com/watch?v=5AWoGo-L16I

Rowboat has two parts:

(1) A living context graph: Rowboat connects to sources like Gmail and meeting notes like Granola and Fireflies, extracts decisions, commitments, deadlines, and relationships, and writes them locally as linked and editable Markdown files (Obsidian-style), organized around people, projects, and topics. As new conversations happen (including voice memos), related notes update automatically. If a deadline changes in a standup, it links back to the original commitment and updates it.

(2) A local assistant: On top of that graph, Rowboat includes an agent with local shell access and MCP support, so it can use your existing context to actually do work on your machine. It can act on demand or run scheduled background tasks. Example: “Prep me for my meeting with John and create a short voice brief.” It pulls relevant context from your graph and can generate an audio note via an MCP tool like ElevenLabs.

Why not just search transcripts? Passing gigabytes of email, docs, and calls directly to an AI agent is slow and lossy. And search only answers the questions you think to ask. A system that accumulates context over time can track decisions, commitments, and relationships across conversations, and surface patterns you didn't know to look for.

Rowboat is Apache-2.0 licensed, works with any LLM (including local ones), and stores all data locally as Markdown you can read, edit, or delete at any time.

Our previous startup was acquired by Coinbase, where part of my work involved graph neural networks. We're excited to be working with graph-based systems again. Work memory feels like the missing layer for agents.

We’d love to hear your thoughts and welcome contributions!

Hi HN — I’m the developer of NetViews, a macOS utility I built because I wanted better visibility into what was actually happening on my wired and wireless networks.

I live in the CLI, but for discovery and ongoing monitoring, I kept bouncing between tools, terminals, and mental context switches. I wanted something faster and more visual, without losing technical depth — so I built a GUI that brings my favorite diagnostics together in one place.

About three months ago, I shared an early version here and got a ton of great feedback. I listened: a new name (it was PingStalker), a longer trial, and a lot of new features. Today I’m excited to share NetViews 2.3.

NetViews started because I wanted to know if something on the network was scanning my machine. Once I had that, I wanted quick access to core details—external IP, Wi-Fi data, and local topology. Then I wanted more: fast, reliable scans using ARP tables and ICMP.

As a Wi-Fi engineer, I couldn’t stop there. I kept adding ways to surface what’s actually going on behind the scenes.

Discovery & Scanning: * ARP, ICMP, mDNS, and DNS discovery to enumerate every device on your subnet (IP, MAC, vendor, open ports). * Fast scans using ARP tables first, then ICMP, to avoid the usual “nmap wait”.

Wireless Visibility: * Detailed Wi-Fi connection performance and signal data. * Visual and audible tools to quickly locate the access point you’re associated with.

Monitoring & Timelines: * Connection and ping timelines over 1, 2, 4, or 8 hours. * Continuous “live ping” monitoring to visualize latency spikes, packet loss, and reconnects.

Low-level Traffic (but only what matters): * Live capture of DHCP, ARP, 802.1X, LLDP/CDP, ICMP, and off-subnet chatter. * mDNS decoded into human-readable output (this took months of deep dives).

Under the hood, it’s written in Swift. It uses low-level BSD sockets for ICMP and ARP, Apple’s Network framework for interface enumeration, and selectively wraps existing command-line tools where they’re still the best option. The focus has been on speed and low overhead.

I’d love feedback from anyone who builds or uses network diagnostic tools: - Does this fill a gap you’ve personally hit on macOS? - Are there better approaches to scan speed or event visualization that you’ve used? - What diagnostics do you still find yourself dropping to the CLI for?

Details and screenshots: https://netviews.app There’s a free trial and paid licenses; I’m funding development directly rather than ads or subscriptions. Licenses include free upgrades.

Happy to answer any technical questions about the implementation, Swift APIs, or macOS permission model.

A year ago, we launched Distr here to help software vendors manage customer deployments remotely. We had agents that pulled updates, a hub with a GUI, and a lot of assumptions about what on-prem deployment needed.

It turned out things get messy when your software is running in places you can't simply SSH into.

Over the last year, we’ve also helped modernize a lot of home-baked solutions: bash scripts that email when updates fail, Excel sheets nobody trusts to track customer versions, engineers driving to customer sites to fix things in person, debug sessions over email (“can you take a screenshot of the logs and send it to me?”), customers with access to internal AWS or GCP registries because there was no better option, and deployments two major versions behind that nobody wants to touch.

We waited a year before making our first breaking change, which led to a major SemVer update—but it was eventually necessary. We needed to completely rewrite how we manage customer organizations. In Distr, we differentiate between vendors and customers. A vendor is typically the author of a software / AI application that wants to distribute it to customers. Previously, we had taken a shortcut where every customer was just a single user who owned a deployment. We’ve now introduced customer organizations. Vendors onboard customer organizations onto the platform, and customers own their internal user management, including RBAC. This change obviously broke our API, and although the migration for our cloud customers was smooth, custom solutions built on top of our APIs needed updates.

Other notable features we’ve implemented since our first launch:

- An OCI container registry built on an adapted version of https://github.com/google/go-containerregistry/, directly embedded into our codebase and served via a separate port from a single Docker image. This allows vendors to distribute Docker images and other OCI artifacts if customers want to self-manage deployments.

- License Management to restrict which customers can access which applications or artifact versions. Although “license management” is a broadly used term, the main purpose here is to codify contractual agreements between vendors and customers. In its simplest form, this is time-based access to specific software versions, which vendors can now manage with Distr.

- Container logs and metrics you can actually see without SSH access. Internally, we debated whether to use a time-series database or store all logs in Postgres. Although we had to tinker quite a bit with Postgres indexes, it now runs stably.

- Secret Management, so database passwords don’t show up in configuration steps or logs.

Distr is now used by 200+ vendors, including Fortune 500 companies, across on-prem, GovCloud, AWS, and GCP, spanning health tech, fintech, security, and AI companies. We’ve also started working on our first air-gapped environment.

For Distr 3.0, we’re working on native Terraform / OpenTofu and Zarf support to provision and update infrastructure in customers’ cloud accounts and physical environments—empowering vendors to offer BYOC and air-gapped use cases, all from a single platform.

Distr is fully open source and self-hostable: https://github.com/distr-sh/distr

Docs: https://distr.sh/docs

We’re YC S24. Happy to answer questions about on-prem deployments and would love to hear about your experience with complex customer deployments.

Hey folks. I'm working on Hey Echo, an app to talk things, find perspective and get clarity on actual next steps. Thanks for checking this out!

Hey HN,

I built ArtisanForge, a free platform to learn PHP and Laravel through a medieval-fantasy RPG. Instead of traditional tutorials, you progress through kingdoms, solve coding exercises in a browser editor, earn XP, join guilds, and fight boss battles.

Tech stack: Laravel 12, Livewire 3, Tailwind CSS, Alpine.js. Code execution runs sandboxed via php-wasm in the browser.

What's in there:

- 12 courses across 11 kingdoms (PHP basics to deployment)

- 100+ interactive exercises with real-time code validation using AST analysis

- AI companion (Pip the Owlox) that uses Socratic method – never gives direct answers

- Full gamification: XP, levels, streaks, achievements, guilds, leaderboard

- Multilingual (EN/FR/NL)

The idea came from seeing too many beginners drop off traditional courses. Wrapping concepts in quests and progression mechanics keeps motivation high without dumbing down the content.

Everything is free, no paywall, no premium tier. Feedback welcome – especially from Laravel devs and educators.

This article presents a memory simulator for training machine learning models, which can help researchers understand the memory usage and performance of their models during the training process. The simulator provides insights into the memory dynamics and trade-offs involved in training complex models.

Hey HN, stripe-no-webhooks is an open-source library that syncs your Stripe payments data to your own Postgres database: https://github.com/pretzelai/stripe-no-webhooks.

Here's a demo video: https://youtu.be/cyEgW7wElcs

Why is this useful? (1) You don't have to figure out which webhooks you need or write listeners for each one. The library handles all of that. This follows the approach of libraries like dj-stripe in the Django world (https://dj-stripe.dev/). (2) Stripe's API has a 100 rpm rate limit. If you're checking subscription status frequently or building internal tools, you'll hit it. Querying your own Postgres doesn't have this problem. (3) You can give an AI agent read access to the stripe.* schema to debug payment issues—failed charges, refunds, whatever—without handing over Stripe dashboard access. (4) You can join Stripe data with your own tables for custom analytics, LTV calculations, etc.

It creates a webhook endpoint in your Stripe account to forward webhooks to your backend where a webhook listener stores all the data into a new stripe.* schema. You define your plans in TypeScript, run a sync command, and the library takes care of creating Stripe products and prices, handling webhooks, and keeping your database in sync. We also let you backfill your Stripe data for existing accounts.

It supports pre-paid usage credits, account wallets and usage-based billing. It also lets you generate a pricing table component that you can customize. You can access the user information using the simple API the library provides:

  billing.subscriptions.get({ userId });
  billing.credits.consume({ userId, key: "api_calls", amount: 1 });
  billing.usage.record({ userId, key: "ai_model_tokens_input", amount: 4726 });

Let's see how it works with a quick example. Say you have a billing plan like Cursor (the IDE) used to have: $20/mo, you get 500 API completions + 2000 tab completions, you can buy additional API credits, and any additional usage is billed as overage.

You define your plan in TypeScript:

  {
    name: "Pro",
    description: "Cursor Pro plan",
    price: [{ amount: 2000, currency: "usd", interval: "month" }],
    features: {
      api_completion: {
        pricePerCredit: 1,              // 1 cent per unit
        trackUsage: true,               // Enable usage billing
        credits: { allocation: 500 },
        displayName: "API Completions",
      },
      tab_completion: {
        credits: { allocation: 2000 },
        displayName: "Tab Completions",
      },
    },
  }

Consume code would look like this:

  await billing.credits.consume({
    userId: user.id,
    key: "api_completion",
    amount: 1,
  });

  await billing.credits.topUp({
    userId: user.id,
    key: "api_completion",
    amount: 500,     // buy 500 credits, charges $5.00
  });

This would be a lot of work to implement by yourself on top of Stripe. You need to keep track of all of these entitlements in your own DB and deal with renewals, expiry, ad-hoc grants, etc. It's definitely doable, especially with AI coding, but you'll probably end up building something fragile and hard to maintain.

This is just a high-level overview of what the library is capable of. It also supports seat-level credits, monetary wallets (with micro-cent precision), auto top-ups, robust failure recovery, tax collection, invoices, and an out-of-the-box pricing table.

I vibe-coded a little toy app for testing: https://snw-test.vercel.app. There's no validation so feel free to sign up with a dummy email, then subscribe to a plan with a test card: 4242 4242 4242 4242, any future expiry, any 3-digit CVV.

Screenshot: https://imgur.com/a/demo-screenshot-Rh6Ucqx

Feel free to try it out! If you end up using this library, please report any bugs on the repo. If you're having trouble / want to chat, I'm happy to help - my contact is in my HN profile.

Sol LeWitt was a conceptual artist who never touched his own walls.

He wrote instructions and other people executed them, the original prompt engineer!

I bookmarked a project called "Solving Sol" seven years ago and made a repo in 2018. Committed a README. Never pushed anything else.

Fast forward to 2026, I finally built it.

https://intervolz.com/sollewitt/

I work on real-time voice/video AI at Tavus and for the past few years, I’ve mostly focused on how machines respond in a conversation.

One thing that’s always bothered me is that almost all conversational systems still reduce everything to transcripts, and throw away a ton of signals that need to be used downstream. Some existing emotion understanding models try to analyze and classify into small sets of arbitrary boxes, but they either aren’t fast / rich enough to do this with conviction in real-time.

So I built a multimodal perception system which gives us a way to encode visual and audio conversational signals and have them translated into natural language by aligning a small LLM on these signals, such that the agent can "see" and "hear" you, and that you can interface with it via an OpenAI compatible tool schema in a live conversation.

It outputs short natural language descriptions of what’s going on in the interaction - things like uncertainty building, sarcasm, disengagement, or even shift in attention of a single turn in a convo.

Some quick specs:

- Runs in real-time per conversation

- Processing at ~15fps video + overlapping audio alongside the conversation

- Handles nuanced emotions, whispers vs shouts

- Trained on synthetic + internal convo data

Happy to answer questions or go deeper on architecture/tradeoffs

More details here: https://www.tavus.io/post/raven-1-bringing-emotional-intelli...

Everything evolves in digitality, and deconstructs in logic.

Tired of filters that make everyone look like a glazed donut? Same.

Yan is not another beauty app. It's a digital chaos engine that treats your pixels like they owe it money. We don't enhance photos — we interrogate them at the binary level until they confess their true nature.

[What We Actually Do] • Luma Stretch: Grab your image by its light and shadow, then yeet it into oblivion. Speed lines included. • Pixel Sort: Let gravity do art. Pixels fall, colors cascade, Instagram influencers cry. • RGB Shift: That drunk 3D glasses effect, but on purpose. Your eyes will thank us. Or sue us. • Block Jitter: Ctrl+Z had a nightmare. This is what it dreamed.

[Why Yan?] Because "vintage filter #47" is not a personality. Because glitch is not a bug — it's a feature. Because sometimes the most beautiful thing you can do to a photo is break it.

Warning: Side effects may include artistic awakening, filter addiction withdrawal, and an uncontrollable urge to deconstruct everything.

Your camera roll will never be boring again.

HN is all about the rich discussions. We wanted to take the HN experience one step further - to bring the familiar keyboard-first navigation, find interesting viewpoints in the threads and get a gist of long threads so that we can decide which rabbit holes to explore. So we built HN Companion a year ago, and have been refining it ever since.

Try it: https://app.hncompanion.com or available as an extension for Firefox / Chrome: [0].

Most AI summarization strips the voices from conversations by flattening threads into a wall of text. This kills the joy of reading HN discussions. Instead, HN Companion works differently - it understands the thread hierarchy, the voting patterns and contrasting viewpoints - everything that makes HN interesting. Think of it like clustering related discussions across multiple hierarchies into a group and surfacing the comments that represent each cluster. It keeps the verbatim text with backlinks so that you never lose context and can continue the conversation from that point. Here is how the summarization works under the hood [1].

We first built this as an open source browser extension. But soon we learned that people hesitate to install it. So we built the same experience as a web app with all the features. This helped people see how it works, and use it on mobile too (in the browser or as PWA). This is now a playground to try new features before taking them to the browser extension.

We did a Show HN a year ago [2] and we have added these features based on user feedback:

* cached summaries - summaries are generated and cached on our servers. This improved the speed significantly. You still have the option to use your own API key or use local models through Ollama.

* our system prompt is available in the Settings page of the extension. You can customize it as you wish.

* sort the posts in the feed pages (/home, /show etc.) based on points, comments, time or the default sorting order.

* We tried fine tuning an open weights model to summarize, but learned that with a good system prompt and user prompt, the frontier models deliver results of similar quality. So we didn’t use the fine-tuned model, but you can run them locally.

The browser extension does not track any usage or analytics. The code is open source[3].

We want to continue to improve HN Companion, specifically add features like following an author, notes about an author, draft posts etc.

See it in action for a post here https://app.hncompanion.com/item?id=46937696

We would love to get your feedback on what would make this more useful for your HN reading.

[0] https://hncompanion.com/#download

[1] https://hncompanion.com/how-it-works

[2] https://news.ycombinator.com/item?id=42532374

[3] https://github.com/hncompanion/browser-extension

Wrote a thing about what makes Elysia stand out in a performance benchmark game

Basically, there's a JIT "compiler" embedded into a framework

This approach has been used by ajv and TypeBox before for input validation, making it faster than other competitors

Elysia basically does the same, but scales that into a full backend framework

This gave Elysia an unfair advantage in the performance game, making Elysia the fastest framework on Bun runtime, but also faster than most on Node, Deno, and Cloudflare Worker as well, when using the same underlying HTTP adapter

There is an escape hatch if necessary, but for the past 3 years, there have been no critical reports about the JIT "compiler"

What do you think?

We recently started to use agents to update some documentation across our codebase on a weekly basis, and everything quickly turned into cron jobs, logs, and terminal output.

it worked, but was hard to tell what agents were doing, why something failed, or whether a workflow was actually progressing.

We thought it would be more interesting to treat agents as long-lived workers with state and responsibilities and explicit handoffs. Something you can actually see and reason about, instead of just tailing logs.

So we built Clawe, a small coordination layer on top of OpenClaw that lets agent workflows run, pause, retry, and hand control back to a human at specific points.

This started as an experiment in how agent systems might feel to operate, but we're starting to see real potential for it, especially for content review and maintenance workflows in marketing. Curious what abstractions make sense, what feels unnecessary, and what breaks first.

Repo: https://github.com/getclawe/clawe

Hey HN! I've been building random tools whenever I needed them over the past few months, and now I have 177 of them. Started because I was tired of sketchy converter sites with 10 ads, so I just... made my own.

Some highlights for the dev crowd:

Developer tools: - UUID Generator (v1/v4/v7, bulk generation): https://calcbin.com/tools/uuid-generator - JWT Generator & Decoder: https://calcbin.com/tools/jwt-generator - JSON Formatter/Validator: https://calcbin.com/tools/json-formatter - Cron Expression Generator (with natural language): https://calcbin.com/tools/cron-expression-generator - Base64 Encoder/Decoder: https://calcbin.com/tools/base64 - Regex Tester: https://calcbin.com/tools/regex-tester - SVG Optimizer (SVGO-powered, client-side): https://calcbin.com/tools/svg-optimizer

Fun ones: - Random Name Picker (spin wheel animation): https://calcbin.com/tools/random-name-picker - QR Code Generator: https://calcbin.com/tools/qr-code-generator

Everything runs client-side (Next.js + React), no ads, no tracking, works offline. Built it for myself but figured others might find it useful.

Browse all tools: https://calcbin.com/tools

Tech: Next.js 14 App Router, TypeScript, Tailwind, Turborepo monorepo.

All open to feedback!

I've done this same println debugging thing so many times, along with some sed/awk stuff to figure out which call was causing the issue. Now it's a small Go package.

With some `runtime.Callers` I can usually find the spot by just swapping the existing Mutex or RWMutex for this one.

Sometimes I switch the

  mu.Lock()
  defer mu.Unlock()

  defer mu.LockFunc()()

Not the most polished library, but it's not supposed to land in any commit, just a temporary debugging aid. I find it useful.

Built this after spending ages looking for the right CRM to work with. I’d sign up for a CRM, get annoyed by the complexity or the monthly per-user pricing, export everything to CSV, and go back to managing my sales in a Google Sheet.

While spreadsheets are great for data, they are terrible for workflows (pipelines, activity logging, moving cards around).

So I built a "stateless" UI layer on top of Google Sheets.

The concept is simple:

No Vendor Lock-in: The app doesn't have its own database. It reads and writes directly to your Google Sheet via the API.

Exit Strategy: If you stop using the app (or if I stop maintaining it), you don't need to "export" your data. It's already in your Google Drive, in a format you own.

Also working on CLI + open API routes that will enable MCP like connectors.

git: https://github.com/sdntsng/sheety-crm live: https://sheety.site

The article discusses the similarities and differences between the programming practices of 'showboating' and 'rodneying', with the former focusing on impressive displays of coding prowess and the latter emphasizing pragmatic problem-solving and maintainable code.

GitHub: https://github.com/ClioAI/kw-sdk

Most AI agent frameworks target code. Write code, run tests, fix errors, repeat. That works because code has a natural verification signal. It works or it doesn't.

This SDK treats knowledge work like an engineering problem:

Task → Brief → Rubric (hidden from executor) → Work → Verify → Fail? → Retry → Pass → Submit

The orchestrator coordinates subagents, web search, code execution, and file I/O. then checks its own work against criteria it can't game (the rubric is generated in a separate call and the executor never sees it directly).

We originally built this as a harness for RL training on knowledge tasks. The rubric is the reward function. If you're training models on knowledge work, the brief→rubric→execute→verify loop gives you a structured reward signal for tasks that normally don't have one.

What makes Knowledge work different from code? (apart from feedback loop) I believe there is some functionality missing from today's agents when it comes to knowledge work. I tried to include that in this release. Example:

Explore mode: Mapping the solution space, identifying the set level gaps, and giving options.

Most agents optimize for a single answer, and end up with a median one. For strategy, design, creative problems, you want to see the options, what are the tradeoffs, and what can you do? Explore mode generates N distinct approaches, each with explicit assumptions and counterfactuals ("this works if X, breaks if Y"). The output ends with set-level gaps ie what angles the entire set missed. The gaps are often more valuable than the takes. I think this is what many of us do on a daily basis, but no agent directly captures it today. See https://github.com/ClioAI/kw-sdk/blob/main/examples/explore_... and the output for a sense of how this is different.

Checkpointing: With many ai agents and especially multi agent systems, i can see where it went wrong, but cant run inference from same stage. (or you may want multiple explorations once an agent has done some tasks like search and is now looking at ideas). I used this for rollouts a lot, and think its a great feature to run again, or fork from a specific checkpoint.

A note on Verification loop: The verify step is where the real leverage is. A model that can accurately assess its own work against a rubric is more valuable than one that generates slightly better first drafts. The rubric makes quality legible — to the agent, to the human, and potentially to a training signal.

Some things i like about this: - You can pass a remote execution environment (including your browser as a sandbox) and it would work. It can be docker, e2b, your local env, anything, the model will execute commands in your context, and will iterate based on feedback loop. Code execution is a protocol here.

- Tool calling: I realize you don't need complex functions. Models are good at writing terminal code, and can iterate based on feedback, so you can just pass either functions in context and model will execute or you can pass docs and model will write the code. (same as anthropic's programmatic tool calling). Details: https://github.com/ClioAI/kw-sdk/blob/main/TOOL_CALLING_GUID...

Lastly, some guides: - SDK guide: https://github.com/ClioAI/kw-sdk/blob/main/SDK_GUIDE.md - Extensible. See bizarro example where i add a new mode: https://github.com/ClioAI/kw-sdk/blob/main/examples/custom_m... - working with files: https://github.com/ClioAI/kw-sdk/blob/main/examples/with_fil... - this is simple but i love the csv example: https://github.com/ClioAI/kw-sdk/blob/main/examples/csv_rese... - remote execution: https://github.com/ClioAI/kw-sdk/blob/main/examples/with_cus...

And a lot more. This was completely refactored by opus and given the rework, probably would have taken a lot of time to release it.

MIT licensed. Would love your feedback.

We're Tom and Ryan and we teamed up to build an algorithm with Rust and SIMD to exhaustively search for the longest line of sight on the planet. We can confirm that a previously speculated view between Pik Dankova in Kyrgyzstan and the Hindu Kush in China is indeed the longest, at 530km.

We go into all the details at https://alltheviews.world

And there's an interactive map with over 1 billion longest lines, covering the whole world at https://map.alltheviews.world Just click on any point and it'll load its longest line of sight.

Some of you may remember Tom's post[1] from a few months ago about how to efficiently pack visibility tiles for computing the entire planet. Well now it's done. The compute run itself took 100s of AMD Turin cores, 100s of GBs of RAM, a few TBs of disk and 2 days of constant runtime on multiple machines.

If you are interested in the technical details, Ryan and I have written extensively about the algorithm and pipeline that got us here:

* Tom's blog post: https://tombh.co.uk/longest-line-of-sight

* Ryan's technical breakdown: https://ryan.berge.rs/posts/total-viewshed-algorithm

This was a labor of love and we hope it inspires you both technically and naturally, to get you out seeing some of these vast views for yourselves!

1. https://news.ycombinator.com/item?id=45485227

I built kanban-md because I wanted a simple local task tracker that works well for the agent loop: drop tasks in, run multiple agents in parallel, avoid collisions, and observe progress easily.

Tasks are just Markdown files (with YAML frontmatter) in a `kanban/` next to your code — no server, no DB, no API tokens. Simple, transparent, future-proof.

What makes it useful for multi-agent workflows:

- *Atomic `pick --claim`* so two agents don’t grab the same task.

- *Token-efficient `--compact` output* (one-line-per-task) for cheap polling in agent loops.

- *Skills included* -- just run `kanban-md skill install --global`; There is a skill for CLI use, and a skill for the development loop using the CLI (might need some additional work to be more general though, but works quite well)

- *Live TUI (`kanban-md-tui`)* for control ~~and dopamine hits~~.

I'd love feedback from anyone running multi-agent coding workflows (especially around claim semantics, dependencies, and what makes you feel in control).

I had a blast using it myself for the last few days.

Tech stack: Go, Cobra, Bubbletea (TUI), fsnotify (file watching). ~85% test coverage across unit + e2e tests. After developing webapps, the simplicity of testing CLI and TUI was so freeing.

One thing I will say is that at Vulnetic we will basically jumble different misconfigurations into a network and the agent always seems to find a way to exploit them. We have tried making them esoteric, and we are even now using EDR and tools like Wazuh to evaluate how our agent evades detection. These models are improving at hacking fast.

Built this because I wanted nvtop + btop in one view while tuning local hybrid LLM inference. Supports themes, charts, and OOM kill tracking. Written in Python.

I am a developer coding under siege. I successfully encrypted the core logic of NOOR locally. My goal is to secure $400 for a laptop to build the full 7th Node. Check my proof in the link

Hello my name is Ben Ward for the past 3 years I have been remastering the financial game Wall Street Raider created by Michael Jenkins originally on DOS in 1986.

It has been a rough journey but I finally see the light at the end of the tunnel. I just recently redid the website and thought maybe the full story of how this project came to be would interest you all. Thank you for reading.

I created a site (https://printableclassics.com) that allows you to download classic books and customize things like the font size, page size, and the cover.

As part of this, I wrote a software pipeline that takes epubs, html files, or pdfs and converts them into formatted books with custom covers, page numbers, chapter formatting, etc.

I used an LLM for categorizing the books. There's a nice way to filter such that you could easily find "Young Adult, Ancient, Fantasy" for example.

When downloading from the site, the PDFS are rendered in a work queue. Hopefully the server I'm using won't get overwhelmed. It takes around 10-15 seconds to generate for most books.

Most of the books currently on the site are from Standard Ebooks. I plan to add more books from Archive.org and Project Gutenberg over time.

I also created a little guide on how you can print and bind books at home with around $200 in equipment. (https://printableclassics.com/print-guide)

Printable versions of the Harvard Classics are available here: https://printableclassics.com/harvard_classics This is an example of direct PDF conversion.

Hopefully this is useful to some people. I plan to use the books here for home education myself so it will at least be useful to me. I'd like to add a guide with top suggestions by age level and some educational theory on how I made the selections. I'm happy to take any feedback on the site or answer any questions.

There is also the option to have the books professionally printed through a print on demand provider. I'm hoping that could be a way to pay for the site hosting.

Thanks for checking it out!