flaminHotSpeedo

It's interesting to me that all the screenshots besides the HN one appear to be from mobile devices?

It's pretty disappointing that this video alludes to, but does not cover performance curves for condensing dehumidifiers.

Even when they don't freeze over, condensing dehumidifiers rapidly lose efficiency at lower temperature and/or relative humidity.

I didn't test as comprehensively but from my observations based on the effect on relative humidity, I found dessicant dehumidifiers to be more effective when RH was ~60% and temperature was ~50-60 degrees.

And in my case I wasn't double dipping by increasing ambient temperature, I was using a dehumidifier which vents the moist air out without condensing it because I needed something that would work below freezing

"cook longer" at the same temperature is my original example (though admittedly I was thinking that cook temp would be another variable, but I didn't write that):

> now we know that I could simply keep cooking the meat for longer

Cooking longer at the same temperature is also pretty much exactly what the experiment in the article was, which found no statistically significant correlation between testing and juiciness.

The experimental group pork chops took less time from when they were put on the skillet to when they were cut (and when they would have been consumed if they were cooked by someone making a meal for themselves).

You're welcome to disagree, but the facts disagree with your stance.

Yes, my example is unrealistic when you apply your own unrealistic constraints on top of it.

But when you remove your unrealistic constraints, it is absolutely realistic. There is a wide temperature band where a cut of meat will reach a given center temp faster than carryover cooking with a difference to edge temperature that is trivial enough that someone is unlikely to notice.

That depends on the heat applied. Which brings up another good counterexample: knowing this, someone could cook longer at a lower temp to get a juicer edge for the same juiciness center.

The article categorically refutes the idea that resting is important for juiciness but that's not the same as saying resting will not improve juice retention. Proof that a relationship once though to be causal is not is a pretty big deal, and the conventional wisdom is wrong.

As a counterexample: let's say the only things I care about are juiciness of the center of the cut of meat and the time it takes me to make it. By the conventional wisdom I'd have to rest the meat, adding time, but now we know that I could simply keep cooking the meat for longer, since that will raise the center temp faster, and then cut it immediately after cooking.

Or another scenario: if I know the precise internal temperature for my preferred level of juiciness, I know exactly what temperature to set a sous vide to.

Quote:

   Today, though, Ars testing on the Lenovo Legion Go S finds recent games generally run at higher frame rates on SteamOS 3.7 than on Windows 11

That's not just a buried lede, this title is straight up wrong (or at least, not backed up by data)

With SteamOS coming to arbitrary hardware, that is a very bold claim to make. And not one that ars has data to back up, apparently.

It's also an embarrassment of an article because they were gifted the steam version of the handheld, then compared that performance against them installing windows... on the steam version of the handheld. Why not buy the version with Windows by default?

Personally I'm nearly certain that SteamOS would give better apples to apples performance than windows, but we shouldn't give an article that shits on both the scientific method and journalistic integrity the light of day

One of the core pieces of static stability (at least in one definition, it's an overloaded term) is being able to handle failure scenarios from a steady state.

The classic example is overprovisioning so that you can handle the extra zonal load in the event of a zonal outage without needing to scale up.

AWS regions are fundamentally different from GCP regions. GCP marketing tries really hard to make it seem otherwise, or that GCP has all the advantages of AWS regions plus the advantages of their approach, which means heavily on "effectively global" services. There are tradeoffs, for example multi region in GCP is often trivial and GCP can enforce fairness across regions, but that comes at the cost of availability. Which would be fine - GCP SLA's reflect the fact that they rarely consider regions to be a reliable fault containers, but GCP marketing, IMO, creates a dangerous situation by pretending to be something they aren't.

Even in the mini incident report they were going through extreme linguistic gymnastics trying to claim they are regional. Describing the service that caused the outage, which is responsible for global quota enforcement and is configured using a data store that replicates data globally in near real time, with apparently no option to delay replication, they said:

   Service Control is a regional service that has a regional datastore that it reads quota and policy information from. This datastore metadata gets replicated almost instantly globally to manage quota policies for Google Cloud and our customers.

Not only would AWS call this a global service, the whole concept of global quotas would not fly at AWS.

I think the most damning thing here is the "what's our approach moving forward" section:

Every single bullet point there is basic stuff you expect a cloud provider to do correctly damn near every time. If you're not paying GCP for that expertise, or if that expertise is built on layers of cruft where that expertise was not applied... what are you paying them for?

To some extent, yes, strong leadership can squash engineering culture.

But if engineers never push back, how is leadership supposed to know they're asking for dangerous things? For most engineers, that means explaining risks and/or engaging more senior engineer. For L8 and up, it is absolutely their job to say no to leadership.

And that's all ignoring things that should have been done here which wouldn't affect the timeline. Leadership doesn't care what order you deploy things in.

You can't pin this entirely on leadership, allowing global blast radius deployments without an extreme level of scrutiny is a failure of engineering culture.

At the very least the global policy should have been deployed prior to the regional service control deployments.

This is really only a problem on GCP, who treats regions far differently from other providers.

From a resilience perspective, it's best to treat GCP as a single region with a bunch of zones.

> Sometimes you need to flip a switch

If anyone needs to flip a global switch, and can't convince their leadership to allocate the resources to do it safely, engineering culture is dead, at least locally to that system.

But I'm not convinced lack of headcount was the problem here, the incident report makes it sound like there's an established pattern for feature flagging even for global changes like this.

Putting aside the fact that this team seems unperturbed by global deployments and all the other scary things, high impact changes should use every mechanism available to shrink fault containers. It would be inexcusable to roll this change out without tha feature flag mechanism if this were a regional roll out.

Skipping the feature flag when this is global is simply incomprehensible. It goes beyond headcount, it should never have been considered in the first place.

I think the only interesting & substantive piece of info here is that AWS will sometimes waive DTO fees. (For once I'm actually thankful for GDPR!)

Their claimed savings are suspect, borderline clickbait, and even if they are correct the preconditions to realize those savings don't apply to the vast majority of other companies.

They already had datacenters and claim that there will be no increased opex for things like power, network (which must be substantial if they pay 1.5MM for 18PB) and employees, only needed a trivial amount of space they already had, and sounds like they're sacrificing redundancy too.

> At which point they'll make sure their branch is only useful on their server

Can you think of any examples where they've done that? They certainly could, but I can't think of any times they have actually rug-pulled like that, and the motive to do so seems tenuous too. In order for Amazon to do something like this they would need established market dominance, as well as a belief that some new player will hurt their market share enough to justify alienating the FOSS community.

Unmanaged VM's created directly by customers still aren't relevant to this discussion. The whole point here is that everyone else uses some form of hardware assisted isolation between tenants, even in managed services that vend containers or other higher order compute primitives (i.e. Lambda, Cloud Functions, and hosted notebooks/shells).

Between first and second hand experience I can confidently say that, at a bare minimum, the majority of managed services at AWS, GCP, and even OCI use VM's to isolate tenant workloads. Not sure about OCI, but at least in GCP and AWS, security teams that review your service will assume that customers will break out of containers no matter how the container capabilities/permissions/configs are locked down.

How Azure isolates VM's is completely unrelated, because containers are not VM's. And if you meant to assert that Azure uses hardware assisted isolation between tenants in general, that was not the case for azurescape [1] or chaosDB [2].

[1] https://unit42.paloaltonetworks.com/azure-container-instance...

[2] https://www.wiz.io/blog/chaosdb-explained-azures-cosmos-db-v...

> This is what the entire public cloud is built on.

Well... The entire public cloud except Azure. They've been caught multiple times for vulnerabilities stemming from the lack of hardware backed isolation between tenants.

I think the more interesting part here (besides the fact that AWS SLA's sneakily screw you over and make it hard to guarantee static stability) is the remediation aspect.

This is a consistent letdown across most AWS products; they build the undifferentiated 90% of a thing, but some PM refuses to admit their product isn't complete, so instead of having optional features flags or cdk samples or something to help with that last 10%, they bury it deep in the docs and try not to draw attention to it. Then when you open a support case they tell you to pound sand, or maybe suggest rearchitecting to avoid their foot-gun they didn't tell you about.

Do you listen for volume degradation EventBridge notifications? I'm curious if or how often AWS flags these failed volumes for you

Occasionally it can be hard to wrestle with but my go-to is PlantUML, which has a simple syntax and for better or for worse doesn't support many formatting options, so I can't get distracted tweaking the specifics of the layout

Fine, I guess I'll just go take my IE7 impressions elsewhere!

Oh my bad, I misread the comment tree and thought this comment was a response to the grandparent.

"give us access to foreign users' data" referred to what the UK is asking for, I thought the post i was replying to was equating the UK's request to the US'

Edit: I misread the comment tree, I thought this comment was equating the TikTok situation to the UK's request.

I agree that the TikTok demands are pretty similar, though I might quibble over whether they're literally the same, since arrangements like that are the status quo in China but not in the US

Original comment below:

How is "remove foreign control of data on our nation's users" remotely the same as "give us access to foreign users' data"?

They're not even figuratively the same, despite you literally misusing that word

Ugh it sucks to be reminded of all that bullshit. Though it's good not to forget.

But I think the earlier comment may have been referring to the restrictions in the US relative to other countries. Most other countries were much more severe for their lockdowns

This coming from the same people who shut OPM employees out of an HR database, citing (legitimate) security and oversight concerns, because they had broad un-auditable access.

How can this department turn around and do this and still maintain they're doing the right thing? By their own admission they know this a bad idea

I don't understand - what could they possibly expel you for?

I'm curious to see how 3rd parties with SteamOS handhelds behave.

Both in the context of the handhelds themselves (do they meet the steam deck's high bar for reliability and longevity) as well as how the companies handle things like open source contributions or vetting games.

It takes more than just the OS to replicate the steam deck's success (even though SteamOS itself is very well executed)

More likely Tencent will own the land and physical infrastructure but it will still be Akamai software operated by Akamai employees.