dramm

Redis’ Trollope reiterated ... [cloud vendors are] free to enter a commercial agreement with Redis.

Senator, you can have my answer now, if you like...

I had sympathy for Redis vs. cloud vendors but the abuse here of folks who have contributed to an open source project, or committed to using something in some part because it was open source, is annoying enough that I now hope Valkey buries them.

Flipper Zero can't unlock cars or anything else with even slightly OK security, but it sure can help detect idiot politicians.

Anthem Insurance staff just following their Claims Manual, Section U.

Had the same t-shirt with the barcode readable source code on it. I think prompted by seeing Greg Rose wear one, may have gotten it from him/mutual friends. As an foreign citizen I was never brave enough to wear it through a USA entry airport.

I need a brain colonic after reading though just some of the mess of overhyped claims in RavenDB marketing and documentation. I appreciate Aphyr doing all this wonderful work and how some of the Raven claims triggered that work. I'd have hoped that anybody building a critical system would have read the mess of Raven documentation/claims/hype and run the other way.

The more Google tries to over-hype stuff the more that keeps giving me a greater impression they are well behind OpenAI. Time to STFU and focus on working on stuff.

OK very nice, but I had brief hope of a home built primary radar featuring a microwave oven magnetron :-)

As employee 10 (or 11, we were not great at counting), I hope folks still there get the fuck out, and go do something productive. Broadcom is a sad sad way for a company to die.

Google Chrome is dead to me. Migrated to Firefox recently. Some learning on the developer tools side, but not looking back.

I'd be more interesting in digging up the corpses of incompetent BBC management from back in the day and prosecuting them than any threat to somebody who has archival content--they ought to be well financially rewarded for protecting that content.

There is no sane way this could ever be expected be received well. What a great way for a CEO to signal their company is desperate.

To be clear GPS does provides high-quality Doppler derived velocity. It's a fundamental output of all GNSS systems, separate from the positional data and certainly not provided by differencing positional data.

---

I suspect much or all of the data boradcast is GPS derived. Would be nice to have some hard data there.

For almost all general aviation aircraft in the USA the data source for ADS-B Out is GPS. All the GA STCs I've seen are GPS only position sources. Many modern GA aircraft will have AHRS but not a full INS, and so INS is not an option for them. Even on larger business jets that may have INS with GPS integration I am not clear any actually use it to drive ADS-B Out, the few installations I've looked at were all GPS.

Boeing was an early advocate for GNSS alone driving ADS-B Out. I think their argument was simplicity, everybody has the same data, and not dependent on erroneous INS or INS settings. I'm not sure what they ended up doing with all their actual installations. If the intent is to send more exotic data such as roll-angle they'll need some INS or at least AHRS integration, but there is no requirement to broadcast that data. The few early third party STCs I saw for ADS-B Out installations in Boeing aircraft only used GPS data sources.

The QHN/Kollsman window setting only affects what is displayed to the wetware. When you strip away all that the autopilot is just servoing to a pressure altitude. But sure if you are flying below the transition altitude and are flying between areas with different QNH settings when you adjust the setting the autopilot will climb or descend as needed because you told it to servo to a different pressure altitude.

There are many EFB (e.g. Foreflight), or log book, or other flight recorders you can use on an iPhone. And some can record the pressure transducer in the iPhone to record an approximate "pressure altitude". e.g. Naviter SeeYou Navigator intended for gliders can do that (but it's not unusual for modern gliders to have an array of sophisticated air data sensors and specialized variometers and flight computers that would feed the app this data over Bluetooth). Popular EFB software Foreflight will not use the iPhone pressure transducer, if you want pressure data there you need to drive that through an external interface like a Sentry ADS-B receiver that has a pressure sensor built into it -- or much better if the aircraft is equipped with ADS-B Out can receive the "own-ship" ADS-B Out broadcast pressure altitude from it's high accuracy encoder). Any in-cabin pressure traducer will be sensitive to the difference between calibrated static pressure and cockpit pressure, things like opening or closing vents, or varying the airspeed significant (and ram air pressure or suction on the cockpit exit vents) can cause observable changes. And when using an iPhone or similar, especially without a great GPS satellite overhead view (e.g. in high wing aircraft) you are likely not to get high-quality GPS altitude data. think best case ~ +/- hundred feet, worse case with little overhead GPS sat view, much worse... but those consumer GPS app is likely to happily display multiple decimal points of precision :-)

