bri3d

With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way.

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.

No, because the two platforms often don't share the same underlying kernels; this has been one of the main issues and complaints with ROCm/MIOpen since the start, although they are catching up slowly.

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.

ZLUDA is still alive. AMD sponsored it and the project was briefly halted during a dispute with them, but it’s been making steady progress.

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.

The CUDA runtime coming with a gazillion reasonably decent kernels (DNN, BLAS, CUTLASS) and a concurrency system (NCCL) is a big deal; especially in the “early days” very few researchers or development runtimes were even writing their own kernels or dealing with CUDA C++ extensively, they were wrapping the ones NVidia gave them.

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).

He gave a talk at Defcon.

Certainly not at these frequencies and corresponding high capacitance values; getting 22nF out of a PCB even with ECM would require quite a large surface area and at 220GHz you can't have that since your wavelength is so short; you'd just be making a giant resonator instead.

A sizable percentage of datacenters use open loop water spray towers, but the alternative, forced air exchange (ie add more giant fans) uses more electricity. It’s fairly complex to quantify which is “better” or “worse” but there exist data centers that evaporate a ton of water and send it elsewhere. (for what it’s worth I agree most of the anti datacenter hype is overblown and driven by specific poorly designed gas turbine powered installations).

That's not how this works, at all.

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.

Simulink, Labview, Bosch ASCET are all pervasive in control systems engineering, especially in European automotive applications.

> It's a zero day in some caching proxy who may not have had that threat model in mind. I guess its primary purpose is caching packages, not restricting internet access.

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.

It's "just" a restructuring; the previous setup was a really bizarre financial product where Citizens Bank gave you a 24-month 0% personal loan to buy an iPhone, but Apple would also buy your phone and loan out and sell you a new one every 12 months.

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.

It doesn't; BMW use the CCC Digital Key standard for "Digital Key Plus" and there's no Internet required post provisioning. This story really reeks of misunderstanding or "needs more information" as for BMW especially, I don't see any scenario where this could have happened, regardless of physical or phone key use.

My experience has been that Qualcomm mobile phone chipsets don’t run Android on the modem side, but that standalone (ie laptop / USB / router) ones like this Quectel part sometimes do, in order to provide the userland components that run on the phone’s Android system / AP in a phone application. The actual basebands run an OS called REX usually.

I don't think I'm really conflating anything, and I don't agree with your thesis even though I agree with individual points.

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.

The myth I was referring to was the overarching theme that “VLIW would have been practical if only a better compiler existed,” which I don’t believe to be true for modern or Itanium-contemporary general purpose computing patterns.

These worked well for “known” intra-task pointer aliasing situations, but if you don’t know what will be in cache due to preemption of any kind, you still don’t know how many cycles the speculative loads will take, so you get the same stall risks across a dependency hazard.

No (sorry, I post this every time the Mythical Compiler Myth reappears), the problem with VLIW is that it fundamentally doesn’t work for anything with unpredictable memory access patterns, and modern general purpose computing has moved almost exclusively in this direction. For VLIW to work, you need to either guess correctly what is in cache or not have a cache at all; as soon as you mispredict what has been loaded, you stall while an OoO processor keeps going and a speculative OoO processor even keeps guessing. With multiple workloads on the same hardware (virtualization, multitasking, multitenancy) this becomes an intractable problem even in the presence of the magic compiler which can solve for software based unpredictability (branch likelihood and pointer chasing), because every context switch clobbers an unknown set of cache lines and blows the entire thing up.

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 enjoyed seeing a throwback wololo link enough that I think maybe it should stay, but the real (linked) research is at https://github.com/mcidclan/psp-media-engine-cracking-the-un... and stands well enough on its own that you don't really need the article.

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.

This is a very good text and regarded as one of the greats for a reason, but it glosses over a lot of lower concepts (like OFDM, which if I recall occupies only a single short chapter) and focuses very heavily on MIMO. Proakis and Salehi ("Digital Communications") and Goldsmith ("Wireless Communications") cover some of the "lower level" concepts like OFDM pretty well in depth from a theory standpoint. Goldsmith is a particularly good middle ground book. A highly underrated book is also Andreas Schwarzinger's "Digital Signal Processing in Modern Communication Systems", which covers how modems for these systems are actually implemented in real life and is quite approachable from an engineering standpoint.

Zoom were a very longstanding modem company who expanded into cable and routers and licensed the Motorola brand in 2016.

Vendor wise, these were never really made by a “Motorola” -this is a Zoom router (thus the domain) that used the Motorola name under license.

The “old” Motorola router division Motorola Home got sold to Arris _without_ the brand name in 2013, and then the brand name went to Zoom in 2016. Zoom merged with another vendor called Minim, went bankrupt in 2023, and the assets were bought by a company called e2Companies in 2024.

