I would probably just watch the listing and/or set up a deal alert on Slickdeals and wait. If you're in a hurry though, you can probably find a used one on Ebay for not too much more.
This article is coming out at an interesting time for me.
We probably have different definitions for "budget", but I just ordered a super janky eGPU setup for my very dated 8th gen Intel NUC, with a m2->pcie adapter, a PSU, and a refurb Intel A770 for about 350 all-in, not bad considering that's about the cost of a proper Thunderbolt eGPU enclosure alone.
The overall idea: A770 seems like a really good budget LLM GPU since it has more memory (16GB) and more memory bandwidth (512GB/s) than a 4070, but costs a tiny fraction. The m2-pcie adapter should give it a bit more bandwidth to the rest of the system than Thunderbolt as well, so hopefully it'll make for a decent gaming experience too.
If the eGPU part of the setup doesn't work out for some reason, I'll probably just bite the bullet and order the rest of the PC for a couple hundred more, and return the m2-pcie adapter (I got it off of Amazon instead of Aliexpress specifically so I could do this), looking to end up somewhere around 600 bux total. I think that's probably a more reasonable price of entry for something like this for most people.
Curious if anyone else has experience with the A770 for LLM? Been looking at Intel's https://github.com/intel/ipex-llm project and it looked pretty promising, that's what made me pull the trigger in the end. Am I making a huge mistake?
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?
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.
Related to your point on supporting 0-transpilation workflows as a first class citizen, is the fact that Flow was explicitly just type annotations & checking, and aimed to introduce 0 runtime constructs.
This is something Flow did from the beginning and TypeScript eventually established as a non-goal after already implementing several runtime constructs that they can no longer afford to remove for backwards compat [1].
Though interestingly enough, Flow themselves recently announced they're going to start introducing runtime constructs, which is an interesting plot twist [2].
In case you're open to something for JS instead of Python, my life has been much better since I switched from AHK to nutjs for my own automation scripts: https://nutjs.dev/
A real programming language, and support for multiple platforms!
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...
Interestingly enough, the topic of the post is something I mentioned in this reply as the "achilles heel" of our instant deployment story: https://news.ycombinator.com/item?id=33135153
Much more work to be done, but I can now sleep a bit better knowing this one has been knocked off the bucket list.
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.
Hi HN, author here. I set out to do a casual comparison of deploy speeds between Reflame (disclaimer, I built Reflame) and other popular services on a near-stock Vite React app, not expecting a whole lot of differences between the others (since most of them were just spinning up VMs/Containers and running the same CLI tools).
I ended up finding out that Netlify had some rather long queuing times that made it ~10s slower than the duration it reports, putting it well behind Vercel (which reports similar a similar duration), but still ahead of Cloudflare Pages (which suffers due to doing a bunch of things irrelevant to the simple Vite app I was deploying).
Meanwhile, Reflame consistently finishes deploying before I can even finish creating the PR. :)
If this piqued your interest for Reflame, I have a demo on https://reflame.app, and more technical details on my Show HN launch post (https://news.ycombinator.com/item?id=33134059). Give it a shot if you're building a client-rendered React web app, and tired of waiting for minute-long deploys that break your flow every time you want to share your work. :)
Developers know much more than other professions about how much SaaS products cost to run in terms of infra (i.e. very little for most products), so are much more likely to anchor on infra costs when considering whether a price is reasonable during purchasing decision than basically any other group.
Most SaaS are priced completely independently of infra costs (or any other costs really), but we are much less likely to accept products priced with high margins on top of obviously low infra costs, even though that doesn't represent nearly the full cost of running a SaaS (which consists mostly of payroll due to how high our salaries typically are haha...).
We also like to justify this line of thinking by the argument that "well, I can build this myself in an afternoon" (significantly underestimating the real ongoing time investment required to build and maintain a SaaS product, even seemingly trivial ones) or "I can write some bash scripts and put this on the VPS that I'm already running anyways" (undervaluing our own time).
Competition for developer tooling products is _fierce_, possibly more so than any other industry, precisely because we really seem to love spending our free time building slightly different versions of the tools we use that suit our preferences better, sometimes before we even try to Google if that slightly different version already exists.
Again, I'm totally guilty of this myself, since Reflame started as a side project initially to scratch my own itch, and I can't claim to have done an exhaustive search on the problem space before I started.
This results in a vicious cycle where every product, however innovative it might be at its inception, gets quickly commoditized by dozens of similar products immediately following any signs of traction, so they end up having to shift to competing on price eventually.
Combined with https://news.ycombinator.com/item?id=33691132 means any product that isn't available for free then eventually rots into obscurity due to the unfair distribution advantage of "free" in this market. Thus they are forced to offer a free version themselves and the cycle continues.
We get so many developer tooling products thrown at us, either for free or dirt cheap, that over the decades it's conditioned us to assign much less monetary value to developer tooling products compared to what a simple opportunity cost analysis would yield, given the high monetary value of our time.
I certainly suffered from this myself to a rather extreme degree in the past, having categorically refused to pay a single cent for anything I used to build side projects with, until I started to seriously think about pricing for my own product. Eventually I realized throwing money at almost any problem where it could buy me more free time should be a no-brainer considering how highly I value my free time.
Tangentially, I think there's an interesting analogue in here to what Steam did in the PC games market, but I digress...
Seeing a lot of comments trying to dispute the claim that "individual developers do not pay for tools". The claim does invite these kinds of disputes since it's so absolutist, but I do believe there is some truth to it, at least if we take it as a generalization (rather than a literal statement).
Anyone who's either worked at a developer tooling company or tried to sell to developers themselves (I personally did both, having worked at CircleCI in the past and now building my own developer tooling product at https://reflame.app, Show HN launch thread here: https://news.ycombinator.com/item?id=33134059) can probably back the observation that we individual developers are notoriously reluctant to open our wallets, even for products that we love and use daily, despite our high disposable income relative to professionals in other markets.
Gonna share a few of my own hypotheses for some of the contributing factors as comments below for discussion.
Would be fun to see folks share their own! Especially if you've seen successful strategies for how someone might be able to overcome these hurdles to selling products to individual developers at scale (a topic near and dear to my heart these days)!
Agreed, this is awesome! I've been using Cloudflare Tunnel for local dev, but the fact that it seems to be coupled to their CDN product with no way to permanently turn off the CDN functionality has caused quite a few headaches lately (though it's possible to turn off temporarily using "Development Mode").
Would love to give this a try, though from the post it's not clear if we could use our own custom domains instead of the provided ts.net ones? This is a necessity for my use case where I need to be able to handle wildcard subdomains.
It's out of stock now unfortunately, but it does seem to pop up again from time to time according to Slickdeals: https://slickdeals.net/newsearch.php?q=a770&pp=20&sort=newes...
I would probably just watch the listing and/or set up a deal alert on Slickdeals and wait. If you're in a hurry though, you can probably find a used one on Ebay for not too much more.