It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.

This is actually a corollary to the point I was making about "CUDA" usually also including a ton of the included kernels and not just referring to a crappy programming environment; translating mid-level C that does math between two runtimes wouldn't be hard for an LLM, but translating "doBigDNNThingNVidiaGaveMeInAKernel()" to "doBigDNNThingByHandBecauseAMDDoesntSupportIt()" isn't a rote translation at all.

Of course, once you accept that it's _not_ "why don't you just translate it," you _can_ iteratively use an LLM to implement the ThingNVidiaGaveYouInAKernel, but it probably isn't well-trained, yet, on low-level AMD optimization tricks, so the kernel you end up with will likely be slower than the CUDA one.

It doesn’t really make sense for AMD themselves or most use cases, though; any compatibility shim just adds problems on top of problems, and for AMD, entrenching a competitors technology even more never really seemed like a great idea.

I do agree that it’s really not great, and I also have never been a strong believer in the CUDA moat overall; as the need for GPUs moves from research to production (inference), companies are plenty willing to build software from scratch anyway (and we see this with AMD GPUs being in plenty high demand in the datacenter and enthusiast market now).

Visual approach is a specific IFR procedure. It's basically designed to expedite and simplify the landing process in situations where the pilot can see the airport and traffic allows - instead of flying a detailed set of waypoints provided by an approach plate (via RNAV/GPS, ILS/VOR/DME, or vectors), the pilot and ATC both agree "hey, you can see the runway and/or traffic, you got this now" and the pilot lands.

By asking for a visual approach and getting approved, then not subsequently asking for another approach, the PIC was flying visually. There's nothing more to it. There's no nuance or gotcha here, and nothing seems procedurally incorrect or even out of the ordinary.

"Canceling" IFR just means concluding the flight plan and "closing the file;" which they were given the option to do in the air or on the ground, but it's not relevant to the approach they chose to fly.

The root cause of this incident is clearly pilot error; the pilot specifically chose to fly a visual approach without adequate visual reference and descended into terrain.

There are proximate causes too, which may or may not relate to the GPS jamming and for which more information is required. For example - did the pilot choose to request the visual approach because they didn't want to fly an RNAV approach in case GPS was inaccurate, or because they didn't want to burden ATC? or did they just choose the visual approach because they could see the airport and it's easier that way? Was this in line with any guidelines from their operator? We don't know that yet. And there's some chance that without GPS jamming, a secondary safety system (GPWS, moving map, etc.) may have saved the pilots from their decision. But these things are all secondary.

In many if not most environments where I have seen these used, they are used to bridge an access boundary and are absolutely security critical. Frequently (and probably in this application, too), they are used for security enforcement in an architecture where CI doesn't have Internet access, but does need to download packages. This is a pretty big deal for a lot of big companies; historically they have relied on stuff like package proxies to help protect them from supply chain compromises like post-install script exploits by preventing CI from being able to detonate an arbitrary Internet payload; if a supply-chain worm were to incorporate this exploit, it would be a lot scarier and more potent. Actually, from the supply-chain worm standpoint, this is arguably a bigger finding than a Docker escape - I suspect we can look forward to more shenanigans in this space coming soon.

Now it's just a normal lease product with a 0% money factor through Klarna, that also works across Apple.

What this does is gives Apple more "price flexibility" (aka, they can raise prices more easily, which was probably a lot of the driver for this), but also gives consumers more buying power flexibility since it's a simple product that works across the board rather than a bizarre iPhone specific optimized financial instrument.

1) Yes, unless you add abstraction at the ABI/ISA level in hardware or microcode, which then defeats the point of VLIW to some extent. I mention this in my comment; Itanium in particular was hamstrung by trying to patch over this. This is one of the "sliders" you're dragging with VLIW; trading floor plan for cross compatibility.

2) Well, kind of, but this is just the Mythical Compiler I discussed in my own parent comment, regardless of language, and I find this argument tangental to the core issue. Yes, C makes things bad by encouraging both aliasing and pointer-chasing, but one can also argue that a sufficiently advanced compiler can discover the intra-program hazards and prefetch accordingly (see monocasa's discussion); this is moving where the parallelism is expressed, but isn't patching the fundamental issue.

Overall, I don't think the issue is that nobody will build a language or compiler for an architecture with compatibility problems. We see good compilers and lots of language research in this space for DSP and AI workloads. I still believe that the fundamental issue is that VLIW is not suited for general purpose computing workloads due to cache residency issues caused by context switching.

VLIW works for single workloads. It works exceptionally well for single workloads with no or explicit cache like DSP. You can trade the footprint and complexity from OoO for a wider execution unit and more SRAM. It works well for HPC, too, for the same reason. But for anything where more than one process exists, it just really doesn’t work, and that’s most modern workload.

Itanium also has a unique set of self inflicted issues due in large part to Intel trying to make a wide variety of cross compatible parts, but IMO even if they’d got it right, it still would have died.

I also sort of disagree with the premise of the article; the ME was not only well known but well used, even back in the day. The cool part here is the VME, which looks like a configurable block pipeline of different DSP elements. This is a pretty common architecture in codec processors but they don't get reversed very often.