cpgxiii

I don't think that's the problem, at least not directly for us. The immediate interface between the languages is handled by a binding layer (e.g. pybind11 or nanobind), but that rarely lets you fully express object relationships (something that would be more possible without the binding layer) so it is very easy to either not capture ownership (and thus the C++ object is destroyed out from underneath you) or express a cycle that cpython can't understand (and thus the C++ objects are never destroyed and can leak a significant amount of memory). Explicit manual control would avoid that, but at a level of work that would be prohibitive of having extensive bindings in the first place.

Coming from an environment in which we extensively use mixed codebases (C++ and Python) to combine performance and ease of prototyping, one of the pain points is that there is almost always some impedance mismatch between the lifetime/ownership models of the two languages. When something goes wrong here, it's usually a real pain to debug and resolve, and often the resolution involves imposing constraints from one language onto the other (e.g. C++ that would idiomatically use unique_ptr instead needs to use shared_ptr because unique_ptr is essentially impossible to completely capture in Python).

Given the issues involved in mixing languages, there can be cases where sticking with one "good enough" GC'd language and having to write a few performance-sensitive parts in very unidiomatic form to minimize/eliminate GC work is preferable.

Of all the bits of software from big tech companies that I use/encounter, there are very few that I would say are better now than they were a decade ago. If anything, I think most of them were better a decade ago than they are now, and I don't think that's a particularly uncommon opinion. I think there's a good argument to be made that any "rationing" then had a positive effect on software quality (at least when compared to the lack thereof in the "post-rationing" era), and that should be a very cautionary tale that a massive increase in software written by AI tools is likely to result in much worse products.

I don't think the last decade of tech (particularly SV) hiring can in any way be defined as "rationing". If anything, we have seen large software companies grossly over-hire for all of the expected dumb reasons (mostly internal politics) and find themselves in the very predictable situation that more people != more productivity.

The Zhoushan "Completion Center" is not an assembly line - it only handles interior fitment and exterior paint on aircraft that are otherwise fully assembled and have been flown from the production lines in Renton or Everett. The Airbus assembly lines outside the EU perform actual assembly of fuselage and wing components into complete aircraft.

> How many aircraft can the world need that it commonly tops the export chart of the wealthiest country?

Airliners and military aircraft are expensive. Consider that nearly the entire aircraft production capacity of Boeing and Lockheed-Martin as well as the engine production capacity of GE and P&W are booked for years to come. Also, unlike Airbus which has multiple final assembly plants across the world, Boeing only does final assembly in the US.

Because a truly massive portion of managers/leaders in AI-adjacent work are heavily buzzword-driven. "System 1/system 2","agentic <buzzword>", etc; someone in the industry starts using it and then everyone else picks it up, regardless of how much (or little) they understand.

There is no mechanism. Finance and startup Bros want to dump their overvalued companies with deceitful accounting on public investors to make a quick profit and socialize the inevitable losses. SOX makes it harder for them to do that.

To whatever extent SOX compliance makes it more complex to go public, it has no meaningful effect on legitimate successful companies - if you think going public will allow you to raise the most money, you'll go public; if ZIRP meant you could indefinitely raise private money, you'd stay private. Finance and startup bros want to blame companies staying private on SOX, but it has everything to do with either (1) the companies being deeply questionable from an accounting perspective, or (2) the companies being able to raise whatever investments they wanted in private without taking any of the costs of an IPO (e.g. the IPO pop, which could (simplisticaly) be thought of as money being made by the banks underwriting the IPO rather than by the existing owners/investors).

There's a range of DDS implementations, definitely a number that are compatible with embedded and spaceflight applications that don't require dynamic memory allocations. You're going to take a hit on some DDS features, but then again you aren't going to need to handle a large queue of large dynamically-sized messages on some small embedded platform.

I think it's rarely the right choice - most of the hardware I've seen that uses embedded DDS probably should have used plain old UDP instead and then whatever client was running on beefier hardware then handled the translation into DDS - but there are shipping products that use embedded DDS.

Any of the integrated actuators on the market (e.g. Cubemars, zeroerr, myactuator, many more) do proper control and feedback.

