andrewia

I don't think so; speculative execution is the cornerstone of modern CPU performance. Even 15-year-old 32-bit ARM CPUs do it. The only phone/PC-grade processors without it are the first generation of Intel Atom, and I recall that early Atom processors sacrificed a ton of performance to keep power consumption low. I doubt this will change since mitigations are "good enough" to patch over major issues.

FYI, the whitelist is enforced differently with MVNOs. I was able to prove a UK Xperia 5m2 was compatible and get it allowed on a prepaid MVNO.

The exchange could be limited to only existing, paid plans. New plans would require a device compatible with the new specification. I don't think it's too hard since American phone carriers were able to offer free LTE devices to users with activated 3g devices.

I think that's a very naïve way of looking at game development. There are many reasons why games are exploitable besides lack of reasonable dev effort.

- Almost all games are going to use a licensed or shared game engine. That means the softwsre architecture is already known to skilled cheat developers with reverse engineering skills.

- Obfuscating the game will only go so far, as demonstrated by the mixed success of Denuvo DRM.

- The game will not be the most privileged process on the machine, while cheaters are glad to allow root/kernel access to cheats. More advanced cheaters can use PCIe devices to read game memory, defeating that mitigation.

- TPMs cannot be trusted to secure games, as they are exploitable.

- Implementing any of these mitigations will break the game on certain devices, leading to user frustration, reputation damage, and lost revenue base.

- And most damning, AI enabled cheats no longer need any internal access at all. They can simply monitor display output and automate user input to automate certain actions like perfect aim and perfect movement.

Yes, but we don't know when the next technology shift will happen. Amazon might be able to abuse their position for decades if a disruption doesn't come.

Aa for E-commerce, it can have a larger inventory than physical retail. You're not going to find many solar charge controllers or mechanical keyboard parts at Walmart, but Amazon will have tons of options deliverable within 48 hours. Few sites can have comparable shipping cost/speed and you have to research each one, whereas Amazon enjoys the position of being the default.

A decade ago, I helped a small Amazon seller with his inventory, and it was eye opening to see all the fees and risks compared to eBay. But he couldn't sell on eBay without losing a massive portion of his customer base, despite their better shopping/buying UX in my experience.

Isn't that basically the point of WinRT and Windows 10 S Mode? The problem is getting developers to adopt the new more secure APIs.

I understand that you can't convince developers to rewrite/recompile their applications for a processor that breaks compatibility. I'm wondering how many existing applications would be negatively impacted by cutting down vector throughput. With some searching, I see that some applications make mild use of it like Firefox. However there are applications that would negatively affected, such as noise suppression in Microsoft Teams, and crypto acceleration in libssl and the Linux kernel. Acceleration of crypto functions seems essential enough to warrant not touching vector throughput, so it seems vector operations are here to stay in CPUs.

I don't think hyperthreading was the bulk of the attack surface. It definitely presented opportunities for processes to get out of bounds, but I think preemptive scheduling is the bulk of the issue. That genie not going back in the bottle another way to significantly improve processor performance for the same amount of instructions.

It's interesting to see that modern processor optimization still revolves around balancing hardware for specific tasks. In this case, the vector scheduler has been separated from the integer scheduler, and the integer pipeline has been made much wider. I'm sure it made sense for this revision, but I wonder if things will change in a few generations in the pendulum will swing back to simplifying and integrating more parts of the arithmrtic scheduler(s) and ALUs.

It's also interesting to see that FPGA integration hasn't gone far, and good vector performance is still important (if less important than integer). I wonder what percentage of consumer and professional workloads make significant use of vector operations, and how much GPU and FPGA offload would alleviate the need for good vector performance. I only know of vector operations in the context of multimedia processing, which is also suited for GPU acceleration.

I'm very interested to see independent testing of cores without SMT/hyperthreading. Of course it's one less function for the hardware and thread scheduler to worry about. But hyperthreading was a useful way to share resources between multiple threads that had light-to-intermediate workloads. Synthetic benchmarks might show an improvement but I'm interested to see what everyday workloads, like web browsing while streaming a video, will react.

I know somebody on the project. The cancellation makes sense, they were years from release and every new VP pivoted the project and lost progress. If they had committed to their original project (a bus) or the first revision (a very high-end car) they could have released on a timely schedule. But they're far too late to the game.

You can reduce render resolution easily, it's available as the unrooted ABD command `adb shell wm size 1080x1920`. You don't need a computer for it either, you can use an app like Bugjaeger to create a loopback connection on most Wi-Fi networks.

I haven't had any issues with a Samsung S7, Samsung S9 (although I broke HDMI output), and Sony Xperia 5 Mark II (very pleasant to repair). iPhones have been much more troublesome for me, as I have destroyed three during repair attempts. All the issues were from damage to ribbon cables, as they are fragile and easily damaged from being bent. So I'd advise avoiding devices with tight tolerances like iPhones, and minimizing interaction with ribbon cables.

I usually use Chinese knockoffs. Brands like Cameron Sino and Nohon are growing brands who accurately state capacity, make good batteries, and don't pretend to be OEMs.

As for official batteries, California's Right to Repair law compels manufacturers to sell parts like batteries for as long as they sell battery replacement services, up to 7 years. Apple still replaces batteries for the iPhone 5S, a 10-year-old phone, so they 2022+ phones should have official batteries available for a long while (and the prices seem quite fair). Google also sells genuine batteries for the Pixel 2, a 6-year-old phone, through iFixit. Samsung only offers batteries attached to a midframe and display assembly, for the S20 and newer, through iFixit for $200+. So the former 2 brands seem like good options.

That's an inherent limitation of modern lithium batteries with a smartphone's constraints of density, size, packaging, charge current, and a bunch of other requirements. Replacing a battery every 18-24 months costs ~$75 (or 1 hour and $35 if you're comfortable with DIY), which is a reasonable maintenance cost considering smartphones cost $300-$1300. Many car owners don't sell/scrap their car until repairs exceed the value of the car, we should apply the same philosophy to smartphones.