twtw

You've gone from "they flew a broken aircraft" to "alight, so they repaired it twice, but you cannot ever trust a malfunctioning aircraft again."

If you think I've changed my argument, you misunderstood my comments. I still think that they flew a broken aircraft.

I'll stand by my statement that 610 should never have taken off, and I'm somewhat surprised that it is contentious. I don't care if all the protocols were followed and the logs made (though obviously the pilots of 610 didn't understand what the previous pilots had done to respond to their incident) - in retrospect, we know that the aircraft was not airworthy going into flight 610, so something needs to change so that next time that is detected before takeoff. Whether that is better observation of the protocols or better protocols, I'm not sure.

The preliminary report from the investigation of LNI610 disagrees with you: https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...

The AoA attack sensor was replaced prior to flight LNI043 (he flight prior to 610), in which the pilots declared pan-pan and had to manually override the auto trim systems (which include MCAS). Between 043 and 610, there was further maintenance that included flushing the pilot valves and cleaning electrical connectors, but the AoA sensor was not replaced between 043 and 610.

An aircraft that was repaired followed by one flight in which the pilots declared abnormal operation and performed 3 non-normal checklists should probably not fly again until they figured out what happened, and the next flight should definitely be aware of the incident on the flight prior. 043 faced and overcame the exact same malfunction as 610 - to me that indicates a clear failure. If you keep flying an aircraft that malfunctions on each flight, you're pressing your luck.

Can something be obsolete if it is still extremely widely used?

IIRC, Linux and FreeBSD both use a buddy allocator for physical memory, and I'm pretty sure it is used (in addition to other allocators) in jemalloc as well.

The comment you are responding to addresses the claim that the 737 max is not passively stable. It is less safe than other aircraft, but not because it requires active control for stable flight in any manner comparable to a fighter jet.

I'll direct you to some portions of my other comments that you seem to have overlooked:

airlines and pilots were not informed well enough about MCAS

previous auto trim systems could also be "out muscled" just by pulling back on the yoke without actually switching on the manual override.

----

polluting this thread with lies

I'm pretty sure everything I've posted on this thread is either true or obviously an opinion. If some things are not true, please point them out specifically so that I can correct them.

Nowhere have I said that the lion air 610 accident only happened because of poor maintenance or pilots actions, but it is undeniably true that with different pilot actions and aircraft maintenance the accident would not have occurred.

But they neglected maintenance when serious issues with the plane were apparent. The pilots of the flights prior to 610 noted that the two AoA sensor readings differed by ~20 degrees, and nearly aborted their flight before overriding the auto trim.

Flight 610 should never have taken off.

The procedure that pilots are taught to override auto trim was unchanged, but I think that previous auto trim systems could also be "out muscled" just by pulling back on the yoke without actually switching on the manual override. It's that second part that people are pointing out (though I will in turn point out that the pilots on the flight prior to 610 faced similar issued and used the manual override to respond to them).

deflecting to something unrelated

I don't think it is unrelated that the only accident thus far of a plane with a failure mode that is more difficult for pilots to respond to was on an airline with a notoriously bad safety record.

I fully recognize the fact that airlines and pilots were not informed well enough about MCAS, but I'm also not ignoring the other circumstances of lion air 610

Safety in depth - a single failure should not be a problem. 610 crashed as a result of MCAS, but also a number of other operational failures of Lion Air and the pilots.

criminal charges

Boeing informed the FAA of the changes, and the FAA decided that the pilots and airlines did not need to be informed. Criminal charges for Boeing would be extremely surprising.

This is a seriously misleading characterization of the 737 Max. If you read https://theaircurrent.com/aviation-safety/what-is-the-boeing... (the source of the article that 'acqq is selectively quoting) you will learn the following:

MCAS is “activated without pilot input” and “commands nose down stabilizer to enhance pitch characteristics during step turns with elevated load factors and during flaps up flight at airspeeds approaching stall.

Since it operates in situations where the aircraft is under relatively high g load and near stall, a pilot should never see the operation of MCAS.

In other words, the aircraft does not need MCAS for stability during flight in anything but exceptional circumstances. Normal flights should never have MCAS active.

This is not remotely similar to the aerodynamics of a fighter jet.

MCAS is a software mechanism designed to prevent stalls in extreme circumstances that can be overridden with the same method used to disable auto trim on previous models of the 737. The A320 has software to prevent phugiod motion in exceptional scenarios, except the A320's mechanism cannot be overridden by the pilot.

