cpgxiii

No, if a process allocates an infeasible amount, malloc fails and the process needs to deal with the failure (which is what already happens, "malloc doesn't fail on Linux" is only really true for smaller-than-page-size allocations). The point being made is that the system should account conservatively for all memory that can be used, not just the optimistic underestimate that overcommit enables (i.e. the plane should always carry enough fuel for contingencies, and landing with extra fuel is a good outcome).

> And I'm sure bipedal walking was also basically solved in the 1980's.

It isn't even efficiently solved now, in the general case. Bipedal walking on approximately flat surfaces with minimal geometry constraints is basically solved, but complex terrain and/or constraints on foot placement require slower methods that wouldn't really be considered "solved".

Not necessarily. Depending on angle and water depth, multi-return LIDAR can give you returns from both water surface and the road surface beneath, in the same way multi-return LIDAR can produce returns from vegetation and the ground beneath.

> The FDA's approval process is stymied by a CYA culture that fails to adopt the risk profile it needs to in order to potentially save large contingents of sick and dying.

Except the history of FDA approval here is that it has been too accepting of drug candidates for Alzheimers with very weak evidence of efficacy and serious side effects. This particular field would probably be better off if the FDA took a harder position on efficacy, rather than deferring to drug companies and patient/caregiver groups that desperately want something.

The depressing part is that these "modern practices" were essentially invented in the 1960s by defense and aerospace projects like the NTDS, LLRV/LLTV, and Digital Fly-by-Wire to produce safety-critical software, and the rest of the software industry simply ignored them until the last couple of decades.

Developers of "IR" seeking missiles have been trying to distinguish between aircraft and countermeasures since the very beginning. I say "IR" because the first really robust countermeasure-avoiding seekers were dual-band IR+UV and have been around for decades. IR+UV is useful because making a decoy that looks like jet exhaust in both IR and UV is quite difficult. Imaging "IR" is a bit more capable, particularly for all-aspect use, but once again this has existed for decades.

Imodium also does wonders for slowing things down and avoiding bowel movements, provided you use it carefully and infrequently such that you don't totally mess up your normal gut functioning.

Almost all of the complexity of PoE is fundamental. To get enough power over 100m of ethernet cable (10x longer than USB) you have to run at much higher voltages like 48V. The same has eventually come to USB: for USB-C Pd to reach 240W, it also has to use 48V.

There have long been lower-voltage "passive PoE" systems which expect a lower always-on voltage on some of the ethernet pairs (usually 12V, 24V, or rarely 48V), which can be very easy to implement so long as your users can handle the setup and incompatibility with other ethernet devices (in the most extreme case of passive PoE on 100Mb/s ethernet, you simply connect the positive pair to the input of the device and the negative pair to the ground, no additional hardware needed).

Multidrop SPE isn't going to outperform newer CAN versions though. Somewhere in the sub-100Mb/s (e.g. 10-20Mb/s range) is the practical maximum speed of a multidrop bus at useful lengths, and that essentially applies equally to CAN or SPE. The only way to really get faster in a "multidrop-like" sense is with logically loop-like systems like ethercat and Fibre Channel where each network segment is point-to-point and the nodes are responsible for the routing.

There are several different levels of ballistic missiles.

ICBMs, for which the GBI is intended, are the most challenging to defend against and show the least interceptor success.

In contrast, we do have some pretty definitive evidence that theater and "lower" MRBM/IRMB ballistic missiles can be intercepted successfully. If you define "effective defense" as "most missiles that would cause damage are intercepted", then it is clearly possible with current technology. If you define "effective defense" as "all missiles are intercepted", then it remains beyond the current technology.

> "well we were hit with a wild tsunami and doubled the nominal price tag of the cleanup with no obvious loss of life or limb"

This is a bit of a wild understatement. (1) the tsunami was by no means wild, as multiple posts here have referenced, and (2) the incident resulted in a number of significant injuries, not including for deaths involved in the evacuation. And those deaths very much count - you can't hand-wave away the consequences of the evacuation on the basis of hindsight that the evacuation was larger than the final outcome necessitated.

> Caveating that I'm not really sure it was even an out-of-design event but if it was then it is case closed and the swiss cheese model is an inappropriate choice of model to understand the failure.

