🛠️ Hacker News Tools

[DevOps] Show HN: Encore – Type-safe back end framework that generates infra from code

[Other] Reproducible C++ builds by logging Git hashes

[CLI Tool] CLI tool to check the Git status of multiple projects

[Testing] RegreSQL: Regression Testing for PostgreSQL Queries

[Database] Show HN: DBOS Java – Postgres-Backed Durable Workflows Hi HN - I’m Peter, here with Harry (devhawk), and we’re building DBOS Java, an open-source Java library for durable workflows, backed by Postgres.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;dbos-inc&#x2F;dbos-transact-java" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dbos-inc&#x2F;dbos-transact-java</a><p>Essentially, DBOS helps you write long-lived, reliable code that can survive failures, restarts, and crashes without losing state or duplicating work. As your workflows run, it checkpoints each step they take in a Postgres database. When a process stops (fails, restarts, or crashes), your program can recover from those checkpoints to restore its exact state and continue from where it left off, as if nothing happened.<p>In practice, this makes it easier to build reliable systems for use cases like AI agents, payments, data synchronization, or anything that takes hours, days, or weeks to complete. Rather than bolting on ad-hoc retry logic and database checkpoints, durable workflows give you one consistent model for ensuring your programs can recover from any failure from exactly where they left off.<p>This library contains all you need to add durable workflows to your program: there&#x27;s no separate service or orchestrator or any external dependencies except Postgres. Because it&#x27;s just a library, you can incrementally add it to your projects, and it works out of the box with frameworks like Spring. And because it&#x27;s built on Postgres, it natively supports all the tooling you&#x27;re familiar with (backups, GUIs, CLI tools) and works with any Postgres provider.<p>If you want to try it out, check out the quickstart:<p><a href="https:&#x2F;&#x2F;docs.dbos.dev&#x2F;quickstart?language=java" rel="nofollow">https:&#x2F;&#x2F;docs.dbos.dev&#x2F;quickstart?language=java</a><p>We&#x27;d love to hear what you think! We’ll be in the comments for the rest of the day to answer any questions.

[Other] Show HN: Agent-to-code JIT compiler for Z3-theorem-proving agents

[Other] Show HN: I made an open-source Rust program for memory-efficient genomics My cofounder and I run a startup in oncology, where we handle cancer genomics data. It occurred to me that, thanks to a recent complexity theory result, there&#x27;s a clever way to run bioinformatics algorithms using far less RAM. I built this Rust engine for running whole-genome workloads in under 100MB of RAM. Runtime is a little longer as a result - O(TlogT) instead of O(T). But it should enable whole-genome analytics on consumer-grade hardware.

[CLI Tool] Show HN: ChatExport Structurer – parse ChatGPT/Claude exports into queryable SQL I wanted to query my own chat history but the JSON exports were a mess to work with. Built a small parser that turns them into clean SQL databases. Parsed 70k+ messages across multiple models. Useful for analyzing chat history, building a personal knowledge base, or archiving conversations. Simple CLI, open source.

