Looks like the IP address is from Linode. So it could be a $5 VPS running an inefficient server-side framework.
I currently host my personal Web site as static files via AWS CloudFront. But even static hosting on a $5 VPS with Nginx might handle an HN surge fine.
I host my AI-generated code portfolio site separately (to unambiguously distinguish it from my 100% human-written open source work), using github.io (seemed appropriate) with a custom domain.
>static hosting on a $5 VPS with Nginx might handle an HN surge
My personal site is hosted on this exact setup. Twice I made the homepage, twice I noticed no slowdown whatsoever.
The only problem is that in May of this year, when my SimCity 3k in 4k article was found by the HN crowd, its access.log bloated to 200Mb causing my logrotate script (that hooks in Goaccess) to blow up every time since when trying to process it, and this log has been growing every day since - because logrotate isn't doing much rotating!
When I can massage my VPS into processing it, I'll have the stats to enjoy.
I've worked with a lot of "smart" engineers over my career with whom autoscaling is a completely foreign concept, or a half-baked concept at best. My favorite is devs pushing to migrate to k8s because it "scales" and won't hear a single thing otherwise.
For a static blog you dont need that. My blog made the (near bottom of) HN front page last year. I didn't notice a thing until I looked at the traffic report (using goaccess). Static site generator with the result served from a bottom of the barrel Hetzner VPS, using nginx.
If a blog needs "scaling" of any sort you are doing it wrong.
Look at the techempower benchmarks, even python stuff can handle 40k requests per second involving database lookups, and when things are cachable compiled/JITed languages scale to millions on 2 CPUs. And if you object that those are microbenchmarks, I have seen this in real systems too. E.g. converting a convoluted hairball of python, lambdas and SQS to a Rust service running on 2vCPUs reduced latencies from seconds to milliseconds.
The "If necessary I can add autoscaling later" mindset is what leads to bloated, slow websites.
You don't need autoscaling for a basic blog to handle the traffic of Hacker News. People have had "this page is hosted on <vintage computer>" sites hit the front page that have stayed up.
I don't think folks think clearly about how their setup scales computationally when they are choosing their stack. I've been writing a lot of software designed for drop-dead simple self-hosting lately (can run CGI-bin or as a standalone server, based on the env it's invoked in), and I put my own instances behind CGI, keenly aware of the risk on the open internet. But I design .htaccess so that the main server is hitting caches for anything anonymous. This works Just Fine for hitting the HN front page in my experience on a 1GB VPS, since the request never even makes it to my Python code.
I think folks just don't prioritize these sorts of optimizations.
No shade on New Horizons intended, but I was talking about the early 2000's revolution in understanding of ice moons/ocean worlds, and that preceded the Pluto flyby by a lot.
It was a valuable piece of corroborating evidence, but not shocking and unexpected in the way results from those three missions were. We had good reason to believe Pluto would look a lot like Triton, and it does.
Fair enough, though how common was that belief that Pluto would look like Triton? Before the first photos from New Horizons pretty much every artistic rendition of Pluto I'd seen was a solid ball of rock and/or ice, more like Ceres than Triton.
Both were known to be Kuiper Belt objects, so it was expected there would at least be a family resemblance. I don't think anyone expected Pluto to be more active than Triton; that was certainly a surprise.
If there are planetologists reading the thread, I'd love to hear a more authorative perspective than mine!
Right. I said mountain to stress the importance of topography in the NM accident. The parent commenter may pat himself on the back for never flying into terrain during GPS outages in Florida, but there are factors in play in addition to his superior skills.
Looking for paid engagements working on technical due diligence for investors, written communications for exec teams, privacy/trust advisory roles, and anything to do with social impacts of AI. I've run a small SaaS business for 17 years and have a long track record as a writer and speaker on topics around social media and privacy (https://idlewords.com/talks).
My core skill is making esoteric and technical things readable and engaging to the audience of your choice, but if pressed I can code.
Thank you! I realize people have subscription fatigue, and that on this site in particular there's a culture of expecting to read the full text of everything for free. So I try to make the previews substantive enough for people to participate in discussion whether or not they sign up.
I do feel like the free sample guy at Costco, confident that once people try the cube of summer sausage on a toothpick, they'll want to buy the whole thing. But I sure appreciate someone else saying it!
A lot of the work was done to a design point of 0.25 seconds, and Dyson's book says the issue there wasn't the blast clearing, but just being able to move the machinery fast enough. I kind of share your puzzlement; I can see the blast clearing this quickly in space (the debris moves at tens of thousands of km/sec) but not in the atmosphere.
The blast clears that quickly in the atmosphere because the shockwave and debris move at-or-faster-than the speed of sound, so a few hundred meters is tenths of a second or less. You sit inside the mushroom cloud, of course, but the important part is gone quickly.
The Rapatronic camera was used to take these kinds of pictures, and you can see that the actual blast front is around 20 meters across after 1 millisecond (!!) https://en.wikipedia.org/wiki/Rapatronic_camera
reply