This is not how safe systems are designed and operated. Safety is not a one-time item, it is a process. All safety-critical systems receive attention throughout their operating lives to identify and mitigate potential safety risks. Throughout history, many safety-critical systems have received significant changes during their operating lives as a result of newly-discovered threats or recognition that threats identified during the initial design were not adequately addressed. Many (if not most) commercial aircraft have required significant modifications to address problems that were not understood at the time they were initially built and certified. Likewise, nuclear power plants in many countries have received major modifications over the years to address potential safety issues that were not understood or properly modeled at the time of their design. Sometimes, this process determines that there is no safe way to continue operation - usually that there is no economically viable way to mitigate the potential failure mode - and the system is simply shut down. This has happened to a few aircraft over the years, as well as several nuclear power plants (in many cases justified, in others not so much).

Fukushima existed in just such a system, and that the disaster occurred was the result of failures throughout the system, not a one-off failure at the design stage.

> I mean, ok. So say they build the plant 35m higher up, then get hit by a tsunami that is 36 meters higher [0] than the one that caused the Fukushima disaster? If we're going to start worrying about events outside the design spec we may as well talk about that one. If they're designing to tolerate an event, we can pretty reliably imagine a much worse event that will happen sooner or later and take the plant out. That is the nature of engineering.

I think you are missing the point. Obviously it is possible that a tsunami higher than any possible design threshold could occur (it is, after all, possible that an asteroid will strike in the pacific and kick up a wave of debris that wipes everything off the home islands). However, the tsunami that struct Fukushima Daiichi was no higher than a number of tsunamis that were recorded in Japan within the last century. The choice of DBA tsunami height was clearly an underestimate, and underestimates were identified for Fukushima and other plants prior to the accident but not acted upon. This was not a cases of "a bigger wave is always possible", it was a case where the design, operation, and supervision were wrong, and known (by some) to be so prior to the accident.

> It isn't a swiss cheese failure if it was hit by an out-of-design-spec event

First of all, the design basis accident is a design choice by the developers of the plant and regulators. The decision process that produced that DBA was clearly faulty - the economic and social costs of the disaster so clearly have exceeded those of a building to a more serious DBA.

> Again I'm going from memory with the numbers but doubling the cost of a rare disaster in a way that injures ... pretty much nobody ... is a great trade for cheap secure energy. It isn't a clear case that anything needs to change or even went wrong in the design process. Massive earthquakes and tsunamis aren't easy to deal with.

This is absolute nonsense. For the cost of maybe maybe tens of millions at most in additional concrete to build the seawall a few meters higher, the entire disaster would have been avoided entirely (i.e. plant restored to operation). With backup cooling that could have survived the tsunami (a lower expense than building a higher seawall), all that would have happened at Fukushima Daiichi is what happened at its neighbor Fukushima Daini (plant rendered inoperable, no meltdown, no significant radioactive release). Instead, we are talking about a disaster that will cost a (current) estimated $180 billion USD to clean up (and there is no way this estimate is realistic, when the methods required to perform the cleanup barely exist yet).

In reality the "swiss cheese" holes for major accidents often turn out to be large holes that were thought to be small at the time.

> [Fukushima] No small alignment of circumstances needed.

The tsunami is what initiated the accident, but the consequences were so severe precisely because of decades of bad decisions, many of which would have been assumed to be minor decisions at the time they were made. E.g.

- The design earthquake and tsunami threat

- Not reassessing the design earthquake and tsunami threat in light of experience

- At a national level, not identifying that different plants were being built to different design tsunami threats (an otherwise similar plant avoid damage by virtue of its taller seawall)

- At a national level, having too much trust in nuclear power industry companies, and not reconsidering that confidence after a number of serious incidents

- Design locations of emergency equipment in the plant complex (e.g. putting pumps and generators needed for emergency cooling in areas that would flood)

- Not reassessing the locations and types of emergency equipment in the plant (i.e. identifying that a flood of the complex could disable emergency cooling systems)

- At a company and national level, not having emergency plans to provide backup power and cooling flow to a damaged power plant

- At a company and national level, not having a clear hierarchy of control and objective during serious emergencies (e.g. not making/being able to make the prompt decision to start emergency cooling with sea water)

Many or all of these failures were necessary in combination for the accident to become the disaster it was. Remove just a few of those failures and the accident is prevented entirely (e.g. a taller seawall is built or retrofitted) or greatly reduced (e.g. the plant is still rendered inoperable but without multiple meltdowns and with minimal radioactive release).

> Native code can already be multi-threaded so if you are using Python to drive parallelized native code, there's no win there.

When using something like boost::python or pybind11 to expose your native API in Python, it is not uncommon to have situations where the native API is extensible via inheritance or callbacks (which are easy to represent in these binding tools). Today with the GIL you are effectively forced to choose between exposing the native API parallelism or exposing the native API extensibility; e.g. you can expose a method that performs parallel evaluation of some inputs, OR you can expose a user-provided callback to be run on the output of each evaluation, but you cannot evaluate those inputs and run a user-provided callback in parallel.

