Mentions

stop pasting your drafts into chatgpt & editing & dealing with walls of slop i built quill. your agent can edit the doc right where you write it. hold a key, talk, watch it rewrite. supports co-writers for variety of different models. hridaya423/quill :) t.co

Using a spare USB keyboard as a macro pad with a C++ SDK I made I've been working on a Windows C++ SDK for handling a selected keyboard separately. One use case is turning an ordinary spare USB keyboard into a macro pad while keeping its original keystrokes out of your apps. The basic flow is to pick the spare keyboard from Get_Devices(), match its current device ID, trigger your macro on the first key-down and suppress the matching key-up too. Track held keys so repeats don't launch the same action over and over. Forward every unrelated event, including your main keyboard and mouse. Repo: TitanCSA/Interceptor-Keyboard-Mouse The Ctrl+H console example shows press/release tracking and forwarding; you'd add the device selection for your pad: github.com/TitanCSA/Interceptor-Keyboard-Mouse/bl… You'll need to write the mapping in C++. It requires Windows 10/11 x64, a driver install with admin rights and possibly a restart. The SDK source is MIT; the kernel is private, and the public driver is a one-hour demo per Windows boot. What would you want to map on a second keyboard?

Tencent Hunyuan's Hyra research agent shipped new open science models 🔬 HyFF molecular force fields and two protein models, HyInv and HyPLM-Flash, are out with weights and code. #AI #AIAgents #OpenSource Tencent-Hunyuan/Hyra-results

[RELEASE] Ultimate Spider-Man 1.0 Hey everyone, I'm finally releasing the PS Vita port of Ultimate Spider-Man. It's a proof of concept, but it's playable: you can do the story, swing around the whole city, do city goals, Venom missions, cutscenes, all of it but it still needs work. It's not an emulator. The PC game's code was statically recompiled to C (same idea as N64Recomp / XenonRecomp) and runs natively on the Vita, with Windows / Direct3D 9 / DirectSound re-created on top of vitaGL. What's in it: • Full game: story, free roam, city goals, Venom, comic-panel cutscenes and the movies (played straight from the game files) • 16:9, Vita button icons in prompts, sound and music, saves on the memory card • A Settings button on the LiveArea (traffic, view distance, resolution, fps cap, debug options) • Camera lock on the rear touchpad Performance: around 18–30 fps. About 20–25 swinging through the city, up to 30 in smaller interiors, lower in big fights. Expect some hitches when the city streams in, especially right after missions. How to install: 1. Get usm.vpk from the releases page and install it with VitaShell 2. You need ur0:data/libshacccg.suprx (same as any vitaGL port) 3. Copy USM.exe and the Data folder from your own PC copy into ux0:data/usm/ (no conversion needed) No game files are included, so you need your own copy of the PC game. Links: Website / install guide: boomannotjeff.github.io Download: github.com/boomannotjeff/usm_vita/releases/latest Source: boomannotjeff/usm_vita Please report issues! If something breaks, turn on "DEBUG: write log.txt" in Settings, reproduce it, and open an issue on GitHub with ux0:data/usm/log.txt attached. And please contribute. I've put a lot into this and I'm honestly burnt out, so I won't be pushing it much further myself. The code is all on GitHub. Performance, bugs, anything: PRs are very welcome. It'd be great to see it get better. Have fun swinging around on the go 🕷️

Hey Stream: a free Android TV player whose whole core is one Rust crate Hey! I've been building Hey Stream, a free and open-source (GPL) TV player for Android TV, tablets and phones. Most players in this space are either paid, full of ads, or crawl on cheap boxes, so I wanted something simple and fast. The whole brain of the app is one Rust crate: API client, SQLite catalog cache, search, parental control, resume and "watched" tracking. The Android UI (Compose) only displays things and talks to the core through UniFFI. Swift bindings are generated too, for a future Apple TV app. What I learned along the way: - Cheap boxes are brutal. It has to stay smooth on a 2 GB box with a 32-bit userspace, so it ships armeabi-v7a next to arm64-v8a. Catalogs can reach 100k entries, so they live in SQLite (WAL, cached statements, paged queries) and are never loaded whole. - Provider APIs are a mess. Numbers sent as strings, maps instead of arrays, fields missing at random. Each entry is deserialized from its own RawValue, so one broken entry is skipped instead of failing the whole list. - TLS without JNI. reqwest + rustls with bundled Mozilla roots, so the core needs no setup on the Android side. - Panics don't vanish. A panic hook forwards the message and file:line to the app through a UniFFI foreign trait, so they show up in the crash reports (anonymous, and users can opt out). It costs nothing until something actually panics. - Tests never touch a real server: wiremock on the Rust side, MockWebServer on an emulator in CI. It's just a player: no content, not tied to any provider. Still early (test builds), so expect rough edges. Next on the list: instant search with SQLite FTS5 instead of LIKE, streaming JSON parsing so huge playlists don't eat all the RAM, and a benchmark on 100k items. Feedback on the core's design is very welcome. - Releases (APK): github.com/Shweepsi/hey-stream-native/releases

Can't get FSR4 w/ Decky Framegen to work on Onimusha: Way of the Sword The game initially starts up, I see the words "Optiscaler" in the bottom left corner of the screen, there's a pause, and then it crashes back to game mode. I'm actually trying to use both LSFG-VK (for frame gen) and Deck Framegen for FSR 4 upscaling (btw...these naming conventions are VERY confusing), but they weren't working together. I disabled Decky Framegen and enabled LSFG-VK and it works, so I narrowed it down to Decky Framegen being the problem. For the record, I don't use Decky-Framegen from the Decky plugin store. I get it from JSONDerulo's github and install it via the zip file. As for the plugin itself I choose "4.1.1 | Valve RDNA2 Compatibility" for FSR4 runtime, dxgi.dll for the dll name, and I just simply click "Patch with dxgi.dll" (after initially installing OptiScaler, of course). That's it. Nothing else. Is there something I'm maybe doing wrong?

@pay_icon I'm trying to! The safety/alignment community was ignoring all of my writing on the topic, so I decided to just do it all myself: Dicklesworthstone/franken_alignment

Using AWS to Manage AI Spec-Driven Development Artifacts My Pain Point Doing spec-driven development with AI agents, I quickly ran into a problem: managing all the artifacts they produce. Brainstorming notes, architecture designs, specifications and contracts, results of architecture and code reviews, troubleshooting notes, etc. Even on a small project you quickly end up with hundreds of markdown files. On a team project, thousands to tens of thousands. The basic approach is to store them in a folder in the repo (e.g. docs/), with an index.md file listing each file with a short description of its content. This approach has several issues: - Documentation pollutes your code base - Publishing an artifact goes through the same PR review as code, which makes code reviews harder and sharing artifacts between team members have to wait the PR review - It is unrealistic to capture the content of an ADR or a spec in a 1-2 sentence description in an index file, so agents can't rely on it to find the right information - You can't share information across teams (e.g. the agents of an application developer need access to the architecture designed by the networking or security team in another repo) How I Used Just 3 AWS Services to Solve it This is why I came up with the idea of using AWS services behind an MCP server to store, manage, share and search these artifacts. The architecture is pretty simple: - S3 stores all the markdown artifacts - S3 Vectors stores an embedding of each H2 section of every artifact. This gives semantic search at a more granular level than the whole document, plus filtering on the vector metadata (e.g. on the artifact type) - A Bedrock embedding model (Titan Text Embeddings v2) creates these embeddings - An MCP server exposes tools to store, manage and search artifacts, a few resources, and an MCP App to browse the artifacts visually - The MCP server uses the developer's own AWS credentials (e.g. an AWS CLI profile) - The artifacts follow the Open Knowledge Format (OKF) for their frontmatter. The artifact sources and relationships (work in progress), as well as the commit references, are stored in S3 object annotations. This way they can be updated without having to replace the S3 object, since S3 objects and their metadata are immutable. - In an enterprise, a single S3 bucket and a single vector index can store the artifacts of all teams and projects, each in its own prefix ("subfolder"). A team can then mark some of its artifacts as shared to make them visible to other projects and teams. Architecture Diagram !Image description The Result Combining just these 3 AWS services gave birth to the Arkeology project with the following features: - Immediate write-then-read consistency: an artifact written in one agent call is searchable in the next - Semantic search with metadata filtering: retrieve artifacts by meaning, not just by keywords - Section-level search precision: a query matches the specific section of an artifact that is relevant, not an average of the whole document - Cross-team knowledge sharing: canonical artifacts such as ADRs can be made discoverable by the agents of other projects or teams. Nothing is shared by accident: only permanent artifacts explicitly marked as shared are visible outside their project - Rich, filterable metadata: every S3 object and every vector carries structured metadata, and S3 objects also carry annotations - Commit-to-artifact traceability: artifacts carry git commit SHA references, stored in S3 object annotations and mirrored into the vector index so you can filter on them - Arkeology Studio: calling it opens a visual artifact browser directly inside any MCP host that supports MCP Apps (Claude Desktop, claude.ai, VS Code Copilot...) - Full artifact lifecycle: archive, delete and purge artifacts as projects evolve - Migration: a skill and server tools to import the documentation of an existing project - And more Arkeology Sudio MCP APP Preview !Image description Caveats Team Sharing and IAM Permissions The sharing of artifacts is enforced by the MCP server, but anyone with IAM read permissions on the whole bucket can bypass the MCP server and, for example, use the AWS CLI to read any data. Least-privilege permissions restricting each team to its own prefix in the S3 bucket must be enforced in IAM. That said, IAM can't do the same inside a shared vector index: any team with query access to the index can read the metadata (titles, descriptions, tags) and embeddings of all teams' artifacts. So only share a vector index with teams you trust. Arkeology Studio MCP App It requires an MCP host that supports MCP Apps (Claude Code, for example, doesn't), or using the MCP Inspector, which is a bit of a pain as a developer. I am currently thinking of building an optional frontend on AWS, to have a web interface to access, search and read the artifacts. Lessons Learned Vector metadata limits Vector metadata is limited to 2 KB filterable and 40 KB total per vector. This is why we can't put sources and relationships in the vector metadata and use them to search and filter artifacts. It is also why only the 20 most recent commit references go into the vector index, so you can still find the artifacts linked to recent commits; the full list stays in the S3 object annotations. Annotations S3 user-defined object metadata is capped at 2 KB and immutable like the object. Annotations hold up to 1 MiB and can be updated without rewriting the object. But there is a catch: overwriting the object deletes its annotations, so every rewrite must read them first and put them back. And if that read fails, it must raise an error rather than return nothing, or you end up writing empty values over good data, with no other copy to recover from. Using annotations for sources and relationships comes with some limitations: - It is not possible to do a search like "give me all artifacts referencing artifact XYZ" - Search results don't include these fields: an agent has to read or list the artifact to see them In other words, agents can only navigate these links, not query them. S3 Vectors QueryVectors doesn't return the distance unless you ask for it (returnDistance: true). Our code defaulted the missing distance to 0, so every result got a perfect score of 1.0 (score = 1 − distance). The search ranking was silently broken while all unit tests passed. Conclusion With just 3 basic AWS services I was able to build an MCP server that basically solves my pain points with managing all the artifacts generated through AI spec-driven development. Improvements to make the tool really functional at an enterprise level would be: - Host the MCP server on AWS - Enforce least privilege, so nobody can bypass the MCP server to read the whole bucket content - Host a web frontend on AWS, to get around the MCP App limitations The code is open source and available at amanoxsolutions/arkeology. _(Note: I used AI only to proofread this article, improve readability and draw the architecture diagram)_

