lewisl9029

I had a somewhat similar experience trying to use LLMs to do OCR.

All the models I've tried (Sonnet 3.5, GPT 4o, Llama 3.2, Qwen2 VL) have been pretty good at extracting text, but they failed miserably at finding bounding boxes, usually just making up random coordinates. I thought this might have been due to internal resizing of images so tried to get them to use relative % based coordinates, but no luck there either.

Eventually gave up and went back to good old PP-OCR models (are these still state of the art? would love to try out some better ones). The actual extraction feels a bit less accurate than the best LLMs, but bounding box detection is pretty much spot on all the time, and it's literally several orders of magnitude more efficient in terms of memory and overall energy use.

My conclusion was that current gen models still just aren't capable enough yet, but I can't help but feel like I might be missing something. How the heck did Anthropic and OpenAI manage to build computer use if their models can't give them accurate coordinates of objects in screenshots?

Congrats on the launch! :)

Apparently I signed up for Instant previously but completely forgot about it. Only realized I had an account when I went to the dashboard to find myself still logged in. I dug up the sign up email and apparently I signed up back in 2022, so some kind of default invalidation period on your auth tokens would definitely make me a bit more comfortable.

Regardless, I'm still as excited about the idea of a client-side, offline-first, realtime syncing db as ever, especially now that the space has really been picking up steam with new entrants showing up every few weeks.

One thing I was curious about is how well the system currently supports users with multiple emails? GitHub popularized this pattern, and these days it's pretty much table stakes in the dev tools space to be able to sign in once and use the same account across personal accounts and orgs associated with different emails.

Looking at the docs I'm getting the sense that there might be an assumption of 1 email per user in the user model currently. Is that correct? If so, any plans to evolve the model to become more flexible?

This is the only real problem I have with how they handled the situation. But it's a big problem.

Whether or not these folks on free plans are ever going to convert to paid, they trusted PlanetScale to serve as a critical building block for their project/business. I think the least they could do is ease the transition by offering them a reasonable amount of time to offboard.

I personally would never trust critical infra to a company that has ever abruptly terminated a product offering with only 1 month notice.

Have been looking forward to this release for quite a while! Huge props to the Cloudflare team for putting this out there!

I've been operating a cluster of NGINX nodes on Fly.io and using njs (NGINX's custom JS scripting engine) for all of my custom routing logic, and have been really feeling the limitations (had to spin up a separate companion app in nodejs to work around some of these). Having access to the entirety of the Rust language and ecosystem to customize routing behavior sounds incredibly compelling!

I did a quick scan over the codebase and couldn't see anything around disk caching like in NGINX, only memory caching. Curious if Cloudflare is operating all their production nodes with memory caching as opposed to disk caching at the moment?

I'd love to see an option for disk caching for use cases that are a bit more cost sensitive.

It's been a while, but last time I checked, write latency on R2 was pretty horrendous. Close to 1s compared to S3's <100ms, tested from my laptop in SF. Wouldn't be surprised if they made progress on this front, but definitely do dig deeper if your workload is sensitive to write latency.

Another (that probably contributes directly to the write latency issues) is region selection and replication. S3 just offers a ton more control here. I have a bunch of S3 buckets replicating async across regions around the world to enable fast writes everywhere (my use case can tolerate eventual consistency here). R2 still seems very light on region selection and replication options. Kinda disappointed since they're supposed to be _the_ edge company.

Vertical tabs in Edge seems to trigger false positives on this. Really hope that's not the only heuristic they're using.

Wow, and here I thought I was the only one to make this move from Firefox to Edge, precisely because of the excellent native vertical tabs functionality.

It's not perfect, but the level of UX polish and the first-class integration with other browser features is unmatched by any Firefox vertical tabs extension I've tried.

I still can't believe the other browsers haven't caught on to the fact that power users want vertical tabs and are willing to switch browsers for it after so many years of Firefox extensions showing the way...

Thank you for taking the time to respond! All very fair points.

The post was definitely written as a content marketing piece for Reflame, but I did also write it with the genuine intent to give an apples-to-apples comparison between the current popular deployment services in use by most people today, that could be useful even for someone who's completely disinterested in ever using Reflame (you're totally right that comparing Reflame to the others is apples-to-oranges, and I honestly did try to disemphasize those kinds of comparisons in the discussions). Hopefully that was true for you as well, but I apologize if the self-promotion was too in-your-face. Will try to do better next time.

Re: scale. Reflame is definitely playing on easy mode at the moment since the deployment service is sitting idle most of the time, and ready to process requests at a moment's notice. The real test will be when we have enough traffic to start saturating compute on individual nodes and require more sophisticated routing and scheduling.

That said, Reflame's intrinsic advantage is that individual deploys are fast and efficient enough that it's feasible to pool them onto a small handful of simple multitenant web servers sharing memory/compute without significantly impacting user experience, rather than requiring each deploy to spin up a new VM/container in a gigantic fleet using dedicated compute and over-provisioned memory. So I'm bullish on our longer term scaling prospects here.

Re: instant. I've definitely been making a conscious effort to avoid the term, but looks like I wasn't successful in that very prominent instance. That's embarrasing, appreciate you catching that. That said, I don't think my use of it is necessarily hypocritical since Reflame deploys fast enough to qualify as truly instant in a fairly rigorous definition of the word as seen in the results of the article.