This doesn't really feel sustainable, you're rolling the dice every time the dependencies are updated.

We don't know if anyone will actually stop it if Trump ever gives a catastrophic military order. Odds are against it, since none of the illegal orders so far have been resisted effectively.

So did some cooling equipment fail here or was there an external reason for the overheating? Or does Amazon overbook the cooling in their data centers?

The nuclear material is probably still buried in the facilities attacked in the earlier strikes (not the war this year). That is a delay on any potential nuclear weapons development, but not more than that.

It showed Iran and the world just how much damage they can cause with their control over the strait. And it removed any factor that previously led Iran towards not blocking the strait even when attacked. In the end the odds are that this whole mess will cause death and suffering, damage the world economy and we'll likely end up with an even more dangerous Iran in the future.

This seems like a really weird decision. If base images are duplicated for every image you have, that will add up quickly.

And the error handling was terrible. Most of these problems resulted in a Python stack trace in some docker-compose internals instead of a readable error message. Googling the stack trace usually lead to a description of the actual problem, but that's really not something that inspires confidence.

There's some legitimate room to spend much more money when making Espresso. But a lot of the more expensive options would be more about the workflow than quality. If you need to make many Espressos in quick succession you'll hit the limits of cheaper equipment.

Though I actually don't know how large shared buffers has to be for huge pages to make a noticeable difference.

I'm using an Aeropress and an 1ZPresso handgrinder. I found that it helped a lot to do things exactly the same way each time. It reduced variability and made it easier to adjust a parameter like grind size. In particular I found stirring to be a really finicky parameter with a potentially large effect. If I stirred vigorously without changing anything else, the coffee got noticeably bitter. I switched to not stirring at all, it's mixed plenty just by pouring the water. Makes the workflow easier and reduces variability.

So while I think there's plenty of ritual around coffee that has no real effect, I suspect the value lies in keeping to exactly the same method and performing all steps the same way each time.

If that were true they wouldn't have wasted enormous amounts of expensive ammunition in Iran.

With WAL archiving you need to wait for a WAL segment to finish before it's backed up. With streaming backups the deadtime is minimized. At least that's as far as I understand this, I didn't get to try this out in practice yet.

I'll have to look at the alternatives again, I think that was mostly WAL-G and Barman. It looks like Barman doesn't support direct backup to object storage, unfortunately. And I find the WAL-G documentation very confusing. What I'm looking for is WAL streaming and object storage support, to minimize the amount of data that can be lost and so I don't have to run my own backup server.

I'd never feel comfortable without a second backup at a different provider anyway. A backup that isn't deleteable with any role/key that is actually used on any server or in automation anywhere.

In a very automated, high-throughput setting I'd imagine that parallelizing the PCR would be the best way to increase throughput. There probably isn't that much potential in speeding up the time compared to just multiplying the number of reactions. Which is part of the point of the article.

Regarding the cheaper lab instruments, I'm not quite convinced by these ultra cheap examples. Many lab instruments need quite a bit of precision and reliability, and I would be suspicious that the cheap examples here could compete in that regard. Even PCR needs pretty exact temperature control across many individual reaction vessels. Of course the margins on lab instruments are likely enormous, and there should be plenty of potential for cheaper ones. But I don't think the ultra-cheap DIY stuff will convince people, and it'll likely also fail at the purchasing process anyway for larger institutions.

Plain old API keys are straightforward to implement. Create a long random string and save it in the DB. When someone connects to the API, check if the API key is in your DB and use that to authenticate them. That's it.