[For Hire] Python & Solidity Dev | Telegram bots, web scraping, automation, smart contracts | from $20/hr What I build: - Telegram / Discord bots: alerts, monitoring, notifications - Web scrapers: any site to CSV, Excel or a database - Automation scripts and API integrations - Smart contracts (Solidity + Foundry) with full tests, plus basic token security checks Everything I deliver runs 24/7 on a Linux server, with clean code and a short guide. Portfolio (working code, tests included): github.com/azoozgamer151-hub I can send a small free sample before you commit. Communication by chat. Payment in USDT/USDC. DM me with what you need.

I'll write a longer case study later, but I just updated the open source code jaybrunet/srvsite One important thing I fixed, the jQuery include is gone now, which was tricking AI into using jQuery ;-) t.co

I always struggled to validate the ideas I am working on so built this skill In agentic coding, specs are the king and this is the first leason everyone learnt when agentic coding took off in 2023. But the question is what good specs? A superficial view is: it's a structured marked down following best practices from systems like speckit. I always struggeled with it. Specs aren't just list of features it's answering: "are we building the right thing" This isnt a one time thing. it has to be done once and then constantly evaluated again and again. any product that has plateaued on revenue, or is slow churning, needs to rethink it's strategy. any new feature needs to be validated. This is core part of spec validation at my agentic superharness - palgu - and I decided that this should be open sourced. So I'm releasing it as a skill that can be used directly in claude code etc . here you go with the full code: alinaqi/ideavalidator Essentially the way it works is like this: A grounded idea-validation pipeline gated by the Palgu PDLC framework. The target isn't "a good idea": it's a business that's profitable from day one. Two principles rule everything: - Desk research is never validation. Grounded research can at most justify GO → real-world tests (interviews, pre-sales, paid pilots), never GO → build. - Behaviour beats stated intent. Money paid, workarounds built, tools switched > "I'd use this." Every evidence item is labelled so you can see which kind it is. How you start it - From a URL: ingest --url <site> [--idea "<angle>"] reads the site + search and writes ideas/<slug>.md. - From an interview: the skill asks only for the missing brief fields (actor, job, workaround + cost, why-us, candidate verticals, money, business model, day-one constraints). - Then: run --idea ideas/<slug>.md executes the pipeline into runs/<slug>/. Here is what makes it more than a prompt chain: 1. Demand signals (signals, auto in run).. search volume + social validation (Reddit API, X via Grok). 2. Category + Business Model Canvas (classify) .. identifies the real category so stages compare to the right incumbents, and surfaces business-model-innovation options + USP; rendered as a BMC grid + value-positioning map 3. Anti-over-qualification ... score the idea as stated for its ICP; adjacent/bigger businesses are parked in adjacent_opportunities, never scored, and stages may not invent an unstated compliance regime or silently re-scope the founder's thesis. 4. Self-validation audit (selfcheck, auto at end of run) .. flags over-qualification, score inconsistencies, weak/single-source KILLs, and unreachable citations (catches fabricated sources). 5. Council (council) ... optional multi-model sounding board: framework personas debate, a Red Team attacks, a Chair synthesises. Opinion, never a gate. Ideavalidator is both a skill and a mod so its easily to use. I hope it helps.

We run Claude Code and opencode as two engines behind one agent: lessons from a local NotebookLM-style app I'm one of the maintainers of SurfSense, so this is self-promotion. I posted the architecture here two weeks ago and got useful feedback, so here's what we've built since, and what we learned. SurfSense is an open-source (Apache-2.0) desktop app for Windows, macOS and Linux: cited Q&A over your documents, plus an agent that writes and edits Word, PDF, PowerPoint and Excel files. It works with a local model or any API. New since the last post - Docker image (2.3.0). The same stack as the desktop app in one container, ghcr.io/modsetter/surfsense. A headless entry runs the same supervisor Electron does (API, workers, llama.cpp, opencode), with Caddy as the only thing listening. CPU only for now. - A second agent engine. With a Claude Pro, Max or Team plan, the agent runs on the user's own Claude Code through Anthropic's Agent SDK. SurfSense never holds the Claude credentials. Both engines sit behind one interface and get the same tools and rules, and Q&A runs Claude Code with every tool turned off. - opencode 2.x. The agent moved to opencode 2.1.2. A turn now starts with only the plugin tools it needs and can pick up more mid-turn, instead of loading every tool up front. - Any remote MCP server. Streamable HTTP with OAuth or a key, reached through SurfSense's gateway, so the agent runtimes never see plugin credentials. - Web pages from a skill. The agent writes one self-contained HTML file with its own SVG charts and interactive figures. No network, no chart library. - More sources. Audio recordings are transcribed locally, and EPUB, MOBI and AZW3 books can be added (2.3.0). - OCR first. Scans and photos go through RapidOCR, or Apple Vision on a Mac, before Docling, which now only runs when it's needed. - Image edits (2.3.0). Ask for changes to a generated image or infographic and get its next version. Things we learned - Transcribe in speech windows, not fixed chunks. Silero VAD finds speech, which is packed into windows of at most 28 seconds, ending at the longest pause once a window holds 20. Silence is never sent, and every window keeps its place in the recording, so citations get real timestamps. - Drive Claude Code instead of reimplementing it. Running the user's installed Claude Code through the Agent SDK meant no credentials to store and no sign-in flow to build, but every Claude Code update can change behaviour, so we pin what we measured and test against the installed version. - Load tools lazily. Offering every plugin tool on every turn wasted context on small models. Holding only what the turn needs, with a catalogue of the rest, fixed it. Repo: MODSetter/SurfSense Download: surfsense.com

agentwire v1.77.3: delegated workers now report back to their spawner automatically, and a wrong session name fails at once, not hours later. Ships with damage-control-dev 0.1.4, which reads the scripts commands run. What next? github.com/dotdevdotdev/agentwire-dev/releases/ta… #BuildInPublic #DevTools

Spiced up my GitHub Stats derive from live API data, but also a config file. Every time I make a change CI rebuilds the visuals so it's never out of sync github.com/ripgrim t.co

