Sure you can provide an image as request body, but you could already do it with b64 query parameter. If you try hard enough, you can poorly use any proposed standard. GET with query parameters already is opaque and makes cache busting trivial.

Query parameters are length-limited, because HTTP URIs are: https://www.rfc-editor.org/info/rfc9110/#section-4.1-5. There is no expectation for arbitrarily long HTTP URLs to be functioning.

Your link doesn't say URIs are length-limited

I'm guessing you never hit this issue then, but it's a real issue. Whether or not it's in the RFC as a hard limit it doesn't matter, no HTTP server will allow unlimited sized URIs.

You simply can't base64 large payloads and you're stuck with workarounds.

You are guessing wrong. Thanks, I know specific implementation will come with their limits. This will equally apply to QUERY body size and caching strategy.

Are we seriously ok with linking the RFC as source while providing a statement that doesn't match? RFC does matter.

The RFC does say "It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements."

One can infer from the RFC that you can reasonably expect many implementations to fail beyond 8000 characters, and that there are no guarantees up to that either.

True, the RFC doesn't specify a limit, but it does clearly indicate that it's not unbounded, nor should you expect it to be.

This RFC (10008) does not require caching to be implemented at all, so it would make no sense to make a recommendation here for what is a reasonable limit to expect caching to work.

They are in the sense that the recommended supported length is only 8000 bytes. There are no such specified length recommendations for HTTP body size.

Recommended supported length is at least 8k.

Of course I don't advocate oversize URLs. That's a point of RFC10008.

Let's say we build a service for image transformation or image information extraction. Get isn't practical. QUERY with image as body could be a valid usage, regardless of caching. It conveys information that request is idempotent and can be retried with no impact on data, contrary to POST. If your http client is configured to support this, it can potentially improve reliability.

> prescriptive nonfiction is the canary in the coal mine

Self-help is not the canary for other genre. Self-help doesn't comme with significant art. Their consumer gets a better experience through LLM that extracts the substance and contextualizes it.

It doesn't tell what will happen at scale regarding fiction and other content where people tends to expect a genuine human contribution. Sure you can get success with AI-written or AI-assisted writing, but it doesn't mean human written books will no longer catch interest.

They don't care much about connecting it to the grid. They'll take whatever is available and cheaper. If gas turbine on trucks are somehow cheaper (reduced regulation, taxation, planning...) than grid, that'll stay as-is in the foreseeable future. Once you spent billions on turbines and gas contracts, you most likely won't connect to the grid overnight.

Revenue? In that industry?

Bad UX (online, onsite, customer service) is not a bug. Ryanair makes you feel like livestock so you experience their cheapness. You must feel like they are milking everything they can to offer absolute lowest possible price.

This include never taking accountability when shit hits the fan.

They also "reap huge benefits from the tight feedback loop that the compiler provides".

When something is easier/requires less context, it tends to work well for both human and LLM.

I've noticed this a lot in LLM generated Java. Since it doesn't know what can or can't be null it tends to wrap everything in Optional<T>. Super strong type systems are becoming even more important.

You probably need to tell it to rip as many of those out as possible (and replace them with null annotations).

I've noticed LLMs sometimes pick a documented anti-pattern (passing Optional around in Java is not recommended), then amplify it (like a human might).

It's small if you do it once. If that becomes a pattern and you know you get away with it most of the time, it can boost revenues. Would that be a pattern, stealing $200K to a single family probably is too ambitious. If that's business as usual, I hope people will now share their stories.

I mostly use it because I'm lazy on the presentation, not so much on the content. I provide full knowledge and content plan in my prompt. I do manual review & fix.

Someone informed can tell the content is generated. I don't really care, that's still my knowledge and I can discuss content in depth.

If you can't even be fucked to write your great knowledge nobody will be fucked to read it.

It provides far better illustration than I can draw. I can focus on solutions while iterating quicker on presentation.

TBH I don't care much people not reading it "because it's AI". It's just work, if you don't need it then don't use it. That fine for me, no hard feeling.

Ofc, it doesn't mean it's any safer outside.

I mean..if it mostly happens in families that does mean it's safer outside

When you basically don't allow kids to go outside, there is little exposition to potential predator other than family, teacher and similar. There is a selection bias. It doesn't mean it's any safer to generally keep kids outside of families.

Families are outside too. Once you trusted your neighbor, if they are abusing their child why wouldn't they abuse yours?

Are those RFID chips preventing me (or a physical robot) from typing generated text?