Built this because I couldn't find one single place to watch validator downtime events across chains in real-time. Tracks slashing, delinquency, missed votes across SOL, ETH, SUI, and ATOM - 819 events and counting.
You can filter by chain or search for a specific validator. The 'in scan DB' links show what we found running on the validator's host from our scanning infrastructure. Feedback welcome, especially on which chains to add next.
Was mostly entertained by the weird names for the SOL validators!
I actually appreciate the feedback here. I find it personally really challenging to take feedback on and this is part of the journey.
The “I’m under attack” mode you mention is a JavaScript challenge which is Layer 7. It doesn’t help when SYN floods hit your kernel before any HTTP connection is established.
You are probably the first person outside my network to watch the video. Thanks.
The vids are real. I’ve been trying to work out how to better demonstrate this.
I built a deterministic, offline audio analysis system that models long-horizon musical structure:
tension, novelty, fatigue, and impact.
It analyses full tracks and produces interpretable curves and events (drops, stagnation,
transitions). No ML or training data.
This repo is the Python reference implementation used to prototype the kernel behind a real-time C++ DAW plugin. The Python outputs are the "golden" results used to validate the C++ port.
Motivation was simple: I heard Beyoncé’s "Haunted" and wanted to understand why it worked so well structurally.
I was not expecting to LIKE Beyoncé!
That turned into a research artefact I thought others might find interesting.
The c++ repo is defo hard work, will share soon.
The behaviour later turned out to align closely with David Huron’s ITPRA framework, though this project doesn’t attempt to prove it.
Love this. Totes getting bored using a gazillion tools to help onboard my users. Before you've even started a new venture, you'll find yourself hunting for the right tool for a job you didn't even expect would exist.
Which support tool. Which analytics tool. Which AB testing tool. Which wizard tool. bla bla bla.
Back to basics. I'll get my coding hat on and actually make an effort. Nice work. Will try this one myself next time I need a wizard.
I am an OpenWrt developer but not part of the core team by far. We've been developing a platform to manage OpenWrt devices from the cloud for the last 18 months.
We struggled with this since day zero. As a startup, we didn't have the luxury money to build our own boxes with loads of memory. Plus we we wanted to support all OpenWrt devices. Ultimately, we took the logic of auto upgrades (and everything else for that matter, separate story) off the aps directly and now do everything in our platform.
Currently we only support a minimal set of devices - about 15 in total. However building / maintaining the firmwares for all of these, making sure they're up to date etc. is a huge burden.
Upgrading a box for a user poses so many challenges, I can't see why this is actually OpenWrt's responsibility?
What to do about testing? New releases can (do) have bugs. Again, since we're bootstrapped, we don't have a lab so we have separate development modes and test these on customers willing to have the bleeding edge.
The Netflix Syndrome as we call it. What if someone/thing is connected - do we still upgrade? I work late, and before sleep, I usually watch some Netflix. However, our nightly upgrades pushed from our platform were ruining my enjoyment! Shock. We had to introduce a feature to disable auto upgrades if there is a device detected.
What about stragglers? Customers with very outdated firmwares were not only vulnerable but also holding our development back. In the end we upgrade all boxes that are 2 months old between 4am and 5am local time every day. Some people refused to upgrade, they like the status quo, they're used to the gotchas in a particular release.
Ok, OpenWrt is becoming hugely popular but there's still a huge knowledge gap. If people struggle to understand the difference between WiFi and broadband, how can we expect them to understand firmware let alone, why it needs to be updated.