The "dumbest" form of this is with logging; people want to redirect whatever logging the native code may perform through whatever they are using for logging in Python, and that essentially creates a Python callback on every native logging call that currently requires a GIL acquire/release.

Could some of this be addressed with various Python-specific workarounds/tools? Probably. But doing so is probably also going to tie the native code much more tightly to problematic/weird Pythonisms (in many cases, the native library in question is an entirely standalone project).

> The only thing that free threading gives you is concurrent mutations to Python objects, which is like, whatever.

The big benefit is that you get concurrency without the overhead of multi-process. Shared memory is always going to be faster than having to serialize for inter-process communication (let alone that not all Python objects are easily serializable).

> That cleanup can be explicit when needed by using context managers.

It certainly can be, but if a large part of the Python code you are writing involves native objects exposed through bindings then using context managers everywhere results in an incredible mess.

> Mixing resource handling with object lifetime is a bad design choice

It is a choice made successfully by a number of other high-performance languages/runtimes. Unfortunately for Python-the-language, so much of the utility of Python-the-ecosystem depends on components written in those languages (unlike, for example, JVM or CLR languages where the runtime is usually fast enough to require a fairly small portion of non-managed code).

> Having to have thread safe code all over the place just for the 1% of users who need to have multi-threading in Python and can't use subinterpreters for some reason is nuts.

Way more than 1% of the community, particularly of the community actively developing Python, wants free-threaded. The problem here is that the Python community consists of several different groups:

1. Basically pure Python code with no threading

2. Basically pure Python with appropriate thread safety

3. Basically pure Python code with already broken threaded code, just getting lucky for now

4. Mixed Python and C/C++/Rust code, with appropriate threading behavior in the C or C++ components

5. Mixed Python and C or C++ code, with C and C++ components depending on GIL behavior

Group 1 gets a slightly reduced performance. Groups 2 and 4 get a major win with free-threaded Python, being able to use threading through their interfaces to C/C++/Rust components. Group 3 is already writing buggy code and will probably see worse consequences from their existing bugs. Group 5 will have to either avoid threading in their Python code or rewrite their C/C++ components.

Right now, a big portion of the Python language developer base consists of Groups 2 and 4. Group 5 is basically perceived as holding Python-the-language and Python-the-implementations back.

> In practice CPython reliably calls it cuz it reference counts ... In a world where more people were using PyPy we could have pressure from that perspective to avoid leaning into it

A big part of the problem is that much of the power of the Python ecosystem comes specifically from extensions/bindings written in languages with manual (C) or RAII/ref-counted (C++, Rust) memory management, and having predictable Python-level cleanup behavior can be pretty necessary to making cleanup behavior in bound C/C++/Rust objects work. Breaking this behavior or causing too much of a performance hit is basically a non-starter for a lot of Python users, even if doing so would improve the performance of "pure" Python programs.

The point is that almost all of the signatories considered themselves to be immune to a "real war" in their futures at the time they signed. E.g. basically all of the European signatories assumed that the end of the cold war and existence of NATO would ensure the end of any possible threat. Given that assumption, as obviously flawed as it was, signing on to a ban was cheap PR (literally cheap, too, because it meant they could divest those weapons and their delivery mechanisms to reduce defense expenditures).

I think the story is a bit more complicated. Core succeeded precisely because Intel had both the low-power experience with Pentium-M and the high-power experience with Netburst. The P4 architecture told them a lot about what was and wasn't viable and at what complexity. When you look at the successor generations from Core, what you see are a lot of more complex P4-like features being re-added, but with the benefits of improved microarch and fab processes. Obviously we will never know, but I don't think you would get to Haswell or Skylake in the form they were without the learning experience of the P4.

In comparison, I think Arm is actually a very strong cautionary tale that focusing on power will not get you to performance. Arm processors remained pretty poor performance until designers from other CPU families entirely (PowerPC and Intel) took it on at Apple and basically dragged Arm to the performance level they are today.

If you look at the V-22 safety record in the context of the level of technical development, it is pretty good (e.g. compare to helicopters and aircraft from the 60s). The first production generation of a brand new type of vehicle is always going to be complicated, and virtually all of the V-22 mishaps come from the "new" components and procedures.

The fundamental tradeoff with tiltrotor platforms is that you trade significantly increased speed for significantly increased complexity. What that means is your battlefield survivability goes up when dealing with any opponent with meaningful air defenses, but at the cost of increasing your "resting" accident rate when most peacetime accidents are consequences of maintenance and/or procedural issues.

