Unfortunately the transparency of the IP stack means that unless u want whole world to know where u live via one DNS query, you'd need to use a service to proxy back to urself. And if ur paying for remote compute anyways, you could probably just host ur stuff there. Any machine that can proxy traffic back to you is just as capable of hosting ur static stuff there.
Yeah I agree with this. The only tool that really matters is file patching -- which you can check something like the opencode patch implementation, its fairly straightforward.
The main problem with actions is the way they advertise its usage "just put workflows together" is a horrible and non-debuggable way to do things. But even in the tech itself, caching is pretty stingy which can slow dev builds for fairly simple projects because every run will repeat some common work unless you have the cache perfectly configured (did u cover npm, docker, etc. with cache keys correctly?)
Looking at these flaws, running workflows from a persistent VM of ur own becomes pretty tempting because you don't need to copy caches around and can easily SSH in.
Yeah its very dumb stuff that people unfortunately fall for.
If those flames of resentment could be redirected toward policy makers and corporations for flooding the lower-income labour market and away from those who took the opportunity, that'd be great.
Yeah its an awkward position, as self-hosting is going to be insanely expensive unless you have a substantial userbase to amortize the costs over. At least for a model comparable to GPT-4o or deepseek.
But at least if you use an API in the same region as your customers, court order shenanigans won't get you caught between different jurisdictions.
It's cool how neural networks, even convulutional ones, are one of the few applications that you can compute through homomorphic encryption without hitting a mountain of noise/bootstrapping costs. Minimal depth hurrhah!
I also know nothing but here's something missing from the blog post:
"A random subgraph of the bunkbed graph is then formed by independently deleting each edge based on the assigned probability."
So the (apparently incorrect) intuition is that an (upper<->lower) connection starts with an extra edge in the connection, so an (upper<->lower) connection has a greater risk of disconnect via random edge removal. Therefore, a same-level connection is more likely to remain after the random edge removal.