fabian2k

It's more of a problem with triggers. But in the end you're switching languages at that point, and devs that have no problem reading your backend language will not necessarily be good at reading stored procedures. Of course depends on how complex you make them.

And of course devs read the content of functions they call. Unless it's a well written library used by many different people, odds are the function isn't documented well enough and has quirks that force you to understand in more detail how it works. This is not external library code, it's still part of your application.

You do not need stored procedures or functions to prevent SQL injection. Any Postgres client library from the last decade or two supports parametrized queries, and that's enough. Odds are, most people will use an ORM anyway, which also avoids SQL injection.

In most situations I'd try to avoid using stored procedures. Unless you're all in on them, the effect will be that it hides some logic from the developers since it is not in the main part of the codebase.

The first thing a malicious AI worm would probably do is compromise enough developer machines and other servers to commandeer all the AI hardware it needs. So I think a purely digital AI attack would not need this.

Now, once the AI can carry all the compute it might need, I'd really worry when it doesn't only carry compute but also more explosive ordinance.

They're the first, I strongly doubt they'll be the last to adjust prices that much. The big cloud providers might have enough margins to eat the cost increases, especially since bare VMs are only a small part of their offer. But I don't see how the smaller, more VM-focused providers will be able to absorb the high hardware prices.

How many liters per 100 km does a typical US car consume?

I don't know enough about this specific party, but a quick look at the Wikipedia page about them shows this quote, which to me does seem to suggest that the label is defensible:

In a podcast segment about immigration and deportations Allard stated his opinion and said that "They will also be forced to leave, even if they are born in Sweden, because they have no natural connection to Sweden. They are not Swedish."

https://en.wikipedia.org/wiki/%C3%96rebro_Party

There's a huge difference between enforcing reasonable immigration laws and what some right-wing parties are proposing. I don't know enough about this specific party, but you'll find similar ones in other countries. And remigration is in the end about deporting even legal and well integrated immigrants.

The vast majority of duplicate closures use already answered questions as duplicates. So ideally that question should have answers that apply to the new question as well. In my observation this is usually the case, though the answer might be more generic.

I have also seen bad duplicate closures that weren't actually exact duplicates. But people talk like this is the only kind of duplicate closure that actually happens. I've no idea if the rate of bad duplicates is so much higher than I observed, or if people are missing that their question is actually answered in the duplicate.

Yes, you can. I am using that in production right now. An ASP.NET Core application as a self-contained single-file binary, without AOT.

.NET AOT right now is a very specialized solution that isn't widely applicable. Self-contained and single-file binaries do work pretty much out of the box already.

See the documention here for the PublishSingleFile and SelfContained options:

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

You don't need AOT for a single self-contained binary. This already works with C#, but it's still JIT-based.

AOT is entirely independent of single file binaries. And self-contained binaries that run without the framework installed are again a separate concept. There are some dependencies between these, but they are not the same thing.

AOT is not all that useful yet for many applications as important libraries still don't support it. So more something for things like CLI tools with a small scope.

It's not quite the same as with Go, the binaries get large if you can't trim them. But creating single-file self-contained executables is very much usable and works well otherwise.

Journalism is allowed to have an opinion, that doesn't make it propaganda.

Assume you fetch a single customer entity with their 100 order entities as includes. With single query this will join both tables and produce 100 rows that contain the order data but also each one contains the customer data redundantly. Now Imagine you had two includes there, that will multiply the number of rows again.

AsSingleQuery is as dangerous as this makes it sound. This works surprisingly well if you know that the number of included entities is low, but only then.

You can get much better queries here if you write a Select() and let EF Core translate that into SQL. That will probably do roughly want you are imagining here, usually with subqueries fetching the data from related entities.

I'd consider keeping the other personal data to be still easily justifiable, as you might want to support various account recovery options. And the odds that a user forgot their password only increases for old accounts.

Those articles don't require deletion in this case, in my non-lawyer opinion. There is still a purpose to keeping the user's personal information here. Sony needs that information to be able to grant the user access to the content they bought.

There's a difference here between an account that hasn't been used and doesn't hold anything of value and an account like this that holds items that were bought.

Scientists tend to understand that part, that's more of a political/cultural thing (I'm ignoring the language part here entirely about which terms to use for which concepts here).

There's the X and Y chromosomes, those produce a binary result (unless you have a genetic anomaly). And after that comes the messy and fuzzy parts I mentioned, where those genes trigger changes in hormone levels and development. And those parts are analog, very complex and contain a lot of different parts. So the outcome is not binary anymore.

One part that people from the software side tend to underestimate is how fuzzy and analog everything in biology is. Genomics look more predictable and organized at first, but even these parts are quite fuzzy and subject to all kinds of physical effects.

