fabian2k

It's a different country and a different time, but when I studied (a natural science) there were dedicated courses at the start for refreshing high school math. Those were optional, and covered relatively simple topics.

There was also a real math lecture that went into topics above high school math, but also contained some repetition. All other courses mostly relied on what was contained there.

So I would fully agree, but I'd also be a bit surprised if you don't have any dedicated "math for scientists"-like courses to cover the stuff usually needed.

Why would that make you more conservative? Republicans don't have any answers to fix the US healthcare system. It would be far more plausible that someone that experienced the failure of the health care system would vote for a populist position here, and for healthcare the more convincing populist position is certainly the left one.

Modern medicine saves lives. Of course natural selection doesn't fully apply anymore in our society. But you're suggesting that letting children die from preventable diseases is a bad thing. It's not.

The media and the scientific community are not set up for the situation where cranks with absurdly unscientific views are at the top of the major scientific and health authorities. RFK Jr. still gets too much benefit of the doubt for his initiatives when it is obvious that he is opposed to science and has views about health that are just outright dangerous.

And we have the usual problem with this administration that there are so many different dangerous things happening that it's hard to concentrate efforts on fighting them. It got a bit quieter, probably due to some internal pushback, but RFK Jr. is still working on dismantling the US vaccination programs. And similar to the seed oil panic in the article, all the demonization of vaccines will result in a terrible price that some children will pay in the future.

Of course there's more than that. Predicting higher uncertainty than warranted would be a different failure in the model. But that didn't really happen in that election.

FiveThirtyEight gave Trump a 30% chance. Their reporting did make clear that with margin was within the range of a normal polling error. And sometimes you get more than a normal polling error.

It doesn't help that the US has a terrible election system that often leads to small margins in some states being decisive.

I think it's a good thing if the pricing gets more realistic. Both for the customers long-term and for the economy. To evaluate AI tools and how much benefit they provide you need to evaluate the costs as well. And right now nobody truly knows where the costs will end up. That's fine as long as the prices are stable, but they aren't.

In one example I know, a boring company that isn't a pure software company, the Github Copilot pricing change will make it around 15x as expensive as before. It's far from ideal when you cannot rely on pricing to stay somewhat stable.

Why assume it's rational? The Ukraine belonged to the USSR, Russia sees itself as the legitimate successor to the Soviet Union. So the Ukraine and the Baltic states belong to it, as far as Putin sees it.

The 70:30 prediction against Trump was far better than most. I did see models back then that considered the state polls mostly or entirely uncorrelated, and those produced obviously garbage with 90% or even 99% in favor of Clinton.

But in the end people pick on Nate because he really enjoys being an asshole on the internet. It's far more about when he acts as a pundit, not as an expert on statistics.

I switched to Linux again because on this PC Windows suddenly just doesn't run stable anymore. Even a complete reinstall didn't fix it, I assume it is some driver issue or something like that.

It took me a while to convince myself it wasn't a hardware defect. I had very frequent single tab crashes in any browser I used. And regular bluescreens, sometimes multiple a day. But it runs entirely stable on a parallel Ubuntu installation with the same hardware.

If you're unlucky, you can run into weird issues that are hard to impossible to fix as a regular user.

Once you run your app with the updated dependencies, that code is executed anyway. And root or non-root doesn't matter, the important stuff is available as the user running the application anyway.

At least it was only online for 1-2 hours at most, and it didn't affect react-query. But still a bunch of quite well-known packages.

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

The blogs post seems overly dramatic to me and vastly exaggerating the importance of that document. A bunch of doctors voiced their concern about the president, and that concern was added to the public record. That's it.

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.

I'd expect someone like AWS to just throttle machines before overloading their cooling. Because they probably can do that, while e.g. a data center that just rents the space can't really throttle their customers nicely.

I thought cooling was pretty much pre-planned in any data center, and you simply don't install more stuff than you can cool?

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?

It was obvious that Trump is unstable and has extreme and volatile views on foreign policy. So yes, I think it is entirely fair to blame anyone that voted for Trump in the last election.

And what did the attack accomplish? It did degrade the Iranian military somewhat. It killed the Iranian leadership, but odds are the replacements are simply even more radical and opposed to the US.

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 difference is particularly noticeable with multiple images sharing the same base layers. With legacy storage drivers, shared base layers were stored once locally, and reused images that depended on them. With containerd, each image stores its own compressed version of shared layers, even though the uncompressed layers are still de-duplicated through snapshotters.

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

My experience with docker-compose is a bit outdated, but my impression some years ago was that it was too sensitive and fragile. I encountered bugs or incompatibilities that broke the docker-compose setup often enough to be forced to pin the specific docker and docker-compose versions.

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.

I have a 200 EUR handgrinder and an Aeropress. That's about the limit for me, there isn't really anything else to improve there for filter coffee. There's probably a lot more ways to make different coffee, but not that much room for making the same coffee better. I also don't want to mess with the water, so that puts a ceiling on coffee quality anyway.

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.

That regression is maybe most useful as a reminder to people to configure huge pages for PostgreSQL. That's the one recommended basic performance tuning that is just annoying enough to set up that I suspect many people with smaller DBs will skip it.

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

There's certainly people that focus too much on minor details. And you really don't need to go into the 4-digit in spending to get very good coffee (especially if you don't want Espresso). But I was a bit surprised how much small details can matter in brewing coffee.

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.

The paper itself is a lot clearer about the purpose. The blog post reads very clickbaity and doesn't really explain the context well.

It does sound like a pretty terrible idea to try to count carbohydrates from an image. There just isn't enough information there to reliably do that. At best you could identify the object in the image and then show reference information on typical nutrition values. But if you need anything more accurate than that, you probably have to read the labels on the ingredients and calculate.

> But the U.S. has made it clear that it wants to concentrate on the Indo-Pacific and the threat posed by China's powerful military, rather than propping up Europe.

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

Are you using WAL archiving? As far as I understand, pgbackrest and Barman can also use direct streaming from the DB (same mechanism as replication), I didn't find any mention of this in the WAL-G documentation.

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 was about to set up Postgres backups with pgbackrest very soon. It looked like the most mature solution for my use case. What I was aiming for was continuous backups to an object storage provider, without a central DB server but the backup tool directly installed on the Postgres server.

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.

Especially in combination with not having scoped api keys at all, if I understand the article correctly. If I read it correctly, any key to the dev/staging environment can access their prod systems. That's just insane.

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.

This is about modern PCR, which is already optimized a lot compared to early PCR. And if you're in a "normal" lab, everything around the PCR, all the handling and preparation will be such a large chunk of time that improving the PCR time alone doesn't really matter that much.

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.

You don't need any encryption or signing for API keys. Using JWTs is probably more dangerous here, and more annoying for people using the API since you now have to handle refreshing tokens.

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.