Yeah that's called survivorship bias. The ones that make it to market can be wildly profitable to manufacture. Doing all the work to sift through what does and doesn't work to discover new vaccines wouldn't happen without public funding.
HN user
baronvonsp
AWS makes it annoying to be resilient as AZs aren't transparent to their users
What does transparent mean here? AWS is super clear what resources are zonal and provides tons of guidance around making things multi-AZ. AZ outages aren't exactly frequent but they're reasonably likely.
Being susceptible to AZ (or region) outages is very much an architectural decision. Or a bug that needs to be fixed (I'm sure Coinbase didn't YOLO single-AZ, they've undoubtedly learned about some edge case that needs to be fixed). Sure it may not be worth the cost/complexity for some systems but resiliency is like job one for anything in the cloud that costs money when it's down.
Ha. Different bug (sentient yogurt cultures) but sort of explored quite amusingly by Love, Death & Robots Season 1 - https://lovedeathrobots.fandom.com/wiki/When_the_Yogurt_Took...
Those sound to me like the very definition of optimizations that are not premature though. His goal was to teach foundational elements of running programs on computers. Loops and sorts are used all over the place and improvements scale with inputs. I see a pretty big difference between solving for a problem you don't yet understand (the way I've always mentally framed "premature optimization") and establishing reasons for implementing primitives in optimal ways.
They're distinct words that say exactly what they do. They're only hard to keep straight if you haven't taken a few minutes to understand the underlying concepts (and, in a field of complex and nuanced concepts, these are hardly the most difficult). Replacing widely-used terms with new not-quite-overlapping terms turns 2 things into 4 things and is not a solution to anything.
These are widely-used industry terms that have been used for decades. If that was a problem, surely we would have seen it by now?
Replacing terms - that have been around so long that many systems' behaviors map to them closely - with new terms that don't quite overlap seems wildly more likely to create ambiguity and confusion.
The exact analogy that came to mind for me.
Plus, relational databases don't just sit under a single application. There's usually multiple applications/services talking to them. Worse, humans connect to them an do all sorts of things they shouldn't do. That's the whole point of managing referential integrity in the DBMS, since you can only control "just write good code" across so many application domains.
Of course whether the performance tradeoff is worth it is a complicated decision for many of the reasons people have mentioned. But in 20 years of working with relational databases at big companies, I've seen few examples where the performance win exceeded the business risk.
While fewer workloads today are CPU-bound in general, these will probably be an especially big win for commercial software use cases in particular. Customers running workloads with processor-based licensing (think databases) now have more options for increasing available RAM without taking on more CPU licenses.
(disclosure, I work for AWS)
Totally agree. There's a lot wrong with them[1], but the audio is good enough and overall I find myself using them way more often than the EarPods so there's some proof in the pudding.
[1] - BT just isn't great tech and there's odd interference/cutout, often around cars; open-case-near-phone-for-battery-level is clunky and inefficient; double-tap to play/pause (voice control for audio control is just non-sensical to me) often doesn't work if it's been more than a few minutes, and seems to prefer opening the Apple Music app which I never use
Sure. Why would you want to?
A single radar return at just he right angle might make the soda can look huge. But with multiple sensors moving relative to the soda can and sampling at 10Hz, you end up able to form a "real" composite of the object