I'd strongly recommend in reading up on the parts of cell biology that come after this. Otherwise you'll get the wrong impression of how messy biology actually is.

These rules are all stuff that you probably should think about at some time. But they're often taught as strict rules, which I don't think is a good idea.

In the end many of them are still quite subjective. It is useful to try to avoid mixing unrelated stuff into the same class. But trying to religiously find the boundary to what a single responsibility means in each specific case is a waste of time.

I had the same experience with the platforms when I first played Space Age. But this depends entirely on how you scale your Nauvis factory before you start launching rockets. You don't want to start too small, if you rush to rockets too quickly the beginning of your space exploration will be tedious.

You never want to burn fruit itself since that wastes the seeds. So you always want to process fruit the first step.

I limit fruit production based on the number of fruit on the belt, to avoid creating a huge buffer. But after that the factory just runs continuously at the same speed. And if I have too much of a final product, it gets destroyed or burned for heat and electricity.

One benefit, especially in the beginning, is that by processing more fruit you get more seeds. And you need the seeds to expand your fruit production later.

The enemies are probably one of the not ideally designed parts of Gleba. It's trivial to handle them if you know how, and can be very frustrating if you try to approach it the "wrong" way. If you have been to Vulcanus and Fulgora you can trivialize their threat.

Limiting production is probably the most difficult way to play Gleba. The easier way is to minimize buffers and have a path to extract spoilage at every position where it could accumulate. And to never, ever have the factory stop at any point in time.

The big changes are presented in the Factorio blog, read FFF #421 to #423 here to get an overview:

https://factorio.com/blog/

https://factorio.com/blog/post/fff-441

https://factorio.com/blog/post/fff-442

https://factorio.com/blog/post/fff-443

It's already faster even without that because it now uses mixed content rockets to build ships and platforms. But space-to-space logistics do mean that you can make rocket launches less bursty and continually ship stuff into space to then use it.

I don't think the developers promised more here, but the community might have overhyped itself as it is common. It's still a very solid .1 release, the improvements to space logistics and platform building are very nice. There's also a whole bunch of really nice circuit additions.

Gleba is different, but I think that is good in a game that is as long as Factorio. There's a bit of a bumpy difficulty curve here if you approach Gleba in certain ways. But it is very different mechanically than the base game or the other planets in a way that is interesting, at least to me.

It took me two or three iterations when I first landed on Gleba. But afterwards my factories there were more robust than on the other planets and almost never stalled or broke down. And solving that was quite satisfying.

it's really a bit of a different concept in scientific publishing, not actually plagiarism. The problematic part is publishing the same results twice, because it increases the burden on reviewers and inflates your publication count. It's also just messier if the results are in multiple places since it makes it harder to follow where those results were used and cited.

The COVID19 vaccines were the most-discussed vaccines ever. And there was an enormous amount of coverage for the potential side effects. Recommendations were adjusted based on new data.

There was also bad communication on the topic, often when politicians got involved or due to outdated information continued to be repeated. But there certainly was a lot of public discussion about the risks of the vaccines, they were simply vastly outnumbered by the benefits of the vaccines.

What happens right now is vastly different than before. Of course there are different priorities in funding for each administration, but those are usually more gradual shifts and especially don't cancel running grants arbitrarily.

And if you think this administration is prioritizing science with actual applications, I have a bridge to sell to you. The cuts they made are not sensible policy, they are inherently destructive and wasteful. They aborted studies that were still running, so a lot of money was spent and we'll never get any results from that because they were not finished.

This administration is both fundamentally anti-science and wants to enforce political control over all government institutions. Science was never a particularly stable work environment, but the sheer insanity you have now makes it a deeply unattractive place. You have no idea if your grant might be denied, or even canceled at any point later by some political commissar that doesn't understand science.

And it's not just particular topics they hate, they hate the entire system and institutions. And they try to either break them and force them to adopt their political views, or they attack their funding or use any other powers to dismantle them.

30-50% of engineers on core teams have been forcefully reassigned to data labeling and RLHF, upsetting folks even more.

This really doesn't sound believable to me, but who knows with all the craziness going on. Software developers in the US are seriously expensive, using them for data labeling would be a waste of resources. And the percentage sounds very high, unless "core teams" is only a small subset of the total developer count.

If I read it correctly, they did espresso and filter taste tests at room temperature (thought they don't state the exact temperature, and how they managed to brew filter coffee with the described setup). Overall the press release is somewhat misleading in what the goal is until the part you mention. If the focus is industrial production of cold, mixed coffee drinks I'd have expected more quantitative measurements instead of taste tests. Testing how well your coffee is extracted is pretty trivial with the right equipment.