The best Hacker News stories from Show from the past week
Latest posts:
I'm starting a social club to solve the male loneliness epidemic
The other day I saw a post here on HN that featured a NYT article called "Where Have All My Deep Male Friendships Gone?" (<a href="https://news.ycombinator.com/item?id=44098369">https://news.ycombinator.com/item?id=44098369</a>) and it definitely hit home. As a guy in my early 30s, it made me realize how I've let many of my most meaningful friendships fade. I have a good group of friends - and my wife - but it doesn't feel like when I was in college and hung out with a crew of 10+ people on a weekly basis.
So, I decided to do something about it. I’ve launched wave3.social - a platform to help guys build in-person social circles with actual depth. Think parlor.social or timeleft for guys: curated events and meaningful connections for men who don’t want their friendships to atrophy post-college.<p>It started as a Boston-based idea (where I live), but I built it with flexibility in mind so it could scale to other cities if there’s interest. It’s intentionally not on Meetup or Facebook - I wanted something that feels more intentional, with a better UX and less noise.<p>Right now, I'm in the “see if this resonates with anyone” stage. If this sounds interesting to you and you're in Boston or another city where this type of thing might be needed, drop a comment or shot me an email. I'd love to hear any feedback on the site and ideas on how we can fix the male loneliness epidemic in the work-from-home era.
I'm starting a social club to solve the male loneliness epidemic
The other day I saw a post here on HN that featured a NYT article called "Where Have All My Deep Male Friendships Gone?" (<a href="https://news.ycombinator.com/item?id=44098369">https://news.ycombinator.com/item?id=44098369</a>) and it definitely hit home. As a guy in my early 30s, it made me realize how I've let many of my most meaningful friendships fade. I have a good group of friends - and my wife - but it doesn't feel like when I was in college and hung out with a crew of 10+ people on a weekly basis.
So, I decided to do something about it. I’ve launched wave3.social - a platform to help guys build in-person social circles with actual depth. Think parlor.social or timeleft for guys: curated events and meaningful connections for men who don’t want their friendships to atrophy post-college.<p>It started as a Boston-based idea (where I live), but I built it with flexibility in mind so it could scale to other cities if there’s interest. It’s intentionally not on Meetup or Facebook - I wanted something that feels more intentional, with a better UX and less noise.<p>Right now, I'm in the “see if this resonates with anyone” stage. If this sounds interesting to you and you're in Boston or another city where this type of thing might be needed, drop a comment or shot me an email. I'd love to hear any feedback on the site and ideas on how we can fix the male loneliness epidemic in the work-from-home era.
Show HN: Onlook – Open-source, visual-first Cursor for designers
Hey HN, I’m Kiet – one half of the two-person team building Onlook (<a href="https://beta.onlook.com/">https://beta.onlook.com/</a>), an open-source [<a href="https://github.com/onlook-dev/onlook/">https://github.com/onlook-dev/onlook/</a>] visual editor that lets you edit and create React apps live on an infinite canvas.<p>We launched Onlook [1][2] as a local-first Electron app almost a year ago. Since then, “prompt-to-build” tools have blown up, but none let you design and iterate visually. We fixed that by taking a visual-first, AI-powered approach where you can prompt, style, and directly manipulate elements in your app like in a design tool.<p>Two months ago, we decided to move away from Electron and rewrite everything for the browser. We wanted to remove the friction of downloading hundreds of MBs and setting up a development environment just to use the app. I wrote more here [3] about how we did it, but here are some learnings from the whole migration:<p>1. While most of the React UI code can be reused, mapping from Electron’s SPA experience to a Next.js app with routes is non-trivial on the state management side.<p>2. We were storing most of the data locally as large JSON objects. Moving that to a remote database required major refactoring into tables and more loading states. We didn’t have to think as hard about querying and load time before.<p>3. Iframes in the browser enforce many more restrictions than Electron webview. Working around this required us to inject code directly into the user project in order to do cross-iframe communication.<p>4. Keeping API keys secure is much easier on a web application than an Electron app. In Electron, every key we leave on the client can be statically accessed. Hence, we had to proxy any SDK we used that required an API key into a server call. In the web app, we can just keep the keys on the server.<p>5. Pushing a release bundle in Electron can take 1+ hours. And some users may never update. If we had a bug in the autoupdater itself, certain users could be “stranded” in an old version forever, and we’d have to email them to update. Though this is still better than mobile apps that go through an app store, it’s still very poor DX.<p>How does Onlook for web work?<p>We start by connecting to a remote “sandbox” [4]. The visual editing component happens through an iframe. We map the HTML element in the iframe to the location in code. Then, when an edit is made, we simulate the change on the iframe and edit the code at the same time. This way, visual changes always feel instant.<p>While we’re still ironing out the experience, you can already:
- Select elements and prompt changes<p>- Update TailwindCSS classes via the styling UI<p>- Draw in new divs and elements<p>- Preview on multiple screen sizes<p>- Edit your code through an in-browser IDE<p>We want to make it trivial for anyone to create, style, and edit codebases. We’re still porting over functionalities from the desktop app — layers, fonts, hosting, git, etc. Once that is done, we plan on adding support for back-end functionalities such as auth, database, and API calls.<p>Special thank you to the 70+ contributors who have helped create the Onlook experience! I think there’s still a lot to be solved for in the design and dev workflow, and I think the tech is almost there.<p>You can clone the project and run it from our repo (linked to this post) or try it out at <a href="https://beta.onlook.com">https://beta.onlook.com</a> where we’re letting people try it out for free.<p>I’d love to hear what you think and where we should take it next :)<p>[1] <a href="https://news.ycombinator.com/item?id=41390449">https://news.ycombinator.com/item?id=41390449</a><p>[2] <a href="https://news.ycombinator.com/item?id=40904862">https://news.ycombinator.com/item?id=40904862</a><p>[3] <a href="https://docs.onlook.com/docs/developer/electron-to-web-migration">https://docs.onlook.com/docs/developer/electron-to-web-migra...</a><p>[4] Currently, the sandbox is through CodeSandbox, but we plan to add support for connecting to a locally running server as well
Show HN: Typed-FFmpeg 3.0–Typed Interface to FFmpeg and Visual Filter Editor
Hi HN,<p>I built typed-ffmpeg, a Python package that lets you build FFmpeg filter graphs with full type safety, autocomplete, and validation. It’s inspired by ffmpeg-python, but addresses some long-standing issues like lack of IDE support and fragile CLI strings.<p>What’s New in v3.0:
• Source filter support (e.g. color, testsrc, etc.)
• Input stream selection (e.g. [0:a], [1:v])
• A new interactive playground where you can:
• Build filter graphs visually
• Generate both FFmpeg CLI and typed Python code
• Paste existing FFmpeg commands and reverse-parse them into graphs<p>Playground link: <a href="https://livingbio.github.io/typed-ffmpeg-playground/" rel="nofollow">https://livingbio.github.io/typed-ffmpeg-playground/</a>
(It’s open source and runs fully in-browser.)<p>The internal core also supports converting CLI → graph → typed Python code. This is useful for building educational tools, FFmpeg IDEs, or visual editors.<p>I’d love feedback, bug reports, or ideas for next steps. If you’ve ever struggled with FFmpeg’s CLI or tried to teach it, this might help.<p>Thanks!
— David (maintainer)
Show HN: Porting Terraria and Celeste to WebAssembly
Show HN: Porting Terraria and Celeste to WebAssembly
Show HN: I wrote a modern Command Line Handbook
TLDR: I wrote a handbook for the Linux command line. 120 pages in PDF. Updated for 2025. Pay what you want.<p>A few years back I wrote an ebook about the Linux command line. Instead of focusing on a specific shell, paraphrasing manual pages, or providing long repetitive explanations, the idea was to create a modern guide that would help readers to understand the command line in the practical sense, cover the most common things people use the command line for, and do so without wasting the readers' time.<p>The book contains material on terminals, shells (compatible with both Bash and Zsh), configuration, command line programs for typical use cases, shell scripting, and many tips and tricks to make working on the command line more convenient. I still consider it "an introduction" and it is not necessarily a book for the HN crowd that lives in the terminal, but I believe that the book will easily cover 80 % of the things most people want or need to do in the terminal.<p>I made a couple of updates to the book over the years and just finished a significant one for 2025. The book is not perfect. I still see a lot of room for improvement, but I think it is good enough and I truly want to share it with everyone. Hence, pay what you want.<p>EXAMPLE PAGES: <a href="https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVffAs3Sp/view?usp=sharing" rel="nofollow">https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...</a><p><a href="https://commandline.stribny.name/" rel="nofollow">https://commandline.stribny.name/</a>
Show HN: I wrote a modern Command Line Handbook
TLDR: I wrote a handbook for the Linux command line. 120 pages in PDF. Updated for 2025. Pay what you want.<p>A few years back I wrote an ebook about the Linux command line. Instead of focusing on a specific shell, paraphrasing manual pages, or providing long repetitive explanations, the idea was to create a modern guide that would help readers to understand the command line in the practical sense, cover the most common things people use the command line for, and do so without wasting the readers' time.<p>The book contains material on terminals, shells (compatible with both Bash and Zsh), configuration, command line programs for typical use cases, shell scripting, and many tips and tricks to make working on the command line more convenient. I still consider it "an introduction" and it is not necessarily a book for the HN crowd that lives in the terminal, but I believe that the book will easily cover 80 % of the things most people want or need to do in the terminal.<p>I made a couple of updates to the book over the years and just finished a significant one for 2025. The book is not perfect. I still see a lot of room for improvement, but I think it is good enough and I truly want to share it with everyone. Hence, pay what you want.<p>EXAMPLE PAGES: <a href="https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVffAs3Sp/view?usp=sharing" rel="nofollow">https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...</a><p><a href="https://commandline.stribny.name/" rel="nofollow">https://commandline.stribny.name/</a>
Show HN: AutoThink – Boosts local LLM performance with adaptive reasoning
I built AutoThink, a technique that makes local LLMs reason more efficiently by adaptively allocating computational resources based on query complexity.<p>The core idea: instead of giving every query the same "thinking time," classify queries as HIGH or LOW complexity and allocate thinking tokens accordingly. Complex reasoning gets 70-90% of tokens, simple queries get 20-40%.<p>I also implemented steering vectors derived from Pivotal Token Search (originally from Microsoft's Phi-4 paper) that guide the model's reasoning patterns during generation. These vectors encourage behaviors like numerical accuracy, self-correction, and thorough exploration.<p>Results on DeepSeek-R1-Distill-Qwen-1.5B:<p>- GPQA-Diamond: 31.06% vs 21.72% baseline (+43% relative improvement)<p>- MMLU-Pro: 26.38% vs 25.58% baseline<p>- Uses fewer tokens than baseline approaches<p>Works with any local reasoning model - DeepSeek, Qwen, custom fine-tuned models. No API dependencies.<p>The technique builds on two things I developed: an adaptive classification framework that can learn new complexity categories without retraining, and an open source implementation of Pivotal Token Search.<p>Technical paper: <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253327" rel="nofollow">https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253327</a><p>Code and examples: <a href="https://github.com/codelion/optillm/tree/main/optillm/autothink">https://github.com/codelion/optillm/tree/main/optillm/autoth...</a><p>PTS implementation: <a href="https://github.com/codelion/pts">https://github.com/codelion/pts</a><p>I'm curious about your thoughts on adaptive resource allocation for AI reasoning. Have you tried similar approaches with your local models?
Show HN: AutoThink – Boosts local LLM performance with adaptive reasoning
I built AutoThink, a technique that makes local LLMs reason more efficiently by adaptively allocating computational resources based on query complexity.<p>The core idea: instead of giving every query the same "thinking time," classify queries as HIGH or LOW complexity and allocate thinking tokens accordingly. Complex reasoning gets 70-90% of tokens, simple queries get 20-40%.<p>I also implemented steering vectors derived from Pivotal Token Search (originally from Microsoft's Phi-4 paper) that guide the model's reasoning patterns during generation. These vectors encourage behaviors like numerical accuracy, self-correction, and thorough exploration.<p>Results on DeepSeek-R1-Distill-Qwen-1.5B:<p>- GPQA-Diamond: 31.06% vs 21.72% baseline (+43% relative improvement)<p>- MMLU-Pro: 26.38% vs 25.58% baseline<p>- Uses fewer tokens than baseline approaches<p>Works with any local reasoning model - DeepSeek, Qwen, custom fine-tuned models. No API dependencies.<p>The technique builds on two things I developed: an adaptive classification framework that can learn new complexity categories without retraining, and an open source implementation of Pivotal Token Search.<p>Technical paper: <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253327" rel="nofollow">https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253327</a><p>Code and examples: <a href="https://github.com/codelion/optillm/tree/main/optillm/autothink">https://github.com/codelion/optillm/tree/main/optillm/autoth...</a><p>PTS implementation: <a href="https://github.com/codelion/pts">https://github.com/codelion/pts</a><p>I'm curious about your thoughts on adaptive resource allocation for AI reasoning. Have you tried similar approaches with your local models?
Show HN: I rewrote my Mac Electron app in Rust
A year ago, my co-founder launched Desktop Docs here on HN. It's a Mac app we built with Electron that uses CLIP embeddings to search photos and videos locally with natural language. We got positive feedback from HN and our first paying customers, but the app was almost 1GB and clunky to use.<p>TLDR; rebuilding in Rust was the right move.<p>So we rewrote the app with Rust and Tauri and here are the results:<p>- App size is 83% smaller: 1GB → 172MB
- DMG Installer is 70% smaller: 232MB → 69.5MB
- Indexing files is faster: A 38-minute video now indexes in ~3 minutes instead of 10-14 minutes
- Overall more stability (old app used to randomly crash)<p>The original version worked, but it didn't perform well when you tried indexing thousands of images or large videos. We lost a lot of time struggling to optimize Electron’s main-renderer process communication and ended up with a complex worker system to process large batches of media files.<p>For months we wrestled with indecision about continuing to optimize the Electron app vs. starting a full rebuild in Swift or Rust. The main thing holding us back was that we hadn’t coded in Swift in almost 10 years and we didn’t know Rust very well.<p>What finally broke us was when users complained the app crashed their video calls just running in background. I guess that’s what happens when you ship an app with Chromium that takes up 200mb before any application code.<p>Today the app still uses CLIP for embeddings and Redis for vector storage and search, except Rust now handles the image and video processing pipeline and all the file I/O to let users browse their entire machine, not just indexed files.<p>For the UI, we decided to rebuild it from scratch instead of porting over the old UI. This turned out well because it resulted in a cleaner, simpler UI after living with the complexity of the old version.<p>The trickiest part of the migration was learning Rust. LLMs definitely help, but the Rust/Tauri community just isn’t as mature compared to Electron. Bundling Redis into the app was a permissioning nightmare, but I think our solution with Rust handles this better than what we had with Electron.<p>All in, the rebuild took about two months and still needs some more work to be at total parity with its Electron version, but the core functionality of indexing and searching files is way more performant than before and that made it worth the time. Sometimes you gotta throw away working code to build the right thing.<p>AMA about Rust/Tauri migration, Redis bundling nightmares, how CLIP embeddings work for local semantic search, or why Electron isn't always the answer.
Show HN: I rewrote my Mac Electron app in Rust
A year ago, my co-founder launched Desktop Docs here on HN. It's a Mac app we built with Electron that uses CLIP embeddings to search photos and videos locally with natural language. We got positive feedback from HN and our first paying customers, but the app was almost 1GB and clunky to use.<p>TLDR; rebuilding in Rust was the right move.<p>So we rewrote the app with Rust and Tauri and here are the results:<p>- App size is 83% smaller: 1GB → 172MB
- DMG Installer is 70% smaller: 232MB → 69.5MB
- Indexing files is faster: A 38-minute video now indexes in ~3 minutes instead of 10-14 minutes
- Overall more stability (old app used to randomly crash)<p>The original version worked, but it didn't perform well when you tried indexing thousands of images or large videos. We lost a lot of time struggling to optimize Electron’s main-renderer process communication and ended up with a complex worker system to process large batches of media files.<p>For months we wrestled with indecision about continuing to optimize the Electron app vs. starting a full rebuild in Swift or Rust. The main thing holding us back was that we hadn’t coded in Swift in almost 10 years and we didn’t know Rust very well.<p>What finally broke us was when users complained the app crashed their video calls just running in background. I guess that’s what happens when you ship an app with Chromium that takes up 200mb before any application code.<p>Today the app still uses CLIP for embeddings and Redis for vector storage and search, except Rust now handles the image and video processing pipeline and all the file I/O to let users browse their entire machine, not just indexed files.<p>For the UI, we decided to rebuild it from scratch instead of porting over the old UI. This turned out well because it resulted in a cleaner, simpler UI after living with the complexity of the old version.<p>The trickiest part of the migration was learning Rust. LLMs definitely help, but the Rust/Tauri community just isn’t as mature compared to Electron. Bundling Redis into the app was a permissioning nightmare, but I think our solution with Rust handles this better than what we had with Electron.<p>All in, the rebuild took about two months and still needs some more work to be at total parity with its Electron version, but the core functionality of indexing and searching files is way more performant than before and that made it worth the time. Sometimes you gotta throw away working code to build the right thing.<p>AMA about Rust/Tauri migration, Redis bundling nightmares, how CLIP embeddings work for local semantic search, or why Electron isn't always the answer.
Show HN: Lazy Tetris
I made a tetris variant<p>Aims to remove all stress, and focus the game on what I like the best - stacking.<p>No timer, no score, no gravity. Move to the next piece when you are ready, and clear lines when you are ready.<p>Separate mobile + desktop controls
Show HN: Lazy Tetris
I made a tetris variant<p>Aims to remove all stress, and focus the game on what I like the best - stacking.<p>No timer, no score, no gravity. Move to the next piece when you are ready, and clear lines when you are ready.<p>Separate mobile + desktop controls
Show HN: My LLM CLI tool can run tools now, from Python code or plugins
Show HN: My LLM CLI tool can run tools now, from Python code or plugins
Show HN: PgDog – Shard Postgres without extensions
Hey HN! Lev here, author of PgDog (<a href="https://github.com/pgdogdev/pgdog">https://github.com/pgdogdev/pgdog</a>). I’m scaling our favorite database, PostgreSQL. PgDog is a new open source proxy, written in Rust, with first-class support for sharding — without changes to your app or needing database extensions.<p>Here’s a walkthrough of how it works: <a href="https://www.youtube.com/watch?v=y6sebczWZ-c" rel="nofollow">https://www.youtube.com/watch?v=y6sebczWZ-c</a><p>Running Postgres at scale is hard. Eventually, one primary isn’t enough at which point you need to split it up. Since there is currently no good tooling out there to do this, teams end up breaking their apps apart instead.<p>If you’re familiar with PgCat, my previous project, PgDog is its spiritual successor but with a fresh codebase and new goals. If not, PgCat is a pooler for Postgres also written in Rust.<p>So, what’s changed and why a new project? Cross-shard queries are supported out of the box. The new architecture is more flexible, completely asynchronous and supports manipulating the Postgres protocol at any stage of query execution. (Oh, and you guessed it — I adopted a dog. Still a cat person though!)<p>Not everything is working yet, but simple aggregates like max(), min(), count(*) and sum() are in. More complex functions like percentiles and average will require a bit more work. Sorting (i.e. ORDER BY) works, as long as the values are part of the result set, e.g.:<p><pre><code> SELECT id, email FROM users
WHERE admin = true
ORDER BY 1 DESC;
</code></pre>
PgDog buffers and sorts the rows in memory, before sending them to the client. Most of the time, the working set is small, so this is fine. For larger results, we need to build swap to disk, just like Postgres does, but for OLTP workloads, which PgDog is targeting, we want to keep things fast. Sorting currently works for bigint, integer, and text/varchar. It’s pretty straightforward to add all the other data types, I just need to find the time and make sure to handle binary encoding correctly.<p>All standard Postgres features work as normal for unsharded and direct-to-shard queries. As long as you include the sharding key (a column like customer_id, for example) in your query, you won’t notice a difference.<p>How does this compare to Citus? In case you’re not familiar, Citus is an open source extension for sharding Postgres. It runs inside a single Postgres node (a coordinator) and distributes queries between worker databases.<p>PgDog’s architecture is fundamentally different. It runs outside the DB: it’s a proxy, so you can deploy it anywhere, including managed Postgres like RDS, Cloud SQL and others where Citus isn’t available. It’s multi-threaded and asynchronous, so it can handle thousands, if not millions, of concurrent connections. Its focus is OLTP, not OLAP. Meanwhile, Citus is more mature and has good support for cross-shard queries and aggregates. It will take PgDog a while to catch up.<p>My Rust has improved since my last attempt at this and I learned how to use the bytes crate correctly. PgDog does almost zero memory allocations per request. That results in a 3-5% performance increase over PgCat and a much more consistent p95. If you’re obsessed with performance like me, you know that small percentage is nothing to sneeze at. Like before, multi-threaded Tokio-powered PgDog leaves the single-threaded PgBouncer in the dust (<a href="https://pgdog.dev/blog/pgbouncer-vs-pgdog">https://pgdog.dev/blog/pgbouncer-vs-pgdog</a>).<p>Since we’re using pg_query (which itself bundles the Postgres parser), PgDog can understand all Postgres queries. This is important because we can not only correctly extract the WHERE clause and INSERT parameters for automatic routing, but also rewrite queries. This will be pretty useful when we’ll add support for more complex aggregates, like avg(), and cross-shard joins!<p>Read/write traffic split is supported out of the box, so you can put PgDog in front of the whole cluster and ditch the code annotations. It’s also a load balancer, so you can deploy it in front of multiple replicas to get 4 9’s of uptime.<p>One of the coolest features so far, in my opinion, is distributed COPY. This works by hacking the Postgres network protocol and sending individual rows to different shards (<a href="https://pgdog.dev/blog/hacking-postgres-wire-protocol">https://pgdog.dev/blog/hacking-postgres-wire-protocol</a>). You can just use it without thinking about cluster topology, e.g.:<p><pre><code> COPY temperature_records (sensor_uuid, created_at, value)
FROM STDIN CSV;
</code></pre>
The sharding function is straight out of Postgres partitions and supports uuid v4 and bigint. Technically, it works with any data type, but I just haven’t added all the wrappers yet. Let me know if you need one.<p>What else? Since we have the Postgres parser handy, we can inspect, block and rewrite queries. One feature I was playing with is ensuring that the app is passing in the customer_id in all queries, to avoid data leaks between tenants. Brain dump of that in my blog here: <a href="https://pgdog.dev/blog/multi-tenant-pg-can-be-easy">https://pgdog.dev/blog/multi-tenant-pg-can-be-easy</a>.<p>What’s on the roadmap: (re)sharding Postgres using logical replication, so we can scale DBs without taking downtime. There is a neat trick on how to quickly do this on copy-on-write filesystems (like EBS used by RDS, Google Cloud volumes, ZFS, etc.). I’ll publish a blog post on this soon. More at-scale features like blocking bad queries and just general “I wish my Postgres proxy could do this” stuff. Speaking of which, if you can think of any more features you’d want, get in touch. Your wishlist can become my roadmap.<p>PgDog is being built in the open. If you have thoughts or suggestions about this topic, I would love to hear them. Happy to listen to your battle stories with Postgres as well.<p>Happy hacking!<p>Lev
Show HN: PgDog – Shard Postgres without extensions
Hey HN! Lev here, author of PgDog (<a href="https://github.com/pgdogdev/pgdog">https://github.com/pgdogdev/pgdog</a>). I’m scaling our favorite database, PostgreSQL. PgDog is a new open source proxy, written in Rust, with first-class support for sharding — without changes to your app or needing database extensions.<p>Here’s a walkthrough of how it works: <a href="https://www.youtube.com/watch?v=y6sebczWZ-c" rel="nofollow">https://www.youtube.com/watch?v=y6sebczWZ-c</a><p>Running Postgres at scale is hard. Eventually, one primary isn’t enough at which point you need to split it up. Since there is currently no good tooling out there to do this, teams end up breaking their apps apart instead.<p>If you’re familiar with PgCat, my previous project, PgDog is its spiritual successor but with a fresh codebase and new goals. If not, PgCat is a pooler for Postgres also written in Rust.<p>So, what’s changed and why a new project? Cross-shard queries are supported out of the box. The new architecture is more flexible, completely asynchronous and supports manipulating the Postgres protocol at any stage of query execution. (Oh, and you guessed it — I adopted a dog. Still a cat person though!)<p>Not everything is working yet, but simple aggregates like max(), min(), count(*) and sum() are in. More complex functions like percentiles and average will require a bit more work. Sorting (i.e. ORDER BY) works, as long as the values are part of the result set, e.g.:<p><pre><code> SELECT id, email FROM users
WHERE admin = true
ORDER BY 1 DESC;
</code></pre>
PgDog buffers and sorts the rows in memory, before sending them to the client. Most of the time, the working set is small, so this is fine. For larger results, we need to build swap to disk, just like Postgres does, but for OLTP workloads, which PgDog is targeting, we want to keep things fast. Sorting currently works for bigint, integer, and text/varchar. It’s pretty straightforward to add all the other data types, I just need to find the time and make sure to handle binary encoding correctly.<p>All standard Postgres features work as normal for unsharded and direct-to-shard queries. As long as you include the sharding key (a column like customer_id, for example) in your query, you won’t notice a difference.<p>How does this compare to Citus? In case you’re not familiar, Citus is an open source extension for sharding Postgres. It runs inside a single Postgres node (a coordinator) and distributes queries between worker databases.<p>PgDog’s architecture is fundamentally different. It runs outside the DB: it’s a proxy, so you can deploy it anywhere, including managed Postgres like RDS, Cloud SQL and others where Citus isn’t available. It’s multi-threaded and asynchronous, so it can handle thousands, if not millions, of concurrent connections. Its focus is OLTP, not OLAP. Meanwhile, Citus is more mature and has good support for cross-shard queries and aggregates. It will take PgDog a while to catch up.<p>My Rust has improved since my last attempt at this and I learned how to use the bytes crate correctly. PgDog does almost zero memory allocations per request. That results in a 3-5% performance increase over PgCat and a much more consistent p95. If you’re obsessed with performance like me, you know that small percentage is nothing to sneeze at. Like before, multi-threaded Tokio-powered PgDog leaves the single-threaded PgBouncer in the dust (<a href="https://pgdog.dev/blog/pgbouncer-vs-pgdog">https://pgdog.dev/blog/pgbouncer-vs-pgdog</a>).<p>Since we’re using pg_query (which itself bundles the Postgres parser), PgDog can understand all Postgres queries. This is important because we can not only correctly extract the WHERE clause and INSERT parameters for automatic routing, but also rewrite queries. This will be pretty useful when we’ll add support for more complex aggregates, like avg(), and cross-shard joins!<p>Read/write traffic split is supported out of the box, so you can put PgDog in front of the whole cluster and ditch the code annotations. It’s also a load balancer, so you can deploy it in front of multiple replicas to get 4 9’s of uptime.<p>One of the coolest features so far, in my opinion, is distributed COPY. This works by hacking the Postgres network protocol and sending individual rows to different shards (<a href="https://pgdog.dev/blog/hacking-postgres-wire-protocol">https://pgdog.dev/blog/hacking-postgres-wire-protocol</a>). You can just use it without thinking about cluster topology, e.g.:<p><pre><code> COPY temperature_records (sensor_uuid, created_at, value)
FROM STDIN CSV;
</code></pre>
The sharding function is straight out of Postgres partitions and supports uuid v4 and bigint. Technically, it works with any data type, but I just haven’t added all the wrappers yet. Let me know if you need one.<p>What else? Since we have the Postgres parser handy, we can inspect, block and rewrite queries. One feature I was playing with is ensuring that the app is passing in the customer_id in all queries, to avoid data leaks between tenants. Brain dump of that in my blog here: <a href="https://pgdog.dev/blog/multi-tenant-pg-can-be-easy">https://pgdog.dev/blog/multi-tenant-pg-can-be-easy</a>.<p>What’s on the roadmap: (re)sharding Postgres using logical replication, so we can scale DBs without taking downtime. There is a neat trick on how to quickly do this on copy-on-write filesystems (like EBS used by RDS, Google Cloud volumes, ZFS, etc.). I’ll publish a blog post on this soon. More at-scale features like blocking bad queries and just general “I wish my Postgres proxy could do this” stuff. Speaking of which, if you can think of any more features you’d want, get in touch. Your wishlist can become my roadmap.<p>PgDog is being built in the open. If you have thoughts or suggestions about this topic, I would love to hear them. Happy to listen to your battle stories with Postgres as well.<p>Happy hacking!<p>Lev
Show HN: Rotary Phone Dial Linux Kernel Driver
A Linux kernel driver that turns a rotary phone dial into an evdev input device. You might be interested in this driver if you<p>- prefer the slow pace of dialing over typing numbers with your numpad,<p>- want to bring your old rotary phone into the digital era,<p>- are an educator looking for a simple example driver with a VM-based end-to-end development & test environment (no real hardware needed)<p>- have another creative use case in mind!<p>This driver was my introduction to embedded Linux years ago—and ultimately led to my career. However, it remained unfinished and unpublished until now. Initially, I intended to reimplement the driver in Rust to explore the state of the Rust for Linux project. Unfortunately, I soon realized that the necessary bindings simply are not available yet, so that part will have to wait.
Show HN: Rotary Phone Dial Linux Kernel Driver
A Linux kernel driver that turns a rotary phone dial into an evdev input device. You might be interested in this driver if you<p>- prefer the slow pace of dialing over typing numbers with your numpad,<p>- want to bring your old rotary phone into the digital era,<p>- are an educator looking for a simple example driver with a VM-based end-to-end development & test environment (no real hardware needed)<p>- have another creative use case in mind!<p>This driver was my introduction to embedded Linux years ago—and ultimately led to my career. However, it remained unfinished and unpublished until now. Initially, I intended to reimplement the driver in Rust to explore the state of the Rust for Linux project. Unfortunately, I soon realized that the necessary bindings simply are not available yet, so that part will have to wait.