Because Sikorski can't make them work. Sure, they can take off and fly fast in a straight line, but they haven't been able to demonstrate sufficient maneuverability due to vibration problems in the rotor head. They are also very tall, prohibitively so for existing shipboard hangar, which would otherwise seem to be their advantage over tiltrotor platforms.

I think you're missing my point entirely. If your project needs specific hardware, you have to use that specific hardware (the obvious examples of which would be Jetsons or Zynq/Zynq-like or something ASIL-D or something that tightly couples "A"/M/R cores together, or you are stuck using a SoC from Qualcomm for cell connectivity). There are a lot of projects that do fall into that category.

There are also a (much smaller) number of projects that will legitimately see the kind of scale of production that justifies aggressive cost optimization for the compute platform, either in terms of designing their own around a SoC or picking some SBC/SoM that they can get a good deal on, where the significant additional up-front engineering cost is outweighed by the production savings (and where the desire/need to keep a fixed platform means the often limited platform support from the vendor is less restrictive).

But a large number of robotics projects (basically everything in the research sphere) - this one very much included - just need "some computer" for general-purpose use. They are already separating realtime control onto a separate microcontroller board. For these projects, it is almost always committing a "premature pessimization" of picking some weird SBC. You are signing up for worse CPU and GPU performance, stability, and development future for very little reward.

There are a variety of x86 products with Coreboot support, if what you are looking for is firmware openness. If what you are looking for is PCB design openness, the options are much fewer, but at that point you are probably optimizing for an overly niche objective.

> Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)

I appreciate the idea, but this is essentially saying "this project will prioritize a specific choice of one (core) piece of hardware to the detriment of everything else, users included". Approximately none of your potential users are going to benefit from the "openness" of the SBC versus that of a more broadly-supported platform (I say "openness" because the reality of SBCs is that actually finding a usefully performant one that is completely blob-free is almost impossible). Open hardware means very little if it isn't running an upstream kernel and userland.

You probably aren't using some weird SOM, though. There is a bit of an unstated exception of "unless said SBC/SOM has specific hardware that is necessary/particularly valuable for your product/project". For example, if you need GMSL you are probably not going to be picking Intel, even though ADL-N and the bigger processors support MIPI, simply because no one else does and the documentation/support for it is basically nonexistent. Designs with closely-coupled A/M/R cores, or CPU/MCU/FPGA hybrids like Zynq would be others.

But generally projects which are choosing some random SBC aren't using any of these features, and are just suffering the pain/imposing it on their users for no good reason.

> The hardware is built around a stackable 10×10cm compute module with two ARM Cortex-A55 SBCs — one for ROS 2 navigation/EKF localisation, one dedicated to vision/YOLO inference — connected via a single ethernet cable.

I will preface this by saying that I have nothing against ARM per se, that my employer/team supported a good chunk of the work for making ROS 2 actually work on arm64, and that there is some good hardware out there.

I really don't understand why startups and research projects keep using weird ARM SBCs for their robots. The best of these SBCs is still vastly shittier in terms of software support and stability than any random Chinese Intel ADL-N box. The only reasons to use (weird) ARM SBCs in robots are that either (1) you are using a Jetson for Jetson things (i.e. Nvidia libraries), or (2) you have a product which requires serious cost optimization to be produced at a large scale. Otherwise you are just committing yourselves and your users/customers to a future of terrible-to-nonexistent support and adding significantly to the amount of work you need to bring up the new system and port existing tools to it.

Because the only signal the Trump administration responds to is "market goes down".

> There are four pair of wires in the cable. If you use all of them for TX, you can't receive.

No, you absolutely can use them all for transmit and receive at the same time. The device at each end knows what signal it is transmitting, and can remove that from the received signal to identify what has been transmitted by the other end.

This is the magic that made 1000Base-T win out among the candidates for Gige over copper, since it required the lowest signaling frequencies and thus would run better over existing cables.

It's both. Anything that you effectively have optimized to the details of its environment will end up dependent on that environment. If that environment is the real world, then it's fine. If that environment is a simulator, now you have sim-to-real problems.

There's always going to be a gap between reality and simulation, because simulation fidelity has an incredibly long tail. "Digital twins" are relatives, not identical replicas, because everything about capturing the real world for simulation involves simplification and discretization and abstraction.

Because "brand new" doesn't mean devoid of context. Within your domain, there will still be common libraries, interfaces, and tools.

C++ is very flexible, with a lot of very mature tooling and incredibly broad platform support. If you're writing some web server to run on the hardware of your choosing, then sure, that doesn't matter. But if you're writing something deeply integrated with platform/OS interfaces, or graphics, or needs to support some less common platforms, then C++ is often your only practical option for combining expressiveness and performance.