There is an element of truth to this. It's also true that the U.S. government is a terrible customer, especially for bespoke or expensive military goods. However, you can see my other comment https://news.ycombinator.com/item?id=47652717 for what is likely the greater contributing factor. Different outcomes require acquisition leaders that prioritize doing the right thing for the public, even if that pits them against their internal government "customers".
The highest priority in U.S. government acquisitions is to respect the business "rights" of suppliers and potential suppliers. It's hard to understand how tightly this is wound into the very foundations of USG acquisition until you've seen the inside of the process. There are a lot of pragmatic things the government ought to be able to do to best represent the public's interests, but the corporate supplier base's business interests almost always trump the public's interests. The exceptions are when acquisition officials buck the system, lay out expectations for technical data up-front, negotiate hard, and are willing to risk the supplier walking away.
The deference to corporate interests is deeply entrenched in how the U.S. government works. In my opinion and experience, it is also why the U.S. government fails so badly at so many things it does.
Imagine you are the end-user of the thing being acquired (e.g., a military service). You know the acquisition is system is slow, ponderous, and subject to a lot of high-level interference. You care less about the public's long-term interests than about getting the thing, especially when there's a strong risk you may never get the thing due to acquisition system failures. When you feel that sense of desperation, you let the acquisition process give away a lot to the supplier if it substantially improves the likelihood you get the thing, or the (real or perceived) timelines to get the thing.
I'm sorry, but this is basically incorrect on every point other than the limited tenure. Source: I work in this sector.
PMs often come directly from industry. Once they do, there is a period over which they are not allowed to make direct decisions that affect their previous company, but the previous company is free to bid on that PM's programs and speak with that PM. When these conflict of interest situations arise, the office appoints a delegate PM to make decisions associated with that company.
There are absolutely varying qualities of PM, but the majority of them would be considered a domain expert or subject matter expert in some technical area. Standard practice is for a new DARPA PM to inherit existing programs that are already executing as the old PM finishes their tenure. When a PM leaves, the office tries to hand the executing programs to a new PM who knows something about that field (or is an expert). That doesn't always happen, for various reasons, but they do try to do it that way.
There is a large contractor staff that does a lot of heavy lifting on both technical and programmatic fronts. The PM is the decision-maker, but the contractor staff are integral. These contractor jobs can pay quite well for senior staff or technical experts. Maybe not FAMANG software developer salaries, but particularly for topics in the physical domain, the salaries can be significantly higher than the equivalent role in industry.
What is your actual assertion? That tools like FEA are needless frippery or that they just dumb down practitioners who could have otherwise accomplished the same things with hand methods? Something else? You're replying to a practicing mechanical engineer whose experience rings true to this aerospace engineer.
Things like modern automotive structural safety or passenger aircraft safety are leagues better today than even as recently as the 1980s because engineers can perform many high-fidelity simulations long before they get to integrated system test. When integrated system test is so expensive, you're not going to explore a lot of new ideas that way.
The argument that computational tools are eroding deep engineering understanding is long-standing, and has aspects of both truth and falsity. Yep, they designed the SR-71 without FEA, but you would never do that today because for the same inflation-adjusted budget, we'd expect a lot more out of the design. Tools like FEA are what help engineers fulfill those expectations today.
That the original comment I replied to is false: "Good luck designing crash resilient structures without simulating it on FEM based software."
Now what's my opinion? FEM raises the quality floor of engineering output overall, and more rarely the ceiling. But, excessive reliance on computer simulation often incentivizes complex, fragile, and expensive designs.
> passenger aircraft safety are leagues better today
Yep, but that's just restating the pros. Local iteration and testing.
> You're replying to a practicing mechanical engineer
Oh drpossum and I are getting to know each other.
I agree with his main point. It's an essential tool for combatting certifications and reviews in the world of increasing regulatory and policy based governance.
Replying to finish a discussion no one will probably see, but...
> That the original comment I replied to is false: "Good luck designing crash resilient structures without simulating it on FEM based software."
In refuting the original casually-worded blanket statement, yes, you're right. You can indeed design crash resilient structures without FEA. Especially if they are terrestrial (i.e., civil engineering).
In high-performance applications like aerospace vehicles (excluding general aviation) or automobiles, you will not achieve the required performance on any kind of acceptable timeline or budget without FEA. In these kinds of high-performance applications, the original statement is valid.
> FEM raises the quality floor of engineering output overall, and more rarely the ceiling. But, excessive reliance on computer simulation often incentivizes complex, fragile, and expensive designs.
Do you have any experience in aerospace applications? Because quite often, we reliably achieve structural efficiencies, at prescribed levels of robustness, that we would not achieve sans FEA. It's a matter of making the performance bar, not a matter of simple vs. complex solutions.
> I agree with his main point. It's an essential tool for combatting certifications and reviews in the world of increasing regulatory and policy based governance.
That was one of his points, not the main one. The idea that its primary value is pandering to paper-pushing regulatory bodies and "policy based governance" is specious. Does it help with your certification case? Of course. But the real value is that analyses from these tools are the substantiation we use to determine the if the (expensive) design will meet requirements and survive all its stressing load cases before we approve building it. We then have a high likelihood of what we build, assuming it conforms to design intent, performing as expected.
I don't know about full-on nationalization, but we have plenty of evidence to show the incentives for publicly-owned for-profit companies whose primary customer is the Government are strongly misaligned with the non-economic interests of the public.
I don't have a pat solution to this, but for example, Boeing, Lockheed Martin, Northrop Grumman, and Raytheon have little reason to improve when they have a captive customer. Raytheon recently agreed to pay ~$1B in penalties for illegal exploitation of their position and the market doesn't care: https://www.justice.gov/opa/pr/raytheon-company-pay-over-950...
Pure capitalism for these kinds of uniquely critical products and services doesn't seem like the right answer.
Excellent comment. As someone who spent time in the MIC, I’m always glad to see others make the same sort of callouts about exploitation of the Government by entities unaligned with and detached from the goals of the people.
Extremes rarely work; rational compromise is what moves the needle forward, bit by bit.
This is a poor example of "Government innovation". It's more an example of legislative overreach / "pork barrel" politics, and bad acquisition practices.
The Government is certainly capable of doing a shitty job, but that tends to happen more when the Government contracts things vs. actually doing real work in-house. At least in my field, I've seen some incredible innovation done within the U.S. Government.
There's more to the Linus-style jerk phenomenon than just telling entitled people to piss off (I would be reluctant to call that being a jerk if that's all it was). See https://news.ycombinator.com/item?id=33058906 for an example thread and associated comments. If you're just ranting or passing off subjective POVs as truth and obvious and those disagreeing with you as doing so out of incompetence or malfeasance, that isn't being direct, honest, or straight to the point. It's being a dick.
I've seen brilliant colleagues for whom I have the utmost technical admiration completely fail to improve bad designs implemented by others, because the brilliant person was so dickish about how they communicated to others.
> And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus.
It's an exaggeration. Means that he disagrees with people who blindly repeat something that, on the level Linus operates, is objectively not true.
I have no context on the broader discussion but it seems both sides haven't equalized the plane on which they discuss. In that context I'll agree Linus was a dick.
But, consider what was said upthread: many high-profile open source contributors hear the same crap every day. No matter how gracious you start off, you'll start rolling your eyes and ultimately resort to sarcasm. And some go even further: start insulting. Ask anyone who works in retail.
So again, to me Linus' statement basically uses an exaggeration to illustrate a point: "Stop repeating something as if it's unequivocally true. It's true only in your context (userland application development). It's not true in kernel context."
That people get offended by that says more about them than about Linus.
Finally, I'll agree it can and should be toned down. Not disputing that. But it's also not so difficult to extract out the true point in such a rant and move on.
We probably won't get much further going back and forth on this. For what it's worth, you seem very reasonable, I've appreciated your comments for a long time, and I'm sure we'd get along fine if we were to work together.
I think you could let Linus off the hook by trying to find the kernel of truth as you suggest, and that seems to be the way key Rust team members work. There's been plenty of needless rancor in HN comments about Rust and you can see people like @pcwalton just not engage with the emotional content while still continuing to engage with the technical points. I'm personally impressed by this, but wouldn't be surprised if it contributed to the burnout.
Should we all aspire to be like that? Doing so seems like the human communication equivalent of Postel's Robustness Principle, which sounds great but in practice leads to shitty implementations getting away with being shitty because of the "robustness" on the other side. Maybe the better play here, especially with asynchronous communication, is to expect people come back to their message draft when they are not so pissed/emotionally triggered and then snip out tangential emotional crap. Especially the ragey condescending stuff.
> I'm personally impressed by this, but wouldn't be surprised if it contributed to the burnout.
I think that people who contribute to languages are of a certain psychological type. They are generous, nice, kind, they want to contribute and are not interested in the social and people drama. They are a special breed of people whom I admire.
At the same time, and as you point out, that makes them more vulnerable to burnout because the social / people drama always creeps in, and they seem less well equipped to deal with it (though I've known of very impressive exceptions).
Personally I found out that bottling up negative emotions is futile; they inevitably erupt and the longer you have bottled them up, the more violent the explosion and the worse the ramifications for your mental health.
That's my main reason for not mincing words anymore. I prioritize my mental health. I am OK if that means I part ways with people and companies. I was a victim of FOMO for most of my conscious life; I want to live my remaining years being more at peace.
> Maybe the better play here, especially with asynchronous communication, is to expect people come back to their message draft when they are not so pissed/emotionally triggered and then snip out tangential emotional crap.
Obviously that's best but I can bet each and every one of us has been in a situation where they knew they had to do that and still didn't. :D Myself included, not proud of some of my comments on HN during Corona time...
But expecting most people to be like that? Super tall order, turns out. :(
--
> We probably won't get much further going back and forth on this.
Likely not, but I am grateful that you entertained it as much as you did. :)
> For what it's worth, you seem very reasonable, I've appreciated your comments for a long time, and I'm sure we'd get along fine if we were to work together.
That's an extremely surprising and very warm message that I couldn't predict if I lived for 1000 years. Thank you! Still very surprised and your message is definitely the highlight of my day now.
Elon is well-known for firing or sidelining technical staff with whom his intuition disagrees, regardless of his own technical depth in any of those matters. His companies have a lot of success for reasons other than his making the wisest technical and programmatic decisions. He sets his own standard for what he considers acceptable, even if those standards fly in the face of existing norms. That's not unalloyed awesomeness - there are sacrifices.
The author, in an admittedly ranty way, levels basic criticisms that are hard to individually disqualify. With the truck, it seems like Elon did Elon things, and his team is struggling to make his vision real in a mass-producible design with acceptable quality.
I don’t disagree with anything you’ve written, but the idea that Musk hasn’t considered oil panning and should’ve just asked an engineer is ludicrous. The author assumes Musk must be an idiot despite all of the evidence to the contrary.
> ... the idea that Musk hasn’t considered oil panning and should’ve just asked an engineer is ludicrous. The author assumes Musk must be an idiot despite all of the evidence to the contrary.
I don't see anything ludicrous in the author's article, even if it sneers at times. Though unquestionably successful overall, since Elon has a history of bad technical or PR/appearance-driven moves, I'm not sure what's wrong with mocking him for some of those things. He is successful despite doing some idiotic things, it's not that everything he does is brilliant and correct.
The article doesn't provide any internal Tesla evidence as to whether Elon considered it and disregarded oil canning (for whatever reason), or if people on his team told him about this likely issue and he blew them off, thinking he could just keep demanding his team bring him solutions instead of telling him about problems with his vision. Under the circumstances, either could validly be criticized as idiotic, in which case mocking him seems like fair game. This would hardly be the first such issue ("Falcon Wing" doors, display screens on the Model S, the incredibly ill-advised 'Full Self-Driving' labeling, etc.).
> I wonder what the situation will be in terms of fuel efficiency. Obviously it will take more energy per second to push through the atmosphere, but that may be defrayed by not having to hold the airplane up as long.
The relevant metric is mass of fuel burned per passenger seat-distance. In American units, this would be (lbs. fuel)/(pax-seat mi.). This measure allows direct comparison of differently sized airplanes with different design ranges and cruise speeds.
Take a look at Figure 1.2.7 in this study a Boeing-led team performed for NASA: https://ntrs.nasa.gov/citations/20100030607 . There were plenty of study contracts awarded under this project - Lockheed Martin did a good study as well, but the Boeing one was the first I found.
The dual/tri class band includes the (lbs. fuel)/(pax-seat mi.) for a high-efficiency large subsonic transport. Call it about ~0.1 for this aircraft type. Note the target of the study, which requires state-of-the-art technology or beyond, is 0.3 for a low-boom supersonic cruiser.
Even taking credit for efficiencies beyond Concorde technology levels, and cruising slower than Concorde, it's still ~3X the fuel burn per pax seat-mile compared to a modern high-efficiency subsonic transport. So reduced flight time is more than offset by the energy expended to fly fast and carrying fewer people in a given flight. The picture will be uglier still for supersonics compared to target efficiencies for next-generation subsonics.
> Give more funding to proper engineers, not physicists/chemists
Materials science departments are often called "Materials Science and Engineering". How do they fall in your categorization?
Without disrespect intended, your words sound like those of someone who has never spent any time in graduate school in a engineering program in physical disciplines. The lines can be blurry.
