bri3d

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.

> Is this not what happens in most SaaS?

I think it's fairly popular to try to do more logical isolation in SaaS now, especially with VM-scheduling-as-a-service becoming more popular. For example, I did security architecture at a company who did relatively simple financial processing; we worked to move to a model where customer documents were encrypted using a tenant key which we'd then wrap in both a service key and a login key; users could only get the login key stapled to their session by authenticating against that account, and the processing jobs ran on a cloud vendor's logical isolation. So the user needed a login key, the service needed the attested service key, and the job ran in what amounted to a mini-VM, avoiding issues like "whoops we sent the wrong document ID and the backend gave it back to us" or "whoops, we routed the request to the wrong tenant backend!" This level of isolation would be really hard to achieve in an LLM vendor context.

> I don't see why they would not hire the best to implement these relatively boring/solved things correctly at an architectural level.

I think a lot of these things develop over time; obviously hiring people who have done them before helps, but it's hard. Even the people with strong experience often only know little slices. And unfortunately, every system operating at these scales has emergent behavior which can become really challenging at scale; mistakes like "we used hash(id) as a key in a memory cache without a collision list, and it collided" which would simply never affect most startups become more and more frequent at scale. High rate of change makes it hard to suss these mistakes out and root-cause them, too; "a customer gave us a log where we swapped X and Y" is hard to bisect when you're doing 500 code deploys a day.

Yes:

* There's an enormous amount of very expensive shared state (context cache) which you do not want to duplicate when you can avoid it.

* Memory locality is crucially important for performance.

* Hardware is extremely over-subscribed.

* Hardware is extremely expensive.

These factors all make hardware or even traditional memory-space (hypervisor/VM/hardware assisted virtualization) isolation a non-starter for most workloads and customers, which forces all isolation to the software layer. This already makes things way harder than they are in commodity SaaS.

Moving beyond that, the tools, frameworks, and hardware which the system runs on (GPU) wasn't designed for task isolation and building this isolation is even moreso an emergent research field than it is in x86 CPU hardware-sharing (which has required a huge amount of effort over the past 30+ years to get where we are today).

And, the ratio of usage/sensitivity to maturity is also just poor overall; these are young companies with rapid development and enormous delivery pressure under incredible customer workload requirements, too.

I can't tell if the original post is a real issue or not, but I'm surprised there aren't more like this overall; the whole thing really is a house of cards in this sense.

> A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.

I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.

BitLocker with PIN works like this:

* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).

* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.

* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.

Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.

Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).

Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).

For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.

It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.

Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.

I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).

BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.

It’s less a question of people and more one of "Why doesn't a hardware company want to give away their IP design documentation?"

For "copter" style drones, 3D printing is basically a "noob" meme at this point; everyone thinks it's a good idea, tries it, and realizes that it's actually really hard and doesn't work.

Copter-style drones are exposed to vibration across a huge frequency range in every axis, and it's almost impossible to avoid really nasty resonance issues using generally-printable FDM filaments and "standard" design techniques; it's a lot easier to just use super-stiff carbon fiber and CNC it.

For planes, like what you linked, 3D printing is more "plausible" than for copters but also not really practical; you can 3D print a good plane, but plastic lacks the durability and favorable weight characteristics of foam - plastic planes tend to be "one time crashed" while foam is easy to repair, restore, and rebuild.

Low end and most open source stuff will use a PID inner loop for “fast path” control (stabilization) and either a second PID loop or something a little better (Kalman filter etc) for the slow path (position / path hold).

Higher end stuff will use a ton of inputs (visual odometry, binocular vision, lidar, range finding, etc) fused into some kind of proprietary blended algorithm that you could probably call an MPC.

RL is pretty cutting edge, especially for fast path motor control; there are a lot of university competitions for drone control that lead to a lot of papers and projects in the space (some promising) but most commercial stuff has not adopted this yet, certainly not at the low end.

Most filament based printed frames end up with really nasty resonance; it’s possible to engineer damping around the issue with some clever 3D design if the parameters of the prints are measured, but overall 3D printing copter frames doesn’t tend to be a straightforward solution.

Ahh, thanks for the correction, it's the window manager that's closed (lipstick-jolla-home). Regardless, I will stand by my statement that a fully open-source build of AOSP is significantly more complete and useful than a fully open-source build of Jolla.

If we're going to start counting forks, we get to count LineageOS and GrapheneOS for Android, and then the goalposts really move.