That was already the case with the M-series chips, which are shared between Macs and higher-end iPads. The Neo just extends it to the A-series as well.
Those speeds on the Pro/Max are impressive though, more in line with Gen5 NVMe drives. Those have been available in desktops for some time but AFAIK the controllers are still much too hot and power hungry for laptops, so I think Apple's custom controller is actually the first to practically hit those speeds on mobile.
It's been done, the ZSNES and Project64 emulators have both had exploits which allowed a malicious ROM to run arbitrary code on the host. ZSNES is written mostly in assembly so that was kinda asking for trouble though.
They haven't added or really changed anything since the acquisition AFAICT, it's just trucking along exactly as it was the day Zoom bought them out. Twitter account proofs were broken by the API changes years ago and nobody is at the wheel to fix or even just deprecate them.
It's kind of bizarre that Zoom is still bothering to keep the lights on at Keybase when it's been completely fossilized for six years now. The writing is so obviously on the wall that nobody should be relying on it for anything, and yet they just won't let it die.
My money is on 12GB in the second gen since that's what the A19 Pro has, and it would still conveniently differentiate from the other MacBooks with at least 16GB.
I can't be the only one who remembers the celebration 18 months ago when Apple finally stopped selling Macs with 8GB of memory... only for 8GB to suddenly be excused again when the Neo arrived. Perhaps it's not the same people but the general vibe is giving me whiplash.
Further down they also mention that the requests come from CFs ASN and are branded with identifying headers, so third party filters could easily block them too if they're so inclined. Seems reasonable enough.
12.08% [of translators] say MTPE produces high-quality output.
A significant portion (around 50%) of respondents do not offer discounts for MTPE work, arguing that post-editing can take as much time as traditional translation.
Among those who do offer discounts, the most common range is between 10-30%.
MTPE (Machine translation, post-editing). This works just like it sounds. The initial translation is done with machine translation, then human translators review and edit the resulting translation to try to correct any mistakes.
And the consensus among professional translators is that MTPE only saves time if you're willing to accept a half-assed result. For them to edit MT up to the standard of manual translation takes just as much expertise and effort as translating it manually in the first place.
It was much easier to pirate games on the Dreamcast - the copy protection was broken to the degree that you could burn a game to a CD-R and have it Just Work without modifying the console in any way. It being both a total piracy free-for-all and also a catastrophic commercial failure doesn't seem to fit what you're saying.
Not to say that easy piracy is necessarily a death sentence for a console, the DS succeeded in spite of ubiquitous and cheap flashcarts, but the Dreamcast shows it's not necessarily a path to success either. There are just more pertinent reasons for a system to sink or swim.
But for ML workloads the comparison isn't between slotted CPU RAM and Apple's unified RAM, it's between Apple's unified RAM and dedicated GPU VRAM, which can more than double even the M3 Ultras bandwidth at up to 1.8TB/sec. Apple Silicon makes a unique set of trade-offs that shine in certain areas but they are still trade-offs nonetheless, so it really depends on what exactly you're doing with the hardware.
Understanding the memory ordering requirements from binary without source and without killing performance by being overly conservative (and hell, the source itself probably has memory ordering bugs if it was only tested on x86) sounds next to impossible.
It is hard, but Microsoft came up with a hack to make it easier. MSVC (since 2019) annotates x86 binaries with metadata describing the codes actual memory ordering requirements, to inform emulators of when they need to be conservative or can safely YOLO ordering. Obviously that was intended to assist Microsoft's Prism emulator, but the open source FEX emulator figured out the encoding (which I believe is undocumented) and implemented the same trick on their end.
Emulators still have to do it the hard way when running older MSVC binaries of course, or ones compiled with Clang or GCC. Most commercial games are built with MSVC at least.
Nothing yet, but the upcoming Steam Frame VR headset is ARM based. The relevant detail is they're bankrolling the open source FEX x86 emulator, with the goal of bringing the whole Steam back-catalogue to ARM systems.
I can't imagine why you'd want to buy a beefy SOC with unified memory, only to have it host a discrete GPU through it's narrow PCIe x4 interface. You'd be better off with a traditional CPU that supports a proper x16 slot.
The Framework Desktop motherboard does actually have a PCIe x4 slot, their case just doesn't expose it for whatever reason. But you can buy the board separately and put it in your own choice of Mini-ITX case which does.
Because software needs to be aware of the memory lifecycle to avoid losing data when its process gets culled. iOS apps are explicitly built for that, but to my knowledge macOS apps aren't, they are allowed to assume they will run forever until the user closes them.
It's got a phone SoC. The use case for this thing is stuff you could do on a phone
I think the key difference is that phone operating systems are designed around extremely aggressive memory management where any background process can be killed at any time. AFAIK macOS just isn't set up for that.