The F-35 is going to be alright. It's overly complex because they tried to jam too many missions into it, and that led to cost overruns and delays, but a lot of the anti-F35 stuff is kinda dumb and overhyped.

Honestly, the defense is so bad at procurement that they tend to put contractors in the position of trying to fight for better value.

Nothing that flies with as much software as the F35 will ever be alright

I'm going to be pedantic simply because you've already admitted to being so yourself, but also you keep bringing up Boeing. The boosters they were talking about are made by ATK, not Boeing (ULA at this point for spacecraft), and certainly not Rockwell. ATK is the ******* that keeps forcing the US to use solid-fueled rockets on manned flights (hint: the rest of the world wouldn't dare do that), and is so entrenched in the MIC that NASA can't fight them. You know, just to be pedantic.

This block? Not very, they're old tech. In the future? Fairly. Comparing Falcon 9 cores to SRB from the Shuttle program is very much an apples to oranges thing. You can't refuel an SRB, much like you can't refuel a bottle-rocket. As long as a Falcon core comes back without extreme thermal trauma, you can refuel it and relaunch it. As long as it's from a Falcon block that was designed to do so (AFAIK, these weren't).

Also, I'm aware ATK advertised the SRB as a reusable system, but after prying out all reusable steel from the shell of an SRB, you're basically remaking the damned thing from scratch at that point.

Rockwell designed the space shuttle, Boeing bought them in 2001.

This is very true. But the actual Shuttle is just one of 3 parts of the SLS. The solid boosters are another (the external fuel tank being the third). Those were made by ATK, which is the firm that basically makes everything from most airbags in the world, to the rocket motors on missiles and ejection seats. NASA never wanted them involved, but congress wouldn't fund the shuttle program without pandering the USAF requirements, which meant ATK would be involved. If not for that, the Shuttle would have had LFR boosters like the later Soviet Buran design.

He asked about the boosters, I was bringing up Boeing/Rockwell had nothing to do with them.

It's like in the cancelled Constellation program. Boeing presented the Orion. Boeing partnered with Lockheed and formed ULA for spacecraft. ATK was the company building the Ares rocket that would carry Orion.

Rockwell had the contract to manufacture the orbiter, but it was my understanding that they designed the shuttle as a whole.

They designed the orbiter after the OMB laid out requirements for the SRBs to be involved in the program. Thiokol (ATK) designed the SRBs, and Martin Marietta (Lockheed) designed the external tank.

https://www.sfgate.com/business/article/Elon-Musk-promises-frozen-yogurt-roller-coaster-10966087.php

When building a roller coaster is preferred to making concessions to your workers

It'll eventually work with enough delays. Automotive software development is pretty horrific (see the Toyota unintended acceleration case) but cars generally get down the road.

Defense systems development is likely better than automotive development in terms of testing coverage and overall paranoia. I expect that there are teething problems with moving to a higher level language like C++, especially from a system design perspective.

It’s basically process finger-wagging and MC/DC adequacy, versus a voluntary but statically verifiable coding standard. Technically they do more about software quality, but only because the government at least forces them to talk about it. But they’re still doing almost nothing.

Uncontrolled acceleration is the worst possible failure mode for a car. Any other failure mode, the occupants are most likely safe. Windows roll back up on their own, parking brake won’t disengage, car alarm won’t turn off... if you haven’t encountered these bugs yourself, you won’t ever hear about them. Fighter jets not only have more failure modes, but none of them are acceptable.

You've never worked in defense. This whole narrative your spinning isn't just wrong, it's dumb. The defense industry has major issues but it doesn't fall into the "bad rent seeking capitalists trying screw every one over." It's a lot more involved than that. There are all sorts of different incentives from different directions that make the whole thing weird and crappy.

The f-35 has about an order of magnitude less code than a modern car, and a lot more effort is put into dealing with it. Fighter jets are also a hell of a lot more mechanically complex than cars as well. Physical complexity can be just as challenging as software complexity, especially on aircraft. The bottom line is that it's simply hard, but with enough money and time it has and will continue to be made to work. With good system design, not all faults are catastrophic. I expect that the flight control law implementation is tested to a properly anal degree before they load it onto an actual plane. A lot of the other stuff can be tested on the ground on real hardware, and won't crash the plane if it goes wrong.

I don't even know what you mean about not using a verifiable coding standard. If you use MC/DC, you pretty much have to use a very rigid coding standard just to make the testing possible. I also guarantee that they have zero wiggle room as to what methods are used for software quality control. That would have all been baked into the contract by government people who have a very strong bias toward "the way we've always done it".

You're correct, I haven't worked in defense. I've worked in software quality tooling and test instrumentation - static analysis, test coverage analysis, stuff along those lines. Those incentives you're talking about are a big part of why I refuse to work in that industry anymore. Despite your skepticism I do have specific reasons for my opinion (I just can't talk about them).

This metric is not meaningful. How much of it is safety critical? What's the state size? What's the cyclomatic complexity?

A tersely written RTOS has much less code than an Android/Java entertainment system, but the former is both much more complicated code and much more likely to kill people.

Also meaningless. Digging a trench with a teaspoon is a "lot more effort" than a backhoe. And, sure, you're "dealing" with the trench problem, but that doesn't mean you're effective, that you chose a good approach, or that you'll be done any time soon.

It's not even a problem of motives, it's a problem of combinatorics. There is no known way to write quality software. Formal methods come closest, but they only prove that your code does what you've proven it to do. They aren't any help for specification bugs, which are responsible for most deadly software failures. Anything else we want is either undecidable or requires factorial time and space. There isn't even a good way of measuring software quality. Test suite adequacy (100% coverage), for example, does not mean your code is tested well. I happen to know for a fact that irrelevant tests (i.e. folks testing "for coverage" but not actually testing anything) is a big nuisance for defense companies; if anybody can build a viable mutation testing product they're going to make a fortune from defense, but for now it's not possible. And neither is writing good quality software.

If LM, Raytheon, Boeing had some software quality secret sauce, they wouldn't've needed to buy the stuff I worked on/designed. There are a lot of companies out there who think the stuff I worked on is their software quality silver bullet. But it's not, there are no silver bullets.

Software is a machine with 20 billion moving parts, in a universe with no Pauli exclusion principle. The mechanical side is complicated, and I'm not trying to minimize that fact. But you're grossly underestimating both the complexity of software and overestimating our ability to deal with it.

Mechanical engineers can take a single part out of a plane, and they can understand it. They understand what shape that part needs to be, they can make positive statements like "there's a 5% chance this part will fail within 10,000 hours of operation". You can use assessments like that to calculate an aggregate risk for the mechanical parts. But software doesn't work like that. You can't measure it, and you can't ever truly understand the risk. How can you say anything about your software when you've tested approximately 0% of the states, and 0% of the possible inputs? It's the problem of induction on steroids.

I am a beneficiary of the amount of time and money they spend dealing with these problems.

A "good system design", "tested to a properly anal degree" is if your entire software system is simple enough that you can simulate every possible state and input exhaustively. If you tell me that's how the F-35's mission critical components were verified, I'll be suitably impressed. I'd also be very surprised.

Anything else isn't good enough. You really need to keep in mind that software isn't a good thing by itself. Software is foremost a cost-saving measure: it replaces labor and custom parts, it makes maintenance and retasking easier and cheaper. Sometimes it legitimately can do things that have no direct substitutes. But always, there's an engineering trade-off. Every time you replace some mechanism with a computer, you're adding complexity. You're increasing your electronic attack surface. Companies need to start making those decisions ****ing critically, and that's not going to happen as long as you have executives who don't understand the trade-off, who consider "lines of code" an asset instead of a new kind of 21st century toxic waste.

Most of MISRA C is statically verifiable. That means software tools can automatically verify whether code is compliant with MISRA C just by looking at the source code. IIRC there is nothing equivalent for defense. MISRA also references HIC++ now, so maybe defense or aerospace has adopted it too.

You need to write highly testable code, sure, but I'm not aware of any standard or recommended ways of doing so. If you're required to follow specific conventions to facilitate MC/DC adequacy, they are probably specific to your company.

like DO-178C

So, is the F-35 doomed because of the amount of lines of code, or because of the inefficiency built into the the structure of its code?

This is an honest question, I have my own bias on the program from a hardware point of view, but none from the software.

Lines is good enough, unless you want me to give you a computer science lesson. Mo' code, mo' problems.

Stable and normal human being.

Unstable and normal human being.

I wonder how much Elon Musk had to give up in the postnup to get her to say they got divorced because of his ruthless, always-on business mind.

Drainage, Elon.

Don't you threaten me with a good time...

But seriously, fair enough. So, how is this avoided in the future? Platforms from here on out are going to have a quagmire of coding, be it air, sea, or land. It's always going to have dozens of firms in the code, is this just the Achilles heel from here on out, or is there going to be a middle ground in development?

We should find out and compare to how much it cost Trump to get a woman to say how good he is in bed.

A powerful alpha male who knows exactly what he wants from his woman and isn't afraid to put her in her place. Always thinking about business and hiring and firing and all of that other businessy ****. Totally didn't hire the same PR firm as Donald Trump.

Hey, he had to convince venture capitalists to give him money one way or another.

I try not to think about the future of this problem. The present is awful enough.

Did you know that every modern Seagate HDD controller runs ARM Linux? It's not just a bunch of ASICs anymore, it runs a full operating system for I/O and controlling the drive motors. What else is running on it? Has it been compromised? ****, that shouldn't even be a surprise. Your blender probably uses an ARM chip wired up to a hall effect sensor to control motor speed. A full-fledged computer to do the job a rheostat is perfectly capable of doing. It's pathological, companies throwing computers into every damn thing without giving it a second thought.

A fun exercise I recommend everybody tries is to, just for one day, count all of the computers you're exposed to that could totally **** up your day if they failed. Car, elevator, HVAC, fire suppression systems, electronic door locks, traffic signals. Do you work in a factory? Does your e-stop hard cut power, or does it send a software signal to the machine? Do you work in a store? Can your security system automatically SWAT you? Your exposure to software risk adds up real damn fast these days, no matter how you spend your time.

The broad-spectrum technical solution is the same as any other risk. Avoid the risk when possible, otherwise mitigate the harm. That means relegating software and computers to as trivial a role as possible: prefer using them for entertainment or providing information that is not sensitive and easy to verify, don't allow them to perform dangerous automation tasks unless supervised and equipped with hard e-stops, and don't allow them to perform essential tasks unless they are equipped with a manual override that allows a human operator to step in and complete the task themselves.

At the same time, companies are never going to acknowledge these risks until they're forced to pay for them. It's asbestos all over again, or tetraethyl lead, or tobacco - this is the kind of stuff big businesses do. Software is sexy, it's futuristic, it sells. They all know it's really ****, they just don't care. And for every one of us blowing the whistle on these kinds of practices, there are a thousand keener junior engineers who think they're badass and will program up any old dangerous thing without thinking. We don't "avoid" the problem in the future, Roach. We clench our butts and pray to God that we aren't standing anywhere near the crater when the teachable moment finally comes.

https://www.theverge.com/2017/8/11/16137388/dota-2-dendi-open-ai-elon-musk

As Chomsky said once: being impressed that a computer beat a human at chess is like being impressed that a bulldozer won a weightlifting competition.

I'm not sure what the point of these AI stunts are, they seem to be a pointless engineering feat.

The cynical take: Elon Musk wastes time on such problems because he wants to promote himself to the likes of ignorant "I ****ing love science" Facebook memers to propagate the mystique of his brand.

1v1 DotA. So basically pure micro, no collaboration with potentially human teammates, no multi-agent planning or pathfinding. This is the kind of scenario where even expert systems have historically dominated humans.

https://jacobinmag.com/2018/02/elon-musk-hyperloop-public-transit-tech

TL;DR stop letting science fiction wish fulfillment replace sensible policy.

Also, anyone else ride the high speed rails in Europe? They are exceptional. Getting from London to Paris in just a few hours at that cost is amazing.

Yup, it's not exceptionally impressive. And we all know they'll run into "problems" trying to upscale the AI.

I took ICE from Strasbourg to Frankfurt. North America has nothing like it, it’s shameful.

Edit: This was in the 90s, and North America still doesn’t have anything like it.

So I guess Tesla has 400,000 preorders for the new car model - and at maximum efficiency, are producing about 4,500 of them per year.

There's no reason the west and east coasts shouldn't have them already. Shameful is right.

https://www.alternet.org/economy/billionaires-wont-save-world?akid=16855.2689436.p8x7xm&rd=1&src=newsletter1090151&t=38

Short and exquisite, summarizes everything I feel about Musk.

California is building an 800mi rail to the tune of $100,000,000,000 and fifteen years.

http://www.latimes.com/local/california/la-me-bullet-train-cost-increase-20180309-story.html

Huh. So it's costing 77 million per kilometer for Americans to get high speed rail, whereas this study done on European rail costs claims the Europeans pay somewhere between 9 million and 39 million euros, so I guess the average would be about 24 million Euros i.e. 30 million USD, somewhere around 2/5 of the cost.

So, either ****'s just really expensive in the U.S., or somehow the U.S. is bad at managing costs.

There seems to be a common answer to why public transportation sucks, when I looked at it: it's because Americans have a love fascination with driving cars, and moreover consider it a sign of wealth, and public transit a sign of poor. Despite that being pretty much dumb.

But the American public also seems immune to learning basic facts about things like these, so I doubt it's going to change anytime soon.