Oh sorry I did not think you were disagreeing I was just trying to be clear and more trying to clear up the GPS accuracy/reliability metrics like SIL, NIC, NACp and NACv being broadcast by ADS-B being completely separate to anything to do with pressure derived altitude, I was going down a rat hole and had to edit that several times. And it can be painfully confusing e.g. the failure flag for pressure altitude aka baro altitude in ADS-B speak failure is called NICbaro but has no relationship to the GPS NIC (Navigation Integrity Category) value. And depending on the system some of the GPS accuracy/reliability metrics are just hard coded, and the ones that really matter like NACp are derived from the GPS and SBAS reception.

John Wiseman does great stuff with ADS-B Out data.

Also for pilots/aircraft owners/A&Ps: The FAA PAPR (Public ADS-B Performance Report) https://adsbperformance.faa.gov/PAPRRequest.aspx provide a summary of their aircraft's ADS-B performance, including all the broadcast GPS quality metrics and any reported failure flags etc. The PAPR system will email out the PDF report. The owner/pilot/A&P can reply to that email and request a Google Earth/kmz and Spreadsheet/CSV data for that flight showing all the received ADS-B transmissions including all those accuracy/reliability metrics. Interesting stuff and very useful for diagnosing problems with ADS-B Out installations. So sensitive you'll might see say NACp degrade as an aircraft banks steeply because the GPS antenna now has a view of fewer GPS satellites. Installations in most (non-experimental/non-light sports) aircraft effectively require use of PAPR to formally validate a new installation is working correctly. It's a good thing for owners to also just periodically check their aircraft's ADS-B performance using PAPR. I suggest just before and after each annual inspection for GA/light aircraft.

Pressure encoders, as I said. That's what feeds all aviation altitude data... i.e. anytime you see the word 'altitude' and its not qualified with 'GPS altitude' which is effectively not normally used. ADS-B Out concurrently transmits GPS height about the ellipsoid data as well as pressure altitude data. No use is normally made of the GPS height data. We are discussing pressure altitude data here, that's what aviation works off of. The accuracy and reliability metrics in the ADS-B broadcast you are referencing refers to the GPS data not the pressure transducer/encoder data. In cases of encoder failure being detected a flag is broadcast and the pressure aka baro altitude data field is set to all 0. ADS-B cannot give information about the pressure altitude accuracy or reliability like it does for GPS metrics. It relies on the encoders being better than their +/- 125' accuracy requirement and that's tested for periodically. ADS-B can in principle broadcast 100' or 25' resolution encoders, that info is in the messages. The ones here will be 25'. (I've got a long background with ADS-B related technology, currently helping the FAA out on some niche stuff).

edit: trying to improve clarity/correctness but there is too much to cover here.

“According to this data, the plane’s altitude was only fluctuating by about 20-30 feet. This is more stable than I expected!”

Autopilots are very good and they are servoing to the pressure altitude.

Many pressure altitude encoders used in modern aircraft (for example to drive altitudes that transponders report to SSR radar or via ADS-B) have 25 ft encoding resolution. That 25ft resolution is likely what is being seen here. Other encoders have 10 ft resolution but 25 ft is very common.

Can't wait to get my hands on more of the RTCA standards documents behind aviation equipment/avionics regulations. Instead of having to beg borrow or steal just to be able to provide free help/advice to organizations like the FAA.

Lots of input there from taxpayer funded organizations like the FAA and Mitre and MIT Lincon Labs and us tax payers end up expected to buy it back again...

This expatriate Australian thought the "Ass holes in Australia" was pretty funny.

Oh well, Cloudflare Registrar here I come. And when I next choose a CDN etc. service it won't be from Google.

Or stardate ¯\_(ツ)_/¯

I wonder if there are LLMs with a full set of TAOCP sitting on their bookshelf just to show off. :-)

I stopped buying HP anything. And startups and others I work with I encourage to purchase Brother laser printers. HP is dead to me. Not only this crap, but Brother makes more reliable and better priced/cost of ownership printers.

What a bizzare disjoint article. Bell Labs, Quantum Computing, racial discrimination, blah, blah. There are analogs to Bell Labs today, including in Google and other working on Quantum Computing, and machine learning, and self driving vehicles, and... With one similarity that large (possibly monopoly) financial power allows companies to make these long term expensive investments. If somebody in Nature wanted to opine on Bell Labs like organizations they only need to look at the many examples out there. Sure they will look different but they are there. Why what was written was worthy of being a feature article in Nature Review physics is beyond me.

Tailscale just keeps impressing. Love how simple their product is and how everything they touch just seems so well done.

Ha. I hated that damn AUI connector latch. I remember giving David Boggs grief over that c. 2000? He said he thought it was a terrible mistake as well and I think the reason given was it was something they found/was the easy quick choice.

