Gemini 2.5 is prone to apology loops, and often confuses its own thinking to user input, replying to itself. Chat GPT 5 likes to refuse tasks with "sorry I can't help with that". At least in VSCode's GitHub Copilot Agent mode. Claude hasn't screwed up like that for me.
Speaking of 5 9s, how would you achieve 5 9s for a basic CRUD app that doesn't need to scale, but still be globally accessible? No auth, micro services, email or 3rd party services. Just a classic backend connected to a db (any db tech, hosted wherever), that serves up some html.
You probably cannot achieve this with a single node, so you'll at least need to replicate it a few times to combat the normal 2-3 9s you get from a single node. But then you've got load balancers and dns, which can also serve as single point of failure, as seen with cloudflare.
Depending on the database type and choice, it varies. If you've got a single node of postgres, you can likely never achieve more than 2-3 9s (aws guarantees 3 9s for a multi-az RDS). But if you do multi-master cockroach etc, you can maybe achieve 5 9s just on the database layer, or using spanner. But you'll basically need to have 5 9s which means quite a bit of redundancy in all the layers going to and from your app and data. The database and DNS being the most difficult.
Reliable DNS provider with 5 9s of uptime guarantees -> multi-master load balancer each with 3 9s, -> each load balancer serving 3 or more apps each with 3 9s of availability, going to a database(s) with 5 9s.
This page from google shows their uptime guarantees for big tables, 3 9s for a single region with a cluster. 4 9s for multi cluster and 5 9s for multi region
Part of the up-time solution is keeping as much of your app and infrastructure within your control, rather than being at the behest of mega-providers as we've witnessed in the past month: Cloudflare, and AWS.
Probably:
- a couple of tower servers, running Linux or FreeBSD, backed up by a UPS and an auto-run generator with 24 hours worth of diesel (depending on where you are, and the local areas propensity for natural disasters - maybe 72 hours),
- Caddy for a reverse proxy, Apache for the web server, PostgreSQL for the database;
- behind a router with sensible security settings, that also can load-balance between the two servers (for availability rather than scaling);
- on static WAN IPs,
- with dual redundant (different ISPs/network provider) WAN connections,
- a regular and strictly followed patch and hardware maintenance cycle,
- located in an area resistant to wildfire, civil unrest, and riverine or coastal flooding.
I'd say that'd get you close to five 9s (no more than ~5 minutes downtime per year), though I'd pretty much guarantee five 9s (maybe even six 9s - no more than 32 seconds downtime per year) if the two machines were physically separated from each other by a few hundred kilometres, each with their own supporting infrastructure above, sans the load balancing (see below), through two separate network routes.
Load balancing would become human-driven in this 'physically separate' example (cheaper, less complex): if your-site-1.com fails, simply re-point your browser to your-site-2.com which routes to the other redundant server on a different network.
The hard part now will be picking network providers that don't use the same pipes/cables, i.e. they both use Cloudflare, or AWS...
Keep the WAN IPs written down in case DNS fails.
PostgreSQL can do master-master replication, but it's a pain to set up I understand.
what if you could create a super virtual server of sorts. imagine a new cloud provider like vercel but called something else. what this provider does is when you create a server on their service, they create 3 services, one on aws, one on gcp and one on azure. behind the scenes they are 3 separate servers but to the end user they are a single server. the end user gets to control how many cloud providers are involved. when aws goes down, no worries, it switches to the part with gcp on
Any tech focused social media site (or tech subcommunity on one) are having a fieldday poking fun and/or expressing how baffled they are.
In the tech world, this is a laughable proposition to most people even at $22.90 (though an order of magnitude more palatable at that price).
In the fast fashion world, this is pretty typical pricing for a seasonal trendy item with a "premium" brand/designer attached. Of course, that's predicated on the trend actually taking off, which isn't guaranteed. But all this social media activity around it in the tech circles is certainly boosting it's visibility to people in the fast fashion world that have iphones, which - going out on a limb here - wouldn't surprise me if it were a not-insignificant number.
Besides, at this price point vs what it is and what it costs to manufacture, even if it "flops" it's unlikely to be a big expense to write off.
Whether or not this tarnishes the Apple brand by shear ridiculousness of it remains to be seen, but Apple's general strategy in the post-Jobs era seems to be "Enshittify, just not as much/fast as everyone else and people wont want to leave even if they complain because we're still not as bas as everyone else"
At this point, you may as well get a powerpack for a mini and put it in one of these slings, you could have a crazy powerful machine in your "sock-et" sling thing here...
When the iPhone Air was just another huge phone...but thinner...smh. Apple should put up some page to check interest level in a smaller phone, and with enough interest, go manufacture it. If it is more expensive because economies of scale don't work out, but they create one that is small yet powerful, that's what I would buy at premium, because apparently compactness is a luxury.
And they say you can “create your own personalized color combination”. This is just literally just the pairing of the phone color and whatever color you pick for the bag. Who calls this a customized color combination?!
You're right. Fashion is about trends. Being in love with Apple products, especially without considering the need, usefulness or cost, does seem to be a trend.
Elegrp switches can be used offline. They need to be provisioned online first though, unless you flash with esphome (which can't currently be done wirelessly), but then you'll have to write a custom integration config.
Pros: very inexpensive, and they look great.
Cons: WiFi/ble only, they feel cheap, dimmers don't support a "transition" comment, so you cant dim over time easily.
