bri3d

* Yes, TRACON have their own dedicated links. You can look into ASTERIX and STARS to learn some of the cursed ways the data processing and dataflow work.

* There is supposed to be a primary and a secondary link, in this case the primary failed and the fail-over also failed. It's unclear from the reporting if they were damaged in the same incident or if the failover was not tested or monitored adequately.

The Philadelphia TRACON site has been notoriously unreliable and was supposedly improved in 2025, it's also unclear if these issue actually could stem from that implementation.

I absolutely agree that engaging with these people beyond "we added checks to ensure your board has the RAM it came with, and this one failed" is a waste of time, but I think that at least providing that level of response would be much more aligned with the image they're still trying to project than just stonewalling entirely.

Really? I found that issue and all of the related ones really disingenuous from the Pi folks; they just stonewalled everyone with "contact your hardware seller" rather than explaining what was going on even at the glossed-over level they managed in the forum thread.

I do feel for them; they're between a rock and a hard place with mis-labeled clone boards. But their implementation seems to be the most hostile and opaque possible way to achieve these goals (which I also understand from an anti-cloning standpoint, but especially anymore, it's going to get reversed anyway).

I see that now… why did they check it in? One of the whole points of this approach is that that assembler should be trivial to re-derive by the end user since it’s just the original program listing. Some of the Xbox 360 recomp projects like https://github.com/mchughalex/skate3recomp offer a better example of how this pattern can be achieved without distributing the binary at any intermediate level.

This is a recomp project, not a decomp project; the original binary is supplied by the user, mechanically translated into source code at an architecture level (rather than a human-readable level), and patched. It’s AOT dynamic recompilation and the original IP isn’t distributed.

I do agree that decompilation projects are obviously not transformative (the only fair use feet they really have to stand on are purpose and market effect), but recomp projects are a little more interesting and might live on much less shaky footing.

I felt compelled to reply to this because I agree with it so strongly (which is also why I phrased my initial post as "sort of odd" rather than "some evil anti-consumer monopoly volcano lair conspiracy"); so many corporate oddity theories are easily caused by dysfunction that I wonder how many of their proponents have ever really been exposed to a corporate job.

Patch embargoes are a debate as old as security.

I think the overall source embargo is rational _until_ fixes appear in a released binary build. Otherwise there's an integration/QA/rollout window where a source patch is public while the binary patch is unavailable to anyone, including attackers, which is undesirable. In "full" open source this has always been a time-suck mental gymnastics exercise around hidden mailing lists and obfuscated commit messages (which probably aren't useful in the LLM era anyway). It makes sense for Google to avoid engaging with that given they don't need to; I think it would be fully logical for them to perform source drops gated on the rollout cadence to the first available binary release channel.

I fully agree the slower-than-Pixel "vendor lead time" windows are really detrimental. Once the binary patch is out, the source patch and disclosure is effectively out too; those extra windows just let OEMs continue to be lazy as a matter of policy (which they love to do regardless) while exploits are already available.

Oh! I had thought they stopped at the same time they closed off AOSP commits - that makes this entire rabble-rousing effort _exceptionally_ silly, then; I can't see the angle GrapheneOS are trying to push at all in that case (like, I get their side of the _concern_, but "Google are shipping features to Pixels that you don't get" becomes... quite a poor argument indeed in that scenario).

So, the real thing that's happening here is:

* Google drop "real" Android source-code updates to OEMs _and_ the public every half.

* But they ship four Pixel updates, including documentation + SDKs.

* Now they added new APIs in a Pixel-only update.

* Google also drop security update backports to "trusted" OEMs monthly (which GrapheneOS have had access to for years).