Savor: A Food Delivery Template for Restaurants and Local Fleets !Savor, a food delivery app built with Codename One Delivery platforms take a big cut of every order, often between 15% and 30%. For a restaurant running on thin margins, that cut can be the whole profit. That's why so many restaurants, small chains and local delivery startups want their own ordering app, and why most of them give up when they see what it takes: a customer app, a kitchen screen, a courier app, an operations console, payments, maps and a server that ties it together. <aside style="border-left: 4px solid #007aff; padding: 14px 18px; margin: 24px 0; border-radius: 4px; font-size: 0.95em;"><strong>What is Codename One?</strong> Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at <a href="codenameone.com">codenameone.com</a>.</aside> Savor is all of that in one Java project. It's the third of this week's templates, after Skirmish and Parley, and it's a sibling of Wayline, the ride-hailing app from last week. Pick the food-delivery template in the Initializr, set your name and package, and you have a working delivery service. The source is under MIT-0, so the business you build on it is yours. <div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0"> <figure style="margin:0"><a href="codenameone.com"><img width="420" height="909" src="codenameone.com" alt="The Savor customer home screen listing restaurants" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Restaurants near you.</figcaption></figure> <figure style="margin:0"><a href="codenameone.com"><img width="420" height="909" src="codenameone.com" alt="The Savor checkout screen" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Checkout.</figcaption></figure> <figure style="margin:0"><a href="codenameone.com"><img width="420" height="909" src="codenameone.com" alt="A Savor order tracked live on a map" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Live tracking.</figcaption></figure> </div> One app, four roles Savor is a single app. The account's role decides the first screen: a customer sees restaurants, a merchant sees the order queue, a courier sees the delivery screen and an administrator sees the operations console. One build to publish, one code base to maintain. | Role | What they can do | | --- | --- | | Customer | Browse restaurants that deliver to their address, build a cart, pay by card or cash, tip, track the courier on a map and get refunds | | Restaurant | Accept or reject orders, mark them ready and see the queue update live | | Courier | Apply with documents, go online, accept offers, navigate to the pickup and the customer, and track earnings | | Administrator | Watch the dashboard and trends, review courier applications and manage accounts | <div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0"> <figure style="margin:0"><a href="codenameone.com"><img width="420" height="909" src="codenameone.com" alt="The restaurant's order queue" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The kitchen's queue.</figcaption></figure> <figure style="margin:0"><a href="codenameone.com"><img width="420" height="909" src="codenameone.com" alt="A delivery offer on the courier screen" loading="lazy" style="width:100%;height:auto" /></a><figcaption>A courier's offer.</figcaption></figure> <figure style="margin:0"><a href="codenameone.com"><img width="420" height="909" src="codenameone.com" alt="The Savor admin dashboard" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The operations dashboard.</figcaption></figure> </div> The hard parts are already handled The screens are the visible part of a delivery service. The business rules underneath are where projects usually stall. Savor has them in place. Money moves at the right time. The card is authorized for the total when the order is placed and captured when the food is delivered. A rejected or canceled order releases the hold, so customers are never charged for food they didn't get. From Payments.java: /// Holds an order's total on the customer's card as the order is placed, /// with no transaction open. Nothing is taken until the order arrives /// ([#settle]); an order that never does lets the hold go ([#release]). public String authorize(String orderId, String username, String methodId, long amountCents, String currency) throws IOException { if (CASH.equals(methodId)) { return CASH; } With Stripe, cards are added on Stripe's own page, so card numbers never touch your app or your server. Other providers plug in through the PaymentProvider interface. Orders and deliveries can't get confused. An order and its delivery are separate state machines that share an id. Every transition is a conditional update that names the states it can come from, so when a kitchen and a customer act at the same moment, only one of them wins. !Diagram Maps without an API key bill. Tracking uses OpenFreeMap vector tiles, OSRM routing and Photon place search. Updates arrive over a WebSocket as they happen, so the customer watches the courier move. Everything Wayline learned, Savor reuses. Accounts, sign-in with phone verification, SMS and push providers, the live channel, the map, billing, the operations console, the database and hosting all come from Wayline. A delivery is, almost literally, a Wayline ride with a stop at the restaurant. Make it yours The guide covers the common ways to reshape Savor: - A single restaurant or a small chain. Turn off merchant sign-up and run Savor as your own branded ordering app. This is the case where avoiding platform commissions pays off fastest. - Pickup and scheduled orders, for when you don't want couriers at all, or not yet. - Your own couriers instead of a gig fleet. - Beyond food: groceries, pharmacy, flowers, laundry, anything that moves from a shop to a door. Point an AI agent at the project and describe the business. The model, the roles and the flow are already there. The colors and corner radius are CSS variables in theme.css, the text is in five languages, and the SMS provider is a setting (savor.sms.provider takes Twilio, Vonage or MessageBird). Try it The development profile simulates kitchens and couriers, so you can place an order and watch it move through the whole flow with nothing installed. Use card 4242 4242 4242 4242 to pay, or 4000 0000 0000 0002 to see a decline. The Savor page has the overview, and the user's guide and implementor's guide go deeper. Tomorrow the series moves from apps to the framework features they pushed into Codename One, starting with More of the Java API, and an Experiment With Unity Games.

Fleet (CVSS 9.9): with SAML SSO on, a team-scoped user who can run live queries could become global admin, with scripts and MDM actions on every host. Patch all replicas or turn off SAML until then. github.com/fleetdm/fleet/security/advisories/GHSA…

A Linux kernel module that claims to unlock higher AI-compute throughput on GeForce RTX 20, 30 and 40 series cards. The performance figures shown are the project's own claims, not independently verified. Zagitta/gpu-unlock t.co

Should a broken link fail your CI build? Block internal links, warn on external ones --- title: "Should a broken link fail your CI build? Block internal links, warn on external ones" published: true tags: ci, testing, github, documentation description: "Failing CI on every broken link makes builds red for reasons you don't control. Never checking lets docs rot. A split policy that works, with GitHub Actions config." --- A pull request fixing a typo in the README failed CI. The reason: a blog post linked from the docs, on a site owned by someone else, started returning 503 that morning. The contributor couldn't fix it, the maintainer was asleep, and the PR sat red for two days. The week before, the same repo merged a renamed docs page that broke 14 internal links, because link checking had been turned off after the last false alarm. TL;DR - Treat internal links (your own site, your own docs) as code: broken means failing build. - Treat external links as data: check them on a schedule, report them, but don't block merges. - Use caching, retries and an allowlist to keep the PR check fast and deterministic. - My opinion: a CI check that can fail because of someone else's server is a flaky test, and flaky tests get disabled. Why "fail on everything" doesn't last External links fail for reasons that have nothing to do with the change in the PR: rate limiting, bot protection, outages, geo-blocking. If those failures block merges, three things happen in order: people re-run the job until it passes, then they add continue-on-error, then they delete the job. You end up with no link checking at all. Why "never fail" doesn't work either Internal links break because of changes in PRs: renamed files, moved headings, deleted pages. The PR is the cheapest moment to catch them, because the author knows exactly what moved. A week later, nobody remembers. The split policy | Link type | When checked | On failure | |---|---|---| | Relative links and anchors in the repo | every PR | fail the build | | Links to your own domain | every PR | fail the build | | External links | nightly or weekly | open or update an issue | PR job: internal only, fast and offline-ish Using lychee, a fast link checker that runs well in CI: # .github/workflows/links-pr.yml name: Links (internal) on: pull_request jobs: internal: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: lycheeverse/lychee-action@v2 with: args: >- --offline --include-fragments --no-progress './**/*.md' fail: true --offline skips network requests and checks only local files and relative links, so the job can't be flaky. --include-fragments also checks #section anchors, which break silently whenever someone renames a heading. Broken anchors are common enough to deserve their own post: Anchor link not working? How to find and fix broken section links. If your docs link to your own production domain with absolute URLs, add a second step that checks only those, with retries: - uses: lycheeverse/lychee-action@v2 with: args: >- --include '^https://docs\.example\.com' --max-retries 3 --no-progress './**/*.md' fail: true Scheduled job: external links, reported not blocking # .github/workflows/links-nightly.yml name: Links (external) on: schedule: [{ cron: '0 3 * * 1-5' }] workflow_dispatch: jobs: external: runs-on: ubuntu-latest permissions: { issues: write } steps: - uses: actions/checkout@v4 - uses: lycheeverse/lychee-action@v2 id: lychee with: args: >- --exclude-path node_modules --max-retries 3 --accept '200..=299,429' --no-progress './**/*.md' fail: false - if: steps.lychee.outputs.exit_code != 0 uses: peter-evans/create-issue-from-file@v5 with: title: External link report content-filepath: ./lychee/out.md labels: links Accepting 429 is a deliberate choice: a rate-limited link is almost always a working link. The full reasoning on which status codes deserve trust is in the false positives post. Keep a short, reviewed ignore list # .lycheeignore ^https://www\.linkedin\.com/ ^https://twitter\.com/ ^https://x\.com/ Every entry should have a reason, ideally in the commit message that added it. An ignore list that grows without review turns into "we don't check links". If you don't use lychee The same policy works with any tool. In a small repo, even a short script that resolves relative Markdown links against the file tree is enough for the PR job. Check links in Markdown docs with a 60-line Python script has one you can drop in. For a live website rather than a docs repo, a browser test like the one in How to find broken links with Playwright fits better, and a scheduled crawl with something like linkbruno.com covers the parts of the site that don't live in the repo. What about redirects? Don't fail builds on redirects. Report internal links that redirect, though, because each one is a hop you could remove (see the redirect chains post). A good middle ground: fail on 4xx/5xx for internal links, warn on 3xx. Common objections "But then external rot piles up." Only if nobody reads the issue. Assign it to a rotating owner and close it weekly, like any other chore. "Offline mode misses links to our own site." That's what the second, domain-scoped step is for. Keep its scope tight so it only hits servers you run. "Nightly is too slow." For most docs, a dead external link that lives for one day costs nothing. If a link is business-critical, it probably belongs on your own domain anyway. My take CI should fail only on things the PR author caused and can fix. Internal links meet that bar. External links don't. Splitting the two keeps the PR check strict and trusted, and still gets external rot onto somebody's to-do list. Over to you Do you fail builds on external links, and if so, how do you keep the job from going flaky? I'd also like to hear how people handle links behind login, which no CI job can check.