[Testing] Show HN: Tokenflood – simulate arbitrary loads on instruction-tuned LLMs Hi everyone, I just released an open source load testing tool for LLMs:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood</a><p>=== <i>What is it and what problems does it solve?</i> ===<p>Tokenflood is a load testing tool for instruction-tuned LLMs hat can simulate arbitrary LLM loads in terms of prompt, prefix, and output lengths and requests per second. Instead of first collecting prompt data for different load types, you can configure the desired parameters for your load test and you are good to go. It also let&#x27;s you assess the latency effects of potential prompt parameter changes before spending the time and effort to implement them.<p>I believe it&#x27;s really useful for developing latency sensitive LLM applications and * load testing self-hosted LLM model setups * Assessing the latency benefit of changes to prompt parameters before implementing those changes * Assessing latency and intraday variation of latency on hosted LLM services before sending your traffic there<p>=== <i>Why did I built it?</i> ===<p>Over the course of the past year, part of my work has been helping my clients to meet their latency, throughput and cost targets for LLMs (PTUs, anyone? ). That process involved making numerous choices about cloud providers, hardware, inference software, models, configurations and prompt changes. During that time I found myself doing similar tests over and over with a collection of adhoc scripts. I finally had some time on my hands and wanted to properly put it together in one tool.<p>=== <i>What am I looking for?</i> ===<p>I am sharing this for three reasons: Hoping this can make other&#x27;s work for latency-sensitive LLM applications simpler, learning and improving from feedback, and finding new projects to work on.<p>So please check it out on github (<a href="https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood</a>), comment, and reach out at thomas@werkmeister.me or on linkedin(<a href="https:&#x2F;&#x2F;www.linkedin.com&#x2F;in&#x2F;twerkmeister&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.linkedin.com&#x2F;in&#x2F;twerkmeister&#x2F;</a>) for professional inquiries.<p>=== Pics ===<p>image of cli interface: <a href="https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood&#x2F;blob&#x2F;main&#x2F;images&#x2F;cli.png?raw=true" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood&#x2F;blob&#x2F;main&#x2F;images&#x2F;...</a><p>result image: <a href="https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood&#x2F;blob&#x2F;main&#x2F;images&#x2F;self-hosted_shorter_output_latency_percentiles.png?raw=true" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;twerkmeister&#x2F;tokenflood&#x2F;blob&#x2F;main&#x2F;images&#x2F;...</a>

[API/SDK] Show HN: DeltaGlider – Store 4TB of build artifacts in 5GB DeltaGlider is a CLI&#x2F;SDK similar to `aws s3` or `boto3`.<p>UPLOAD: It stores the first file in a S3 path as a full-size (reference), but saves next uploaded archives as deltas (tiny binary diffs) with respect to the reference.<p>DOWNLOAD: it reconstructs the original file on the fly, bit-perfect and verified with SHA256.<p>Why Xdelta3? It&#x27;s a compression-aware and block-level binary diff algorithm. Perfect for representing differences between archives, where small changes shift bytes but most content stays the same. It can efficiently delta compress ZIP&#x2F;JAR&#x2F;TAR archives up to 99.9% between versions, provided the difference in compressed content is overall small.<p>Killer use cases Software versioning, periodic db. backups, JAR, ZIP, TGZ.<p>The impact for us was &quot;2 orders of magnitude&quot; storage price reduction. I hope you can benefit from it too!<p>License: GPLv3<p>Feedback and contributions are super welcome!

[Database] Show HN: YaraDB – Lightweight open-source document database built with FastAPI

[Other] Show HN: Real-time 4D Julia set navigation via gamepad I&#x27;ve written Atlas, a GPU scripting language that eliminates the boilerplate of managing textures and uniforms. Here are some demos including 4D fractal exploration with gamepad controls. Press 7 to see the Julia set, and try reloading if you see rectangles&#x2F;it glitches. Documentation: <a href="https:&#x2F;&#x2F;banditcat.github.io&#x2F;Atlas&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;banditcat.github.io&#x2F;Atlas&#x2F;index.html</a> *requires approximately an RTX 3080.

[Other] Performance hacks for faster Python code

[Other] Show HN: Creavi Macropad – Built a wireless macropad with a display Hey HN,<p>We built a wireless, low-profile macropad with a display called the Creavi Macropad. It lasts at least 1 month on a single charge. We also put together a browser-based tool that lets you update macros in real time and even push OTA updates over BLE. Since we&#x27;re software engineers by day, we had to figure out the hardware, mechanics, and industrial design as we went (and somehow make it all work together). This post covers the build process, and the final result.<p>Hope you enjoy!

[Other] Terminal Latency on Windows (2024)

[Other] Show HN: Git Quick Stats – The Easiest Way to Analyze Any Git Repositor

[Other] Grebedoc – static site hosting for Git forges

