- The real challenge is that implementations aren't static.
Just because today's implementation has 4 9s that doesn't mean tomorrow's will...
- Each AWS service may choose different pipeline ordering based on the risks specific to their architecture.
In general:
You don't deploy to the largest region first because of the large blast radius.
You may not want to deploy to the largest region last because then if there's an issue that only shows up at that scale you may need to roll every single region back (divergent code across regions is generally avoided as much as possible).
A middle ground is to deploy to the largest region second or third.
- Former AWS employee here. There's a number of reasons but it mostly boils down to:
It's both the oldest and largest (most ec2 hosts, most objects in s3, etc) AWS region, and due to those things it's the region most likely to encounter an edge case in prod.
- 2 points
- I think Wiim can do this
- The real issue is the administration of the hospital sees every minute the doctors spend taking better records instead of seeing another patient as a loss of ability to bill someone's insurance for that time.
I'm sure there's many doctors who would like to take better notes if they were allowed the time to do so.
Maybe the case for better records reducing costs to insurance by assisting in prevention / early intervention is a path forward?
- Naming may provide useful hints about some utility of a tool but naming does not bound the utility of a tool.
- If the mainboard is upgradable similar to Framework laptops this is pretty amazing. If not it's an e-waste generator.
Couldn't find any info on that on the page.
- Microservices for days.
I worked on lifecycle ~5 years ago and just the Standard -> Glacier transition path involved no fewer than 7 microservices.
Just determining which of the 400 trillion keys are eligible for a lifecycle action (comparing each object's metadata against the lifecycle policy on the bucket) is a massive big data job.
Always was a fun oncall when some bucket added a lifecycle rule that queued 1PB+ of data for transition or deletion on the same day. At the time our queuing had become good enough to handle these queues gracefully but our alarming hadn't figured out how to differentiate between the backlog for a single customer with a huge job and the whole system failing to process quickly enough. IIRC this was being fixed as I left.
- 4 points
- Fume hoods have an exhaust to outside the inhabited area, which allows the interior of the hood to operate at a negative pressure. This means air is drawn in through the gaps rather than allowed to escape through them.
- The feature requires both the airpods and a connected iPhone to work. The phone has GPS.
- Amazon seems to be taking the "When Everybody Is Digging for Gold, It’s Good To Be in the Pick and Shovel Business" approach here.
Don't need to train the models to make money hosting them.
- 3 points
- This is and isn't true.
The room is the limiting factor in most speaker setups. The worse the room, the sooner you hit diminishing returns for upgrading any other part of the system.
In a fantastic room a $50 speaker will be nowhere near 95% of the performance of a mastering monitor, no matter how much EQ you put on it. In the average living room with less than ideal speaker and listening position placement there will still be a difference, but it will be much less apparent due to the limitations of the listening environment.
- Prior thread on the paper about this: https://www.hackerneue.com/item?id=44699452
- Can you share settings and/or a link so an exported SVG?
- DSQL only uses Postgres for the query processor layer, so it doesn't require a replication library within postgres itself. Definitely NOT from DSQL.
> We’re not using any of the storage or transaction processing parts of PostgreSQL, but are using the SQL engine, an adapted version of the planner and optimizer, and the client protocol implementation. [1]
Rather, DSQL seems to do its region replication using the distributed journal abstraction [2].
[1] https://brooker.co.za/blog/2024/12/04/inside-dsql.html [2] https://brooker.co.za/blog/2024/12/06/inside-dsql-cap.html
- This could easily have as much to do with support costs as anything with the technical side of the protocols.
A member of my family works in customer support for a company making devices using both zigbee and thread, and claims that support calls for debugging zigbee are often among the longest (and thus most expensive) calls they handle.
Unsure what IKEA's tech support looks like, but I assume that most issues not solved by support turn into returns, which are also bad for the bottom line.
That covers the input side of th equation. Thorium can help transform the outputs of our existing reactors into waste with orders of magnitude better in terms of dangerous lifespan