NohatCoder

The problem is that Unity has a lot of customers that make freemium/ad supported/low cost (mobile) games. $0.20 per install is absurd when most players are gone after less than an hour of playtime.

Of course if you sell games at $60 a piece it is not a whole lot, and the regular seat pricing of Unity is most likely a far greater expense.

A government would still have to make and use their own keys in a man-in-the-middle attack. The forged key means that if anyone bothers to check it will be detected, and there are also various ways that an application can lock the used key to make this impossible. Man-in-the-middle requires a lot of control over the infrastructure, for something that works reliably they would need to cooperate heavily with telcos, and spend a good deal of money.

To backpedal just a little, I take offence at the simple conclusion, that removing lines, signs and lights will make things better. If you read a bit closer most of the experiments are a bit more nuanced, for instance "a traffic circle, an extended cycle path, and a pedestrian area". It seems that in the famous experiment Monderman actually did add a fair amount of paint to the asphalt.

Also, bad paint is worse than no paint, in particular dividing the road into more lanes than there is room for.

So, if you make one special road intersection that breaks all the rules of how road intersections normally work people will slow down and pay extra attention. If you make a million of them people will get used to them and/or they will get tired of paying all that extra attention. The cost of going slower all the time will add up, so people will go back to going fast.

All of this means that an experiment of one intersection doesn't necessarily tell us anything useful about the results of a broader implementation.

The article even does mention places with less traffic regulation that serve as much better test beds, and then waves away the obvious conclusion.

The difference is that in the case where the condition is false and predicted false the jump variant will not delay if the value being moved into rax is delayed, the cmov variant will. Effectively that value becomes a false dependency.

As best I can tell this case is rare enough that one shouldn't generally be afraid of cmov, and probably compiler authors should consider using it more frequently.

What one shouldn't do is to load values, that are likely in memory or L3, unnecessarily in order to be able to use cmov. It is the case that runs the greatest risk of degrading performance, and it puts extra load on resources that are shared between cores.

AES has a key length and a round count. The speed of the cipher depend only on the round count. This suggestion takes a large key, but a moderate round count, making it only slightly slower than AES128-GCM.

That could work, but unless you can somehow deliver similar speeds with radio the network would bottleneck on the ground to satellite links.

It is pretty simple, you can't see through a cloud because the visible light gets scattered. This system works with 1550 nm light, which behaves pretty much the same in the context.

Normal ground to satellite communication use wavelengths of 7 mm and up, as those have reasonable cloud penetration.

An actual 50 Mbps link is perfectly good for most use cases, you can stream anything and it is not really a bottleneck in determining how quickly pages load. Large file transfers may still take appreciable time, but it is rarely a big issue.

An advertised "50 Mbps" mobile connection is dog food if you are used to 50 Mbps fiber. You are lucky if you get 20 Mbps through, though it can be much less. Worst part is all the packet loss that cause inconsistent latency and speed.

On top of this I really doubt the claim about working in bad weather. Some weather will work, sure, maybe at reduced speeds. But if there is a proper cloud in the way, the near-visible 1550 nm light will be scattered completely.

Fabian Giesen has a decent rant on AVX512. https://mastodon.gamedev.place/@rygorous/110572829749524388

Tldr it is not that it isn't useful, but the 512 bit part makes implementation prohibitively expensive.

Yup, it is perfectly possible that their divination AI has flagged and closed his account without any human intervention. Basically it is a lottery.

I see the chain of reasoning, but it also seems quite logical that quality answers written by real humans should be a pretty big competitive advantage. Throwing away your biggest sales point just because the competition has something new is a business suicide.

In total I think I have gotten more useful answers from closed posts than non-closed ones. Someone at SO have greatly underestimated the value of having a handful of almost identical questions each with their own answers.

If anything the network might have lost traffic because moderators have been too efficient in closing duplicate questions before they got useful answers.

That said, AI garbage posts do have to be fought with fire.

If the description is to be believed, then no, they don't do that.

Neat, but only really relevant for rolling updates. This feature is a one-shot installer.

Yes, that is what you should do. The problem is that they don't do that.

No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.

>> What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP.

