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.

One of my relatives is a high level Barefoot employee who was integrated into Intel leadership after the acquisition. I was told that it was killed because of worries about internal competition with Intel IPUs. It still seems like a ridiculously foolish idea, considering how much money Intel spent acquiring Barefoot. Not that the founders and CEO care, they got their money!

The whole thing definitely seems symptomatic of Intel's extreme caution. I wonder why they didn't apply the same caution when buying Barefoot. Intel obviously didn't have a great idea on how to leverage them.

This is all in stark contrast to AMD buying Pensando, a company that my SO works for. It makes sense for AMD to acquire Pensando to expand their data center offerings and compete directly with Intel. I think AMD made a smart buy.

Yes, but the vast majority of human drivers will stop when they hit somebody, and when there's screaming under their car.

SF politics are notoriously slow about a lot of things. There are actually new, significant lobbying efforts to tackle some issues: https://www.cbsnews.com/sanfrancisco/news/tech-rooted-groups...

Citation needed. When googling for traffic signal information, all I found was discussions about expanding right-on-red bans to more intersections, and traffic lights with LIDAR. https://www.sfmta.com/blog/smarter-traffic-signals-prioritiz...

Don't forget PTM thermal pads! They have a respectable 8 W/m•K conductivity and don't pump themselves out or dry out like thermal paste. They've become popular with gaming laptop companies and users.

Windows is common from what I've seen. When I did a brief interview with Abbott Medical Devices in the 2010s, Windows experience was mentioned.

Yep, high-resolution recording while charging, streaming music, and displaying a map will quickly exceed the thermal constraints of any phone. I guess a MagSafe holder with mini sunshade and active cooling fan could help?

I found the primary maintainer from the Github org. Their bio has a link to support them. https://github.com/pukkandan which links to https://ko-fi.com/pukkandan

It looks like the IRS is moving to test their own preparing/filing software for the 2023 tax year. Hopefully in 4-5 years, TurboTax and HR Block will only be needed for people with complicated tax situations, while the remaining 90% of the population can use the IRS's application. https://www.pbs.org/newshour/politics/irs-moves-forward-with...

The issue is that NSO makes spyware available to far more countries by lowering the barrier to entry. Looking at their sales history, they have little criteria for sales besides following the preferences of the Israeli government. They sometimes sell to nations that generally promote human rights, and other times sell to nations that are very repressive yet important allies to Israel.

It does make iOS slightly more inconvenient, such as when adding each other on iMessage. And it severely reduces JavaScript performance in Safari. I think Apple wants to avoid making iOS feel slower or clunkier than Android. And zero-day spyware is usually targeted towards important individuals, not used for mass surveillance, so it indeed is a smaller risk to individual people.

I'd prefer a third mode that compromises between the two, perhaps letting you lower your security for a few minutes when you need the extra functionality. For example, Safari could detect when JavaScript is being slow and pop up an offer to re-enable JIT.

Some stuff, like electronics, can be petty decent from unbranded sellers. And some people are broke and need the cheapest clothes money can buy, regardless of the quality.

It depends on the TV manufacturer, since Roku is just a software layer. My TCL P607 has no such LED.

Did you actually read the article? They said their first two picks will boot to the most recent input without any UI to step through, which they consider acceptable. Combined with CEC input switching, I agree that the UI shouldn't be much of a concern. I use a TCL P607 disconnected from the internet, and the UI is not a concern because of CEC switching.

Thinking in terms of the average consumer, I think cybersecurity isn't a major concern, but the hassle of setup is. Most people expect an appliance to do its job with minimal fuss. (This can lead to problems, like how car owners can ignore oil change reminders and disable lane keep assist.) But in general simplicity is a good thing - it reduces the mental overhead needed for home life.

For appliance makers, they need to have a better selling point for connectivity. Only a few appliances benefit from automation and remote commands (like thermostats and some light fixtures). Other appliances, like ovens and clothes washers, require physical presence at the start of the cycle, have a predictable runtime, have simple interfaces, and can't predict failures (due to a lack of sensors and cost of further firmware development). So connectivity isn't beneficial.