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.
It's interesting to me that other trackers have end-to-end encryption. I wouldn't have expected it but makes sense for the threat model.
> Providerslike Apple and Google achieve location indistinguishability by end-to-end encrypting location information using a public key embedded in BLE advertisements emitted by a tag
Though it makes me wonder... What's the private key? If the public key is attached to the tag, how is the device getting it? I'm guessing it gets shared during pairing.
Very cool! I only skimmed Section 4 a bit, but that's really cool!
I was going to ask how the web UIs possibly work if the location is indistinguishable, but I went to the Google Find Hub, and it appears you can't view the location for tags unless you enter your phone's pin code / pattern lock. This must either communicate with the phone or the keys are stored on Google's end.
EDIT: I turned my phone off, and I can still get the location of my keys... surely this doesn't mean the key is stored on their end? Wouldn't be very good E2EE in that case :)
AFAIK, there's a pre-shared key exchanged during pairing, and you then calculate keypairs based on (key, timestamp).
Rotating your keypairs in that way prevents attackers from identifying you across time. E.G. if they link a particular keypair to you — let's say at an Airport security gate — that doesn't let them know you've entered a lawyer's office a week later, because that's done under a different, unrelated public key.
If the author is reading this, the hyperlink to the book in the first paragraph is broken. Looks like it's attempting to direct you to an absolute url that was meant to be relative.
I've struggled with this "responsibility" take. What does it mean in the context of an open source project? As far as I understand it, the original contributors of bugs are often not the ones fixing them (though they can be). Is it that if you write enough buggy code you get banned as a contributor? Is it that you're not allowed to say Claude ate my homework?
> Is it that if you write enough buggy code you get banned as a contributor?
If this is a consistent issue, your contribution would (ideally) be continuously put into a backlog until someone else with no connection to you verifies that it's as bug-free as it appears to be. (Excluding non-obvious security & performance issues)
> Is it that you're not allowed to say Claude ate my homework?
Yes. As the contributor, you should be the first one to look over the code, not someone else.
I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that way though, and make caching decisions based on it. As far as I know, they shouldn't.
Obviously it's against the spirit of the thing, but I don't think it's wrong per-se.
I reckon it is still an abuse. I am willing to interpret longer target URIs… so long as they don’t contain a question mark. /no-query-strings is longer than /?.
I've never been in the position that I've had to deal with this. Is the best you can do in this situation to pull the files and optionally republish them to a robots.txt'd path (with authn/z, too)? I can't imagine you can get it pulled from search engines very quickly...
There's a way to submit a request with Google ticket content taken down and then the easiest way would be probably to do a no index in the header response for future content
I've been waiting for something like this to come along. I keep hearing people say LLMs are a new abstraction layer, and I fundamentally disagree. We don't commit our compiled machine code, we commit our C. Yet, with LLMs, we commit our generated source code, completely throwing away the English language abstraction.
This seems to scratch that itch. The non determinism makes it probably not suitable for most uses, though.
We've had "natural language"-esque DSLs for a long time. Cucumber is probably among the better known, at least the first that comes to mind.
> Yet, with LLMs, we commit our generated source code, completely throwing away the English language abstraction.
Unless you want to commit your chats, that's very much a bonus. You don't want two different people "compiling" completely different versions of your application, because LLMs aren't deterministic.
As far as I'm aware, Pyroscope itself is not a profiler, but a place you can send/query profiles. OpenTelemtry is releasing a profiler, so they don't compare. One can be used with the other.
Not sure how I feel about transcripts. Ultimately I do my best to make any contributions I make high quality, and that means taking time to polish things. Exposing the tangled mess of my thought process leading up to that either means I have to "polish" that too (whatever that ends up looking like), or put myself in a vulnerable position of showing my tangled process to get to the end result.
reply