trklausss

Totally true! That’s why I don’t blame Boeing yet, but their bad press and mishaps in safety tend to make a bias towards thinking there is something here.

I will wait for the FAA report on that :)

I agree 100% with you. That’s why you as a manufacturer release proper TNs, maintenance procedures, and inspection intervals, train maintenance crew, etc.

I will wait for the FAAs final report, I’m definitely not blaming Boeing here yet, but their bad press is surely a bias point against them and giving a second thought about whether they are doing things right…

Would you prefer that the manufacturer lets it fly while it is not safe like the Mad Dog? That’s exactly what gliders go through, every 3000 hours they get a complete check of the structure, if it can’t be repaired or are too expensive to repair, they get scrapped… I don’t know why do you think it’s a hot take when that’s standard practice.

It’s issued by the FAA based on the reports from the manufacturer, which can collude, falsify or mislead the authorities. The FAA does 0 testing on the airplanes, it is all done and documented by the manufacturer.

I did not imply that, and what you are asking there is a fallacy. Maintenance is a core part of airworthiness, and the only way you can mitigate design flaws.

But at the same time, if you had a running processor with a known side channel vulnerability, and you know the manufacturer doesn’t release a mitigation or doesn’t really care that much about security, would you still use it? Is the manufacturer liable for not releasing mitigations or not caring that much about security?

If the airframe is not airworthy after inspections and there is no maintenance remedy that can be applied to it at an economical cost, then that airplane shall be scrapped… Even before it reaches the FAA. So in a way yes, if you can’t apply maintenance the way it is supposed to be, then it is not airworthy, and if the manufacturer does not release proper TNs to mitigate design flaws, then it is also not airworthy. I will wait to the report from the FAA and see what they find out.

Partly yes. Safety should come in first line from design, second from maintenance. If an airframe is not able to safely fly anymore, it’s airworthiness certificate should be removed by the issuer, which in the era of self-certification is the manufacturer.

1. [6] happened on 2nd of January. 2. [1] is related to consumables (probably batteries; [2] is an engine shutdown issue, not airframe (criticalities are different and guards against its failures are far better risk-managed); [3] related to consumables again; [4] systems/airframe issue.

The only incident that could a priori be related to the airframe is [4], and funnily enough it happened on a Boeing. What is demanded from Boeing is that 1) they train maintenance personnel properly, or if not in scope release proper documentation for said training, and 2) they design systems so that maintenance is reduced to a minimum and safety is not compromised.

It’s not about “Boeing didn’t plug a door properly”, it’s about “this airplane requires you to tighten the bolts every 300h (came-up numbers here)”. There is the technology to make bolts secure so that they don’t pop out, if you defer safety of the system to maintenance accidents are bound to happen.

We are talking safety here. Even if it is a 30yo plane, and Delta is in charge of maintenance, Boeing as manufacturer should release a TN to mitigate the issue. If it’s deemed that the airplane is no longer safe to fly after 30 years because you can’t guarantee it’s safe to fly, then as manufacturer you should retire it.

This should all come from Boeing _before_ it reaches the FAA. That’s the meaning of self-certification through AMCs.

I’m assuming here however that there are no TNs associated with this particular issue with the landing gear.

If they are talking about the power plant I’d assume it’s also characteristic things like response times and control/configuration data. That’s what ultimately identifies a reactor to pick the apart from others.

E.g. if you exactly know reactor XY was assigned to Z submarine, and you see it in the boneyard, you could assume Z was decommissioned. And if you are e.g. China you could estimate how many submarines are deployed in your vicinity.

Not at all, you can encase everything on an “unsafe” block and live happy.

However you won’t have Rust’s guarantees of fearless concurrency and you expose yourself to other defects related to memory (free after use etc.)

If you understand the language, you even program much of the std libraries with unsafe code in them.

For more info you can consult the Rustonomicon.

What worked for us was actually rebasing, and having one person orchestrating the merges. That way you can have 10+ feature branches and only when you are ready to merge you rebase and check everything is working fine.

Do you mean 70m/s?

My guess is that power generation would be greatly reduced or constant after that. It can also be that the whole thing breaks apart, and therefore needs to be stowed in those conditions (we are talking about category five hurricane)

Dumb question: do we need an OS on an soldering iron? I understand that several tasks/threads may need to be developed, but a full-fledged operating system sounds like too much. Your thoughts?

We have had this in Spain for decades. At the entrance of every village you have two traffic lights: a blinking one, where the measurement is performed, and the actual red-amber-green. The main light is always green until a car crosses the detection line, then it turns red for the exact time that it takes to cover from the measurement area to the traffic light at 50km/h… Problem is of course enforcement. No one prevents you from just disregarding it unless you pair it with a speed/traffic light trap.

Seems that you did not read the README:

There are two encoding modes, RGB and B/W. It uses a pixel-to-data width of 2x2, but says YouTube's compression algorithm is brutal, and one corrupted pixel already renders the whole thing corrupted.