[Testing] Show HN: Tusk Drift – Open-source tool for automating API tests Hey HN, I&#x27;m Marcel from Tusk. We’re launching Tusk Drift, an open source tool that generates a full API test suite by recording and replaying live traffic.<p>How it works:<p>1. Records traces from live traffic (what gets captured)<p>2. Replays traces as API tests with mocked responses (how replay works)<p>3. Detects deviations between actual vs. expected output (what you get)<p>Unlike traditional mocking libraries, which require you to manually emulate how dependencies behave, Tusk Drift automatically records what these dependencies respond with based on actual user behavior and maintains recordings over time. The reason we built this is because of painful past experiences with brittle API test suites and regressions that would only be caught in prod.<p>Our SDK instruments your Node service, similar to OpenTelemetry. It captures all inbound requests and outbound calls like database queries, HTTP requests, and auth token generation. When Drift is triggered, it replays the inbound API call while intercepting outbound requests and serving them from recorded data. Drift’s tests are therefore idempotent, side-effect free, and fast (typically &lt;100 ms per test). Think of it as a unit test but for your API.<p>Our Cloud platform does the following automatically:<p>- Updates the test suite of recorded traces to maintain freshness<p>- Matches relevant Drift tests to your PR’s changes when running tests in CI<p>- Surfaces unintended deviations, does root cause analysis, and suggests code fixes<p>We’re excited to see this use case finally unlocked. The release of Claude Sonnet 4.5 and similar coding models have made it possible to go from failing test to root cause reliably. Also, the ability to do accurate test matching and deviation classification means running a tool like this in CI no longer contributes to poor DevEx (imagine the time otherwise spent reviewing test results).<p>Limitations:<p>- You can specify PII redaction rules but there is no default mode for this at the moment. I recommend first enabling Drift on dev&#x2F;staging, adding transforms (<a href="https:&#x2F;&#x2F;docs.usetusk.ai&#x2F;api-tests&#x2F;pii-redaction&#x2F;basic-concepts">https:&#x2F;&#x2F;docs.usetusk.ai&#x2F;api-tests&#x2F;pii-redaction&#x2F;basic-concep...</a>), and monitoring for a week before enabling on prod.<p>- Expect a 1-2% throughput overhead. Transforms result in a 1.0% increase in tail latency when a small number of transforms are registered; its impact scales linearly with the number of transforms registered.<p>- Currently only supports Node backends. Python SDK is coming next.<p>- Instrumentation limited to the following packages (more to come): <a href="https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;drift-node-sdk?tab=readme-ov-file#requirements" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;drift-node-sdk?tab=readme-ov-fil...</a><p>Let me know if you have questions or feedback.<p>Demo repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;drift-node-demo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;drift-node-demo</a>

[Monitoring/Observability] Show HN: Linnix – eBPF observability that predicts failures before they happen I kept missing incidents until it was too late. By the time my monitoring alerted me, servers&#x2F;nodes were already unrecoverable.<p>So I built Linnix. It watches your Linux systems at the kernel level using eBPF and tries to catch problems before they cascade into outages.<p>The idea is simple: instead of alerting you after your server runs out of memory, it notices when memory allocation patterns look weird and tells you &quot;hey, this looks bad.&quot;<p>It uses a local LLM to spot patterns. Not trying to build AGI here - just pattern matching on process behavior. Turns out LLMs are actually pretty good at this.<p>Example: it flagged higher memory consumption over a short period and alerted me before it was too late. Turned out to be a memory leak that would&#x27;ve killed the process.<p>Quick start if you want to try it:<p><pre><code> docker pull ghcr.io&#x2F;linnix-os&#x2F;cognitod:latest docker-compose up -d </code></pre> Setup takes about 5 minutes. Everything runs locally - your data doesn&#x27;t leave your machine.<p>The main difference from tools like Prometheus: most monitoring parses &#x2F;proc files. This uses eBPF to get data directly from the kernel. More accurate, way less overhead.<p>Built it in Rust using the Aya framework. No libbpf, no C - pure Rust all the way down. Makes the kernel interactions less scary.<p>Current state: - Works on any Linux 5.8+ with BTF - Monitors Docker&#x2F;Kubernetes containers - Exports to Prometheus - Apache 2.0 license<p>Still rough around the edges. Actively working on it.<p>Would love to know: - What kinds of failures do you wish you could catch earlier? - Does this seem useful for your setup?<p>GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;linnix-os&#x2F;linnix" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;linnix-os&#x2F;linnix</a><p>Happy to answer questions about how it works.

[Other] Listen to Database Changes Through the Postgres WAL