I'm not saying there aren't flaws, I'm saying none of them happen at a rate significant enough to be worth switching to another system (with an entirely new set of flaws).
I haven't heard a compelling argument that anything needs to be fixed with email-based auth patterns. It is imperfect but not bad, and every proposed alternative seems to be worse.
The article seems to lean into security and usability concerns.
On the security front: the weak-point is still the human. If you hand over your credentials to someone nefarious, well.. you handed over your credentials to someone nefarious.
Usability isn't convincing me either. One of the great things about email is that it really is the lowest-common denominator, as another commenter mentioned above. (Almost) everyone, from kids to the most tech-inept luddite have some sort of email.
There are a few companies out there that provide it, Runpod and Replicate being the two that I've used. If you've ever used AWS Lambda (or any other FaaS) it's essentially the same thing.
You ship your code as a container within a library they provide that allows them to execute it, and then you're billed per-second for execution time.
Like most FaaS, if your load is steady-state it's more expensive than just spinning up a GPU instance.
If your use-case is more on-demand, with a lot of peaks and troughs, it's dramatically cheaper. Particularly if your trough frequently goes to zero. Think small-scale chatbots and the like.
Runpod, for example, would cost $3.29/hr or ~$2400/mo for a single H100. I can use their serverless offering instead for $0.00155/second. I get the same H100 performance, but it's not sitting around idle (read: costing me money) all the time.
GPT-4 (and Claude) are definitely the top models out there, but: Llama, even the 8b, is more than capable of handling extraction like this. I've pumped absurd batches through it via vLLM.
With serverless GPUs, the cost has been basically nothing.
I'm bullish on AI, but I'm not convinced this is an example of what you're describing.
The challenge of understanding minified code for a human comes from opaque variable names, awkward loops, minimal whitespacing, etc. These aren't things that a computer has trouble with: it's why we minify in the first place. Attention, as a scheme, should do great with it.
I'd also say there is tons of minified/non-minified code out there. That's the goal of a map file. Given that OpenAI has specifically invested in web browsing and software development, I wouldn't be surprised if part of their training involved minified/unminified data.
Fwiw, I've never paid for Copilot. I was automatically given free access for open source contributions. My largest public repo had maybe 100 stars. I've made minor commits to larger repos.
I don't know what the threshold is, but I'm fine with the trade-off I received.
> do people doing their own server setup like this use containerization at all?
Depends on what you're deploying, really.
If it's one Go service per host, there's no real need. Just a unit file and the binary. Your deployment scheme is scp and a restart.
For more complicated setups, I've used docker compose.
> Also like setting up virtual networks among VPSes seemed like it required advanced wizardry.
Another 'it depends'.
If you're running a small SaaS application, you probably don't need multiple servers in the first place.
If you want some for redundancy, most providers offer a 'private network', where bandwidth is unmetered. Each compute provider is slightly different: you'll want to review their docs to see how to do it correctly.
Tailscale is another option for networking, which is super easy to setup.
It rarely makes sense to hire for a specific need. I want people that are smart and high agency. Seeing how they approach problems like this is generally enough to tell.
I've done similar interviews in the past and they are remarkably high signal.