meet.hn/city/37.0481715,-112.5285237/Kanab
- I’m not sure I agree. Not sure I disagree, either. If I’m another pilot in the air when this occurs, it feels like the most important things for me to know are (1) stay the hell away from the runway, and the announced approach, for a while; (2) only a single aircraft is doing an emergency autoland currently; (3) assume that the aircraft will need medical response while on runway (no auto-taxi) so if I was planning on landing in the next half hour or so, go to alternate. (1) and (3) are well covered, but (2) is subtle — /today/, the chance of two aircraft doing an emergency autoland at the same field at the same time is negligible, but it’s still something both I and the system designers need to think about.
- > Once you’re on public roads, you need to ALWAYS fail-safe.
Yes.
> And that means not blocking the road/intersections when something unexpected happens.
No. Fail-operational is not the only allowable fail-safe condition for automobiles. For example, it is acceptable for loss of propulsion to cause stop-in-lane — the alternative would be to require high-availability propulsion systems, or to require drivers to always have enough kinetic energy to coast to side. This just isn’t the case.
One can argue that when operating a fleet with correlated failure modes the rules should change a bit, but that’s a separate topic.
- This is not how communication is done in aviation. Instead, it’s common to abbreviate to the last three alphanumerics of tail numbers (so “niner alpha bravo” for N789AB) after the first call — but this is conditional on not having a potentially confusing other aircraft on frequency (N129AB), and the system here can’t reasonably know that, so must take the conservative option.
- > I’m not sure exactly what the concerns are, nor why Qualcomm deserves any shade.
Yeah, the missing subtext here is the opinions of the folks who have worked with Qualcomm’s (software) org and products professionally. They’re… not beloved.
- > Why count bytes when you can just... not?
The amount of memory used defines the size of the state space of the system — with exponential growth in the number of representable states. The amount of testing needed to have confidence in the behavior of a system grows (and I’d state based on experience, but without proof, grows faster than logarithmically) with the size of the state space. Building smaller, simpler systems is still the key to being able to realistically test and define behavior at high confidence levels, regardless of the price of a bit.
- To beat it, not to solve it. Solving means something very specific in the context of games — deriving and proving a GTO strategy.
- An IDE, by name, integrates the development environment. Depending on target, development lifecycle usually includes writing code, generating binaries, pushing those binaries to the target, executing on the target, and debugging on the target; so an IDE includes editing, compiling, linking, device/JTAG drivers, and debugging, in my mind. I suppose for platforms without cross-compilation the device drivers vanish, and for languages without compilers and linkers similar; but at a minimum, development means both authoring and debugging code, and so an IDE must provide an integrated view of the debugging process.
- > why
> should
I don't know if "should" is intended as a moral statement or a regulatory statement, but it's not at all unusual for server operators to need to comply with laws in the country in which they are operating…
- > As for electric, I would guess it's zero?
Yes, exactly [0].
- Can you give an example? I see RISC-V being used to replace custom 16 and 32 bit cores, and M0-class ARM cores, in the 10k+ gate range, but haven't really seen a migration in the 8 bit space.
- Except that if you're in country B, which has a law that says "you may not make information available to children that discloses that Santa Claus is made up," and the age of becoming an adult in your country is 18 -- knowing that a person accessing your site from country A is an adult in country A (which means, say, ≥ 16) is not sufficient to comply with the law.
- Or like it's 2025. Plenty of current-production parts using an 8051 core as either their main sequencer, or as a low power core with bigger options on the main power rail.
- An anytime algorithm monotonically improves some evaluation metric. For a sort, the evaluation metric is usually the number of inversions in the list. At completion, there will be zero inversions. If at time 0 there are N inversions, then at time 0 < t < completion time there will be ≤ N inversions; that is, the list is "more sorted" than it was before. As the various examples about games and animation elsewhere in the comments show, this can be interpreted as "somewhat smoothly moving towards sorted over time," which is an (occasionally) ((rarely)) useful property.
- The article, and many of the responses, are hinting at the fact that bubblesort is an example of an anytime algorithm. This is a wide class of algorithms which provide a correct answer after some amount of time, but provide an increasingly good answer in increasing amounts of time short of the completion time. This is a super valuable property for real time systems (and many of the comments about games and animations discuss that). The paper that introduced me to the category is "Anytime Dynamic A*" [0], and I think it's both a good paper and a good algorithm to know.
- > I don't remember reading any Clarke short stories
Stop what you’re doing and read The Star.
- A more everyday example is the Hexagon DSP ISA in Qualcomm chips. Four-wide VLIW + SMT.
- > All that means is that 10 years ago you had to rely on humans to write the code that today can be done more safely with auto generation.
No. It means more than that. There's a cross-product here. On one axis, you have "resources needed", higher for code gen. On another axis, you have "available hardware safety features." If the higher resources needed for code gen pushes you to fewer hardware safety features available at that performance bucket, then you're stuck with a more complex safety concept, pushing the overall system complexity up. The choice isn't "code gen, with corresponding hopefully better tool safety, and more hardware cost" vs. "hand written code, with human-written bugs that need to be mitigated by test processes, and less hardware cost." It's "code gen, better tool safety, more system complexity, much much larger test matrix for fault injection" vs "human-written code, human-written bugs, but an overall much simpler system." And while it is possible to discuss systems that are so simple that safety processors can be used either way, or systems so complex that non-safety processors must be used either way... in my experience, there are real, interesting, and relevant systems over the past decade that are right on the edge.
It's also worth saying that for high-criticality avionics built to DAL B or DAL A via DO-178, the incidence of bugs found in the wild is very, very low. That's accomplished by spending outrageous time (money) on testing, but it's achievable -- defects in real-world avionics systems overwhelming are defects in the requirement specifications, not in the implementation, hand-written or not.
- I’m sorry, but I disagree. Building these real-time safety-critical systems is what I do for a living. Once the system is designed and hardware is selected, I agree that if the required tasks fit in the hardware, it’s good to go — there’s no bonus points for leaving memory empty. But the sizing of the system, and even the decomposition of the system to multiple ECUs and the level of integration, depends on how efficient the code is. And there are step functions here — even a decade ago it wasn’t possible to get safety processors with sufficient performance for eVTOL control loops (there’s no “just spec a faster chip”), so the system design needed to deal with lower-ASIL capable hardware and achieve reliability, at the cost of system complexity, at a higher level. Today doing that in a safety processors is possible for hand-written code, but still marginal for autogen code, meaning that if you want to allow for the bloat of code gen you’ll pay for it at the system level.
- It’s also much, much more resource intensive (both compute and memory) than what a human would right for the same requirements.
SoCs with on-die memory (which is, these days, exclusively SRAM, since I don't think IBM's eDRAM process for mixing DRAM with logic is still in production) will not be effected. SiPs with on-package DRAM, including Apple's A and M series SiPs and Qualcomm's Snapdragon, will be effected -- they use the same DRAM dice as everyone else.