cpgxiii

"Crews can't stop sweating on the flight deck" is exactly like saying "the middle east is hot and people sweat in the sun there". It has very little to do with the ships and everything to do with a climate that is hot (which, rather obviously, effects almost everyone in the region). If you want an actual example of a meaningful operational problem cause by a warship not suited to operations in hot waters, see the Type 45 (and even that is finally being fixed).

> That's just another way of saying what I said: they can't operate at close range and must instead use stand off weapons instead of, say, gravity bombs.

It really isn't. Outside of rare cases where mid-air refueling is unavailable, standoff weapons are used to reduce exposure to enemy air defense, not to increase range. Your airwing uses exactly the same gravity bombs to strike a target 10 miles from the carrier as they do at 50 miles or 100 miles or 200 miles.

Satellite launch is so much easier than storable SAM/ABM, the comparison is not really useful.

There are a bunch of other problems with this comment, but this part in particular is laughably wrong.

> Our ships are designed to operate in the Pacific or North Atlantic, not the Persian Gulf.

Nearly every type of ship in the USN has spent considerable deployment time in the Persian Gulf. They are absolutely "designed" for deployment there. What "prevents" their deployment there is that it does not make tactical or strategic sense to put highly capable warships during a war in a tiny waterway when said warship is capable and effective at operating from outside said tiny waterway. Put a CBG in the Persian Gulf and it becomes just about as expensive to defend as an air base on land (much more so, given the logistics involved). That same CBG operating in the Indian Ocean against the same targets has tens of thousands of square miles in which to operate and avoid detection and attack, and never need to fire a missile in self-defense.

The munitions that (1) are currently solid-fueled and (2) represent a stockpile depletion issue are all SAM/ABM interceptors. The only new liquid-fueled missiles worth the development effort are a liquid-fueled ramjet equivalent to the MBDA Meteor and air-breathing hypersonics.

> It’s saying we can do that faster than we can get another AP production facility online

Oh boy, have you seen how long SAM/ABM development takes? The critical munitions that actually need to be designed here would be liquid-fueled equivalents to THAAD, PAC-3, SM-2, SM-3, and SM-6. Not yet-another-cruise-missile which is already liquid-fueled.

Famously, of course, not at all the case, with Enterprise, Saratoga, and Ranger all surviving. Yes, losses of pre-war carriers were severe (Lexington, Yorktown, Hornet, and Wasp).

Anyone who describes hydrocarbon fuels and high-test peroxide oxidiser as a stable and proven combination is a charlatan trying to sell you something questionable. If you want a proven liquid fuel combination that works in missile environment conditions with well-behaved ignition, Hydrazine/UDMH+N2O4 is the king.

Solids are better from a storage and deployment standpoint in almost all cases; anyone making a sincere case for liquid fuels should be making it on the basis of munitions that are best designed around them (notably, of course, most of the long range cruise missiles that have received the most hand-wringing about stockpile depletion are already air-breathing jet-fueled). The actual stockpile issues wrt solid rocket fuel are high-performance SAM/ABM interceptors, and those would require complete redesigns to make liquid-fueled equivalents.

The DGX Spark/GB10 has CPU cores from Mediatek (in a pretty odd cluster configuration, too).

The reality of robotics is that the existence of the theory often means little about practical feasibility. I have myself joked about problems being solved in the '80s, but the joke is really something closer to "all of the interesting problems in planning and control were solved in the' 80s and known to be intractable", because the theoretical complexity is just prohibitive.

The last 40 or so years haven't really moved the needle on theoretical complexity, but we have developed new methods and improved existing methods (and also computers have gotten massively better) such that a much larger subset of the problem space is actually practically solvable. Even still, it is almost trivially easy to go from a practically-solvable problem to a practically-unsolvable one, and much of the confusion that exists in the popular understanding of robot capabilities is the result of the solvable/unsolvable line being so close and subtle.

On the topic of bipedal (and quadrupedal) locomotion, I think you could actually argue that we very much do not understand how to solve the problem, and exhibit #1 is that basically everyone (Boston Dynamics included) is giving up on MPC-based control and adopting RL-based controllers which seem to work better but are much less comprehensible from a theory standpoint.

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.