There's a global status page, and then there's a local update for people with instances on an affected host --- past some threshold of hosts, the probability of having an issue on some random host gets pretty high just because math. The local status thing happened for people with instances on that machine.
Ordinarily, a single-host incident takes a couple minutes to resolve, and, ordinarily, when it's resolved, everything that was running on the host pops right back up. This single-host outage wasn't ordinary. Somehow, a containerd boltdb got corrupted, and it took something like 12 hours for a member of our team (themselves a containerd maintainer) to do some kind of unholy surgery on that database to bring the machine back online.
The runbook we have for handling and communicating single-host outages wasn't tuned for this kind of extended outage. It will be now. Probably we'll just paint the global status page when a single-host outage crosses some kind of time threshold.
I guess what OP is getting at is that these providers stick to the battle tested proven bedrock and nothing like "run your app where your users are" which I find interesting because that too can be done with any cloud that has a Datacenter in the region where you happen to have users.
So this "closer to your users" voodoo is a little beyond me.
The 'where each user is' is implicit, the expectation is that you're some kind of global SaaS, and you want low latency whereever your users are.
Sure you can do that with any cloud (or multiple) that has datacenters in a suitable spread of regions, but I suppose the point (or claimed point, selling point, if you like) is that that's more difficult or more expensive to coordinate. Fly says 'give us one container spec and tell us in which regions to run it', not 'we give you machines/VMs in which regions you want, figure it out'. It's an abstraction on top of 'battle tested proven bedrock' providers in a sense, except that I believe they run their own metal (to keep costs down, presumably).
Some workloads are surely latency sensitive but some of those transactional CRUD systems don't need that much closer to the edge is my possibly flawed opinion.
I mean chat or e-commerce yes, the edge and all.
But for a ticketing system, invoicing solution or such, a few hundred millisecons are not that much of a big deal but compliance, regulations matter more.
models are still having trouble reasoning – current tricks still depend of feeding back an intermediate answer with a different prompt, but it is still an LLM, and most times the same LLM
Yeah, it's a large language model not a large reasoning model. I don't really have any faith in what seems to me like attempts to make LLMs act like LRMs.
I think it's always going to be a bit shit, no matter how large they make them it's always going to be an obvious faker, always going to confabulate and lie etc.
As long as we are using a technology that merely fakes intelligence (using statistics to generate the most likely next token based on training data is not intelligence), it is going to be obvious that it's fake. This whole bubble is going to burst when people start realizing how overrated it is.
parent gave five examples of issues they found while using a taxi in the manner you described
you could have just believed them instead of being antagonistic about it, this is especially unnecessary given the topic has a history that supports the experiences the parent poster listed
import flask
import random
app=flask.Flask()
@app.route('/')
def random_redir():
with open('urls.txt') as of:
return flask.redirect(random.choice(of.readlines()))
Premature optimization may sometimes be unadvisable, but in this case the optimized version uses half the memory, is two orders of magnitude faster, and doesn't let your users DOS you by triggering huge file reads on each request.
> doesn't let your users DOS you by triggering huge file reads on each request.
I understood what you were trying to do on your first reply – "Prolly don't want to read the file on every request though" – no need to repeat yourself.
plese remember:
1. it's pseudo code, the optimisation is superfluous