He is an instructor, that's a non-academic position and does not have tenure. Not having tenure may set him free from Oxford.

Ah now my addled brain finally wakes up, well maybe. What may be happening here is the ADIRU is doing AoA based static port compensation. It will normally be a small correction, and I was trying to keep that out of the discussion because I thought there there have been reports of erratic airspeed in previous Lion Air flights and that was not jiving with small changes of airspeed I was expecting (and now I'm going to reread the Lion Air preliminary report to check what was reported). But to start with you only need 5 knots to trip the IAS disagree, so sure I'll expect it could trigger that (and also possibly an altitude disagree). But potentially more intersting is what does that usually small static compensation change do when the ADIRU thinks the AoA is really out of whack, does it keep applying the "correction" or does it ignore it? So that question circles back to be similar to what Greenspun is asking in the original article.

AoA disagree does not imply airspeed disagree. Indicated airspeed is purely a pitot and static pressure driven measurement. AoA is there largely as part of the anti-stall warning system, e.g. driving the stick shaker/pusher. An important point of having AoA sensors is to provide a stall warning systems that is independent of IAS, you don't want these systems crossed with each other.

B737 airspeed disagree I believe just requires 5 knots disagreement for more than 5 seconds between left/right IAS. No AoA involved.

There may be some confusion happening due to the events in the Lion Air B737 Max. The maintenance crew tried to address what they believed were ADIRU/ADR issues in previous flights... including as a possible source of erratic airspeed indications and airspeed disagree warnings. So there are some discussions of airspeed disagree in relation to that aircraft. There may be a lot going on there we don't know about yet, with say faulty ADIRU/ADR causing multiple problems. The ADIRU has inputs from the AoA vane but does not use that in calculating airspeed, it is using that to drive stick shakers/pushers and optional display AoA, and unfortunately in these cases to also drive MCAS.

Having a AoA disagree indication (and/or full AoA display option) might have allowed more prompt diagnosis of problems, but only if pilots were aware of and trained on MCAS. And even then, yes it's a minor point. I was not intending to claim that itself is a deep solution here, just not having a disagree warning as standard was a bad decision. The entire system, and overall approach taken by Boeing seems tragically deeply flawed.

You seem to be arguing multiple sides here.

Philip Greenspun's speculation is a plausible concern, that is all it needs to be a valuable point, that type of data limit handling ought to be considered as the system is looked at. I read his post that he was talking a specific simple example, all the other types of things you mention could also be looked at. How the AoA sensors failed, any potential issues with signal handling, and especially what happened with the Lion Air AoA sensor repaired in Florida need to be investigated, that sensor repair sure seems to be. (BTW data handling in aviation is pretty interesting,

Greenspun is a fairly unique combination of EE/CS/past MIT lecturer/geek and experienced pilot, including holding an ATP certificate and flying for regional airlines.

The system as implemented could not have a "re-command full-nose down after reset". To start with there is not really a "reset" for MCAS. The pilot's only way to fully disabling MCAS continuing to do bad things is via STAB TRIM cutout switches. The STAB TRIM cutout switches are required to handle lots of other problems. e.g. runaway full nose down trim. The stabilizer trim system itself is a dumb as a rock, and has no idea where the trim should be set to if the power is restored to it. I suspect the only likely sensible behavior of the trim system itself is that it makes no automatic change. If MCAS is driving the trim wrong and if it was possible to remove the MCAS input to the trim system then the pilot should be able to reset the trim they want (with then hopefully functioning electric trim switches), or allow the autopilot to do it (outside of MCAS the A/P is the other automatic system that manages the stabilizer trim). The problem is that was not anywhere in Boeing's plans here, there was no way to separate MCAS going nuts and commanding extreme trim changes, from the actual stabilizer trim system.

However I do agree with your sentiment about (all the other) bad mistakes. In my view when a seemingly largely self-regulated group goes off and designs something with so many glaring issues (single AoA sensor source, lack of documentation and training, not even having a standard AoA disagree alert, etc.) and other possible issues (rationale of extension of MCAS trim authority, trim wheel forces needed to crank mechanical trim at stabilizer trim limits, Boeing slowness in responding to issues etc.) then everything needs to be looked at. My hope is there are very thorough investigations, of the actual systems, of all the proposed remedies (which separately, I am not convinced are enough), of Boeing, and of the failure of FAA oversight here. And I hope that is done as fast as possible, and as slow as really needed.

All submitted resumes will be put on hold for five days and then deleted. :-)