@Juanmh033 @WillDobrev Quis dizer o Fork desse cara aqui: google-gemini/gemini-cli

that-guy-wade/tubefs *Definitely breaks YouTube TOS, post 4K TV static on your channel at your own risk.

@br_springtrap let me know if this helps Eglantine-steamdeck#1

[Hyprland] cykler-caelestia, a personal caelestia fork with all of the missing features that i wanted to see. — customization options, widgets, layouts, updates and more. A friend and I have been running and modifying caelestia for months, and this is the first time we've posted any of it now that we have released v0.3.0. So: what it is, and what we changed. caelestia is a Quickshell desktop for Hyprland — bar, launcher, dashboard, notifications, OSD, session menu and lock screen, all one process, themed from your wallpaper. caelestia-dots/shell cykler-caelestia is our fork of it. We merge upstream in regularly and build the things we missed on top. Most shell tweaking is a colour scheme and a wallpaper; what we kept wanting was to move the shell itself around, so that is where most of the work went. The layout is yours A layout editor with a miniature screen where every part of the shell is a tile: drag the bar, launcher, dashboard, notch, sidebar, OSD, session menu, popups, toasts and desktop items into place, on separate Shell and Desktop layers. The bar itself moves to any of the four edges. Popups and toasts each pick their own corner. The lock screen's cards reorder, drag between the two columns, resize and take new ones — network and volume — with the profile picture shape, an analogue clock and the revealed session controls on the same page. The panels A window overview where every workspace and window is in one blurred grid: click to jump, drag windows and whole workspaces, keyboard and page navigation. A notch pill that drops down on a track change and can stand in the bar's middle when it's free. A notification popout on its own blurrier layer. Per-corner hot actions. A session menu you reorder and trim. Turning special workspaces off closes them and moves their windows back instead of stranding them. Widgets on the desktop Thirteen cards — calendar, clock, weather, focus timer, resources, now playing, battery, fetch, audio visualiser, sticky note, pictures, GitHub contributions and to-do — with styles, an ordered grid, a rearrange mode, a picker that previews each one with your live data before you add it, and application shortcuts alongside them. The popout became a workspace A notepad: notes as plain files in a folder you choose, autosaved as you type, with a browser to get around them. To-do lists with deadlines and reminders, wrapping text and inline editing. A music library that plays in-shell with a queue, shuffle and repeat, and browses by folder, artist, album or search. The launcher does more than launch >ocr grabs the text out of a screen region with tesseract, >lens sends it to Google Lens, >ssh lists your hosts, >gpu switches supergfxctl modes, >ai is an opt-in Gemini query, and >b opens a browser tab. Media and audio One media tab that follows your audio between external players and the built-in one, with a player you can pin so nothing else takes over. An opt-in ten-band PipeWire equalizer that applies to every stream rather than just the player. Everything that used to need a config file Colour scheme, flavour and variant pickers in the settings app, a keybind editor that reads your Lua config and writes changes back with a reload, input sensitivity and touchpad settings, a drag-and-drop display arrangement that reverts itself unless you confirm, swapping the shell's own images, wallpaper rotation, per-app notification rules with a do-not-disturb shortcut, and an updates page that pulls, rebuilds and restarts the shell from inside the session. Smaller things A countdown timer in the utilities card, a tri-state keep-awake, phone integration over KDE Connect (file drop, storage browsing, scrcpy mirroring), native polkit prompts instead of the GNOME dialog, screenshots that land on the clipboard with a framed preview, and automatic Hyprland power saving on battery. Repo, install script and the full feature table: cykler01/cykler-caelestia Demo clips for most of it: cykler.dev It's two of us and it's built around our own machines first, so expect rough edges elsewhere — but it should work on most setups, and we'd rather hear about a problem than not. Issues and PRs are welcome.

A visual reminder, in case you forgot what the Minotaur Project was. jedeyesniv-art/MinotaurProjectRemastered

GitHub Hidden Gems now distinguishes GitHub API throttling from exhausted quota and permission failures. Merged PR #42 halts further API calls after rate limits. Offline CI passed; live throttling was not tested. github-hidden-gems#42

I'm Open to New Opportunities | Software Engineer (Backend) Hi everyone, I'm currently open to new opportunities and looking to connect with teams hiring for Software Engineer, Backend Developer, or Full Stack Developer roles. I'm a Software Engineer with experience building backend systems, RESTful APIs, and financial applications. My core tech stack includes: - C# / .NET / ASP.NET Core - Node.js / NestJS / Express.js - SQL Server / PostgreSQL / MySQL - Entity Framework Core / Prisma - REST APIs, Authentication, RBAC, and API Integrations - Clean Architecture, SOLID, DDD, and CQRS I've worked on fintech and transaction-based applications, including loan management systems, customer onboarding, payment integrations, and backend business logic. I also have experience with database design, query optimization, and building scalable, maintainable applications.I'm particularly interested in Backend Engineering (.NET or Node.js) and Full Stack roles where I can contribute to meaningful products, solve technical challenges, and continue growing as an engineer.Location: Lagos, Nigeria. Open to: Remote, On-opportunities (including international remote roles)If your team is hiring or you know of any opportunities that might be a good fit, I'd appreciate a referral or a DM. I'm happy to share my CV and GitHub/portfolio. Thanks! linkedin.com github.com/Olukeye

I made a dinosaur trivia tool for my terminal. Feedback welcome Hi! I built dinofacts.fyi to show a dinosaur fact whenever I open my terminal, works in a browser too. Mods approved me sharing it here. It picks short passages from Wikipedia using Rust scripts and Qwen 2.5 via Ollama on a cheap vps, and the model is asked to stick closely to the source, with text-overlap checks afterward. I'd appreciate feedback on the extraction logic and model prompt/checks, especially where and how selecting pieces can be improved to serve better trivia and facts. The gif is how I use it with Ghostty, with some sensitive details omitted.

Location: Dhaka, Bangladesh Remote: Yes (any timezone, flexible overlap with US/EU) Willing to relocate: No Technologies: TypeScript, React, Next.js, Vue, React Native, Node.js, NestJS, PostgreSQL, Prisma, Redis, GraphQL, Docker, LangChain, OpenAI API, AI agents, MCP Résumé/CV: [link to your CV, e.g. Google Drive or portfolio] Email: saifurdev26@gmail.com Frontend-focused full-stack engineer, 4 years remote. In the last year I shipped AI SaaS products end to end (Figma to production), several now earning recurring revenue, plus an App Store app. Looking for a founding or early engineer role, or contract work building MVPs with solo founders and small teams. Portfolio: https://saifgg.netlify.app · GitHub: https://github.com/bobiafk

Writing a TV player's core in Rust, shared with Kotlin and Swift via UniFFI Hey! I've been building Hey Stream, a free and open-source (GPL) TV player for Android TV, tablets and phones. Most players in this space are either paid, full of ads, or crawl on cheap boxes, so I wanted something simple and fast. The whole brain of the app is one Rust crate: API client, SQLite catalog cache, search, parental control, resume and "watched" tracking. The Android UI (Compose) only displays things and talks to the core through UniFFI. Swift bindings are generated too, for a future Apple TV app. What I learned along the way: - Cheap boxes are brutal. It has to stay smooth on a 2 GB box with a 32-bit userspace, so it ships armeabi-v7a next to arm64-v8a. Catalogs can reach 100k entries, so they live in SQLite (WAL, cached statements, paged queries) and are never loaded whole. - Provider APIs are a mess. Numbers sent as strings, maps instead of arrays, fields missing at random. Each entry is deserialized from its own RawValue, so one broken entry is skipped instead of failing the whole list. - TLS without JNI. reqwest + rustls with bundled Mozilla roots, so the core needs no setup on the Android side. - Panics don't vanish. A panic hook forwards the message and file:line to the app through a UniFFI foreign trait, so they show up in the crash reports (anonymous, and users can opt out). It costs nothing until something actually panics. - Tests never touch a real server: wiremock on the Rust side, MockWebServer on an emulator in CI. It's just a player: no content, not tied to any provider. Still early (test builds), so expect rough edges. Next on the list: instant search with SQLite FTS5 instead of LIKE, streaming JSON parsing so huge playlists don't eat all the RAM, and a benchmark on 100k items. Feedback on the core's design is very welcome. - Repo: Shweepsi/hey-stream-native - Releases (APK): github.com/Shweepsi/hey-stream-native/releases

@miles_matthias @ExaAILabs We want Exa wherever agents pick their tools! @treg_ai already lists our search and contents; we just sent a PR adding Podcasts and our new Lite mode for even cheaper high quality search :) treg#1381 t.co