I don't care if you choose to never fly on a plane again, but don't spread this misinformed hysteria.

No, it doesn't. The 737 max has software to prevent stalls in situations outside of the profile of normal flight. As does e.g. the A320.

It's interesting that you reach that conclusion.

I'll fly 737 max.

I won't fly Lion Air or Ethiopian Airlines.

Southwest: fleet size 754, founded 1967, total of seven accidents with 3 deaths.

Ethiopian Airlines: fleet size 107, 64 accidents with 459 deaths since 1965.

The new system (MCAS) was not intended to take action in normal flight. It was intended the trim in certain scenarios (roughly high AoA + steep turn + high g + near stall), but on lion air 610 the AoA sensor was malfunctioning, which caused MCAS to activate when it shouldn't have.

There already is a switch to disable auto trim. The pilots on the flight prior to 610 used it, as trained. The pilots on 610 did not.

because Comcast has -bribed- donated to way more congresspeople than google

Is that true? [1] indicates Google spent more than Comcast in lobbying in q1 2015. I have no idea how this varies quarter by quarter and since 2015, but Google spends a lot lobbying.

I would not be surprised if that extends to campaign contributions as well. Google donates a ton of money to a ton of politicians.

[1] https://www.theguardian.com/technology/2015/apr/21/google-co...

Discrete optimization and automatic differentiation.

Apple started opencl too, and that didn't last very long.

Thus

> Whether that would be worth it for instruction decoding, I don't know

There would be significant overhead to design a decoder such that it could switch between legacy and aarch64 only, but it could conceivably be done.

fyi clock gating isn't the same as power gating.

"ARM Takes Wing: Qualcomm vs. Intel CPU comparison"

https://blog.cloudflare.com/arm-takes-wing/

Maybe you don't consider those "real" benchmarks, but they look like benchmarks to me.

That's... not the way hardware works.

Regarding transistor / area budget, sure.

Regarding power budget, that absolutely could be the way hardware works. Modern chips can and do power off pieces of silicon when they are not needed. Whether that would be worth it for instruction decoding, I don't know, but it could be.

"Hey AI, is this a hot dog?"

"You've asked me that a billion times - I'm sick of looking at all your pictures. Figure it out yourself."

Maybe that's how we will know.

No, it isn't supposed to be ironic.

The title says "should," after all. Who says every programmer should knows these things about memory? Obviously not you. Ulrich Drepper does - I bet if you asked him, he would say everyone should know these things, but would concede that almost no programmers do and most programmers don't need to.

If you are objecting to "every," then sure, not every programmer needs to know anything about memory. You can program without knowing that there is such a thing.

But it's a fun title, and an excellent resource.

What would be a breaking change for Linux that would justify a major version increment? Linux doesn't break userspace, and there are no stable internal APIs or ABIs.

Thanks!

Ah, yes, and every curve is a line.

If some amount of something didn't have meaningfully negative effects, than a vastly increased amount of that same thing can't possibly have negative effects!

Sure, and the article discusses that. I was thinking at the instruction level. I tend to think of convincing the hardware to do what you want and convincing the compiler to do what you want separately as an effect of writing code before the languages had specified memory models.

EDIT: Though as I think about it I'm having a hard time thinking of a system in which those compiler optimizations are problematic on a uniprocessor system. It is definitely true that optimizations that are safe on a uniprocessor break on a multiprocessor, but I can't think of any systems that don't (effectively) have a memory barrier when switching between threads. SMT wouldn't see a problem because both threads are on the same processor.

The naming is not misleading, because the article says a lot about parallel processing.

It is talking about memory consistency models, for heaven's sake. If you have a uniprocessor, or any kind of concurrency without parallelism, it makes zero sense to talk about memory consistency models because you automatically have sequential consistency and don't have to think about it.

If you don't have a multiprocessor, you don't need to think about memory consistency models. If you have a multiprocessor without parallelism, that's your problem, not the author's.

Computer engineering is not substantially newer than aerospace engineering.

Sure, for UB.

But extensions like typeof are different from UB. They have documented behavior, it is just documented by GNU instead of the C standards committee.

typeof is a GNU extension, but it (or an equivalent) is implemented in every compiler anyone actually uses.

You can do it in C, you just can't do it in the part of C the standards committee has decided to standardize.

I'm not sure what the value is of defining C as standard C when loads of software has shipped for decades using this pattern.