No, the firmware copies a program from itself to Windows, that program then downloads and executes another program from the internet, without verifying it correctly.

Article says: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." So unless that is downright wrong the MitM path is wide open. There is a signature check built into Windows, but way too much stuff has been signed to make that a meaningful barrier.

Certificates do not have to expire. This is all firmware handling 101, you put a public key in the software update function, and the updater checks any alleged update against that key, no dates involved.

HTTP, and no check of the executable signature. I'd say the latter is the worse offence, but the two flaws really come together to provide an excellent MitM vector.

Depends on a lot of factors, but most databases have some overhead per call, especially if it happens over a network. If you can write some procedural code that runs on the database and eliminate calls and network traffic that may be a win. Then there is the SQL overhead of parsing and compiling queries, various forms of stored procedures can mitigate that by having a function that is compiled once, and then called with different input data.

How this all works varies a lot between databases, so what works in one may not be optimal in another.

The turning into a pile of rubble was gradual, there was something worth defending not that long ago. But mostly I suspect it is because they have to kill the Russians somewhere. If they have a strategic advantage defending the pile of rubble they will cause more damage to the invaders than they will take themselves. Who ultimately holds the rubble is less important than what the battle cost each side.

I think that splitting things can be a good idea once in a while. The important part is that you only make a new service because some job fits being its own service.

The microservice syndrome begin once you start splitting services simply because you arbitrarily declare them too large.

I think the main point here is that there is no limit to incompetence. And sure, having your own servers allow for some goofs that won't happen with cloud (the opposite is also true). But your org had the means to fix the issue, and they choose not to. That has fundamentally got nothing to do with technology choice.

A $5 instance gets you something like 1 core on a slightly dated CPU. Aka approximately as much processing power as a top of the line desktop processor 15 years ago. Aka enough processing power to fill a 25 Gb/s port with TLS data (not that you have the port to go with that).

A few requests per millisecond should be well within the capabilities of this instance, depending on the complexity of each request of course.

They kind of need to be there anyway, physically maintaining servers turns out to be a miniscule part of the whole maintenance. If you really care about uptime you still need people on-call who can intervene as necessary.

This. And I think people tend not to understand how little actual hardware they are paying for when using AWS et al.

A really cheap server leasing deal will cost you yearly about as much as the purchase price of the server. With opaque AWS services it is probably more like a month of subscription to pay for the hardware that you are indirectly using.

It is funny, the article claims to test the 64 bit code on "Dual-core Intel Xeon 2.6 GHz 64-bit processor with 4096KB cache". That is a really poor description, as it does not tell us what architecture the processor is. But one can go through a list of all Intel Xeon processors to find the ones that match the description. Turns out that there are none.

If we broaden the search to 2.66 GHz processors there are 4: 5030, 5150, 3070 and 3075. All released in 2006 and 2007. This means it is either one of the last "NetBurst" CPUs or one of the first "Core" CPUs. Assuming "Core" the relevant operation has a 5 clock latency, as best I can tell. This is down to 3 clocks on pretty much all modern X86 CPUs. Modern CPUs also get an extra load port, so I doubt the relative difference is much different on modern CPUs.

Overall it looks like a pretty bad benchmark, thrown into a paper on collision likelihood, which itself looks like an academic exercise with no relevance for the real world.

Others have hinted at this, but to be clear: This algorithm is slow, even in the optimal case where the tables are in cache. On new X86 CPUs it is theoretically limited to less than 2 bytes per cycle. Probably somewhere around 1.5 for an implementation that loads 8 bytes of input at once and shift though them in order to limit load on the load slots.

Even without getting into SIMD algorithms you could load 8 bytes at a time and pretty easily go faster than that, possibly while using the multiplication instruction for mixing.

This of course ignores that we are not looking up values from a hash table in a vacuum. Other code will also be competing for the cache, and that generally means that everything runs slower because of more cache misses.

So they installed a comically inefficient CO₂ scrubber in order to generate this headline. In order for CO₂ scrubbing to have even a chance of making sense we need big efficient dedicated plants. There is absolutely no synergy in installing the scrubber on an EV, and handling the measly amount it produces is logistically inefficient.