To be fair Apple of all companies have the best shot at pulling it off. They've been perfecting their hardware security for years for other reasons and this is just another way to take advantage of that work. But yes, if someone breaks it then the trust is gone and it casts doubt on all of the photos that were ever captured using the broken system.
I replaced my old Forester with the new Trailseeker. Stsrting price (and interest rate) is much better than the R2.
I can slide in an 8’ board no problem when I’m too lazy to use the roof rack.
I haven’t upgraded the wheels or tires yet but the stock ones have had no problem going up and down the old logging and forest service roads of NW Oregon and SW Washington.
If the Toyota sienna had a plugin ev option that would be really compelling for me. The electric van market is surprisingly sad. I currently only boogie board because it fits in my car.
I’m really tempted by current sienna hybrids, my current gas one gets 20mpg on a good day. Plug-in for the daily school commutes and after school activities would be great
But as gp correctly points out, with ARM there tend to be additional technical challenges for that compared to your normal PC even if Valve does nothing to intentionally lock it down.
It'll be highly dependent on the game. Unlike foveated streaming the implementation of foveated rendering could mean many things. Actually rendering at a lower resolution in areas you aren't actively looking is probably the most complicated approach because it seems like you'd have to render two times (low res + high res) to get the desired effect.
> Actually rendering at a lower resolution in areas you aren't actively looking is probably the most complicated approach because it seems like you'd have to render two times (low res + high res) to get the desired effect
In the newer implementations, you can split the display into tiles, and render each tile at a different resolution, so it's not that bad. A bunch of the intermediate rendering targets are already rendered at reduced resolution, so you won't see a full 4x speed up in the low-res regions, but you should be able to achieve a ~30% overall speed up with modern foveated rendering.
The framebuffer that you are filling out is still at native resolution, but while computing that frame buffer you can do many of the steps at reduced resolution. For example, instead of evaluating the pixel shader code for every pixel, it could evaluate once for a block of four pixels in the reduced resolution region and use the result for all four.
No, memory is not limited to facts. There's just no visualization to go along with the recollection of faces etc. You can absolutely still recognize people correctly when looking at them.
Exactly this. Search for a mini PC and it'll have a cheap Intel SoC in it that performs way better than a Raspberry Pi 5 but cheaper (comes with everything for ~$300), and even consumes a similar amount of power.
Swap is so much more than a safety net and can increase performance if used correctly. See Chris Down's "In defense of swap" and follow-up that breaks down zram vs zswap.
Swap is required for hibernation. And with fast ssd or properly tuned zram/zswap one can run task that use 10%-20% more memory than installed RAM. Surely there is a slowdown, but it is not that big especially when SSD can read write more than 5GB/s.
TL;DR that swap shouldn't be seen as "spare RAM", but a mechanism for paging out anonymous pages, which is desirable in many circumstances in avoiding OOM situations and making memory management work better. It paradoxically typically reduces I/O thrashing.
It helps with performance by allowing your system to have more free physical RAM. And by free I mean for caches. It does this by moving data from inactive pages out of physical RAM. You shouldn't care about the peak bandwidth of zram vs. ordinary swap because latency matters more.
I mean, are you saying ‘but more RAM?’ because obviously yes that’s true but not a solution if you already own a laptop, and have you seen ram prices? Also swapping to a fast SSD isn’t like it used to be on spinning discs. I’ve been amazed how responsive Mac neo laptops are and they are swapping all the time.
I'm not saying to avoid swap. It is great at what it was designed to do. I only take issue with optimizing swap for bandwidth when it will never be able to keep up with RAM bandwidth. The MacBook Neo for example has 60 GB/s of RAM bandwidth but only 1.5 GB/s SSD bandwidth.
Because it wouldn't soften the blow. Swap benefits the most from improved latency not bandwidth. Data is moved from swap back to physical RAM when swapped out pages are accessed by software (which stalls the thread). The kernel has less insight into the memory access pattern to prefetch the next page so the stalls likely continue for each page it needs to restore. The latency of zram (compressed in memory) is still lower than the fastest SSDs which reduces those stalls.
EF Core and F# still don't fully work, neither do the GUI frameworks, with exception of the buggy WinUI, mostly because it is all COM/WinRT underneath.
EF Core heavily relies on reflection so that's not really a surprise. F# not working surprised me but apparently the main thing is its `printf` depends on reflection.
By "the GUI frameworks" I assume you mean Microsoft's GUI frameworks. They're all basically abandoned or just bad. Use Avalonia! It's better, cross-platform, and supports AOT!
Well, they had enough time to refactor EF Core to use code generators.
F# is improving on .NET 11, but still not fully there, as contrary to the rest of .NET, it is mostly community driven.
Most Microsoft shops only consider Microsoft GUI frameworks, regardless of the great work done by Avalonia, and Uno as well.
As for being bad, they surely are much better than most competitors from other ecosystems, unless we're adding Delphi, C++ Builder, Qt into the picture.
I had projects with Java on the server and Microsoft GUIs on the desktop, for example. Swing and JavaFX are also quite good, however require additional programming for what Forms and WPF do out of the box, unless one is willing to pay for something like JGoodies.
I experienced the same issues but went the other way and migrated from React Native to React. Still one codebase but none of the issues. Performance was better too even though half the code stayed the same.
reply