ollien

These days I work in infrastructure at Discord; lots of fun problems to solve in that space. I'm getting to work on a lot lower level than my job description would imply.

Hope things are going well with you at Dagger(?)!

Not really a question, but just saying "hi!". You might not remember this, but in 2012 I was about 13 years old, interested in computers, and had no one to really talk to about them. By some miracle my father (who is in no way in tech!) found some connections to YC and organized for us to come out to California to see a bunch of companies. dotCloud was one such company, I still have the t-shirt! I remember chatting with you and you taught me how to use pip, it's a fond memory I look back on often.

What sandboxing tools do you recommend? There's lots out there and I'm unsure which to trust.

Hug of death? Archives don't have it either

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 :)

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.

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.

    <a href="https://books/face-with-tears-of-joy">

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?

When the goal is "the funniest way", I think that's a hit :)

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'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...

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.

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.