Show HN: I built a fuse box for microservices https://ift.tt/3NATCnO

Show HN: I built a fuse box for microservices Hey HN! I'm Rodrigo, I run distributed systems across a few countries. I built Openfuse because of something that kept bugging me about how we all do circuit breakers. If you're running 20 instances of a service and Stripe starts returning 500s, each instance discovers that independently. Instance 1 trips its breaker after 5 failures. Instance 14 just got recycled and hasn't seen any yet. Instance 7 is in half-open, probing a service you already know is dead. For some window of time, part of your fleet is protecting itself and part of it is still hammering a dead dependency and timing out, and all you can do is watch. Libraries can't fix this. Opossum, Resilience4j, Polly are great at the pattern, but they make per-instance decisions with per-instance state. Your circuit breakers don't talk to each other. Openfuse is a centralized control plane. It aggregates failure metrics from every instance in your fleet and makes the trip decision based on the full picture. When the breaker opens, every instance knows at the same time. It's a few lines of code: const result = await openfuse.breaker('stripe').protect( () => chargeCustomer(payload) ); The SDK is open source, anyone can see exactly what runs inside their services. The other thing I couldn't let go of: when you get paged at 3am, you shouldn't have to find logs across 15 services to figure out what's broken. Openfuse gives you one dashboard showing every breaker state across your fleet: what's healthy, what's degraded, what tripped and when. And, you shouldn't need a deploy to act. You can open a breaker from the dashboard and every instance stops calling that dependency immediately. Planned maintenance window at 3am? Open beforehand. Fix confirmed? Close it instantly. Thresholds need adjusting? Change them in the dashboard, takes effect across your fleet in seconds. No PRs, no CI, no config files. It has a decent free tier for trying it out, then $99/mo for most teams, $399/mo with higher throughput and some enterprise features. Solo founder, early stage, being upfront. Would love to hear from people who've fought cascading failures in production. What am I missing? https://www.openfuse.io February 18, 2026 at 11:04AM

Show HN: I built a "Socratic" AI to stop my daughter from copy-pasting homework https://ift.tt/SOIpJsa

Show HN: I built a "Socratic" AI to stop my daughter from copy-pasting homework Hey HN, I’m a dev and a dad to a 10-year-old. I built this because I caught my daughter using ChatGPT to do her history homework. She wasn't learning; she was just acting as a "middleware" between the AI and the paper. The Backstory: I realized the problem isn't the AI—it's the zero-friction answers. Most "AI for kids" apps are just "parrots"—they mimic intelligence by repeating patterns. What’s Different: Qurio is a "Bicycle" for the mind. It treats the child like a future "Architect" rather than a "Junior Executor." Technically, it wraps an LLM in a strict "Socratic Loop." It detects intent to "cheat," refuses the direct answer, and generates a leading question based on the user's current logic level. It forces "Healthy Friction" back into the learning process. The stack: Next.js 14, Supabase (Auth/DB), Vercel AI SDK. Mods: I've added the backstory and differentiator as requested. Ready for the re-up! Thank you. https://thinkqurio.com/ February 16, 2026 at 12:55PM

Show HN: How I built Timeframe, our family e-paper dashboard https://ift.tt/5rUHdSJ

Show HN: How I built Timeframe, our family e-paper dashboard I'm proud to share the e-paper family dashboard I've been building over the past decade. I think you might find it interesting. It's open source: https://ift.tt/wOhr1zY . https://ift.tt/vuzd23P February 17, 2026 at 11:20PM

Show HN: Windows 98 web desktop with a functional remote browser (no CORS) https://ift.tt/75vgyNz

Show HN: Windows 98 web desktop with a functional remote browser (no CORS) https://ift.tt/AIzWguc February 17, 2026 at 04:24AM

Show HN: Glitchy camera – a circuit-bent camera simulator in the browser https://ift.tt/ZqMYVPB

Show HN: Glitchy camera – a circuit-bent camera simulator in the browser Fun little side project I built after learning about circuit bending in cameras for intentional glitch effect. It is browser based camera toy where you "rewire" CCD pin pairs, turn knobs to get different glitch artefacts in real time to capture as photos. I had fun learning to simulate different pin modes - channel split, hue/phase shifts, horizontal clock delays, colour kill etc. Here are some photos taken: https://ift.tt/6cEVomW I intentionally leaned towards skeuomorphic design for nostalgia. I miss the days where I'd spend hours making a button to look like a physical button. Here I chose to make it look like a "good enough" Teenage Engineering device UI. I tested/used GPT-5.3-Codex to build this from scratch, since there was a lot of hype around it on X. Maybe I wasn’t using it right, but I found it needed a lot of code cleanup at every step and a lot of hand holding along the way. It missed details/nuances and didn't land the skeuomorphic buttons or the interaction polish. It mostly helped with boilerplate where there wasn't much thinking/detailing. It did give a basic starting point for the effect calculations, but didn't really move the needle on the details. Please give it a go and let me know what you think - your photos and video never leave your browser (you can download them if you choose to). Everything is processed locally in your browser (works offline), nothing is uploaded or seen by anyone. https://glitchycam.com February 16, 2026 at 08:57AM

Show HN: Script to check if Notepad++ is backdoored by Lotus Blossom APT https://ift.tt/y6AJMrH

Show HN: Script to check if Notepad++ is backdoored by Lotus Blossom APT https://ift.tt/elLWxcX February 17, 2026 at 01:16AM

Show HN: OpenEntropy – 47 hardware entropy sources from your computer's physics https://ift.tt/pNK8kiM

Show HN: OpenEntropy – 47 hardware entropy sources from your computer's physics I built this to study something most security engineers wave off: whether external factors can nudge hardware entropy sources. Here is why. Princeton’s PEAR lab ran RNG work for about 28 years and shut down in February 2007. People in the lab tried to shift random event generator output, and they reported small deviations after tens of millions of events. https://ift.tt/OtPT1D4 The Global Consciousness Project took a similar idea outside the lab. It has run a distributed network of hardware RNGs since 1998 and looks for correlated deviations around major world events. Most people looking at hardware entropy want true randomness for crypto. I want to treat entropy like a sensor. I want to see what might perturb the underlying noise, not just consume a final stream. So I built OpenEntropy. It samples 47 physical-ish sources on Apple Silicon, like clock jitter, thermal beats, DRAM timing conflicts, cache contention, and speculation timing. Raw mode gives you unprocessed, per-source bytes so you can run your own stats on each channel. The PEAR-style question is: does output shift when “intention” is the experimental condition? With 47 sources, I can run intention vs control sessions and ask if multiple unrelated channels drift the same way at the same time. If thermal and DRAM timing both shift during intention blocks, that’s the kind of pattern I want to measure. https://ift.tt/0wJsQTL February 16, 2026 at 10:52PM