So, there are now Pixel-exclusive app features on the Pixel SDK version which isn't available to OEMs - but, it's highly unlikely any app developer would actually depend on these new APIs, since Pixel marketshare is tiny to begin with. This in essence just makes Pixels a weird beta-testing device for what will come out a quarter later to "normal" devices, which is sort of an odd business decision, but also a weird thing to get really mad about, in my opinion (I do see what GrapheneOS are trying to do, with having OEMs saber-rattle about not getting features on the same cadence as Pixels, it just doesn't resonate very loudly for me).

However, the API headline seems to bury a deeper lede; in the thread, GrapheneOS also claim that the quarterly Pixel releases contain security content which is not appearing in the monthly backports. This is quite bad and very sloppy if true, since the Pixel releases can easily be patch-diffed and exploits backed out of them. I'd be interested in seeing this enumerated in more depth.

CA v. Altai (where the abstraction-filteration-comparison principle comes from) and SAS v. World provide pretty strong positive evidence that clean room is a valuable technique in both the US and Europe.

I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.

By not having void air space in between cylindrical cells like you'd get with two 18650s? It's mostly just a matter of packaging.

Pouches can be made to have better volumetric density than cylindrical cells quite easily, which is why laptops aren't generally full of cylinder cells anymore; the challenge is just providing them enough external support/compression and swelling allowance, which can be accomplished through chassis design.

I read this as the chunks are 64 bytes and thus each chunk is split over 9 frames. I haven’t looked yet but it’s probably an ISO-TP esque framing protocol.

Yeah, that’s a good way to summarize what people are mad about; they basically moved all of the calibration from onboard to offboard diagnostics, and then thwarted most efforts to access the offboard diagnostics.

Automotive is similar and I’m a bit worried for EVs; for ICE autos there’s enough emissions related regulation that some diagnostics and manuals are accessible, but for EVs there’s nothing much stopping a Deere style complete lockdown.

Newer Deere equipment has a lot of components that have to be adapted using DSA - turbo actuators, various hydraulic sensors, various suspension leveling sensors, fuel injectors, interior displays, and anything SCR related are the big ones. Basically, any sensor that needs a calibration step or triggers an emissions code, or a few intentionally vehicle locked modules (ECM).

Palantir sell consulting services ("forward deployed engineering") around graph and map database platforms, using data supplied by customers. Some of their customers ask them to make surveillance aggregation systems, others ask them to make totally banal and random enterprise software (this is why you commonly see freak-outs around hospitals buying "Palantir," for example; usually they are operating as consultants making some kind of medical records warehousing system owned by the customer).

Samdesk provide risk analytics using traditional risk analysis investigation and research, which they have now welded an "AI platform" to, like everyone does these days. They aggregate crime and protest data to make a map of "places your employees might be at risk" and sell it to companies.

Samdesk would be a Palantir _customer_ if they liked parting with their money, not a competitor; Palantir operate at a much "lower level" and don't do the data collection or research on their own.

I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier. Certainly, vertical integration makes OS porting (ie Asahi) and lower level emulation more difficult, since the hardware and firmware's contract with the OS is entirely proprietary and can be freely changed from revision to revision, but something like WINE operates many layers above this anyway.

There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.

I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.

No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.

I don't think this is new with LLMs (finding an exploit based on a few words offhand has always been a fun part of exploit development), but it's scaled and democratized to mass exploitation of low value targets. Backing exploit PoCs out of patches, commit messages, and random overheard or over-read sentences is a practice as old as vulnerability research. The difference with LLMs is that an explosion in actors "skilled enough" (human or not) has enabled sloppy / low-skill "exploit the whole Internet" actors in a way they weren't previously enabled.

I do agree with the author's ideas, though; most of these are things that should have been done much sooner, and I suppose it's good in a sense that there is a forcing factor now.

> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.

I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.

> You can compile a decomp into the same binary, but that's only to prove functional equivalence.

This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.

Yes, I agree with you (see my sibling post), but it's not what the post I replied to was saying.

It seems like it could go either way to me in the US (not a lawyer, but someone who has a fair amount of experience in reverse engineering / fair use issues).

On the one hand, it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.

On the other hand, these projects are mostly free, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.

So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.

Most of these projects carefully distribute only the source code representation of the binaries, for this reason, relying on the consumer to acquire / own the art assets and copyrighted material (logos, trademarks, etc.).

Only server, as far as I know. Server is now either high-density E core (Sierra Forest) or low-density P core (Granite Rapids), but desktop and laptop are heterogeneous still; laptops are getting even more heterogeneous because they have P-Cores, E-cores, and Low Power Island cores.

There’s a technology fundamental driving the short form aspect too, current video models are all trained on <500 frame sequences and struggle to generate long shots. There are a lot of attempts in the literature to improve cross-generation coherence but there needs to be an architectural breakthrough or significant scaling improvement before longer continuous shots are practical. So you’d be making a really ADD feature film at the moment.

Android has a proprietary HAL on both ends; the userspace interfaces to drivers are not the same as on "normal" Linux for almost any devices (baseband, video acceleration although this is at least EGL based, cameras, sensors, audio DSP, hardware media codecs, etc.), so by the time you replace every component of the OS, you've just made AOSP without the useful security parts.

> The advantage being, we can manage packages using a regular Linux distro

It's much easier, more plausible, and more logical to sandbox a regular Linux package-managed distro inside of Android, which numerous solutions exist for.

Friction drive e-bike conversions were popular years ago.

They generally:

* Wear tires surprisingly quickly

* Absolutely suck in any form of weather or terrain condition (dirt, rain, etc.)

* Have ~20% less efficiency than any other drive form.

But, they are easy, and they do work.

> Wait until they find out your mechanic has unfettered access to your car's OBD port when you hand them the keys

Surprise! “They” did find this out and UN155/156 regulate a bunch of protections against local “attackers,” often to the detriment of right to repair.

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.