DevRel Didn't Die, Its Audience Changed --- title: DevRel Didn't Die, Its Audience Changed published: true description: tags: ai, agents, devrel, mcp cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com canonical_url: debbie.codes --- Most evenings I put my agents to the test. I've been experimenting with a lot of stuff lately, and I'm literally taking products I'm curious about and building something with them. This is how I learn and experiment with a new product. Now, I'm not building something using a code editor, or writing code, or even reading through their docs. I know, stay with me here. You might all think, well then you're not gaining the technical skills required to understand this product. And you're right, I'm not. But that is not the objective of this test. I want to see if an agent can use the product and be successful with it. Then I want to understand what is missing, and how I can guide the agents, or the developers, to create the tools needed so the agents can use the product so much more successfully. I've built a tremendous amount of things, and I've documented everything in Notion. I spend a lot of time working through what we could build, why we should build it and what we need to think about. The next day I go through all the documentation in Notion and study it. Then I either build on it, or I get excited about a product and say, whoa, let's add this to my website. And if it feels a bit boring, that tells me something too, because I need to believe a product is interesting to advocate for it. This is how I get really excited about products. It's fascinating how much I can experiment with other products, and I also get to see where they fail when it comes to being agent first. DevRel's audience changed Many people say DevRel is dead. A lot of DevRel jobs were eliminated in the last year or so, yet with so many new products out there, there really is a need for DevRel and quite a number of these are hiring their first one. So what is DevRel now compared to what it was? I don't think anyone has the actual answers, and it's very different depending on the company and the product. > "AI agents are already using your APIs and skipping everything else. [...] DevRel isn't dead. But the old playbook is." (Amit Jotwani on X) If you're hiring for DevRel, I'd love to know why. What is it that's missing in your stack, what is it you need? Sometimes it's a mixture of things. Your engineers don't have the time to do the work that DevRels do, or don't have the interest, or simply don't have the skill set. A lot of really talented engineers find it very difficult to break complex tasks down into simplified versions so that people can learn them. Creating educational content is very difficult for a lot of highly technical engineers. They're also sometimes very deep in the product, so they don't realise the learning journey people have to go through to get there. At least that was the case in the original DevRel world. Now the one going through that learning journey might not be a person at all. People don't have to go through the documentation so much anymore. They don't even have to learn how to do something. They can just get it done. And this is where I think DevRel becomes agent rel. An agent is going to be using your product much more frequently than a developer will in the coming future, and some of you have probably seen this happen already. In 30 days of traffic to the docs Mintlify hosts, AI coding agents made 45.3% of requests, nearly as much as browsers at 45.8% (Mintlify). Netlify's Mathias Biilmann calls the product side of this agent experience, or AX. Agent rel is the DevRel side of it. I'm not the first to say it either: on 30 Oct, @teyc replied to one of my posts with "DevRel will be replaced by AgentRel", and I think that's spot on. > "'Agent Experience' is the new devX. How easy is it for an agent to set up, to advise its dev, to maintain once it's up?" (Rachel Nabors on X) Building my own hire me page I saw this for myself when I added a voice agent you can talk to. I first tried it in the ElevenLabs builder, then built it with my Grok Bot and the ElevenLabs API. Using an agent, I was much more successful in one way, but I failed a lot more in another. The reason I failed was that the agent didn't even send me through the guardrail section. When I first built it in their builder, rather than with an agent, it showed me that this was the next step I had to take. The agent skipped it. The UI teaches a human the next step, but nothing told my agent. Agents are going to miss steps, and that's a big problem, because I could think I've got an amazing voice agent, publish it, and the next minute I've got no guardrails, without even knowing they existed. I had to ask my agent to add them, and they're on now. Now here's the thing. You're saying, what do you mean you didn't know that existed? You should be technical enough to know all this, you should have studied all this, and that's why we shouldn't let agents just go and build things. I get you, I hear you. But this is the thing. The people building with agents now and in the near future won't all have studied this. If the guardrails step only lives in a dashboard, the agent won't find it, and neither will they. So what happens when you hand other products to a non-developer, a builder, an agent? What I found when I gave products to agents Most of these were built by my Grok Bot, with me just chatting, deciding what to build and guiding it. I only stepped in for a few sign-ups and logins, like a phone check. The clicking through dashboards and using the products was done by my bot, which I think is pretty fascinating, because that's normally the hard part of using any product: getting it up and running in an unfamiliar environment. An NVIDIA QA agent NeMo Agent Toolkit is NVIDIA's open source library for building and evaluating AI agents. My agents used it to build a QA agent that runs on a Nemotron model through NVIDIA's hosted endpoints and uses Playwright MCP to drive a real browser. Its job was to test a tiny movie app where we'd planted a bug in some builds, like a search that finds nothing, and answer PASS or FAIL with evidence. An AWS QA agent AgentCore Browser, part of Amazon Bedrock AgentCore, is a Chrome browser that AWS runs for you in the cloud. My agents built a QA agent where Amazon's small Nova Lite model drives that browser, checks a to-do app against acceptance criteria I wrote in plain English, and hands back a Playwright test. An MCP server on ngrok ngrok gives something running on your laptop a public web address, so tools in the cloud can reach it. I wanted to see if a cloud AI could test an app running on my laptop. My agents ran Playwright MCP locally, put it online with ngrok, and connected it to Grok on grok.com. In about 34 seconds it found a bug we'd planted in a tiny shop. Because that address gives control of a browser on my laptop, we kept it behind a secret link and only had it online for the test. A mock shop that let my agent through To understand how shops tell bots from people, my agents built a small mock shop in Node and Express with a stand-in risk checker that scores each visit from 0 to 100. It looks at clues like navigator.webdriver, a HeadlessChrome user agent, typing rhythm and mouse movement, plus a device ID from open source FingerprintJS. A plain headless Playwright script was blocked straight away. A Grok Bot driving its own browser was approved, because to our stand-in it looked human, which matters when that agent is shopping for a real person. That was one run against our own mock, not a real fraud system. These were all just small fun projects that could easily be turned into a talk or video or could be explored further. Who knows, maybe they will be. Anyone is going to be a builder, and they already are We are working in a world where it's not only developers who are going to be building things going forward. It's going to be builders: product managers, CEOs, anyone. SlashData estimates 16M to 22M people without a coding background already create working software with AI tools (SlashData), next to about 48.4M developers (SlashData developer population). Take any small business, like a hairdresser. They are going to be able to build an agent on their website to take appointments. And if that hairdresser is able to do that, then they should be able to be successful with your products without having to read docs or be technical to get something done. That might scare developers: if a hairdresser can just put an agent on a page, why do we need developers? Developers are still needed to build the tools that let agents do this work. And in bigger companies, we still need developers to check, verify and test what the agents make. Restaurant reservations are a good example. I went to a restaurant recently, and they didn't have anything on their website, so we had to make a phone call, a person had to answer it, and they had to look in a book to see if there was a table. It could be fixed by adding a simple booking form to their website, or better still, a voice agent for people who prefer to call, that can check if there's a table. I've been here before. I've spent years helping small businesses get online. Back then, I was the one advocating for websites, literally walking around where I lived trying to persuade small businesses to get a website. Restaurants, bars, taekwondo clubs, paint shops, you name it. Everything close by. And I built them, and they all ended up having websites. With restaurants especially, I had to convince them they needed an online presence, so that tourists coming to the area could look them up beforehand and find they existed. Then they could compete with the other restaurants more easily, and people were going to be booking online. At the time they were like, no, people don't do that. They're just going to walk into a restaurant. They're never going to look online for one. And now we spend most of our time looking online for restaurants, not walking past them. So there was definitely a need for that. Now we can take that even further with an agent on the page that answers the questions people can't find on the website. Are you open today, it's a bank holiday? Do you have gluten-free options for celiacs? What this means for DevRel So what am I learning, if I'm not learning the product the old way? It's a bit of all of it: where a product breaks for agents and how to fix it, how people build now, and who the new users are. DevRel is still about learning, but not about teaching it like before, because content creation is now so much faster to do. What DevRel still brings is a trusted human voice that people actually listen to. I know this sounds strange, because DevRel is developer relations, and I'm advocating for the role to be a bit more non-developer focused. The reason: we are going to have a hell of a lot more people building and shipping these kinds of products who don't have the developer skills we've had for the last 15 to 20 years. Things are going to change big time, and we need to be ready for that. We can't just gatekeep and say, well, if you don't have the coding skills, you shouldn't be able to build an agent. I think that's wrong. It's like websites. Before, you needed a developer to build and deploy a website. Now anyone can, and I think that's fantastic. That's the way it should be. What to do if you're in DevRel 1. Give your product to an agent with no docs. See how far it gets and where it gets stuck. 2. Put the critical steps where agents look. That means an MCP server, an llms.txt your docs actually link to, and your API responses, not only a step in your dashboard that a human would see. Ahrefs found that 97% of llms.txt files got no requests at all in May 2026, so a file nobody links to may not help much. 3. Test it with a non-developer. If someone who isn't a developer can't get it working with an agent, you've found your next piece of work. What I've built Here's some of what I've been building and trying out. I say I built it, but really I directed the agents. Making my own site work for agents - My hire me page has a voice agent, built on ElevenLabs Agents, so you can just ask it about me. Here's how I built and tested it. - WebMCP on my site gives browser agents 4 tools: list-videos, topic-brief, search-content and get-current-page (latest PR). WebMCP is still experimental. - An llms.txt, a map of my site for agents. Testing with agents - The NVIDIA, AWS, ngrok and mock shop tests above. - In my playwright-movies-app, an agent found and fixed messy accessible names on the movie cards. Teaching agents with skills - Learn agent skills. - In Grok Bot, I built skills that help me publish. When I drop a new video, they write its YouTube title, description and posts. They also publish my blog posts to my site and cross-post them, build my conference slide decks, and make tutorial videos with Remotion. Working with my bots - An Alexa skill so I can talk to my bots (code). To build it, I used Grok Bot's call feature to call my engineer bot, the one that had a cloud agent build the Cloudflare Worker behind the skill. I opened the Alexa developer console, told it what I wanted to do, and then we talked our way through it screen by screen, instead of reading the docs. - Asking for proof. After a batch of demo work, I asked my bot straight out: "Is all this real? Did you actually do all this, or is any of it hallucination?" It went back to the raw files, not its memory. My rule: if a bot can't point to a file, a log or a recording, the claim doesn't go on a slide. I spend half my time experimenting with agents now, and it makes me better at DevRel, or whatever the role should be called now. If I joined a team tomorrow, I'd know the direction I'd go, the demos I'd build, and how I'd talk to people about why the product is necessary, how to use it and where the gaps are. I'd try to fix those gaps within the product and make it more agent friendly. Not just agent friendly. I'd make sure non-developers can be successful with it too. What I really want is to help developers and non-developers build and work with AI agents, whether that's for personal use, a small business or a large enterprise. I don't know yet which company that will be with, but I'll keep going until the right one comes along. After a hard year with multiple layoffs, I'm looking for my next role in DevRel around AI agents, testing and MCP. Something that excites me and ignites my passion. Oh, and just so you know, I don't do coding challenges.