In general implementing a weaker memory model (e.g. aarch64) on a stronger memory model (e.g. x86_64 or s390x) is fairly easy, while the reverse is more difficult (see Apple's processors which have a dedicated "stronger" mode to better support execution of translated x86_64 code). It all requires some additional complexity, but starting from a complicated high-performance CISC architecture which already supports a wide range of backwards compatibility modes you are already going to have many of the building blocks on hand to support something new.

The "naive notion of system performance" is that the system is primarily operating in the ideal regime, and thus all deviations deserve alerts (and receive attention). The reality is that often the system is operating often enough in some failure mode that any such alerts would be regularly triggered by accepted behavior, and thus the alerts are systematically ignored/disabled/normalized.

E.g. nominally you should never be mixing traffic types (aircraft and helicopters, civilian and military) in close proximity to a major airport and in a regime where TCAS is unlikely to offer sufficient protection. So in theory, any mixing should immediately trigger an alert and investigation to develop new procedures. But in practice, if you routinely allow such mixing under what you believe are "safe" practices (and get away with such mixing for a long time) then when a real accident happens you will have plenty of "proto-accidents" to look back on, but the warning signs from those near-accidents will have become accepted practice.

Either they believe their own hype and their reliability is a reflection of the real weaknesses of AI coding, or they're complete liars and doing far more traditional SWE than they claim. I think the former case is far more likely and that while they may have hired plenty of senior people from big companies, there's definitely a self-selection for "true believers" in AI coding baked into that hiring process.

To a first approximation, basically no one in the industry does. Users regularly report performance regressions in basically every major piece of software, most of which would have been caught by performance testing.

Indeed, regulation is the only way to protect passengers from market greed here, but the airplane makers play a critical role in what designs they make available to airlines. Airbus and Boeing both like to market their newer designs and interiors in terms of passenger comfort (lower cabin altitude, reduced noise, larger windows, etc) so clearly they (and their customers) understand that passenger comfort justifies spending somewhat more than the bare minimum. And given past designs (and designs still fitted in widebodies) they very much know how to build useful lavatories.

I suspect in time there will actually be safety consequences to the continued downsizing of airplane lavatories. There are already a number of serious incidents that have been caused by fluid leaks from galleys and lavatories (IIRC Quantas came pretty close to losing a 747-400 due to a kitchen leak leading to massive water intrusion into the main electrical/avionics bay - once you end up pouring large quantities of water on your avionics all bets are off about the systems failures that will happen and you are well beyond any backup/redundancy that has been designed in, and during the 60s and 70s the USAF experienced serious corrosion of flight control cables on C-130s due to urine "leakage"). Too-small lavatories basically guarantee that water and urine are going to end up in undesirable locations and at best they will cause expensive interior corrosion and at worst they will cause serious corrosion to the airframe or critical equipment.

Not covered: the inevitable even-smaller lavatory to further insult the dignity of the flying public.

At this point, the designers of narrow-body interiors should be actively shamed for how hostile they have made lavatory designs. In a world in which every major flying population is aging and more overweight, yet every generation of airplane lavatories is even narrower and less accessible for everyone.

> Falklands war shows otherwise.

Well, actually, the Argentinians had no trouble delivering high explosives to UK vessels, but they did have a great deal of trouble getting those explosives to sink those vessels ... mostly because their bomb fuzes were incorrectly set or inappropriate for the delivery profile.

But on a more serious note, none of the ships sunk by air attack in the Falklands were large military vessels. The largest vessel sunk was the Atlantic Conveyor, and that was (1) a civilian cargo ship built to civilian levels of durability, and (2) it was carrying a large quantity of ammunition essentially unprotected (unlike how a large warship would carry it). Even then, the missile strike and fire did not sink the ship immediately. For the largest military vessels sunk by air attack, the two Type 42s Sheffield and Coventry were relatively small destroyers (less than half the displacement of either their USN contemporaries the Spruance/Kidd or a modern Arleigh Burke) and again there the Exocet strike and resulting fire did not sink Sheffield immediately either. The smaller Type 21 frigates lost, Antelope and Ardent, were never really meant to survive meaningful damage and yet both remained afloat overnight before sinking. For comparison, the roughly contemporary USN frigates, the Perry-class (larger in displacement than the Type 42s), survived both Exocet (Stark) and mine (Samuel B. Roberts) strikes.

(The General Belgrano was a larger military vessel lost to submarine attack with, but considering that it was a treaty-limited 44-year-old light cruiser operating unprepared for submarine attack, it is hard to draw too many conclusions about modern ship durability from its loss - and her sisters in the Brooklyn class generally survived quite a punishment in WWII.)

If you look at larger multi-copters, 6 and 8 are quite common since they allow for some redundancy, allowing for safe landing and/or continued flight following the failure of one of the rotors.

As other replies note, 4 is the simplest arrangement mechanically and control-wise, as the control math is quite simple (just rotor speeds/torque) and the only moving parts are the fixed-pitch rotors.

The minimum, as seen in real (and model) helicopters, is either two (approximately) constant-speed rotors with swashplate control, or one (approximately) constant-speed rotor with swashplate control and one tail rotor, either with (approximately) constant speed and variable pitch, or with variable speed. At the scale of real helicopters, two rotors may often be more powerful and efficient (e.g. CH-47, V-22) but the size and weight of the gearbox needed to transmit so much power is a significant contribution to the weight and cost of the helicopter, and thus having a single main gearbox is much lighter and cheaper. The notable difficulties of shaft drive between multi-rotor helicopters, particularly with distributed engines (see a number of V-22 issues) strongly discourages helicopters with more than 2 rotors.

Yeah, clean room implementation is the only way - and the route chosen by the aravis project that builds a FOSS implementation (which is a really great piece of software, way nicer to work with and easier to debug than the terrible vendor SDKs).

Because these bodies want to maintain a moat for the products made by member companies. No more, no less.

A great example of this is the GigE Vision/GenICam standards that are used by basically all machine vision cameras, which were accessible to non-licensees but not usefully implementable (these standards explicitly prohibited their use in implementing any open source implementation of the standards). So essentially all they could be used for were (1) as a licensee producing closed-source software for their own cameras, or (2) you as customer trying to complain to your camera/software vendor that they failed to implement some part of the standard correctly.

> companies don't tend to be in the business of making highly advanced robots

I think you've gotten hung up on the idea that making robots is the essential part of the problem. I'm not going to go as far as much of the ML community and say that making hardware is secondary, but the software side is where most of the latest and greatest work is happening. Better hardware is not going to magically solve all the outstanding problems of manipulation. Better software might solve them entirely independent of hardware so long as the hardware is "good enough". I think there is a general sense that the field that robotics is approaching the equivalent on the mid 2000's with respect to computing architectures - there are still first-party RISC UNIX workstations on the market (e.g. Apple, IBM, Sun) but the incoming tide of commodity x86 platforms is clear for all to see. There are still some gains to be had by designing everything in-house, but the marginal gains versus off-the-shelf components or even full systems are steadily narrowing. There is every reason to believe that COTS hardware capabilities will continue to mature and become more commoditized.

Of course, the purchase here that actually mattered happened several years ago; this headline is just the final piece. BD and Hyundai have been working fairly closely on Altas applications to auto manufacturing for some time, never mind the additional research being done at BDAII/RAII.

> I don't need robotics experience, I need automaker experience. Their software is universally terrible.

If you had any auto industry experience, you would know that the people responsible for the design and build of the physical car and the people responsible for the user-facing software are very separate (in fact, the user-facing software might be entirely contracted out).

> What... positive experience do you have to assume that one of the lowest-tech industries in existence is somehow giving experience with some of the most advanced tech in the world?

You do realize how laughable this position is, commenting on an article about one of the largest automakers in the world buying out the remaining stake in the robotics development company that they already effectively owned. Do you really think that somewhow between owning BD and their partnership with GDM that no-one in the entire corporate structure of Hyundai is aware of the state of the art in robotics?

> Not that it has much to do with why automation fails to penetrate certain tasks. The reason why "long tail" tasks are often beyond automation is: piss poor ROI, calculated correctly.

I actually don't think any of the big automakers have ever really, in-depth considered the ROI of "traditional" assembly automation (i.e. anything SoTA pre-2020), with experts in all parts of the process in same room. It's easy to assume that these companies must make careful measured decisions based on evidence, but in practice big decisions are made by small groups within the C-suite, often pretty divorced from the reality on the ground.

For example, many of the big asian automakers seem to have completely ignored the well-understood effects of their demographic crises (i.e. significantly aging population) on the future of their workforce (i.e. they are having trouble retaining and hiring new workers as the older generation retires) and this totally changes the economics of automation! Now they are all having to play catch-up, having realized that they must automate, at whatever the cost, because the issue is not "robots must be cheaper than human labor" it is "we might not be able to afford human labor at all".

Ford doesn't even make the top 5 - and however "low-tech" you think these companies are is the point, the overwhelming majority of new cars are being built by those "low-tech" automakers. The problem is not the limits of current technology (or even of the state of the art 10 years ago), it is the lack of vision and will within these companies to invest in using it.

> I can’t imagine this would bring much actual experience with this new generation of robotics.

Luckily for you, my job has always been within the robotics research side of the company, so I am very much aware of the strengths and weaknesses of the current technology.

> "Could be in principle" and "could be in practice, under technical and economical considerations in play" are two very, very different beasts. > Everyone in the industry learned that the hard way.

The auto industry is notorious for making incredibly myopic choices to save money/make money in the near term versus long-term investments. The relationship between automakers and their suppliers/vendors is basically a century-plus of the automakers trying to (1) outsource anything they can for a quick buck, and (2) grind the supplier/vendor margins down to nothing. (This is part of why the newer Chinese automakers with much greater vertical integration are such a threat to the traditional automakers; vertical integration has a high up-front investment but the payoff in flexibility and speed is significant).

> How long ago was your robotics experience?

This is over the last decade at one of the largest automakers in the world. Naturally there is significant variation between individual lines and plants; some are newer and more automated, some are older and much less automated. Are some cars being built on more automated lines? Yes. But a great many, probably the vast majority, are being built with fairly low assembly* automation.

* There is a significant split in automation between "body weld" stages and "assembly" stages. Body weld is very heavily automated basically everywhere (although there are some surprising exceptions in places), while assembly is much less automated.

> Everything that could be done by a purpose specific robot arm bolted down to the factory floor is already done by a purpose specific robot arm bolted down to the factory floor.

Hah! Hardly. I say this as someone whose first "real job" was in applying robotics research to automotive assembly - there are still a ton of assembly tasks that could be performed by a fixed-base robot arm, or a robot arm on a linear rail/fixed gantry. Wheeled mobile manipulators are only needed in a few cases, and humanoid form-factor is only "necessary" in very few cases (and I don't think the current crop of humanoids is particularly suited to these tasks).

In my opinion/experience, the impediments are that (1) the system integrators that are usually responsible for assembly-line robotics are too stupid to figure out how to apply robots to the problem, (2) the automakers themselves are often too short-sighted/stupid/unwilling to invest in increased automation (and particularly in building the in-house competency that they really need), (3) the hostile/exploitative relationship between (most) automakers and their main suppliers means that low-hanging improvements to parts/assemblies are a non-starter, and (4) the automaker C-suite (and investors) are too drawn to silver-bullet solutions (e.g. humanoids) than practical automation improvements.

> If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.

All of this is up to the implementation in practice. The codebases I work on generally follow the pattern that exceptions may be thrown but may not be caught*, and thus they practically serve as terminate. And we absolutely get stack traces in our core dumps (Linux, both GCC and clang), and basically all of the complex debugging I do starts with a coredump stacktrace.

* We follow this pattern for a few reasons, (1) it is generally safer for us to assume that libraries we consume (STL included) will behave as expected with exceptions enabled, (2) "don't catch exceptions" (or if you must, catch the as close-to-throw as possible) is a simple way to avoid exceptions-for-nonexceptional-cases control flow, and (3) most of the C++ codebase is exposed through bindings in Python, and propagating errors as exceptions is the only Python-friendly way to handle it.

>> Are we talking HTP+Kerosene or UDMH+N2O4 here?

> I’m thinking kerosene or even methane. UDMH is a toxic mess.

Methane is absolutely out because of pressures/temperatures involved in keeping it liquid for any useful length of time. It would require both significant on-site gas storage as well as a gas compression plant to produce liquid methane on demand, both considerable additional targets (and very fragile ones at that). Kerosene + additives (e.g. RP-1 and JP-8) is the only really viable storable "friendly" hydrocarbon.

In practice, Hydrazine/UDMH + N2O4 is going to be much easier to handle safely than you think (Hydrazine itself is probably safer to handle than Ammonia, and there's a lot of Ammonia handled out there). You fill and seal the tanks at assembly, and outside of rare leaks the handling is fairly benign. Most notably, basically every major military has, as some point in the 20th century, done so - including aboard USN carriers, famously a very skeptical customer from a handling standpoint. Even today, every single F-16 (about 2000 in active service with about 25 operators around the globe) carries Hydrazine in the onboard EPU, and those operators are prepared to service (and handle leaks) safely.

While they aren't pleasant chemicals by any stretch, Hydrazine/UDMH + N2O4, by virtue of its immediate hypergolic behavior, is actually quite well-behaved from a fire/explosion safety standpoint, which is practically a larger concern than toxic fumes (consider how many other things in and around a combat environment can produce toxic gasses). Hydrazine/UDMH + N2O4 ignite promptly on mixing, and thus don't accumulate in an explosive mixture to be ignited later like alternative fuels and oxidizers.

Where exactly is that storability not needed? In the VLS cells of USN warships? In the missile canisters of field-mobile SAM batteries being driven cross-country (which, for survivability on the modern battlefield need to be moving a lot more)?

The only real cases a non-storable SAM/ABM is viable are where the target being protected is so small and so known that (1) all missile infrastructure on/near the target is vulnerable and (2) sufficient advance warning is available to handle liquid fuels as needed. There is really only one case of this: Guam. I think there is a case that a dedicated unique-to-Guam liquid-fueled SAM/ABM farm would go a long way to addressing stockpile and magazine depth concerns.