Even if you've ticked that box, the conversation can still be trained on if you:

(a) Click thumbs-up/down in the conversation [1]

(b) Have the conversation flagged for potential safety concerns

[1]: https://help.openai.com/en/articles/5722486-how-your-data-is....

Hi, Since you're here, I just wanted to alert you to the fact that the link you posted w.r.t donating to Jellyfin doesn't work. https://jellyfin.org/donate gives a 404 and the correct link for donating is at: https://jellyfin.org/docs/general/contributing/direct-donati...

Thanks for the heads-up I'll get that changed now

I've updated that now and done a quick check so it's actually linked to the devs properly. Much appreciated and thanks for reading the article

Card acceptance may be up (I can't comment one way or another) but last I was in India, a large number of POS seem to straight up block international Credit Cards.

Yep, international/amex cards aren't enabled by default by most POS providers (_due to the high fees on the merchant side_) and most small businesses don't really know or care enough to enable them.

Isn't that GP's own 3d engine?

As someone who's tried several keyboards, a key feature I've found myself unable to go without is contouring of the keyboard. Keyboards like Kinesis Advantage 2, Kinesis Advantage 360 and the Glove 80 essentially. I've personally found it the biggest gain to reducing strain on my left hand.

Using GET with a Body doesn't work if you try using it in the browser with JS fetch for example[1]. Additionally, a lot of existing web servers by default ignore GET requests with a body.

The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET requests not having a body, there's a limit to the amount of data you can put in the URL and you also cannot put sensitive data in it.

Additionally, GET requests are meant to be highly cacheable by default while a lot of the QUERY type requests are usually meant more for one-shot access.

QUERY is meant to address these limitations.

[1]: https://github.com/whatwg/fetch/issues/551

There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.

To clarify, by REST spec I meant the state of access defined by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/....

This is just HTTP. The definitive guide to REST is "Architectural Styles and the Design of Network-based Software Architectures" by Roy Fielding.

>Additionally, a lot of existing web servers by default ignore GET requests with a body.

I think the point made is that _all_ existing web servers have no idea what a "QUERY" is anyway, so changes need to be made anyhow.

Not exactly. OPTIONS lets servers tell you that QUERY is supported if the client requests it and Status Code 405 lets servers tell you that QUERY is not supported. That's very different from the current landscape where several proxy servers and web servers simply ignore the Body of a GET request.

Was reminded of this article when I read what you said: https://brooker.co.za/blog/2026/06/19/waiting.html

I have an ancient Windows 98 computer which I used to use at my grandparents' home until a few years ago. All the problems you mentioned did exist. However, the machine still felt more responsive than today's laptops. Something being objectively slow is very different from it feeling slow when you use it. As an example, I never had Word autosave turned on. It was always explicit (even if this meant I'd usually lose what I was working on when the computer lost power)

It's fun to see the Treedix tester come up on HN. I got one a few months back and have quite enjoyed using it. One thing which I did find interesting was that one of the cables had the emarker data lie. IIRC, the emarker data would suggested it supported much higher speeds and wattage than it did. Fortunately, the other testing screens successfully detected it only had USB 2.0 wires even though it claimed to support 40 GB/s.

This is off-tangent but I find it a bit odd that the blog uses a URL fragment to load different articles when it's usually used to navigate within a page.

A consequence of this seems to be that clicking the link to a different article leaves you at the bottom of the page even though the article itself has changed.

This seems to be using JS to fetch the markdown and then render it but I do feel that it may be better off to simply pre-convert the markdown as part of the deployment process and serve the static page.

That's a great idea. Going to try this next :)

Happy to help :)