WhatCable sits in your menu bar and reads the cable data your Mac already has access to. Plug in a cable and it tells you in plain English what it can actually do: charging wattage, data speed, display support, Thunderbolt, etc.
Built in Swift/SwiftUI. Open source, free, no tracking.
I bought a Roland FP-90X piano partly because it had Bluetooth MIDI. On my Windows 11 PC, pairing succeeded, but my DAW couldn't see the keyboard, and notes I sent from the PC never made the piano sing. After a regrettable number of evenings, I'd separated this into three independent bugs stacked on top of each other.
The first one is the famous one: Windows only natively exposes BLE-MIDI through the WinRT API, which almost no DAW polls. So even when pairing succeeds, MIDI apps still don't see the device. The usual workaround is MIDIberry + loopMIDI, but I couldn't get that combination to work reliably in my case, and I wanted a single-app solution. The new Windows MIDI Services stack ships with a feature called loopback endpoints: anything written to one comes out the other, and any winmm/WinRT/WMS app sees them as normal MIDI ports. So the app does WinRT BLE-MIDI in, WMS loopback out. That solved direction one, piano to PC.
Direction two, PC to piano, still didn't work. NoteOn writes were getting ATT-acked, but the piano stayed silent. I tried both write modes (some BLE-MIDI firmware silently drops one or the other), poked the proprietary ISSC characteristic. Every variant ATT-acked, every variant produced silence. So the bytes were reaching the piano. Something above the GATT layer was discarding them.
After ruling out pairing, encryption, write-mode, and proprietary characteristics, the only obvious lever left was the MIDI channel itself. The FP-90X has a panel setting called Transmit Channel, default 1. Yet it turns out the FP-90X actually receives on channel 4 (and it can't be changed). Notes I sent on channel 1 were being GATT-acked and silently dropped at the synth engine because they weren't on the channel the engine was listening to. Zero feedback at any layer. The fix had to live up at the application layer, so I added a Detect button that plays N test notes ascending on each channel from 1 to 16: you count the notes you actually hear, and that number is the receive channel. Saved per BLE MAC, about 75 seconds, done forever per piano.
Tech stack: .NET 10, Avalonia for the UI (the BLE/MIDI side is Windows-only but the UI layer is portable), Microsoft.Windows.Devices.Midi2 packages for WMS, Windows.Devices.Midi (WinRT) directly for BLE rather than relying on Korg's older WinMM driver. MIT, single self-contained ~21 MB exe, no installer, no telemetry, no account.
I built it for myself and use it with my FP-90X to play through a few apps and Web MIDI sites. Pete from the Microsoft Windows MIDI Services team commented positively on the BLE integration when I shared it on r/synthesizers (https://www.reddit.com/r/synthesizers/comments/1szvuiq/comme...).
Site (with screenshots): https://mayerwin.github.io/Perfect-Bluetooth-MIDI-For-Window... Source: https://github.com/mayerwin/Perfect-Bluetooth-MIDI-For-Windo... Long-form technical writeup with the full debugging story: https://dev.to/mayerwin/why-your-bluetooth-midi-keyboard-sil...
Personally tested with my FP-90X only. The BLE side is generic, so other keyboards (WIDI Master, CME, Yamaha MD-BT01, Korg microKey Air, ROLI Seaboard, etc.) should work, but I haven't confirmed individually. Device test reports, issues, and PRs very welcome.
We've been on HN twice before with text-to-CAD/3D experiments [1][2]. The honest takeaway from those threads: prompt-to-3D model web apps are fun, but serious mechanical engineers don't want a black box that spits out an STL. They want help inside the CAD tool they already use, with full visibility and control over the feature tree.
So we built that. Adam is now a harness that integrates directly with your CAD. It reads your parts, understands the existing feature tree, and edits it for you agentically. We are now live in beta on Onshape and Fusion! [3]:
Install link Autodesk Fusion: https://fusion.adam.new/install
Install link PTC Onshape: https://cad.onshape.com/appstore/apps/Design%20&%20Documenta...
Things people are using it for today: - "Merge redundant features and clean up my tree" - "Rename every feature so the tree is actually readable" - "Round all internal edges with a 2mm fillet" - “Parametrize my model”
Along with of course, using Adam to generate CAD end-to-end!
A few things we care about that aren't obvious from the listing:
1. From the start we have always believed in CAD as code as the right abstraction. Our harness leverages Onshape's FeatureScript and Python in Fusion heavily.
2. We run an internal CAD benchmark across frontier models. There has been a massive jump in the spatial reasoning capabilities of recently released models. Particularly GPT 5.5 and Opus 4.7 [4] [5]
3. We open-sourced our earlier text-to-CAD work [6]
A note on the Anthropic Autodesk connector that shipped a couple days ago [7]: We think it's great for the space and validates the direction. Where Adam is different:
- Model-agnostic. We pick whichever frontier model is winning on each task type from our own internal bench, instead of being tied to one lab.
- We live natively in your CAD apps and are actively building integrations across all programs
What would you want an in-CAD agent to do that nothing does today?
[1] https://news.ycombinator.com/item?id=44182206
[2] https://news.ycombinator.com/item?id=45140921
[3] https://x.com/adamdotnew/status/2050264512230719980?s=20
[4] https://x.com/adamdotnew/status/2044859329329893376?s=20
[5] https://x.com/adamdotnew/status/2047795078912172122?s=20
I've been playing around with Cloudflare's Browser Run and Workers AI to create this funny "website vs website"-website.
Google's Gemma 4b model is actually quite good at vision.
Later I figured there should be a better way to continue my claude sessions remotely on my phone from the gym. So I did a cloudflare worker that connects to my local machine. I just need to ensure the laptop is plugged in.
I know I might be reinventing the wheel, but I love that it just works. Still working on E2E encryption. iOS app still in review.
Lemme know your thoughts.
Type /destiny to see today's destiny!
It uses the actual classical East Asian astrology system. You enter your birthday once, then /destiny gives you today's reading anytime.
Two layers, kept honest:
1. The numbers (your eight-character birth chart, today's day pillar, the hexagram for the moment, five-element relationships) are computed by a Python script. Same person + same day = identical output. You can verify against any traditional calendar source.
2. The prose (today's stars, character sketch, life arc, advice) is written by Claude, applying centuries-old reading conventions to that fixed data. Not LLM-hallucinated horoscope.
If you have fun with it, a star would mean a lot.
After that experience, we each found ourselves struggling through Ctrl+Tab through multiple Claude Code windows in our terminals. While we enjoyed having agents working for us in parallel, context switching and cycling through each terminal tab was a real pain.
So we thought: Can we design a TUI dashboard that manages a large swarm of agents in one place? Even better, can agents manage agents hierarchically, like how companies work?
OMAR (Open Multi-Agent Runtime) is the result of this exploration. We spent months building it, and we think it is now ready to show the world. If you find OMAR interesting, give it a try. We would love to hear from you. :)
Check out our blog here for more details: https://omar.tech/blog/introducing-omar/
Thanks! Karim & Shaokai
Architecturally, instead of etcd, it has options to use sqlite or postgres as backend. I am trying to make it compatible with kubernetes apis and kubectl should just work out of the box.
This is not 100% ready yet but just wanted to show the first look.
It should just work out of the box on macos with docker as runtime.
For anyone unfamiliar, Freenet[1] is a general purpose platform for building decentralized systems.
So I implemented a working prototype which already hosts the freenet-core repo, integrating as a git remote helper. It's still early so I'd greatly appreciate any feedback and will iterate quickly if there is interest.
Some time ago I tried to find a way to clean up my 10k emails inbox and could find anything which worked for me. So I built built my own tool which evolved into a client.
More that out of necessity but for fun add semantic search, LLM based tagging, and clean up rules through Ollama.
It has a demo mode to try without configuring anything.
On Mac:
brew tap herald-email/herald brew install herald herald --demo
With Go:
go install github.com/herald-email/herald-mail-app/cmd/herald@latest herald --demo
The DEMO uses pre-populated synthetic data so no risk for your inboxes.
Any feedback will be highly appreciated.
I am looking for enthusiastic people who want to see longevity and bio-hacker community grow.
At the moment the app is completely free to use. There is no sign up or anything like that. I need your feedback to build something beautiful.
https://github.com/xtellect/vibe
It uses one background epoll thread. Application code polls an inbox queue for CONNECTED, DATA, and DISCONNECTED events, and sends through per-connection outboxes.
The pieces I wanted:
- TCP or Unix stream sockets - 4-byte length-prefixed messages - non-blocking application-side polling - single-copy fan-out via refcounted payload chunks - explicit per-connection backpressure instead of unbounded queues
For multicast, the payload is copied once into a refcounted chunk, then queued by reference to each recipient. A 1 KB message to 1,000 peers is one payload allocation/copy plus 1,000 queue nodes, not 1,000 payload copies.
It is Linux-only for now: epoll, eventfd, accept4, and Linux abstract Unix sockets. No UDP, TLS, HTTP, or WebSocket layer.
This is not meant to be a full networking framework. I’m posting mainly for your inputs/revies, especially around connection lifetimes, backpressure accounting, edge cases, and the queue design.
Apache 2.0.
This is how TimmyGram came to exist. On one side we have the server: Golang application deployed with docker-compose Parents can upload videos Video is transcoded with ffmpeg to portrait aspect ratio Parent can see connected devices and set up new ones Parents can block devices access or remove devices And the iOS app: Parent opens app Scans a QR code from server UI to setup device Or enters server URL and PIN to register device Parent enters name and description of device and configuration PIN Child can browse and watch videos Child can like videos Child can download videos for offline viewing
I almost achieved all the goals I set for myself, but there are some others that came to my attention after using this setup for a while. More then one account would be nice Ability for children/parents to record their own videos from within the app An Android version of the app (will not and can not publish on Play Store, so only option for me here is either different store, or hope that somebody else will develop it)
I will be happy to get some feedback or other perspective on the idea.
Major & Minor Improvements:
- Much easier. I was getting a lot of feedback that the puzzle was too difficult, from here, reddit and others. This was for a number of reasons, but I have made best efforts to simplify the puzzles.
- Improved checking : One user advised that common crossword proactive is to have more "checking" where letters intersect. This has been increased, within the possibility of a shared grid.
- Increased number of shared letters - I have attempted to add more shared letters to puzzles which makes them easier, more fun, and more in the spirit of the game.
- Ensured that copy and paste is accessible via keyboard shortcut on main game screen.
- Ensured that rules for vocabulary and grammar logic for clues are more tightly regulated. One comment mentioned plurality of a clue but not an answer. This is poor crossword form, and now improved.
- Addressed enhanced tracking bug in Firefox (still could be an issue)
Thank you to everyone, I want to make the game fun to play. Feel free to check out the new puzzles today and this week, which are improved. I may have to reduce the difficulty once again, but will see!
Original Post :
Forkle (forkle.co.uk) is a daily word game where two thematically linked crosswords occupy the same grid simultaneously. Every tile contains two letters - one belonging to each puzzle - displayed as a diagonal colour split. Where the two puzzles intersect, some tiles share the same letter, giving you a foothold into both crosswords at once. The mechanic has two layers: the shared grid, and the connected themes. Each day's two crosswords are thematically paired around a central idea. For example, a previous puzzle was "Same House, Different Kingdoms" - same home, same humans, entirely different worlds. One crossword is the dog's world, the other is the cat's. The themes are chosen to be related but distinct, which creates an extra layer of satisfaction when the connection clicks.
The constraint of forcing two crosswords into one physical space turns out to create genuinely interesting solving decisions - sometimes the two puzzles help each other, sometimes they fight.
Built solo over a few months using React, Python, Supabase, Fly.io and Resend. Three months of daily puzzles pre-loaded. Launched two weeks ago.
Would love feedback from anyone willing to try it.
That is what I am building. The power source is betavoltaic — electricity generated continuously from the decay of a radioactive isotope, with no moving parts, no combustion, no charging infrastructure.
The device I am describing is not a current smartphone with a different power source. It is a device designed from the ground up around a power budget that current betavoltaic technology can sustain. Day One capability is meaningfully more limited than a 2026 flagship phone. That gap closes as the power architecture advances.
The source physics:
Tritium (H-3) decays by beta emission to helium-3.
The emitted electron carries a maximum energy of 18.6 keV, with a mean energy of approximately 5.7 keV. The neutrino carries the rest and is unrecoverable. The beta spectrum is continuous — a statistical distribution of electron energies up to the endpoint — which is why mean energy, not maximum, is the relevant figure for power calculations.
Tritium activity for power calculation: 1 Curie of tritium is 3.7 × 10¹⁰ disintegrations per second. At 5.7 keV mean energy per disintegration, 1 Ci of tritium releases approximately 1.6 × 10⁻¹⁹ J/eV × 5,700 eV × 3.7 × 10¹⁰ dis/s = approximately 33.8 mW of total beta energy. This is the upper bound on recoverable power — conversion efficiency determines how much becomes electricity.
Tritium's specific activity is 9,650 Ci/g. One gram of tritium therefore releases approximately 33.8 mW/Ci × 9,650 Ci/g = 326 W/g of total beta energy. Commercial betavoltaic cells at 1–4% conversion efficiency yield approximately 3.3–13 W/g electrical output — but tritium gas is diffuse and the actual cell includes a substrate, so power density per unit volume of assembled cell is far lower than per gram of tritium. Practical assembled cell power densities in current commercial products run 1–10 mW/cm².
City Labs in Miami produces tritium-on-silicon betavoltaic cells commercially under NRC license. Their current cells produce in the range of 50–300 μW/cm² of active junction area under typical loading. A mid-range figure of 150 μW/cm² is defensible for planning purposes with current commercial cells.
A multi-layer stacked cell module with 35 cm² of active junction area per layer and four layers — a total stack volume roughly comparable to a conventional battery pack — yields approximately 35 cm² × 4 layers × 150 μW/cm² = 21 mW total output. Accounting for interconnect losses and cell-to-cell variation, net output at the module terminals: approximately 15–18 mW continuous.
The conservative number — fewer layers, lower-yield cells — lands around 5–8 mW. I am designing the Day One architecture around 5 mW continuous as the floor, with 15 mW as the target as cell technology matures.
The decay curve is governed by the half-life P(t) = P₀ × (1/2)^(t/12.32)
At t = 5 years: P = P₀ × 0.755. At t = 8 years: P = P₀ × 0.629. At t = 12 years: P = P₀ × 0.499. The device at year 12 produces half its launch output. That output is predictable to high precision years in advance. No battery ages on a curve this clean.
The decay curve and upgrade cycle:
A device launched at 5 mW reaches the Day One capability floor at year 12. No consumer electronics device in history has been designed around a decade of predictable, transparent degradation rather than a two-year replacement cycle driven by software obsolescence. This one is.
What I'm looking for:
I'm the founder. I'm raising a pre-seed round to sign two co-founders: one with betavoltaic or nuclear battery hardware experience who can lead the prototype program. If you're that person, or you know them, I'd like to talk.
For the full essay and technical whitepaper, or to contact me directly, visit shelvin.com.
I also wrote a separate app to actually rip the CDs using this library and populate the metadata, but I think technically it is much less interesting.
I think the biggest takeaway is that if you have some intimidating project, give it a try! It might be very much doable.