HN user

perpil

594 karma

Founder of Speedrun https://speedrun.cc Speedrun is markdown to build tools. It's an extension to GitHub markdown to prompt for inputs, get temporary AWS credentials, run Javascript and reference configuration so your READMEs, runbooks and documentation can do what they describe with a click.

Posts12
Comments51
View on HN

Agreed, maybe a forest fire or lightning strike might have made it more obvious that charring preserved. Charcoal in a campfire could have easily disappeared in the next fire.

They do give Leonardo a lot of credit for a single sentence, but it may be the first documented instance of this charring technique.

This is very thorough, but I have a few things to add if you are using Node 22. I benchmarked Node 22 earlier this year using something similar to the light benchmark. https://speedrun.nobackspacecrew.com/blog/2025/07/21/the-fas...

I found that Node 22 had ~50ms slower coldstarts than Node 20. This is because the AWS Javascript V3 SDK loads the http request library which became much heavier in Node 22. This happens on the newly released Node 24 as well.

I recommend that if you are trying to benchmark coldstarts on Lambda, you measure latency from a client as well. The Init Duration in the logs doesn't include things like decrypting environment variables which adds ~20ms and other overhead like pulling the function code from S3. The impact of this manifests when comparing runtimes like llrt to Node, the Init Duration is faster than Node, but the E2E time from the client is actually closer because the llrt bundle size is 4-5MB larger than Node.

Its predecessor (mkdocs material) supported blogs via a plugin and rss feeds via a mkdocs plugin (https://guts.github.io/mkdocs-rss-plugin/). I don't believe it supports blogs yet according to this: https://zensical.org/compatibility/#phased-transition-strate... but will in the next phase when it supports plugins.

It doesn't support loading content from a database that I'm aware of, it uses markdown files on disk as input.

This is not about the AWS Console. It is talking about the customer's site hosted on CloudFront. It is possible to cross wires with user sessions when using CloudFront if you haven't set caching granular enough to be specific to an end user. This scenario is customer error, not AWS.

The fact you've copied screen.studio so closely leaves a bad taste in my mouth. On the landing page you apply formatting in Google Sheets, just like screen studio does. It's ok to be inspired by screen studio but remember they are mostly a solo dev too so try and be more original.

Not OP but was there 15 years (left Dec 2021) and surprised I wasn't aware of this. I was only aware of a few tools that acted like chatbots to automatically gather context or take action from chime/tt/alarms.

When I was at AWS, I built something so I could run things straight from the wiki. Think cloudwatch queries, aws cli commands etc with user inputs but without all the setup of securely getting the right credentials and formatting inputs. I've rebuilt to run stuff straight from GitHub. Here's it invoking a lambda function straight from a github wiki with user input in 4 lines of code: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...

"we cannot confirm that no other such instances occurred". I'd like to understand this more. Do they 1. not have a fingerprint of what the exploit looked like because it was indistinguishable from customer behavior? 2. Not have logging necessary to audit this? Regardless, with the added monitoring to detect suspicious activity, do they also have the logging to see everything a bad actor did if there is a new exploit?

Markdown lacks prompting for inputs and running javascript but is easier to write and offers a quicker update, preview, deploy cycle. Preview and deploy is often a simple save vs. a build and deploy process. By extending markdown to support prompting for inputs and running javascript, you close some of the gaps and get the best of both worlds.

"Privacy & settings – where it lives now – is a natural home for it, but we think it should appear elsewhere too."

Seems like the next step would be to send an app push notification before the call and to have a banner that's visible as soon as you log in to the app. Some sort of visual indicator that appears everywhere in the app that you should not be on a call may also reduce an attackers chance of succeeding.

I got the same good chill running down my spine watching this as when I watched Second Reality 30 years ago. I think how they mirrored the music so well caused my brain to just fill in the pieces of the graphics. I was especially impressed at the attention to detail down to the font in the end credits. Hats off, this made my day.