So e2Companies is who the author should email, but good luck. I’m shocked these were even “maintained” until 2024.

AMBA has been an open standard for a really long time, I think maybe since it was released?

It’s a completely different backend model; as far as I know alipay works just like PayPal where transactions are fully “internal” - the buyer pays Ant Group and the seller cashes out at a later date.

UPI is a real inter-organization payment system more akin to credit card processing, where fund requests flow from the payer, through a payer processor, through a merchant processor, and finally to their end destination, and the actual reconciliation happens through a bank transfer system. It’s a much less centralized system.

Right, there are two problems there:

* Pilots are very concerned about life and safety and are heavily exposed to drone “incident” related anecdotes, so they err far on the side of caution with drone sightings. Which is to say a very low percentage of them are real.

* Poorly implemented cUAS systems, especially ones based on passive or active RF locating (radar) can actually make the problem worse: they hallucinate everything into drones, pilots hallucinate everything into drones, and now everything is a drone. This also happens frequently when people try to repurpose military systems (which are usually designed to operate in significantly less crowded environments and trigger at the slightest hint of an issue, due to mostly orthogonal-to-airports threat models people discuss at length on this thread like “dark drones”) into urban use.

This type of array based directionfinding system is cool and it could work as a small ingredient in a drone detection system, but it’s not anywhere near the state of the art in the space and most airports are probably already ahead of this to some extent.

Most major airports will already have a counter-UAS system, it's a huge industry.

One big issue with radar is that it has the same problem pilots and human observers do: it struggles to distinguish drones from anything else in the sky (birds, balloons, planes, etc.). This is an active and improving research space, but by and large with radar, when your pilots report a drone, you still don't know how to figure out if it's the typical mis-identification or something real.

This is weird to me too, especially to say in the present tense in 2026.

I think I get the point about "Rust culture" (although it's too vague to agree or disagree with, probably on purpose).

But in 2026, Rust is fully a commodity language, and especially to compare it to Zig in this angle is bizarre. Even turning my stereotypes to 11 and thinking back to when I worked with a team developing Rust professionally in 2021, I'd say we got mostly ended up hiring "proglang enthusiasts" and not "Rust people." In terms of "cultural dilution" alone Zig is orders of magnitude more culty than Rust because that many fewer people use it.

It’s a huge problem. The most common approach to address it is called smearing; the duration of each second for a 24 hour period ahead of the “leap” is adjusted. For strict ordering systems this works as each device maintains time sync with the global clock, the duration of a clock cycle is just slightly different. I think this was in the original Spanner paper, actually.

Some rare systems use monotonic oscillator seconds and ignore the earth rotation second, but if you ever have to translate those to real time, you get an accumulating disaster over time and it’s generally regarded as not a good idea.

Users with data caps are an obvious reason, for example, see this frustrated user report here: https://support.google.com/chrome/thread/415181794/chrome-al... .

To your point about `fetch` in the sibling comment; yes, I would also be annoyed by a website which downloaded 4GB in the background without asking me, too.

I don't think this is some moral outrage, to be clear; it's well within Google's rights, it doesn't seem "sketchy" at all, and it is kind of a cool feature, but it feels like they could have done a lot better by just making it opt-in and a little less fingerprintable.

Just the availability wouldn't be that bad from a fingerprinting standpoint (getting one bit that a majority of Chrome users have is just the same bits you already have, usually), except, it also exposes whether the underlying hardware is "eligible," and once it's running, you can also benchmark the language model performance. It's a mess. I think it might also be broken and work in iframes, which would be an even bigger mess; there are a few bug reports suggesting this although many of them look like slop.

This feature was massively bungled; I actually don't overall hate the idea of it (having a shared, pre-downloaded model that can run effectively from JS is kind of awesome versus sites downloading stuff into LocalStorage to use with hacked up wasm/webgl inference engines), but it really, really needed a permissions dialog and a proper anti-fingerprinting model.

Impression v. Lexmark is directly relevant to the patent situation here; in a case involving reprogrammed ink cartridges, the Supreme Court held that patent rights are exhausted by first sale doctrine; that is, if you sell me something patented, you can't sue me for patent infringement for using the thing you sold me, even if I do something later that makes you upset.

It's also been widely held that ink cartridge compatibility tools/hacks are allowed under DMCA.

However, it does seem likely that there's probably some shenanigan involved in the area - one example I could think of would be if HP have patented the way the ink cartridges are retained in the printer, for example, that would have to be carefully audited. And there will be license and trade secrets issues with the use of the cartridges, although if they were reverse engineered cleanly and the printer doesn't come with cartridges, those are probably pretty easily side-stepped.