@OndrejMirtes Well, I hadn’t noticed this before launching fluidstan. Nice ❤️ I essentially applied the same approach to the #typo3 Fluid Template Engine at fluidstan/fluidstan.

Casas en venta en Medellín según parqueaderos: precio y m² de cada grupo En Medellín, una casa en venta del grupo «Sin parqueadero» se pide en 525 millones de pesos en la mediana y una del grupo «2 o más parqueaderos» en 2.200 millones de pesos (+319,0 %). Por… DOI: 10.5281/zenodo.23518877

hk21x/007-agentunderfire-recomp Welp there it is, now it just needs online multiplayer.

@sachintwtss Datastream, a privacy view-only wallet for cryptocurrencies; Bitcoin, ZCash, Ethereum marcfernandezo/datastream

@goon_nguyen CloudHarness MCP fits Guard’s server path. The guide covers the repo details for a HOL Guard PR: github.com/hashgraph-online/hol-guard/blob/main/d…

Casas en venta en Palmira según número de baños: precio y m² de cada grupo En Palmira, una casa en venta del grupo «2 baños» se pide en 320 millones de pesos en la mediana y una del grupo «4 o más baños» en 950 millones de pesos (+196,9 %). Por metro cuadrado,… DOI: 10.5281/zenodo.23522587

@hyperseref @ditzikow @spc @carmenli @silicondata @absurdistphil @jumptrading @brexton @unhedged21 @eqxlabs Slowly, then all at once :) arkhai-io/simple-compute-market

Self Hosted Diagram & Documentation | CTRoadmap 4 Months in and CTRoadmap is coming along great. User feedback has been invaluable and really helped shape the trajectory of the tool. Latest update included the new SYSTEM SNAPSHOT, a one-time scan of the host machine & LAN which should be super helpful for new users ingesting a larger system , while remaining a stand-alone non-integrated documentation tool. Also Included in v0.9.0 - ARM64 support - Expanded Notes for the Handbook (Markdown format) - Improved Connector lines modal Upcoming: - More polished Rack Builder with textures, variety of layouts & actual port connections with cables. - Functioning CODE EDITOR in the handbook to save & manage scripts & configs - Alternate CANVAS's with bundled layouts or "logical" vs "physical" layouts. CTRoadmap is a free homelab diagram & documentation tool, self-hosted in docker, chiefly for newer enthusiasts starting out and wanting a visual layout of their set-up PLUS track how it all works together. CTR is intentionally NON-INTEGRATED, does not manage , access or monitor your system. Everything you put in your Diagram is also converted into a scrollable , searchable HANDBOOK you can add to as well. It is not a monitoring dashboard like other foss solutions such as homelable. Built using CODEX, more detail on that process in the README on github

Idea validation is a core part of palgu spec validation. I've just made it open source. It's not just writing spec but validating across competition, metrics, business model etc. alinaqi/ideavalidator #superharness t.co

