* 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.
Reporting is saying that the backup was cut a while ago and they only discovered it when the primary failed. Apparently nobody was ping testing the backup link.
I’ve had enough double-redundant links fail - and I mean pretty thoroughly double-redundant, different provider, different media, different physical path - that I’m quite surprised something like the air traffic control system only has two links.
Contractually dual-path, or actually dual-path? My understanding is that there's enough infrastructure horse-trading going on behind the scenes that it's very difficulty to be certain that two circuits between points A and B don't share the same infrastructure somewhere in between.
First big oops of this form that I remember:
"In December 1986, the ARPANET had 7 dedicated trunk lines between NY and Boston, except that they all went through the same conduit -- which was accidentally cut by a backhoe. "
I'm talking about data not able to leave the building, not even data getting lost on the way.
One example was a site that had fiber and coax, from different companies. They might have shared a pipe at some point along their length, hard to say. But both connections went down at the same time for digital reasons, not physical. The providers had simultaneous unrelated backend router problems and the site lost contact to both gateways.
This was with a nice SD-WAN system that routed everything dynamically across both pipes to address latency and errors, but if the packets get dropped at the first hop in both networks, there's not much you can do!
The saving grace in that case was the third redundant connection, a 4G cell modem, with a lot less bandwidth but able to keep the critical transactions going. These days I'd certainly want Starlink on the roof as well.
Yup. Seven different paths comes with seven different sets of equipment, and seven different rights-of-way that have to be negotiated, purchased, leased, whatever.
One thing that needs to be reviewed is if they are dual links or redundant links.
In any system where both sides of redundancy always carry traffic then loss of one link can cause congestion failure if any link fails. This is a very common means of failure in electrical networks that requires load shedding. Well, you can't load shed air traffic.
A more complex system that I like, but comes with it's own set of constraints and implementation issues is a system where both lines carry all the traffic at all times. This way the default state of the system is always working and your first failure isn't invisibly critical.
But this is very hard as we see in TCP when things get out of order and high latency creeps in. You have to manage a lot more state at the data level.
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 dunno - I think the victims in a lot of these cases aren't stupid. They can't contact the seller because they bought it from 'some guy' who's disappeared into the night. They know they've been had and are trying to get a knock-off board working at the expense of [the time of] someone completely unrelated to this.
It's pretty normal for the first port of call / warranty claim for a busted item to be the dealer that sold it to you.
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.
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.
Thank you for explaining this. I had the exact same misunderstanding as the parent poster, and was only corrected (and educated) by reading your comment.
A hypothetical relating to the legal aspects: Since this was mostly done by an LLM, the legal considerations would become incredibly interesting in cases where the original code (source or binary) was illegally leaked. What happens if the LLM saw the leaked code in its training material?
(My non-lawyer brain thinks it's completely obvious that in that case you have a derived work, but apparently the world has decided that it's completely fine to train LLMs on e.g. GPL code without the output being considered derived, so what the hell do I know…)
> the world has decided that it's completely fine to train LLMs on e.g. GPL code without the output being considered derived
I think it's more of a "the constitution is not a suicide pact" approach to GPL: while the GPL is obviously violated by its inclusion in the training corpus, we have two options:
- demand the destruction of LLMs that are trained on copyrighted or copylefted works and the training of new ones
- accept that LLMs that are trained on copyrighted or copylefted works are more important to humanity than the rights of the authors
Well if it's the second, then surely I can train my LLM using the frontier labs' models too? And have my LLM "interpret and reproduce" GTA 6?
How is any of this going to work out if we just decide to throw out copyright like this?
(I am well aware that it is not currently technically feasible to copyright-wash GTA 6. Replace that game with a best-selling novel or whatever.)
And, if we do decide that copyright is just gone, can we please make laws to that effect? Instead of just shrugging our shoulders and going "oh well, this new thing is useful, so we'll let it slide, but don't you dare to pirate movies, because reasons!"
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.
* 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.
> * Google drop "real" Android source-code updates to OEMs _and_ the public every half.
All of the major OEM shave access to the internal source with a _very_ small delay. OEMs don't ship these intermediate releases because they choose not to, not because Google witholds the source for them.
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).
The whole security embargo things seems incredibly stupid. OEMs are always too late rolling out security patches. So Google thought, "let's create an embargo of months so that the OEMs have time to integrate the patches". Anyone could see it coming that nothing would change and the OEMs would still wait until the very last moment.
So now everybody is off worse. Not only are OEMs still slow with security updates, while CVEs float around for months among those within the know (or reverse engineering skills) for months.
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.
It's probably no decision at all, but merely poor coordination between separate departments.
Once a bureaucracy surpasses a certain size, odd side effects accumulate on their own, and the growing number of people affected by them seek to cast blame where no purpose ever existed.
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.
I don't really see what the Pixel-only early API releases achieve except for allowing developers to work on Pixels ahead of time, but Pixels are such a small sliver of the universe that it basically just gives Google a leg up, I would assume. And if you're on Graphene why would you care about Google's beta edge apps?
Exclusive access to QPR1 and QPR3 releases gives Pixels an unfair advantage over other Android OEMs. They get an extra 2 major updates per year. Introducing new APIs for third party app developers as part of these updates means third party apps will now run best on the Pixel OS. Google apps already run best on the Pixel OS due to many exclusive features. It's Google's standard overall approach to propping up parts of their business with their monopolies in other markets. It's not legal.
Pixel 9a and earlier were officially sold as Android Open Source Project reference devices. Google made a commitment to providing 7 years of updates from launch for 8th/9th gen Pixels. Google then arbitrarily declared they were no longer AOSP reference devices with the release of Android 16 and stopped providing those updates. Many people bought Pixels due to this and it wasn't fulfilled. GrapheneOS has been able to continue support with a massive amount of work including reverse engineering, but other operating systems haven't been as successful and mostly haven't even moved to Android 17 yet or supported 10th gen Pixels.
There are currently around 400k to 600k active Pixels with GrapheneOS. There have been far more than that when including the past devices our users have purchased. Pixels are a small segment of the overall market and that's substantial. If you add in people on other operating systems such as LineageOS then there are even more people using Pixels with another OS. A significant portion of people who bought Pixels did so because they were AOSP reference devices.
Samsung provides 7 years of support with monthly updates for their flagship devices. Unlike the Pixel OS, Samsung ships a lot of the security preview patches early.
Motorola Signature (2026) has 7 years of support. The upcoming successor to it is the first non-Pixel meeting all of the update and hardware security feature requirements for GrapheneOS.
Pixel 11 currently doesn't meet our security requirements due to at least temporary lack of MTE support which may get added in Android 17 QPR2. The upcoming Motorola device is also going to be using a 6.18 kernel at launch rather than 6.12. We would have launched Pixel 11 series support already if they met our security requirements. It's likely they will down the road but it's not clear why they omitted firmware and software support for a major security feature at launch. It's the firmware part which impacts us.
“many people”? Almost no one cared when they bought Pixel is more like it.
Many people bought Pixel because they saw it in a store or online. A few people bought Pixel because it was supposed to represent the leading edge of Android and it still does. Almost no one bought Pixel for AOSP reasons or even know what AOSP is.
> Many people bought Pixel because they saw it in a store or online
That's usually reserved for iPhones and Samsungs. Pixels have a tiny marketshare compared to Apple and Samsung. The GP is right when they say a significant portion of buyers bought a Pixel believing Google's claim that it was the 'purest' Android experience since it was a reference AOSP device.
> Many people bought Pixels due to this and it wasn't fulfilled.
Did they though? Or is this just conjecture? Because, honestly, Pixels are not even available worldwide so a few AOSP enthusiasts dropping off and going to Graphene hardly seems concerning for the mighty G.
AOSP reference was a tagline for a few nerds that still wanted the Nexus devices of yore, but it was clear from day one that Google wanted their Pixel phones to be their iPhones.
Android's official documented listed Pixels as the Android Open Source Project reference devices until the release of Android 16. It also promised 5-7 years of support from launch.
Pixels are sold in 33 countries across North America, Europe, Asia and Oceania. A substantial portion of the Pixel userbase is using other operating systems. 400k to 600k active GrapheneOS users on Pixels is a significant amount based on how many Pixels are sold. It's only one of the alternate operating systems people are using. It's not only a few users as you're claiming.
Saying that holding a particular opinion makes you irrelevant is not gaslighting? It's not nice to respond to a frustrated developer by saying they don't exist. It feels comparable to saying someone's concerns are not real, which does amount to gaslighting to me.
No one says graphene os doesn’t exist, or the developers don’t exist, just that their opinions don’t matter because they are a miniscule fraction of the market. 2% of active devices drives no decisions at Google.
I'm pretty sure the commitment has always been is for security updates, not for the latest OS.
My first phone was a Motorola that shipped with Eclair. Froyo had already been released and Motorola had a release date for Froyo scheduled in their website. They changed their mind. I don't trust Motorola one iota. Google has never lied to me they way they Motorola has. Good luck.
No, there's a clear commitment to 5-7 years of major OS updates in addition to security updates. Both commitments have been broken for the Pixel 6 through Pixel 9a. Those were sold as Android Open Source Project (AOSP) reference devices but had the updates to it prematurely cut off with Android 16. Pixel 10 and later weren't sold as AOSP reference devices so there was no commitment to providing it, but that's not the case for the earlier devices.
Thats a long time for a critical security patch to land (like this one [0], although it looks like it has been fixed now, at least in their alpha channel, which is annoying (not their fault) because we really need this patch).
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.
Yep, this is the case. Nine frames are transmitted with the first frame containing a sequence number and the first five bytes, followed by seven frames containing just data, and a final frame containing the last three bytes of data, and a two byte CRC.
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).
Interesting. I just finished with a thorny hydraulics problem on a 9870 Combine. It turned out to be a faulty sensor. Part of my troubleshooting involved buying a new sensor, and swapping out each sensor in the system one by one with the new unit until I was sure they were all working correctly. No calibration needed. When i do need to calibrate a system i can do it all from the onboard computer.
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.
Exactly, go look at Lucid/Tesla and a few others for examples of how the car is a brick without the manufacturers sekret unlock codes and calibration software. If they decide not to help, you are out of luck.
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.
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.
Microsoft's business model regarding Windows is to sell an operating system capable of running on as many devices as possible.
Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.
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.
>> Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
> 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.
Here is my corroboration. Apple publishes XNU to the world in this repository:
https://github.com/apple-oss-distributions/xnu
There is no such publication of the GUI frameworks required by macOS programs.
> I do think there is an argument to be made that Win32 was more straightforward ...
I did not make that argument. Instead, the position I hold regarding Windows is:
... an independently derived emulation layer is
possible (not easy, just possible) ...
When an organizational goal is to sell devices, instead of operating system licenses, there is no need to engineer portability within the OS as the target hardware is well-known. This is a luxury MS-Windows never had, as its goal has been to run on as many disparate devices as plausible. Thus the "intrinsic portability" I referenced.
In fact, you have made my point for me:
> ... 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.
* 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.
reply