I built a free, open-source replacement for SteelSeries GG & Sonar on Linux — mixer, Sonar EQ, ChatMix, OLED, 20+ Arctis headsets reddit.com 📺 **Video (2:48): youtu.be Hi! I'm the developer of **Arctis Sound Manager (ASM)**. If you own a SteelSeries Arctis and game on Linux, you know the problem: GG and Sonar are Windows/macOS only, so half of the headset's features just aren't there. ASM fills that gap, natively, on top of PipeWire (no Wine, no vendor driver): - **Sonar-style mixer**: Game / Chat / Media / Aux / Output channels as real PipeWire devices. Drag an app's icon to another channel and it stays there. The **ChatMix dial** works, with an on-screen bar over fullscreen games. - **Sonar parametric EQ** for Game, Chat and Mic (up to 10 bands, applied live), **350+ game presets**, picked automatically when you launch a game from Steam, Lutris or Heroic. - **Spatial audio** (virtual 7.1 from the game's real surround channels), volume boost, smart volume. - **Mic processing**: RNNoise or DeepFilterNet noise suppression, noise gate, compressor. - **Headset control**: battery, ANC/transparency, sidetone, sleep timer, mic volume, and on base stations the **OLED screen** (time, weather, now playing, current EQ preset). Hardware EQ on eleven models. - **Streamer mode**: a separate mix for OBS, so viewers hear a clean game whatever you do with your own volume. - **Clips**: keeps the last 30 s in memory, one audio track per channel. Supported: Arctis Nova Pro (Wireless / Wired / Omni), Nova Elite, Nova 7 / 7P, Nova 5 / 5X, Nova 3, Arctis 7 / 7+, Arctis 9, Pro Wireless, Arctis 1 / 7X / 7P, GameBuds and more. Some newer models are still marked "in testing", so feedback is very welcome. **Install** (Arch/CachyOS, Fedora/Nobara, Ubuntu/Debian; SteamOS and Bazzite via Distrobox; NixOS module available): curl -fsSL loteran.github.io | bash Also on the AUR, COPR and a PPA if you prefer your package manager. - Video presentation: youtu.be - GitHub: loteran/Arctis-Sound-Manager - Community EQ presets & themes: loteran.github.io - Discord: discord.gg It's GPL-3.0, no account, no telemetry. Not affiliated with SteelSeries. Happy to answer questions, and if your headset misbehaves, open an issue: one diagnostic file is usually enough for me to fix it.

GitHub趋势：AI并行干活 今天这三个工具，让 AI 替你并行干活：agent-desktop 让 AI 智能体直接操作电脑；paperclip 统一管理工作中多个智能体，并行也不乱；worktrunk 用 Git worktree 开多个工作区，互不干扰。其中 agent-desktop 单日涨了两千多星。你最想先试哪一个？ 本期项目地址： - agent-desktop: vercel-labs/agent-desktop - paperclip: paperclipai/paperclip - worktrunk: max-sixty/worktrunk 背景音乐：Alexi Action《Lifelike (Dark Glitch Technology Background Music)》，CC BY 3.0 授权 #GitHub热门 #程序员 #开源 #AI #科技 #GitHub趋势

How to Diagnose Moderation API Timeout Errors in Node.js with Bounded Retries (and Why) Short answer: Treat a moderation API timeout as an unresolved decision, retry Node.js work only inside one deadline, and send exhausted reviews to a durable manual queue. A moderation timeout is a missing decision, not a negative decision. For a media platform reviewing code changes that can affect publishing workflows, the safest response is to keep the item unresolved, retry only within a deadline, and record enough state to prevent a late response from being applied twice. That gives the quality-versus-latency trade-off a hard boundary: spend the available review budget on a bounded number of attempts, then send the change to a durable review queue. The short answer sounds conservative because it is: a timeout is a transport fact, while a moderation result is a content decision, and conflating those two facts creates the kind of duplicate or incorrectly accepted review that a later dashboard cannot reconstruct cleanly. Keep it pending. This sounds less clever than retrying until the provider answers. It is also easier to operate. A timeout can happen after the remote service accepted the request, so an identical retry may create two decisions. The caller must therefore separate transport uncertainty from moderation output. How should Node.js handle moderation API timeout errors? It tells you that the caller did not receive a usable response before its deadline. It does not tell you that the content was safe, unsafe, or never processed. That distinction is the first incident lesson. In a code-review workflow for a media organization, the item might contain a proposed change to a caption filter, a transcript import, or a publishing rule. The structured finding should have an explicit state such as pending, accepted, rejected, or manual_review; it should not infer accepted from an empty response. The request also needs a stable review ID, because retry identity is part of the data model rather than a detail hidden inside an HTTP client. I initially treated a timeout as a request that had failed before leaving the process. That assumption breaks at the exact boundary operators care about: the network can fail after the remote side has started work. The corrected rule is simple: retry an unresolved operation, but make completion conditional on the review ID still being unresolved. The quality target comes first. If the review SLO is 30 seconds, a 10-second timeout followed by unlimited retries is not resilience; it is queue starvation wearing a retry label. Set a deadline before choosing a retry Use a single end-to-end deadline, then derive each attempt's timeout from the time remaining. Exponential backoff with jitter reduces synchronized retries, but it cannot create capacity, and it must never extend the request beyond the review budget. A practical policy for moderate content is two attempts after the initial call, with a short initial delay and a final handoff to a human or durable queue. The exact values belong in configuration and should be validated against the measured service-time distribution. The following Go example models the control path. The interface is deliberately generic: the review service can be replaced without changing the state machine. The result is accepted only when the caller receives a complete structured finding, and a timeout leaves the operation pending. package review import ( "context" "errors" "fmt" "math/rand" "time" ) var ErrTimedOut = errors.New("review attempt timed out") type Finding struct { ReviewID string State string Reasons []string } type Client interface { Review(ctx context.Context, reviewID string, content []byte) (Finding, error) } func ReviewWithBudget(parent context.Context, client Client, reviewID string, content []byte, budget time.Duration) (Finding, error) { deadline := time.Now().Add(budget) var lastErr error for attempt := 0; attempt < 3; attempt++ { remaining := time.Until(deadline) if remaining <= 0 { return Finding{ReviewID: reviewID, State: "manual_review"}, ErrTimedOut } ctx, cancel := context.WithTimeout(parent, remaining) finding, err := client.Review(ctx, reviewID, content) cancel() if err == nil && finding.ReviewID == reviewID && finding.State != "" { return finding, nil } lastErr = err if attempt == 2 { break } delay := time.Duration(100*(1<<attempt)+rand.Intn(75)) * time.Millisecond if delay >= time.Until(deadline) { break } select { case <-parent.Done(): return Finding{ReviewID: reviewID, State: "manual_review"}, parent.Err() case <-time.After(delay): } } return Finding{ReviewID: reviewID, State: "manual_review"}, fmt.Errorf("review %s unresolved: %w", reviewID, lastErr) } In a Node.js service, the same rules map to an AbortController deadline, a retry counter, and an idempotency key carried through the request. The language is incidental. The important checks are the stable ID, the remaining budget, and the refusal to convert uncertainty into a safe result. How do you prevent a late response from winning? Retries need a commit rule. Store the review record before the first attempt with a unique review ID and a state of pending. Each response handler performs a conditional transition: pending may become accepted or rejected; manual_review may be updated only by an explicitly authorized workflow. A response that arrives after the deadline can be logged and discarded if the record has already moved on. That conditional write is more valuable than another retry strategy. Without it, attempt one can time out locally, attempt two can return a result, and the delayed response from attempt one can overwrite the newer finding. The resulting incident is difficult to reproduce because both responses may be individually valid. Keep the payload and decision separate. The payload may be retained for audit according to the media platform's retention policy, while the decision record carries the review ID, attempt number, timestamps, timeout classification, and final state. Do not log raw user content by default; logs should support diagnosis without becoming a second content store. What should the SLO measure? Measure more than the percentage of successful HTTP calls. A useful review SLO includes the fraction of items reaching a complete structured finding within the budget, the age of the manual-review queue, and the rate of duplicate or conflicting completion attempts. Latency percentiles show pressure; they do not show whether the answer was correct. Capacity planning starts with arrival rate and the review budget. If a queue receives 20 items per second and each attempt occupies a worker for 400 milliseconds, retries can consume the equivalent of eight workers before any increase in content volume. That is why retry counts belong in the capacity model. The exact worker count still depends on concurrency, service time, and the admission-control policy; the example is a unit calculation, not a capacity promise. Instrument these fields: review_id, attempt number, elapsed time, outcome class, remaining budget, and final state. Sample or redact content-bearing fields. Alert on budget exhaustion and queue age, not merely on raw timeout count, because a timeout that is recovered within the SLO has a different operational meaning from one that creates manual work. When should this advice change? Do not apply the same policy to every content class. A low-risk caption suggestion may tolerate a manual queue after bounded retries; a workflow that can publish restricted material may require fail-closed handling and a human gate. The decision belongs in the risk policy, not in an HTTP helper shared by unrelated jobs. Likewise, a long-running asynchronous review should not be forced into a synchronous request budget. Submit once with a stable ID, poll or consume a callback through an authenticated channel, and make the completion transition idempotent. If the system cannot prove that a callback belongs to the original review, it should remain unresolved. A buy-versus-build decision should use the same criteria. A managed moderation endpoint may reduce operational work but can constrain timeout semantics, data residency, or observability; a self-hosted component may expose more controls while transferring patching, capacity, and on-call responsibility to the platform team. The relevant comparison is the review SLO and failure-handling contract, not a feature checklist. | Decision area | Managed service | Self-hosted component | | --- | --- | --- | | Capacity | Less infrastructure to run; quotas and backpressure remain external constraints | Direct control of workers and queues; scaling becomes an owned operation | | Failure evidence | Usually limited to the response and provider metrics available to you | Full request, queue, and worker telemetry if instrumented well | | Change burden | Provider changes require contract and regression checks | Model, runtime, security, and dependency updates are your responsibility | | Lock-in risk | Higher when request and decision semantics are proprietary | Lower at the interface boundary if the review contract stays generic | The comparison is conditional. A team with a strong operations function may value control; a small team may value less infrastructure. Neither choice removes the need for a deadline, a durable state transition, or a manual-review path. The operational rule Treat a moderation timeout as an unresolved review with a finite budget. Retry with jitter only while time remains, preserve a stable review ID, commit results conditionally, and route exhausted work to a visible queue. This keeps latency bounded without pretending that an absent response is a safe decision. For a media platform, that is the useful invariant: quality is protected by explicit uncertainty, while latency is protected by a deadline that the retry loop is not allowed to negotiate. Sources - nodejs.org - developer.mozilla.org - rfc-editor.org - openai/whisper

@mircoveltri The readiness card plus separate panels sounds useful. To list it, check for a duplicate, try the server, then open a PR with a short description and repo link. Guide: github.com/hashgraph-online/awesome-ai-plugins/bl…

le das un video y te da un rig? wut? canitcode/video2rig

it's still early/still an experiment, but would love some feedback modem-dev/boxery

@chasedovey That one-provider boundary is a useful safeguard. If you want to add harness-interface support to HOL Guard, the opt-in command guide shows the PR and fixture steps: github.com/hashgraph-online/hol-guard/blob/main/d…

Waypoint: A zero-telemetry spatial canvas browser for macOS Waypoint: A zero-telemetry spatial canvas browser for macOS — built, tested, and shipped with Hermes Agent (Open Source) Repository: rpmalouin/waypoint (MIT Licensed, Free & Open Source) preview.redd.it What Waypoint Does Waypoint is a local-first, zero-telemetry spatial canvas browser built natively on Electron and TypeScript for macOS Apple Silicon. Instead of relying on bloated browser extensions or heavy tab-management runtimes, it organizes web browsing across an infinite 2D drafting canvas using native WebContentsView tiles. - 3-Tier View Architecture: Clean separation between the Canvas base, native guest WebContentsView tiles, and an Overlay HUD/dock. - True Container Jars: Isolated session partitions (@work, u/shopping, ephemeral temp:anon-...) that maintain strictly separate cookie, cache, and IndexedDB storage jars. - Network-Level Interception: Zero upstream telemetry and an embedded 41,000-host filter list (StevenBlack) dropping trackers and ads before TCP handshakes initiate. - Local-First Tooling: Per-tile inverted dark mode, atomic Markdown article clipper, HSL color harmonies with SVG canvas grain, and flat, container-aware bookmarks (bookmarks.json). - Session Persistence & Autosave: Debounced autosave (500ms) with clean exit flush, viewport/camera restore, and multi-display window geometry matching. - Native Packaging & Maintenance: Packaged as an ad-hoc signed /Applications/Waypoint.app, paired with an automated nightly Chromium/Electron update pipeline driven by a signed launchd helper to safely navigate macOS TCC volume permissions. How Hermes Agent Built It Waypoint wasn’t coded by hand—it was built, tested, audited, and maintained end-to-end through Hermes Agent operating in an autonomous developer loop using DeepSeek Flash. - Token Economics: The entire production cycle chewed through ~340 million tokens across 2,600+ API calls for under $4.00 total compute cost. With massive context caching, Hermes processed full AST file payloads and entire repository diff sweeps on every turn. - Zero-Regression Gate Discipline: Hermes ran under strict pre-commit test gates on every single pass. The repository currently maintains clean TypeScript across 61 files, 251 unit tests, and 326 automated smoke assertions. If a gate turned red, the agent automatically reverted and re-evaluated before touching the tree. - Navigating Native macOS Edge Cases: - BaseWindow Cocoa Roles: Caught that standard Electron role: 'copy' and role: 'paste' handlers target the parent window and fail on child WebContentsView tiles, replacing them with direct webContents responder dispatch. - macOS TCC Attribution: Engineered a signed C-based LSUIElement helper (WaypointNightly.app) utilizing fork()/execl() so unattended launchd maintenance jobs retain responsible attribution to access secondary volumes without tripping EPERM. - Auditable Tooling: Hermes maintained its own synchronized AST code graph (head_matches_build: true), Obsidian engineering logs, falsification testing records, and Kanban task tracking throughout the build. Setup & Local Build Requirements: Apple Silicon Mac (arm64), Node.js 20+. git clone rpmalouin/waypoint cd waypoint npm install npm run check # runs typecheck + 251 unit tests npm run smoke # runs 326 headless smoke checks npm run build:app # builds, ad-hoc signs, and installs /Applications/Waypoint.app The repo is fully open source under MIT. Happy to dive into the architecture, the container partitioning model, or the specific Hermes prompts and test harness used to orchestrate the build. If you want it, you fork it and you support your own installation. I only fix or improve my repos for my use.

Kindle won’t let you back up your books anymore. Here’s how I host mine at home and read them on my phone (free app) Amazon removed Download & Transfer last year, so the Kindle books you buy can't really be backed up anymore. Your books, highlights and reading position all live on their servers. So I keep my books on my home server instead through Calibre. Here's my setup: 1. calibre on my NAS. calibre is a free app that organizes your ebook collection, like a music library but for books. I drop my EPUBs and PDFs into it. 2. calibre's content server. It's built into calibre (Connect/share > Start Content server) and puts the library on my home network, like Plex or Jellyfin but for books. If you'd rather run it in Docker, calibre-web does the same job. 3. Athene on my phone. That's the app I made, a free EPUB and PDF reader for iPhone, iPad and Android. Point it at your server's address (something like 192.168.1.20) and your library shows up with covers, authors, series and tags. Tap a book to download it, and your highlights, notes and progress can go back to calibre. 4. Optional: my Kobo. It runs KOReader (a free reading app for e-readers), and a small open source sync server on my UGREEN NAS keeps my place, highlights and notes the same on my Kobo and my phone: adityasreedhar/athene-sync Athene also reads any OPDS catalog (the standard way book servers share their catalog) and syncs with any KOSync server. No account, ads or in-app purchases, and your books and notes never pass through a server of mine. I also spent a lot of time on the UI/UX so it looks good and is easy to use. The app is closed source, the sync server is open. Heads up: it can't open books bought on Kindle, because they're locked with DRM. It's for DRM-free books, like the ones in your calibre library, stores that sell DRM-free, or the 70,000 free classics in the app. iOS: apps.apple.com Android: play.google.com Step-by-step guides: theadipost.com Open to feedback, thanks!

🤖 TokenEconomizer ⭐ 4,444 stars AI coding agents can burn through your API budget fast. Here’s how to slash token costs without sacrificing code quality. 🔗 microsoft/TokenEconomizer #AI #MachineLearning t.co

Scaling Declarative Schema Synchronization: Concurrency, Locking, and Distributed Safety Scaling Declarative Schema Synchronization: Concurrency, Locking, and Distributed Safety We’ve all been there: you open up your db/migration folder on a Monday morning only to find a chaotic stack of V142__add_status.sql, V143__fix_status_typo.sql, and a broken CI build because two feature branches collided on V144. Traditional migration tools like Flyway and Liquibase served us well for a long time, but in fast-moving, distributed microservices, linear script chains create constant friction and Git merge hell. In my previous post, Stop Writing Database Migration Scripts: Declarative Schema Sync for Java, we looked at how shifting to declarative schema synchronization using SchemaSynchronizer lets you define your database's desired state in a single configuration file and let the engine handle the safe, additive diffs automatically. But what happens when you take that declarative engine and drop it into a horizontally autoscaled Kubernetes environment where five pods boot up simultaneously and try to reconcile the schema at the exact same millisecond? Welcome to the split-brain zone. In this technical deep-dive, we're tackling concurrent execution safety, database-level advisory locks, enterprise safety guardrails, and why declarative sync scales at O(M) instead of dragging down your startup times with cumulative O(N) script bloat. --- 1. Concurrency, Locking, and Distributed Safety The Split-Brain Problem in Horizontal Deployments Consider a standard rolling deployment in Kubernetes where a Spring Boot application scales from 3 to 5 replicas. As the new pods initialize, their initialization hooks trigger the schema synchronization engine (SchemaSynchronizer) against a shared PostgreSQL database. Without proper coordination, the following sequence of failure occurs: 1. Catalog Inspection Race: Pod A and Pod B read the database metadata concurrently. Both observe that a new index (idx_work_items_status) is missing. 2. Concurrent DDL Issuance: Both pods issue CREATE INDEX IF NOT EXISTS idx_work_items_status ON work_items (status); at millisecond proximity. 3. Catalog Locking Contention: Depending on the database engine, concurrent DDL statements on the same relation either cause lock contention, throw exclusive table access errors, or result in duplicate execution overhead that wastes database resources and risks connection timeouts. To guarantee single-writer safety across distributed nodes, we must introduce a reliable synchronization barrier. Distributed Locking Mechanisms: Advisory Locks vs. External Coordinators When choosing a locking mechanism for database schema synchronization, introducing external dependencies like Redis or ZooKeeper adds unnecessary operational complexity. The safest and most resilient coordinator is often the database itself. Leveraging PostgreSQL Advisory Locks For PostgreSQL deployments, session-level or transaction-level advisory locks provide an elegant mechanism for application-level mutual exclusion without locking actual table rows or schemas. public class DistributedSchemaLock { private static final long SCHEMA_SYNC_LOCK_ID = 9876543210L; public boolean acquireLock(Connection connection) throws SQLException { try (PreparedStatement stmt = connection.prepareStatement("SELECT pg_try_advisory_lock(?)")) { stmt.setLong(1, SCHEMA_SYNC_LOCK_ID); try (ResultSet rs = stmt.executeQuery()) { if (rs.next()) { return rs.getBoolean(1); } } } return false; } public void releaseLock(Connection connection) throws SQLException { try (PreparedStatement stmt = connection.prepareStatement("SELECT pg_advisory_unlock(?)")) { stmt.setLong(1, SCHEMA_SYNC_LOCK_ID); stmt.execute(); } } } Idempotency and Atomic DDL Transactions Unlike DML statements (INSERT, UPDATE), many relational database engines handle DDL statements (ALTER TABLE, DROP INDEX) differently regarding transaction safety. - Idempotent DDL Generation: Every statement generated by the diff engine is constructed with safety clauses (IF NOT EXISTS, conditional guards). - Statement-Level Chunking & Error Isolation: The engine captures vendor error codes, rolls back transactional boundaries where supported, and halts with diagnostic reports rather than leaving the database half-migrated. --- 2. Enterprise Guardrails: Dry-Runs, Impact Analysis, and Rollback Strategies In an imperative workflow, a rogue script can slip into a pull request unnoticed. In a declarative model, the synchronization engine inspects the delta between desired and actual state on the fly. Without automated pre-flight checks, a developer could inadvertently introduce a destructive change. Automated Impact Analysis & Risk Classification Before any DDL statement is dispatched, the diff engine runs an impact classification pass: 1. Tier 1 (Safe Additive): Operations guaranteed not to cause data loss or table locks (auto-applied). 2. Tier 2 (Modifying / Warning): Operations altering data types or adding constraints (trigger warnings). 3. Tier 3 (Destructive / Critical): Operations involving data destruction or irreversible truncation (triggers an immediate fail-closed boundary). The Dry-Run Mode: Simulating Execution Plans In CI/CD pipelines or staging validation gates, operators need to inspect what changes would be made without mutating the target database. The dry-run execution path builds the full DDL execution plan and outputs proposed statements without sending execution commands over JDBC. Enforcing Manual Review Boundaries When a Tier 3 destructive change is detected, SchemaSynchronizer deliberately halts execution and outputs copyable migration scripts for manual DBA sign-off, preventing accidental production data loss. --- 3. Performance Benchmarks: Declarative Evaluation vs. Linear Script Execution The Scaling Trap of Linear History (O(N) vs. O(M)) - Imperative Migrations (O(N)): Startup latency grows linearly with the cumulative count of historical migration scripts (e.g., parsing 150+ scripts sequentially). - Declarative Synchronization (O(M)): Startup cost is tied strictly to the size of the current active schema (M). Initialization cost remains flat and constant regardless of project age. Benchmark Summary Table | Metric / Scenario | Imperative Migrations (150+ Scripts) | Declarative Sync (SchemaSynchronizer) | | :--- | :--- | :--- | | Cold Startup Latency | ~4,200 ms | ~650 ms | | Warm Rolling Restart | ~1,800 ms | ~350 ms | | Database Round-Trips | N round-trips | 1 batched round-trip | | CI Merge Conflicts | High | Zero | --- Conclusion Moving from imperative script chains to declarative schema synchronization eliminates Git merge hell, keeps application startup times fast and predictable, and establishes robust enterprise safety guardrails for modern distributed Java microservices. To explore the implementation, contribute, or try it out, check out the SchemaSynchronizer open-source repository.