Boeing Believed a 737 Max Warning Light Was Standard - <AUTHOR> https://www.nytimes.com/2019/05/05/business/boeing-737-max-warning-light.html <comment><USER2> > But months after the planes were flying, company engineers realized that the > warning light worked only on planes whose customers had bought a different, > optional indicator.

If I am to read this correctly, the angle-of-attack disagree light is installed on all Boeing 737-MAX aircraft. For customers who did not buy on optional additional indicator, the angle-of-attack disagree light was always off, even if there is a disagreement between to sensors of the angle of attack of the aircraft.

Doesn't this seem dangerous in-and-of itself? If a pilot assumes that the light is off because there _is not_ a disagreement, instead of because there is no information available, she is acting on incorrect information, and might try to address problems unrelated to the actual problem.

Also, pilot may switch aircraft and expect the same functionality of safety features and may make incorrect assumptions about the functioning of this light.

<comment><USER3> > Doesn't this seem dangerous in-and-of itself?

To me, more dangerous, is that some safety systems are considered optional. Surely the plane either needs a safety feature or not, and it shouldn't be down to someone at an airline to make a decision on?

<comment><USER4> Different countries have different standards of safety, and different budgets. Boeing got more $$$ from airlines in the US by making planes in Ethiopia and Indonesia less safe. Yay capitalism.

<comment><USER5> That's weird to say. Lion Air is a sloppy, cheapskate airline — look at their horrible maintenance and crash history for evidence of that. That they didn't want to pay slightly extra for additional options on the plane was their choice. And Ethiopian is a flag carrier: they could have easily gotten the extra option, but likely some accountant thought it wasn't necessary. Who spends over $100 million on an airplane and then declines a $1 million safety option?

<comment><USER6> > Who spends over $100 million on an airplane and then declines a $1 million > safety option?

Someone being pitched 30 different $1 million safety options?

<comment><USER7> Someone who wants to buy 100 of those airplanes, but knows that the safety option reduces the risk of incurring a $100 million total hull loss by _less than_ one percent, thus saving _less than_ the $100 million extra cost for the option? Obviously the numbers are different, but see the oft-quoted 'Fight Club' line about product recalls for similar logic.

</comment></comment></comment></comment></comment></comment><comment><USER8> This sounds so much like my enterprise experience, where you can bring up a huge security vulnerability, have everyone senior to you explain to you that it isn't a problem. Leaving you utterly confused.

Then when someone else finds out a few months later, suddenly alarm bells start ringing, and everyone up to the CTO is called into an emergency meeting because there is a _huge_ security vulnerability.

Yeah, no shit.

 _sigh_

<comment><USER9> Sometimes I think this is a victim of the "invented here syndrome". I don't know why it is, but many, many people seem to have absolutely no respect for their coworkers. If you bring up an issue (of any kind), it's often treated with suspicion before people even understand what it is. But if the issue is generated by "an authority", suddenly it's a massive problem -- again even before people understand what it is.

I've found this also happens for _good things_. "I've found this amazing thing that will save us millions of $". "It'll never work and as soon as I understand what you are talking about, I'll tell you why".

What's absolutely horrible about this is that I've caught myself having the same attitude! I've been trying to stop myself from doing it, but man is it difficult. The default, "My coworkers are brilliant" point of view is just so contrary to my cultural upbringing ;-)

<comment><USER10> > _The default, "My coworkers are brilliant" point of view is just so contrary > to my cultural upbringing ;-)_

It's not just cultural upbringing. It's difficult to really realize that the intelligence/competency distribution at work is vastly different than in the rest of your life and all those years before work. Especially if you work for a highly selective employer in a high-skill job market. We learn from experience afterall and encounter a lot of incompetency throughout life. We also tend to weight negate experiences much higher than expected ones.

I still catch myself being happy and surprised, if I encounter someone competent and usually expect incompetency. It's rude and on average probably wrong, but trained from experience.

</comment></comment></comment><comment><USER11> > After discovering the lapse in 2017, Boeing performed an internal review and > determined that the lack of a working warning light "did not adversely > impact airplane safety or operation," it said in its statement.

> As a result, Boeing said it did not inform airlines or the Federal Aviation > Administration about the mistake for a year.

There was a warning light installed in the cockpits which was completely non- functional in 80% of the 737 max fleet, and Boeing did not notify the airlines for an entire year? Did they honestly think that "lack of a warning light" is equal to "lack of _working_ warning light"?

<comment><USER12> The "warning light" is an "AOA DISAGREE" text that appears on the main flight display:

[http://www.boeing.com/resources/boeingdotcom/commercial/737m...](http://www.boeing.com/resources/boeingdotcom/commercial/737max/updates/AOA_VaneIndicator_AoA_Disagree_lg.jpg)

So there was no non-functional physical light on the cockpit.

<comment><USER11> Ah, I was not aware of that. But surely the pilots were under the impression that such a warning message existed?

<comment><USER13> So there a weird thing about angle of attack: the autopilot uses it, but civilian pilots don't use it (they use airspeed and descent angle). It's used in the military, and airlines who recruit a lot of military pilots tend to buy the angle of attack option to get them comfortable. Ignoring the little MCAS issue, it was a fine reasoning, the autopilot can detect a disagree (I guess they just drop out, but I don't know about cat 3 landings), ex-military pilots need a disagree because they read it, and other pilots don't need to know.

<comment><USER14> I found it amazing that civilian pilots don't use angle of attack so went looking and found this article about the debate on installing angle of attack indicators on commercial aircraft, which cleared up for me why this would be the case. But not in the most reassuring manner.

[https://apstraining.com/the-angle-of-attack- debate/](https://apstraining.com/the-angle-of-attack-debate/)

>"From day one, pilots should be—and in most cases are—taught that stall occurs when the critical angle of attack is exceeded. They are then told to memorize the stall speeds in various configurations. By the time they have become proficient, they relate stall to a certain airspeed, and don't really relate it to an AOA anymore."

<comment><USER15> Air France 447 immediately comes to mind, where the crew (or maybe specifically the copilot who kept pitching up for minutes) lost their airspeed indication and thought the stall warning was frivolous despite falling vertically at terminal velocity for minutes.

<comment><USER16> Critically in that case, the stall warning stopped when the nose was pulled up even further, because the computers rejected the indication as too large to be correct. So every time the nose was lowered, the stall warning _activated_.

<comment><USER14> Fucking hell. That is a fucker of a dark UX pattern.

<comment><USER16> Indeed. And it goes to show that rejecting "impossible" values is a dangerous strategy.

<comment><USER14> I think you can reject impossible derivatives, though only if being very fucking careful.

<comment><USER17> Let's say you notice a sudden change in a sensor which is surely not physically possible. Was the value more accurate before or after the sudden change? Do you reject the current actual value or the dead-reckoned value based on the old data?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> > In the months after the Lion Air crash, Boeing quietly worked to appease > some customers, according to a person briefed on the matter. In several > instances, it activated the angle of attack indicator for free, which then > turned on the disagree alert.

Instead of activating the indicator for all customers, Boeing only activated it for customers that explicitly asked. Greedy until the end.

</comment><comment><USER19> Boeing statement: [https://boeing.mediaroom.com/news-releases- statements?item=1...](https://boeing.mediaroom.com/news-releases- statements?item=130431)

This PR is helpful in that it reminds me that there are actually people paid to take a simple set of information and mix in with a ton of PR bullshit so that you have to read it 4 times before you actually understand that yes, they screw up.

<comment><USER20> Here is the ass saving statement from the press release: "Senior company leadership was not involved in the review and first became aware of this issue in the aftermath of the Lion Air accident."

<comment><USER21> Courious they try the same strategy as VW. We all know how that is most likely to end...

<comment><USER22> With increased sales and better revenue?

[https://www.volkswagenag.com/en/news/2019/03/VW_Group_delive...](https://www.volkswagenag.com/en/news/2019/03/VW_Group_deliveries_2018.html)

<comment><USER21> And got a the former CEO and other exects indicted in two countries and cost the conptany billions. The story is still ongoing. And might have contributed to the issue with the new Golf 8. Did I mention that some former managers are in jail already?

</comment></comment></comment></comment></comment><comment><USER23> What worries me even more is the monkeypatching they are now trying to do in order to get the permission to fly the plane again.

In the original design they had designed the MCAS to be able to make drastic changes which then caused the crash.

Now they are trying to fix that by making the system less intrusive, but didn't the engineers design the system to be so strong for a reason (because of the changed position of the engines)?

This seems to me like going through a codebase from someone else because there were errors and just deleting stuff that made problems. Even if the initial version had problems, it was designed that way for a reason?

</comment><comment><USER24> > In several instances, [Boeing] activated the angle of attack indicator for > free, which then turned on the disagree alert.

This sounds like the "indicator" and "warning light" are not physical devices that must be installed at extra cost, but rather are software features that can be "activated" by changing some configuration file.

If so, then Boeing has blood on their hands. The active control system is already a cost-cutting hack. Charging extra for zero-cost safety features related to the new, unproven control system is an act of appalling greed.

<comment><USER25> So, the AoA indication is a feature that can be activated for a fee (which most likely exists to cover costs of modifying the configuration from the base configuration, so imagine as an analogy a $2 fee for some really minor change to a car you ordered). The reason this is an option is that it requires additional training for the pilots, some airlines already have this training (American Airlines is one example) and theres no enabling it and then not training the pilots on it.

As many have noted, AoA is not commonly used in non-military piloting in the United States, so its no surprise its not commonly ordered.

I am also under the impression that the AoA Disagree indication was new on the 737 MAX, I haven't checked the 737 NG manuals for it.

</comment></comment><comment><USER26> This story is really starting to annoy me. Now there's a new person named "Boeing" who somehow lacks self awareness to know what they're doing or selling even though this Boeing character designed, built, and sold two variations on their product. I feel like Boeing will soon become the main character, and try to plead insanity.

<comment><USER27> Hey now, if we started holding individuals accountable for the criminal negligence of the corporation they run, surely bedlam would errupt.

It's Limited Liability in it's purest, most distilled form.

<comment><USER28> Interesting linguistic phenomenon: Commonwealth grammar uses plural verbs for collective nouns -- i.e. English newspaper articles will say "Boeing have decided.." instead of "Boeing has decided..".

Strikes me as subversive in this current environment: language reminding you that a corporation's decisions are made by actual people.

<comment><USER29> As an Indian, I was surprised at "Collective are..." and believe it arose after the colonial days.

<comment><USER28> That's interesting! I wonder when this strong preference for plural verbs appeared in British English.

</comment></comment></comment></comment></comment><comment><USER30> This is a phenomenal failure of management. The failure of the team is always the fault of the leader.

I've seen this so many times in industry. Some decision on high comes through that costs need to be cut, which means cutting corners. It always means cutting corners, because the only way they have to measure costs is Salary × Butts-In-Seats. So they hire lower cost people (i.e. less experienced, often off-shore where there is no oversight on process) and cut the number of people (often several key roles that would put the brakes on bad plans).

They make a short-staffed team of people who don't know any better, then look around confused when things go wrong. "But the PowerPoints said we'd be successful. The management consultants said everything was on track".

When it's a website for a government bureau, people just throw up their hands and act like this is normal. The customer eats the cost of the useless product and they start over, usually with the same contractor on an extension, often not learning any lessons in the process (how could they? They can't imagine a world in which any of this is their fault).

It should never happen for any project. It should be a damn crime, upwards of fraud, with massive fines. But stuff that can kill people, this should be sending people to jail.

I can hear the meetings in my head, I've been through them so many times. "Who knew this was a problem?" "Uhhh, I brought it up at the outset, you said it wasn't my place to bring it up." "You're on report for your negative attitude."

</comment><comment><USER31> > Boeing performed an internal review and determined that the lack of a > working warning light "did not adversely impact airplane safety or > operation,"

Why is this review not done by a third party auditor? The cynical view is that corporations have a conflict of interest. They are only incentivized to act ethically up to the point that the cost of ethical behavior exceeds the damage done by unethical behavior... These costs do include future fines/penalties, but these are often woefully disproportionate to the damage done as evidenced by the fraudulent NASA metal supplier incident.

<comment><USER32> Because the third party auditor (the FAA) has had it's operating budget slashed so viciously, it can't compete in attracting the talent required for independent certification.

Remember, to regulate something, you need to be 10% smarter than what you are regulating. Which means you have to be able to make sure you can attract the best talent possible.

As a regulator, you have to be on your game all the time. The regulated just need to get lucky once to get away with what they shouldn't.

</comment></comment><comment><USER33> "Boeing Believed a 737 Max Warning Light Was Standard. It Wasn't."

This is retrospective ass-covering, to distract us from the fact that the the pilots were never informed as to the existence of MCAS (Maneuvering Characteristics Augmentation System) and therefore could not even know how to disable it. The presence of or lack thereof of a warning light being rendered specious. And MCAS read only the one AoA sensor, from the captains side.

So to summarize, the pilots don't know about MCAS, MCAS is still engaged even when the auto-pilot is disengaged. A single AoA sensor failed, triggering the MCAS into a nose-down mode, the pilots begin ignorant of this, repeatedly tried to regain level flight using the trim wheel. This they failed at.

"The warning light notifies pilots of a disagreement in the sensors that measure which direction the plane is pointed"

This wouldn't even work in the way described, in a two sensor system, the computer can't tell which sensor is giving false readings. That's why they hooked up MCAS to only the one sensor. And Boeing didn't tell the FFC or the pilots as they would of had to get the plane re-certified and the pilots retrained.

<comment><USER34> It's (almost?) wilful. If ever there was a suitable time for using a military acronym such as FUBAR, this is it.

In my own view, leadership should be held criminally responsible for the loss of lives. Of course it will never happen, but that's what ought to happen.

Hopefully they'll at least be responsible for liability in a lawsuit by the victims' families. They deserve being taken to the cleaners, well and proper.

<comment><USER35> At this point I feel like it's fair to call Boeing's actions malicious. You charge for safety features that cost you nothing to deploy? Yeah, that's malicious. They knew people could die, but they wanted more money, so they let people die. Now, the company needs to die. Buyers of aircrafts would be clever not to trust Boeing ever again, and buyers of tickets would be clever to avoid flights that use Boeing planes. If everybody acted cleverly, Boeing would die and other aircraft manufacturers would take note. I doubt everyone will act cleverly, but repeatedly informing people of their malicious actions could help facilitate it. Not flying on Boeing planes would help too, but unlike a traditional boycott you have an actual selfish incentive to do so (not dying). Just like a traditional boycott, your individual participation is statistically meaningless unless you're actually in a position to buy a large number of aircrafts. I honestly don't think I'll avoid flying on Boeing planes in the future, but I'm also probably more willing to gamble with my life than most people are; I never said I was clever.

<comment><USER34> Agree on malicious, especially given that the Max change was a big hack of an existing airframe. It _needed_ all the extra safety features it could get; to charge through the nose for them was shocking and callous.

However, given the amount of Boeing planes out there, and the number of employees, the company dying would be harsh. What needs to happen is a fundamental shift of culture; this is why I think that leadership should be held responsible for what's happened, and that this (with leaders in jail, new ones would have to take their place) would help force the changes that need to happen for safety and engineering quality again to be the number one drivers - not just profits and bean counting.

It's an opportunity for them to fully reset the company. Fingers crossed, it will happen.

<comment><USER14> >However, given the amount of Boeing planes out there, and the number of employees, the company dying would be harsh.

346 dead from wilful incompetence, followed by utter bullshittery, half- truths, outright lies and finally, when it has to admit what it has been doing, a desperate insistance that executives could not possibly have known.

And all the while fighting against them being grounded.

Break the damn thing up already.

<comment><USER36> > Break the damn thing up already.

I dont think any US politician has the guts to take down Boeing, if it goes down there wont be any major US aircraft manufacturer.

<comment><USER14> That's another reason, given the evident issues with the total fuckwits currently in management, it should be broken up. If it isn't, then the US may end up without a major US aircraft manufacturer.

<comment><USER37> So far, Boeing stocks went up since the time _before_ the first crash...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> One question to ponder: Would the two crashes still have happened without this particular mistake, that is, if the planes had had a working AoA disagree indicator?

It depends, I think:

1\. Did the AoA sensor malfunction occur before the takeoff roll?

2\. Would the AoA disagree indicator come on early enough to abandon takeoff?

3\. Would the crew reject takeoff once the AoA disagree indication comes on?

If it's a "yes" on all three questions, then presumably the accidents would not have happened.

Once you're in the air, and all hell breaks loose (stick shaker etc.) while MCAS tries to dive you in the ground, I doubt that the indication would have made any difference: before the Lion Air crash, crews didn't even know about MCAS. After, they did know, and the Ethiopian Airlines crew, from what I gather, diagnosed the problem, though maybe too late - but again, I doubt whether the AoA disagree indication would have helped.

That leaves above questions.

1\. For the Lion Air crash, the AoA malfunctioning was there before takeoff. For Ethiopian, I'm not sure.

2\. I'd think yes.

3\. Don't know. Anyone an idea? (Today, presumably you'd abort with a MAX and AoA issues. Back then?)

<comment><USER39> I think you're too quick to dismiss the importance of the disagree indicator, and doing so on a shaky basis. A significant amount of time was spent trying to figure out what the hell was happening. I think it's safe to assume that if the pilots saw an error warning pop up warning that there was a disagreement between two sensors, that would focus their attention on that system—which quite conceivably could have caused them to shut it off manually sooner.

<comment><USER38> > that would focus their attention on that system—which quite conceivably > could have caused them to shut it off manually sooner.

But you can't shut off the AoA measurement "system", AFAIK. And the system causing the trouble (under wrong AoA information), the MCAS, can be shut off by setting the Stab Trim switch to Cut Out, but how should the crew know the connection between AoA and MCAS when they weren't even briefed about MCAS in the first place?

<comment><USER39> iirc the Malaysian flight had in the cockpit a pilot that was hitching a ride, who figured out what was going on but too late. He knew about the MCAS. Had they vocally stated something about the AoA sensor early on, or had he caught a glimpse of the message, perhaps he could have intervened sooner.

For the Ethiopian flight, you're right. They likely wouldn't have known what to do with that information. But it might have prompted them to get on the radio and ask someone, or consult a certain part of the manual (assuming there was any relevant information there.. I don't know).

It certainly seems like crucial information. And even in the small chance it could have made a difference, the absence of it is critical

<comment><USER32> For Lion Air, he remedied the symptom; he realized there was some sort of periodic trim runaway, and guided them to remedy it with Stab Trim cutout without having any intrinsic understanding of what the cause or underlying principle of the runaway was.

Big difference. Still didn't do anything for the fellows on the next flight.

</comment></comment></comment></comment></comment><comment><USER40> The warning light might matter for squawk reporting (pilot to maintenance bug report, if you will).

But even if the pilot notices the warning, if they don't know about MCAS, then they don't know about "MCAS upset" which can result when MCAS acts on bogus AoA information. And this particular variety of "MCAS upset" quickly induces a mistrim, and high airspeed. So I'm unconvinced the indicator is a "safety" feature in-flight that will result in any different behavior on the part of pilots in an "MCAS upset" situation.

It is a mistake to think that trim is only about attitude (nose up or down relative to the horizon), it also implies an airspeed. Nose down trim effectively translates into a higher airspeed, all other things being equal. If you reduce power, the plane will nose down (this is a function of positive static stability, a FAR 25 certification requirement for transport category airplanes), and the plane will stabilize to maintain the airspeed implied by that trim. Add power and it will climb, to maintain the airspeed implied by the trim.

The central problem is still that the pilots weren't trained about MCAS in either it's intended working condition, or "MCAS upset", or how the airplane behaves with autotrim disabled and therefore without the benefit of MCAS. The pilot not being aware of these three of these behaviors is just flat out wrong. It's bad enough they weren't also required to demonstrate competency (knowledge and practical test) for all three.

</comment><comment><USER41> So I draw two conclusions from this clusterF of astronomical proportions:

1\. The A320neo really caught Boeing off guard. The 737 MAX was a panicked reaction to something that they thought would threaten their business to a significant degree. The A320neo and A320 have a common type rating too. Googling seems to suggest the differences are fairly minor however. I guess Airbus benefits in the A320 being a newer airframe than the 737 (which is ~50 years old now)?

2\. Somewhere along the line this is a management failure of gigantic proportions. That management would risk Boeing's reputation on something that, in hindsight, is so incredibly foolish is mind-blowing. And the buck stops with the CEO. If this ends with anything less than the CEO deciding to spend more time with his family it's a joke. And whoever replaces him should clean house with anyone remotely responsible for this.

This isn't unprecedented either. Through this fiasco I came to learn about the 1990s 737 rudder issue [1] and it's scary how similar the reaction is. "The planes are fine". "There is no issue". You know, until there is.

I expect the only thing stopping a lot of airlines from cancelling their 737 MAX orders and buying A320neos instead is at this point they'd probably have to get in the back of the line and wait years. They really have no choice but to stick with the 737 MAX now.

Actually I guess airlines like Southwest (who are 100% 737 IIRC) are kind of stuck anyway. It's the likes of American Airlines who has such a large and diverse fleet that really bet on the wrong horse.

I really hope this ends in a court case or even better, a criminal case. I really want to know who signed off on this plan and at what point warnings were given and ignored.

[1] [https://en.wikipedia.org/wiki/Boeing_737_rudder_issues](https://en.wikipedia.org/wiki/Boeing_737_rudder_issues)

<comment><USER42> If the airlines switch from 737 to A320neo then all the 737 pilots would have to be trained on the new plane which would cost the airlines big $$$

<comment><USER43> Southwest has ~10k pilots. At $20k type rating per pilot, that's $200mil. An A320neo is $110mil. So, a big cost but not the biggest.

<comment><USER40> There are on-going costs of maintaining each type rating, so it isn't a one time cost. Also, you'd want most or perhaps all the pilots maintaining both type ratings, so they can still be matched with any 737.

<comment><USER44> Apparently, pilots can only be rated for one type at a time.

So during the cross-over period, you will need two completely independent fleets of pilots, one to operate the old 737s and one to operate the new A320-NEOs.

Each fleet needs to have different spare pilots to cover absences or overtime emergencies. And the pilots who currently are training for the new type rating can't be in either fleet.

The airline will have to temporally increase the number of pilots until the whole switch-over finishes.

<comment><USER45> Interesting, if this is the case it would also have meant needing a second set of pilots for the MAX if it received a different rating.

<comment><USER44> It gets more complex.

Airbus have designed their A320, A330/A340/A350 planes with almost identical cockpits and handling characteristics to allow cross-crew qualification.

A pilot with an A320 type rating can take a 7 day course to become qualified on the A330 (instead of the 40 day course normally required). And they can maintain the type rating on both types simultaneously.

Since the A330 shares a type rating with the A340 and A350, this allows a pilot to fly quite a few airbus planes.

Given the Max is so close to older 737s, I see no reason why Boeing and the FAA couldn't come to a similar arrangement, were pilots can be cross-trained with a 1 week course and maintain simultaneous type ratings on both the Max and Older 737s.

Boeing does have a few common type ratings: The 757 and 767 share one; The 777 and 787 share another. But as far as I'm aware, pilots can only be qualified on one Boeing type rating at a time.

<comment><USER46> _Given the Max is so close to older 737s, I see no reason why Boeing and the FAA couldn 't come to a similar arrangement, were pilots can be cross-trained with a 1 week course and maintain simultaneous type ratings on both the Max and Older 737s._

Greed and hubris, would be my best guess.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER47> > Boeing performed an internal review and determined that the lack of a > working warning light "did not adversely impact airplane safety or > operation,"

> after the crash of Lion Air Flight 610 […] conducted another review and > again found the missing alert did not pose a safety threat

How was it possible to come to this conclusion? Twice!? Even after it caused a crash!?

<comment><USER28> "Well, we didn't tell pilots that MCAS exists, which means we didn't tell them that AoA is hooked up to it, which means that AoA failure isn't relevant to their decision making, so there's no safety threat from not communicating it."

(In case there's doubt: I am not joking, I think this is seriously the argument.)

</comment></comment><comment><USER48> >"You better start knowing things about the airplane you're building and selling because my life and the passengers that I carry safely across the globe depends on it," Mr. Tajer said.

haha wow. If that's representative of how pilots feel then Boeing is in trouble.

<comment><USER18> May I ask how this gets Boeing into trouble? The only thing pilots could do is strike which I find improbable.

<comment><USER49> SAS had a seven-day pilot strike just last week, over (mainly) working conditions, so how would a pilot strike over this be so improbable?

</comment></comment></comment><comment><USER50> So even now Boeing will not include all safety features for all customers. Not that Airbus is doing better, but this indicates that Boeing is not concerned that it could face serious charges for continuing to sell planes with some safety features missing. That's interesting! Why are they so assured?

<comment><USER51> The USA have a long history of being very supportive of their companies ("regulation is evil!").

</comment></comment><comment><USER52> It's surprising that there has been no legal proceeding initiated against Boeing for this. They traded the lives of hundreds of people in exchange for an important safety feature.

<comment><USER53> There are cases in court filed in relation to both crashes. And there are various official investigations, including an FBI investigation.

</comment></comment><comment><USER54> So a year from now, when we are flying and see that it's a 737 Max... who is going to opt for another flight? Everyone? Because this shit is kinda fucked how flippant Boeing was with getting around safety testing.

This video was both hilarious and terrifying.

[https://m.youtube.com/watch?v=NhZ0D-JRtz0](https://m.youtube.com/watch?v=NhZ0D-JRtz0)

<comment><USER55> Note: The linked video is by foul-mouthed Canadian YouTuber AvE, in which he disassembles and comments on an angle-of-attack sensor from a C-130 military aircraft. He comments favorably on the build quality of the assembly, but is not impressed with the sensor itself or the lack of internal redundancy.

The analysis is interesting but of limited value to consideration of the sensors and MCAS system on the Boeing 737 MAX.

<comment><USER54> Yeah, I just thought the guy's voice was hilarious. He sounds like someone who lives in the machine shop, knows his shit, and has never had to interact with customers. If I had a personal J.A.R.V.I.S., I'd want to use his voice for it.

</comment></comment></comment><comment><USER56> Even next year when the 737 max will no longer be grounded, I will pay special attention not to fly on them. I'm also increasingly worried about flying on 787s...

I wonder what percentage of customers will do the same and how that will impact airline's bottom line.

<comment><USER57> How does one even figure that out though? Almost every flight one books, the aircraft model isn't listed.

<comment><USER56> You can enter the flight number and date in seatguru to get the aircraft model. It's not 100% accurate but helps. The other way is to check flightaware for that flight number.

This doesn't protect you from an aircraft change and I don't know how I would deal with it if it happened.

</comment></comment></comment><comment><USER58> It's a very bad sign when an aircraft manufacturer builds a warning light and then says, if it doesn't work, that's not a safety issue.

</comment><comment><USER59> Here's an article from 1995 that talks about how 737 pilots didn't know they had to turn off auto throttle on takeoff abort - [https://www.csmonitor.com/1995/0821/21082.html](https://www.csmonitor.com/1995/0821/21082.html)

I wonder how software testing will change (if at all) in the industry post this revelation. There was an old joke during 777 development (Boeing's first full fbw) about the difference between airbus and Boeing software testing architecture - airbus used formal techniques and Boeing put the software engineers on the first flight.

</comment><comment><USER60> I bet even more will come to light.....[https://www.wsj.com/articles/boeing- knew-about-safety-alert-...](https://www.wsj.com/articles/boeing-knew-about- safety-alert-problem-for-a-year-before-telling-faa-airlines-11557087129)

</comment><comment><USER61> Reading the article I was reminded of the depths auto makers would sink to in order to saver pennies on every car made.

On another note; am I the only person that these AOA vanes seem so hokey and inelegant to? I am not a pilot, nor a designer, but if I was buying and flying something that had these sticking out like an after thought; I'd be like WTF are you kidding me?!

</comment><comment><USER62> This sounds like a case of a system so complex that the humans trying to reason about were unable to do so. As a software engineer I've sometimes had to run a piece of software to properly understand how it works. This doesn't seem like a desirable property for systems that are critical for safety.

</comment><comment><USER63> What gross negligence. I hope this forever remains a stain on Boeing's legacy.

</comment><comment><USER64> This issue of the AOA-disagree warning light keeps getting brought up again and again, which is unfortunate because the presence of such a light would not have saved those 346 lives. Imagine you are a pilot and your airplane's nose keeps getting pushed toward the ground no matter how much you pull back on the stick. You try everything. Now you notice a little warning light 'AOA disagree'. How does that help you, exactly? The lack of this warning light is completely irrelevant. The problem is that they allowed the readings from 1 single sensor to force the nose of the aircraft toward the ground.

</comment><comment><USER65> What fucking piece of shit decides that MORE SAFETY is a PREMIUM ADDONT? That is literally suggesting that some passengers lives are worth less than others.

Planes should be as safe as they can possibly be. Full stop. Premium should be for things like comfort and things you can do with out.

<comment><USER66> It's the same in the car industry, unfortunately. Many options that are more or less pure safety-only, and not convenience, are not included unless you open up a little more.

It economically (to the car industry) may make sense (opt ups, recover costs, etc), but it's sad in a way.

</comment></comment><comment><USER67> This is "crime against humanity" level of corporate bullshit. I think, they saved a lot of money by neglecting thorough testing. Also, like in all large corporates, they have n number of departments with terrible infighting and consequentially poor communication.

</comment><comment><USER68> I find Boeing's dismissal of this as not being a safety concern unconvincing.

Boeing spent the money adding this to their design. They spent the money adding the capability to every plane they had. And they thought it was important enough that they shouldn't be charging airlines for it, unlike the addition of a backup sensor (which wasn't considered important enough to be delivered standard).

What was the thinking when doing the review? Hey, here's this feature we thought was important enough that we added several costs without charging airlines for it, while we were nickel and diming them on backup sensors, but actually it was all a big mistake. We were just being generous on this for no reason at all?

</comment><comment><USER69> Send the CEO to jail for life, only way to be sure.

<comment><USER70> Pretty sure everyone who died in the two crashes would agree with you if they could voice their opinion. Specially the pilots.

</comment></comment><comment><USER71> If you look at Boeing stock price over the year, it seems none of this has significantly affected it. It is actually up YoY. I can safely say that this scandal will have no major effect on the management.

</comment><comment><USER72> Sort of OT, AvE did a BOLTR on an AoA sensor last week. (from a military cargo plane, I forget which. Said plane has _4_ of them)

I watched it last night in the same state that he apparently films his vidjeos, and I enjoyed it. YMMV.

[https://www.youtube.com/watch?v=NhZ0D-JRtz0](https://www.youtube.com/watch?v=NhZ0D-JRtz0)

</comment><comment><USER73> Sure, but they are still responsible for the effects. That we can't forget.

Ignoring the complex system they have created is their fault

</comment><comment> village-idiot It's probably time to revoke the 737 Max's type certificate and send Boeing back to the regulatory drawing board.

</comment><comment><USER64> Not only is Boeing too big too fail, it's too big to succeed.

</comment><comment><USER74> [https://www.youtube.com/watch?v=rvkEpstd9os](https://www.youtube.com/watch?v=rvkEpstd9os) explains about MCAS

</comment><comment><USER75> The money quote:

 _The anti-stall system, created to compensate for the Max's large new engines, will push down the nose of the plane if the angle of attack sensors indicate the plane is dangerously close to stalling.

But the system relied on only one of the two angle of attack sensors, introducing a potential single point of failure into a critical flight system. And the anti-stall system was also changed late in the design process to make it much more powerful._

</comment><comment><USER76> Is Boeing's problem lack of competition?

<comment><USER77> If anything the problem is they rushed this plane so they could compete with Airbus

</comment></comment><comment><USER78> so these Boeing fools set the entitlement flag for the necessary AOA disagree display as a child of another, non-required "safety" display option?

Idiots. How the hell do they not have a robust system to validate the correct application of instrumentation rules?

</comment><comment><USER79> This is a sad month for Boeing.

</comment><comment><USER80> This is the sort of fault that causes everyone to pray the investigation comes back "pilot error". Because the alternative is the entire company gets pulled through the mud. Rightfully, but man, this is going to hurt Boeing, and by extension the US.

<comment><USER81> I find the idea that society should not keep corporations and their behaviour in check because "the economy may be damaged" to be frightening and dangerous.

<comment><USER80> I didn't say we shouldn't. I'm fairly comfortable with the idea of bitter medicine. But acknowledging "this is going to be bitter" is a remarkably helpful way to gain rapport, and doesn't actually interfere with the administration of the treatment. If anything, it reduces the patient's odds of rejecting the medicine.

</comment></comment></comment><comment><USER42> I think part of the blame can be placed on the airlines. They willingly didn't buy the Warning light

<comment><USER44> The airlines thought they had the warning light. Boeing thought they had delivered the warning light all airlines as a default.

It was only later that Boeing discovered they messed up and had made the warning light dependant on another feature which was optional.

And then Boeing didn't tell airlines about the broken warning light until just a few months ago.

<comment><USER78> what a cluster F of permissions management

F Boeing

</comment></comment></comment><comment><USER82> The media seems to be on a mission to kill commercial aviation similar to what happened to recreational aircraft. I wonder how long before we see an article about how Boeing knowingly omitted flare and chaff systems despite the risk of surface-to-air missiles. They'll talk about how the AN/ALE-47 system could avoid 22 deaths/year for only $30k.</comment>


Hacking a storyboard - <AUTHOR> http://blog.getrockerbox.com/post/hacking-a-storyboard

<comment><USER2> paper and pencil...are the only way to hash out your ideas. Too much functionality on storyboard software makes things more confusing.

<comment><USER3> I like using a physical whiteboard. Maybe it is the smell of markers...</comment></comment>


Microsoft's 7 Foot Surface Hub Wall-Computer Will Set You Back a Cool $19,999 - <AUTHOR> http://techcrunch.com/2015/06/10/microsofts-7-foot-surface-hub-wall-computer-will-set-you-back-a-cool-19999/

<comment><USER2> $20k for something like this isn't exactly astronomical, I don't see how the pricing is absurd. Does anyone here even do hardware purchasing? Do you know how much a 1U or 2U pizza box can cost? Hint: Depending on specs, at least $10k USD, if not more.

If companies can find an application that fits their needs, the cost is justified.

<comment><USER3> We have a few Cisco TelePresence MX Series so this price range for that functionality is not absurd and with even better functionality (on paper).

<comment><USER4> How much ballpark does a Cisco TelePresence MX cost?

<comment><USER3> 5-40k (USD) per room depending on configuration. Not sure how much the backend servers cost. Under the hood it's XMPP basically. I will say they are solid and work very well compared to our previous home built solutions or Mondopads. Downside is they really are presentation/video solutions. (Edit: also cost) Whiteboarding is not something they do.

Edit2: Also they are not self contained computers like the Microsoft Surface Hub solution (which is good and bad)

</comment></comment></comment></comment><comment><USER5> I found the reporting wanting (but this is techcrunch :-) but lately have been thinking about this sort of application. Sort of an office view screen. Now that I've got a bunch more people I interact with regularly all around the world this sort of thing is more useful. But $20K isn't the price point where I expect these to take off. Especially given that a 4K 84" TV ([http://www.amazon.com/LG-Electronics-84LM9600-84-Inch-LED- LC...](http://www.amazon.com/LG-Electronics-84LM9600-84-Inch-LED- LCD/dp/B00B10UAAS)) is about $8k and a really nice machine to drive it and to OCV vision for knowing where you are touching it is less than $2K, the "make it" seems to be so much less than the "buy it" choice I wonder if it loses on that basis.

From a practicality point of view having a "whiteboard" that you can bring from meeting to meeting seems like a win, and if you can share it with someone else's screen in a remote location even better. And since you're probably replacing a projector set up in your conference room ($3K for a 1080p projector, $1.5K for a more modest one) that is a benefit.

I wonder if they will have these in their stores, it would be interesting to see one operate.

<comment><USER6> $7,000 for the 55" version. I'd expect a lot of businesses could get by with that.

</comment></comment><comment><USER7> I've been working with these for the last couple weeks, and I must admit it's pretty well done and incredibly useful for whiteboard brainstorming. Just the ability to have shared documentation updated in real time is very productive.

</comment><comment><USER8> If you can afford Cisco's equivalent stuff you can afford this.

Still: probably not a product they expect immense amount of orders for at this point.

</comment><comment><USER9> The price point is good for enterprise but don't expect to see them around. Surface Hub is huge opportunity though for other applications in markets that can't afford it.

</comment><comment><USER10> So their market is large corps that want to show off, and set designers for James Bond movies and police procedurals. (Can definitely see this on the likes of CSI: Cyber.)

<comment><USER11> You can whiteboard for people in the office and simultaneously screen-cast for those not in office. I can see how this can be used, especially since many of us have distributed teams.

</comment></comment><comment><USER12> Surface Hub == Big touchscreen TV, computer, MS Windows, true or false? Is there more to it than the packaging, and is this the only way to get that "more"?

</comment><comment><USER13> Aw come on! I gotta make my app look good on screens from 5" to 7 feet?

</comment><comment><USER14> I wonder when we'll get to the wall-screens of Fahrenheit 451.

</comment><comment><USER15> Why are expensive things described as cool?

<comment><USER16> It provides emphasis. It's been used for centuries (literally).

[http://www.etymonline.com/index.php?term=cool](http://www.etymonline.com/index.php?term=cool)

> _Applied since 1728 to large sums of money to give emphasis to amount..._

Also used in Great Expectations.

[http://literature.org/authors/dickens-charles/great- expectat...](http://literature.org/authors/dickens-charles/great- expectations/chapter-57.html)

> _leaving a cool four thousand to Mr Matthew Pocket_

</comment></comment><comment><USER17> I assume you're going to hear the fans on those things?</comment>


Apple Announces Full WebRTC Support in Safari 11 - <AUTHOR> https://blog.peer5.com/apple-announces-support-for-webrtc-in-safari-11/ <comment><USER2> WebRTC was the #1 most requested web platform feature for Safari. Now coming to macOS and iOS: [https://webkit.org/blog/7726/announcing-webrtc-and-media- cap...](https://webkit.org/blog/7726/announcing-webrtc-and-media-capture/)

You can even try it out now on Safari Technology Preview: [https://webkit.org/blog/7627/safari-technology- preview-32/](https://webkit.org/blog/7627/safari-technology-preview-32/)

<comment><USER3> I can't get many WebRTC projects/test pages to actually work on the new Safari preview. Is there anywhere they list the specific features implemented from the spec?

<comment><AUTHOR> Try running [https://test.webrtc.org/](https://test.webrtc.org/)

<comment><USER2> Unfortunately this test page uses legacy APIs that have been removed from the spec years ago, so it can't give an accurate assessment.

</comment></comment></comment></comment><comment><USER4> SO excited about this. Data-channel and all. Non-jailbroken torrenting on iOS at long last :P [https://webtorrent.io/](https://webtorrent.io/)

Also, definitely worth trying out this AR.js demo if you're running the beta: [https://freinbichler.me/apps/web-ar/](https://freinbichler.me/apps/web-ar/)

Always thought it was a little peculiar that the Media Capture APIs are tied to what is otherwise a very data/protocol-oriented spec.

Wish we could have had a camera feed in a canvas element on Mobile Safari a few years ago without having to wait for the entirety of WebRTC to be vetted. :P

\---

And now, for my own unrelated Web API peeve:

Beyond service workers and all that jazz, I'm a little bummed out that the Pointer Events API isn't even _listed_ on the Webkit Feature Status page: [https://webkit.org/status/](https://webkit.org/status/)

It just seems like such a pleasant unification of all of the input-type APIs (mouse, touch, pen, hypothetical future peripherals...)

At least touch events have a "force" property with Apple Pencil input in the meantime. No tilt though.

Maybe next year :/

<comment><USER5> How would this allow you to torrent on iOS without jailbreaking the device?

My phone, though an iPhone 6, seems to shut down Safari if I've been using other apps long enough. I can't imagine it staying alive long enough to torrent anything large.

<comment><USER6> Keep Safari active. You can use other apps in split screen while the file downloads.

<comment><USER7> No split screen on the phones (unless perhaps the plus size allows it, but I don't think so).

</comment></comment></comment></comment><comment><USER8> What WebRTC apps can we expect will be mainstream in, say, 6 years? I'm just trying to picture what this technology will allow (or replace).

<comment><AUTHOR> That's the $1B question. The obvious application is the video conferencing style hangouts, Skype (which are using WebRTC already). The nice thing about having video conf capabilities in the browser is that you can embed it in any web page and start do interesting things with it - like interactive lectures. Improved gaming networking is another vertical. We've built Peer5 (W17) on top of WebRTC to create a P2P CDN for Video streaming

<comment><USER8> What about a WebRTC version of Twitch.tv? Is that feasible in 5 or 10 years? Twitch does transcoding and I'm not sure how transcoding would work with WebRTC.

<comment><USER9> It would probably be possible for smaller communities today, given how cheap bandwidth already is. For comparison, I'm currently paying ~$13/mo for a (symmetric) gigabit connection.

The main reasons for transcoding are downstream bandwidth usage and codec support. WebRTC mandates VP8, so codecs shouldn't be an issue. Downstream bandwidth usage probably wouldn't be a major concern when it's viable to stream at 1080p to thousands of viewers from a home connection (though I doubt that's going to happen soon). So you could probably ignore transcoding entirely.

However, marketing would probably be an issue, since this architecture would prevent streamers from having more than about a hundred watchers, meaning that the big fish would stick to Twitch. That said, I suppose you could have a failover system, where larger streamers would switch to a relay-based system.

<comment><USER10> Where do you live? Internet is _way_ more expensive in the US.

<comment><USER9> Stockholm.

<comment><USER7> If you're lucky enough to have Google Fiber in the US it's $70/mo for symmetric gig, IIRC.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Wow, this has been a long time coming. So many shoddy video communication hacks can finally go away. This is huge.

</comment><comment><USER12> Should we assume mobile safari will also get WebRTC support, or is that a lot less likely to happen in the near future?

<comment><USER2> It's coming to both macOS and iOS in Safari 11 and iOS 11.

<comment><AUTHOR> Can you share a link please?

<comment><USER2> Here's the announcement on the WebKit blog: [https://webkit.org/blog/7726/announcing-webrtc-and-media- cap...](https://webkit.org/blog/7726/announcing-webrtc-and-media-capture/)

</comment></comment></comment></comment><comment><USER13> Does this mean Apple may actually implement Service Workers and Web Push in the next Safari?? :)

<comment><USER14> I hope not as Service Workers is an awful technology.

It is completely hostile to users. If I close a web page I expect everything related to that web page to stop. Immediately. I don't expect there to be lingering background threads consuming battery life, network data and disk storage. And in Chrome you can only discover service workers by enabling a Debug mode and memorising a specific URL. Exactly how does a non-developer figure out what is going on ?

If Apple had any sense they would ban service workers and instead propose use case specific, tightly focused and managed APIs that focus on security and battery life first.

Also just a hint at a future where Botnets are running in your browser:

[https://sakurity.com/blog/2016/12/10/serviceworker_botnet.ht...](https://sakurity.com/blog/2016/12/10/serviceworker_botnet.html)

<comment><USER13> Service workers were designed to only work during events which you opted into. Either because you loaded the site which is now making requests, or because you OPTED IN to receive notifications.

Think about it this way... why do you have to download an entire app just to use a site? Don't like the notifications? Turn the off.

<comment><USER14> Yes because ordinary users never, ever opt in to things they shouldn't. And because of that one opt-in mistake suddenly they have invisible service workers mining Bitcoins which they could never learn about since the discovery mechanism for service workers is currently non-existent.

Again, the concept of background tasks isn't necessarily a bad thing. But it needs to be locked down to specific use cases not a free for all allowing arbitrary JS to be executed.

<comment><USER15> So limit the amount of CPU/bw/etc. they can use, just like mobile platforms do for background apps?

<comment><USER16> Installing an app is a higher bar than tapping the "get out of my way" button on a modal dialog that some website just shoved in your face.

</comment></comment></comment></comment></comment></comment><comment><USER17> ive dreamt of this for years!!! so excited.

quick question: i noticed that the camera isnt available on iOS 11 if you put a web-app capable page on to your homescreen. when you open the page in full screen, mediaDevices is undefined. is that just an iOS beta bug?

<comment><USER18> It's not a bug. Spoke to an Apple engineer about this today at WWDC. There's security concerns enabling media devices for webviews outside safari, but it should be coming 'soon'.

<comment><USER17> Noooooooo

<comment><USER18> Yeah... I'd file a bug anyway though, might help them prioritise it.

</comment></comment></comment></comment><comment><USER19> So now they'll start supporting Opus at last, or they'll find another excuse not to support free codecs? Once they'll support it, AAC can be thrown out in the garbage.

And when are they going to support MSE[1] in iOS Safari?

1\. [https://en.wikipedia.org/wiki/Media_Source_Extensions](https://en.wikipedia.org/wiki/Media_Source_Extensions)

</comment><comment><USER20> Anyone else feel like Apple is the new Microsoft and they hold the world hostage by only updating their products every couple years with features we actually want? It seems like just as the unrest is about to hit critical mass they spring into action and implement just enough to placate everyone for another couple years.

</comment><comment><USER21> We're not out of the woods yet: [https://thenewdialtone.com/hold-apple-webrtc- ios-party/](https://thenewdialtone.com/hold-apple-webrtc-ios-party/)

<comment> TD-Linux Plan B is pretty disappointing, Chrome compatibility winning over standards compliance :(

</comment></comment><comment><USER22> I'll take a quick moment to share my favorite web app which uses WebRTC: Instant.io [0]. I use it all the time to transfer files among local devices, or to send medium to large files to friends.

[0] [https://instant.io](https://instant.io)

</comment><comment><USER23> It would be interesting to see surveys about mobile IPv6, will it get along with P2P? Will mobile users get P2P video this way or have the operators crippled end-to-end connectivity?

</comment><comment><USER24> TypeError: nativeMediaDevices.addEventListener is not a function

still some bugs maybe...

<comment><USER25> This is a capturing API, I guess?

Using webrtc-adapter, all of my webrtc code instantly worked. Though it doesn't seem to want to connect to firefox peers.

</comment></comment><comment><USER26> So, any one know how one might block WebRTC in Safari?

</comment><comment><USER27> Can it be disabled? (VPN privacy, and all...)

</comment><comment><USER28> YASSS!!! FINALLY!

</comment><comment><USER29> Yayaya!

</comment><comment><USER30> Still only supports proprietary codecs from what I understand. So not "full".

<comment> TD-Linux It does support Opus for audio! No VP8 yet, but halfway there.

</comment></comment><comment><USER31> I saw this yesterday on twitter and my thought was "they don't support webrtc yet?!? seriously?"

It sometimes baffles me how apple is holding up progress on the web - and that they aren't criticized more for it.

<comment><USER32> They're not holding up progress. They have different objectives, and chief among them is power efficiency. Chrome eats up a lot more battery life than Safari.[1] So did Flash (among other conflicts), and I think we all accept now that "holding that up" was good for the web in the long run.

Apple tends to take a little longer and suffer a little short-term pain to get it right in the long run.

[1] [https://daringfireball.net/2017/05/safari_vs_chrome_on_the_m...](https://daringfireball.net/2017/05/safari_vs_chrome_on_the_mac)

<comment><USER33> Apple has absolutely kneecapped web technologies. Mobile Safari has simple, egregious bugs that have been open for years. We're talking about things like being able to crash the browser with CSS or file selection, etc. It's impossible to make the case that Apple is just rejecting features for the sake of the user. The next question is why, and you'll need some creativity to come up with any other answer than pointing to the monolithic, money printing app store.

<comment><USER34> Any input that can crash the browser is a potential security vulnerability. Can you point me to an example of an inpatched crash in Safari that has been "open for years"?

<comment><USER2> We'd super appreciate bug reports of reproducible crashes and we definitely try to look at them. Bugs welcome at [http://bugs.webkit.org/](http://bugs.webkit.org/)

</comment></comment></comment></comment></comment><comment><USER35> Apple and Microsoft waited five years to deploy this thing. Given how quickly it was implemented and adopted by other browsers, I have to wonder what their motives were for deliberately not integrating it; because frankly they could've done it pretty quickly at any point in the last five years.

I remember having to integrate WebRTC through cordova (thank goodness somebody did it first) a couple years ago, and wondering why on earth Apple didn't find time or money for this. libwebrtc has been stable for years, it represents effectively no security risk, it performs well on all of their platforms. It truly boggles the mind.

<comment><USER2> WebRTC is actually quite complicated to implement and it took a large effort by a big chunk of the WebKit team, even though we had a lot of code that we could reuse. People have a lot of theories about Safari deliberately omitting one feature or another, but the truth is there's only so much we can do at once.

ETA: If you look at the page counts of all the required specs (ECMAScript APIs, WebRTC protocol specs, underlying codec and protocol specs like Opus and RTC) it adds up to multiple thousands of pages. By comparison, the whole HTML5 spec (current WHATWG version) is 855 pages.

<comment><USER35> I understand, though when it comes to WebRTC, there is an existing, efficient, stable implementation in a license which is compatible with WebKit and Apple's proprietary embeddings of it. You aren't going to be translating the WebRTC protocol diagrams and interfaces yourself. The main effort would be elsewhere (adapting it to Apple's platform TLS libraries perhaps, verifying the bindings, fitting it into the compositor, sandbox, etc.).

I would think the greatest barrier to integrating Opus would be getting Apple legal to agree not to sue other Opus adopters . Fair enough, but that's not five years worth of legal research. I would be gobsmacked if Apple bothered to write their own encoder or decoder just for WebKit, you don't need to read the bitstream format documentation.

And again, Apple has so much cash on hand that it takes the accountants five minutes to walk across a line on their balance sheets. Maybe the rest of you are busy, fine, but there are people who are qualified to put WebRTC in WebKit in the general public. Apple could send some money to the qualified people at Collabora, Igalia, or Ericsson Research (who I think have had WebRTC in Webkit since 2015).

All in all, it's absolutely bogus that Safari hasn't had WebRTC for at least two years already. You can make all the excuses you want, but this API drives more customer value than _any ES6 feature_. Nobody actually deploys ES6 on the web today, because it has forced browser vendors to completely reengineer their compilers, taking half a decade each, and as a result it has not been deployed long enough with decent performance to offer any value. WebRTC has been deployed for going on five years in valuable applications which are _otherwise completely impossible on the web_ , half the other crap has no userbase, and offers questionable tangible value.

<comment><USER36> _I understand, though when it comes to WebRTC, there is an existing, efficient, stable implementation in a license which is compatible with WebKit and Apple 's proprietary embeddings of it._

Just like with all of the other web standards, I'm pretty sure the WebRTC code is in the publicly available repo.

Obviously Apple isn't afraid to collaborate with other entities--Igalia did the CSS Grid implementation that ships in Safari and WebKit.</comment></comment></comment></comment>


Request for Balanced to support Bitcoin as a payout method - <AUTHOR> https://github.com/balanced/balanced-api/issues/204

<comment><AUTHOR> Conversion started as a result of Jon Matonis' article: <https://github.com/balanced/balanced-api/issues/44></comment>


Monitoring and Tuning the Linux Networking Stack: Sending Data - <AUTHOR> https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/ <comment><AUTHOR> If you enjoy this post, you may also enjoy the companion post which dives into the same level of detail, but for the receive side[1].

I set out to write all this up because so much of the existing documentation (including the man pages) is vague, incomplete, or nonexistent. FWIW, I think this is probably to be expected for a system as complex as the Linux kernel.

[1]: [https://blog.packagecloud.io/eng/2016/06/22/monitoring- tunin...](https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux- networking-stack-receiving-data/)

<comment><USER2> Can any of what you wrote be submitted as a patch to the documentation itself?

</comment></comment><comment><USER3> _It is impossible to tune or monitor the Linux networking stack without reading the source code of the kernel and having a deep understanding of what exactly is happening._

No, it isn't.

Sure, reading the source code won't hurt, but I'd wager that most people who have set up adequately tuned servers did not need to read a single line of the kernel's source.

Putting such a definitive statement right at the top of this document makes me feel far less confident in trusting what it says. Is everything in it going to be just as over the top?

<comment><USER4> I wonder how much of the linux kernel Brendan Gregg has read. I bet it is a decent bit. Also, this guy has posted numerous blogs on the very intimate details of the Linux kernel and even given talks on it. I was lucky enough to watch one of his talks last year @ Monitorama and it was my favorite talk of the entire conference for the level of technical depth it went into.

Whether or not you think he is good based on your dislike for the top doesn't make it any less of a fantastic technical post.

This was the talk I saw, and it was amazing:

[https://blog.packagecloud.io/eng/2016/06/29/monitorama-2016-...](https://blog.packagecloud.io/eng/2016/06/29/monitorama-2016-all- of-your-network-monitoring-is-probably-wrong/)

<comment><USER3> You seem to have got my argument the wrong way round, I wasn't claiming that people who can optimise networking haven't read the kernel source code, and I said nothing to do with the skill or knowledge of Brendan Gregg. I simply dislike such polarising, over the top "everything is black or white" statements.</comment></comment></comment>


Researchers just released profile data on 70000 OkCupid users without permission - <AUTHOR> http://www.vox.com/2016/5/12/11666116/70000-okcupid-users-data-release <comment><AUTHOR> src: [http://www.heise.de/newsticker/meldung/OkCupid- Wissenschaftl...](http://www.heise.de/newsticker/meldung/OkCupid- Wissenschaftler-veroeffentlichen-70-000-volle-Datensaetze-von-Dating- Seite-3208624.html)

</comment><comment><USER2> Publicly available data was made public! Everybody panic!

<comment><USER3>
      publicly available to OkCupid users

That isn't really "publicly available". You need to sign into an account with a password to view it. And before the account was created, the creator had to agree to OKCupid's terms of service agreement.

<comment><USER2> Needing an account to access it doesn't preclude it from being publicly available. And adding some terms that nobody with malicious intent would care about to the sign up process doesn't protect them from public view either. If someone posted your tax, pay, etc details on a torrent site you needed to sign up to before anyone could access them wouldn't you say they were publicly available?

<comment><USER3> I would say they made it available to the users of that torrent site.

There is a difference between "publicly available to OKCupid users" and simply "publicly available." When you lose the "to OKCupid users" you change the definition of public.

<comment><USER2> Sure, but "they made data which was freely available to members of a website freely available to visitors to a different site" is not a headline which is going to surprise or upset many people.</comment></comment></comment></comment></comment>


Ask HN: Why is clockify not open source? - <AUTHOR> Or more generally, why do free, privacy-respecting tools choose to not go the open source route? <comment><USER2> If it's not open source, how do you know it's a privacy-respecting tool?

<comment><AUTHOR> Because of their GT&C, I would at least hope that companies follow the law, and that the law is rather clear. This tool in particular (according to my google search) seems to be rather popular on HN, which increases my confidence a bit.

<comment><USER2> So... faith? I'm not accusing them of anything. Maybe they aren't harvesting your info.

I'm just pointing out that maybe you're asking the wrong questions.</comment></comment></comment>


Ask HN: What's your biggest pain point in your life? - <AUTHOR> <comment><USER2> I spend the majority of my focus and time on stuff I don't find meaningful. I'm a university student studying mathematics and work part time in buy side finance ~20 hours pr week. I want to work on my startup, but I work most days from 5 to 19 (a little later in weekends) so I can't find any focus or energy to begin working in the evenings on my startup.

I'm probably going to quit my job real soon...

<comment><AUTHOR> Having job + uni can drain any energy to work on your project

</comment></comment><comment><USER3> Doctors are over-specialised and have no real ability/incentive to track down problems. If you go to a GP with a complaint, the doctor will look at the most common causes of the complaint. If it doesn't fit, then they may send you to specialists. The specialists are useful if your GP guessed right as to what the problem might be, but otherwise they are completely useless. They do do a quick look to determine if you fall into their category of specialisation, but if you don't then you are out the door. You go back the GP, who may send you to another specialist. You keep getting shunted back and forth with each specialist saying, "Nope. Not me. Next." At every step you need to explain your problem and there is no continuity in the process. You aren't narrowing down the problem: you are only narrowing down the number of specialists who are willing to look at your problem. If you have an ailment that is even a little bit complicated, for example if it touches a number of different areas, nobody has an overarching understanding of what's going on. The GP only sees you for 5-10 minutes at a time and each visit to a specialist results in all of the information being essentially thrown away. The only person that has the ability to piece together the whole puzzle is the patient. However, they are the least qualified to do so. Without _considerable_ effort in self education, it is practically impossible to figure out what's going wrong. It's also embarrasing to ask questions because the doctors want you out of their office as soon as they realise that you aren't going to be treated by them (and if I'm cynical you aren't going to make them any money).

<comment><USER4> Not to mention the absolute abyss of useless care that is physical therapy. The same cookie cutter treatment plans are assigned to every patient. Any PTs that have real skill and interest in curing their patients (as opposed to symptom management for geriatric care, which is a huge majority of the market) don't accept insurance. I've been given almost the exact same home care program by 5 different PTs despite me describing what I've tried and didn't see results from, and I'm pretty sure it's because that's what their insurance allows them to prescribe. God forbid they try to dig in at the individual, underlying issues with a novel treatment plan that could open their practice up to liability issues.

</comment></comment><comment><USER5> > What's your biggest pain point in your life?

Having to work full time, but using 80% of my income to survive (tax, flat, food, transport..)

<comment><AUTHOR> Almost all your income is going for essentials, not much in the way of savings.

</comment></comment><comment><USER6> Feeling like I won't have time to do everything I want to. Which, ya know, I won't but I guess I just haven't been able to accept that yet.

Oh, and money. Not enough of it sadly but I'm young and it's early in my career so I'm hopeful.

</comment><comment><USER7> Not knowing what I want to do with my life. I'm in my 30s now, have hopped jobs a lot of times, and have some savings, but I feel more lost than ever.

</comment><comment><USER8> Every two years or so my software job will bring in a director from overseas and I have to go find another job. This has happened four times in 8 years.

<comment><USER9> OMG that would suck. From my experience, when they come from outside, not just overseas, they have an arrogant attitude that the locals 'just do not understand, if they did it my way...'.

Is it the industry you are in? Or is it because of the country you are in, that causes this. 4 times seems awful high.

<comment><USER8> I would say culturally these directors have been more on the same wavelength with the VP's and SVP's of the companies. That is I think it is more likely to pay a bribe or do a shady deal for a job in many countries. I'm not saying Americans don't do that, its just there are fewer willing.

Plus, the companies want to hire an outsider usually, not someone with political allies all over town. Third every company is in some stage of "replace all Americans with H1B's" and these directors are like brokers for H1B's. H1B's don't want an American manager either. Foreign managers don't want American employees because they have a lot more power in the workplace.

</comment></comment></comment><comment><USER10> That my skills keep me at a computer screen all day.

</comment><comment><USER11> Not knowing what are other people's pain points

</comment><comment><USER12> Being mostly stuck inside, having no outside relationships (har), for the next three years while Trump tries to kill us all off with covid.</comment>


How to use array reduce for more than just numbers - <AUTHOR> https://jrsinclair.com/articles/2019/functional-js-do-more-with-reduce/ <comment><USER2>
      function splitLineReducer(acc, line) {
          return acc.concat(line.split(/,/g));
      }
      const investigators = fileLines.reduce(splitLineReducer, []);

That's unnecessarily quadratic. So yes, definitely use the more readable `flatMap` (with appropriate polyfill):

      const investigators = fileLines.flatMap(line => line.split(','));

(The `flatMap` in the article is not an appropriate polyfill)

The object spread example has the same problem, like c-smile mentioned. Use a Map for lookups instead.

> Some readers might point out that we could get a performance gain by > mutating the accumulator. That is, we could change the object, instead of > using the spread operator to create a new object every time. I code it this > way because I want to keep in the habit of avoiding mutation. If it proved > to be an actual bottleneck in production code, then I would change it. ↩

Avoiding (very local) mutation because it's an FP bad word in a language like JavaScript is just a terrible way to go about things. Also, this turns out to be an actual bottleneck way more often than people notice.

<comment><USER3> > Also, this turns out to be an actual bottleneck way more often than people > notice.

I wish more devs -- particularly web front-end devs -- tried out their work on something that isn't a top-of-the line developer computer. There are plenty of devices out there that are computationally constrained and/or memory-bounded. Moreover, no one ever runs these things in isolation. So, while profiling in isolation makes a ton of sense to rule out external factors, in the real world you're competing with all the other open tabs and windows. That's a tricky problem to model, of course, but it doesn't mean we shouldn't try.

<comment><USER4> > I wish more devs -- particularly web front-end devs -- tried out their work > on something that isn't a top-of-the line developer computer.

I agree, and I am, and I do.

I held out on laptop from 2009 until recently, it had a core 2 duo, It was (and is) a really good machine for showing up sloppy performance hungry websites, and has been the source of a few of my rants here on HN when discovering some stupid side JS animation saturating one of it's cores unnecessarily.

I agree there's a lot of shitty JS code out there. But there are a few of us web devs that care, and will do anything we can to prevent the crap we see around us.

<comment><USER5> Slow machines aren't good to just easily notice bad websites, they're also good to notice bad server-side code and native apps.

</comment></comment></comment></comment><comment><USER6> At my current project we try to do everything as functional as possible (we're backend developers using node).

After a year or so of trial and error, we have pretty much stopped using reduce. The reason is that it pretty much always causes the code to be far less readable, specially for new devs that come from more object oriented approaches.

With the .Map, .foreach and .filter, methods we don't usually have that problem, people get the hang of them quite quickly and find them more elegant, but reduce always seem to require to stop for a few seconds to learn what it's doing.

<comment><USER7> I think it's reasonable to expect engineers to be able to learn how .reduce works. It's part of JavaScript, after all.

If a new hire doesn't know (a junior dev, or someone without experience in JS/Scala/etc.), an hour of reading plus coding exercises should be plenty to get them up to speed (if it's not, that would be a red flag to me, and could be a sign of poor performance to come in other areas, too).

<comment><USER8> The distinction isn't "can possibly learn" but "can clearly and immediately understand while doing the real work". It's one thing to sit down and play around with alternate styles, code golfing, etc. but for production work it's usually best to pick the most understandable way to reduce the cognitive overhead so when someone is making a change, debugging, profiling, etc. they're not instead spending time decoding the clever trick their predecessor (possibly them six months ago) used.

This is particularly true with religiously following functional style in languages which weren't designed from the ground up to work that way. The results usually take more time to understand and are often slower because the runtime is not as optimized for uncommon styles.

</comment></comment></comment><comment> c-smile This sample

        function keyByUsernameReducer(acc, person) {
          return {...acc, [person.username]: person};
        }
        const peopleObj = peopleArr.reduce(keyByUsernameReducer,   {});

has O(n*n) complexity and memory consumption of the same magnitude.

This, while being not so functional pure, is better I think:

        function keyByUsernameReducer(acc, person) {
          acc[person.username] = person;
          return acc;
        }

But still... needless function call on each iteration.

<comment><USER9> I too prefer to use the "inefficient" notation because it just feels wrong (kind of an antipattern in the functional sense if you will) to mutate the argument. And as long as you are not dealing with a huge input list, this doesn't really matter at all.

Also, why would the memory complexity be n * n? Sure, a new object is created in each iteration, but its not like you have to keep the previous ones in memory - all but the last one can be garbage collected.

<comment><USER10> There's nothing wrong with mutating an argument. The whole reason JS passes objects by reference is so that you can do it.

<comment><USER11> There are tons of wrongs with mutating arguments. The fact that it is possible to mutate arguments in JavaScript does not make it a good idea. Such functions cannot be trusted (how can you know what happens when you call it?), and they are hard to test.

There is _always_ a better alternative to mutating arguments in a function.

<comment><USER12> Sure, but here it's a local mutation, it won't leak to the rest of the program. There is nothing wrong with mutating acc in reduce.

<comment><USER13> I agree, should you always test the reducing function separately outside the reduce? And if so, what's the real benefit of not mutating accumulator? Seems silly to just copy a transient value which is immediately discarded and then do it for all reduced elements. Does the original reference to the object even stay during the iterations? Hmm, I guess it does.

To me it seems weird to be so puristic about a simple reduce-function, which by-design leads you to mutate the accumulator. I mean for object-accumulators it definitely is just a massive waste to _not_ to just mutate the argument directly without copying. Although as a disclaimer I have to say I am big fan of simple code, were it FP or not. So if you have a messy reduce-function I guess having it immutable makes it a somewhat easier to manage.

</comment></comment></comment></comment></comment></comment><comment><USER14> I see a lot of for loops.

Working on a project in which there are really nary such resources available, and I'm stuck with only 'for' ... guess what? I don't miss much of these functions; I just don't find myself reaching for them, wishing I had them.

Either a for loop, or a couple of lines of code, or _gasp_ you end up writing a short custom utility function to do specifically what you want, which is generally better optimized anyhow.

<comment><USER15> Usually it is the other way round: you miss what you had somewhere else and learned to love. When you go back it hurts. Try a 800x600 monitor nowadays and you will cringe. For me after using functional constructs a lot I find myself wishing for them in languages where they are not available that easily.

<comment><USER14> Yes, we miss nice screens when we go back to crappy ones, agreed, but this is my point: I don't miss most of these lodashy functions when they're not there. Maybe a little bit.

</comment></comment></comment><comment><USER16> I'm not opposed to using `reduce` where it solves a problem in a readable or performant way, but it seems there's a trend among JS developers recently (I noticed this in the react ecosystem) to use `map` / `reduce` for _everything_.

Sure, _some_ problems can be solved elegantly and efficiently with it, but a lost of the time it just impedes readability, and maintainability of the code. A `for of` loop (or your C-styled for loop) would sometimes be better suited.

<comment><USER17> Wouldn't map and reduce be more readable if you were used to reading it? I've been using a lot of Elixir and Ruby, both of which use map and reduce, and neither of which make extensive use of for loops. Map and reduce are what I am used to reading.

<comment><USER16> When you have some imperative code inside the reduce function and you have to go out of your way to achieve something (ie, immutability by using Object.assign, spread, or Array.prototype.concat, etc) and on top of that have some conditional and imperative code, then the reduce function stops being elegant, and looks horrible.

Sure, every problem can be solved in a functional way, but JavaScript is not a purely functional language. Why limit yourself to a subset of the language? IMO, you should use the _best_ tool you can for the problem. Sometimes that's reduce, sometimes it's not.

Also, I love Ruby (and used Elixir), and it's not really a comparison that makes sense, they're different languages with different APIs, syntax, and there's a category of problems in JS you never have to think about when using Erlang/Elixir, or Ruby. I could say that I'm used to seeing maps and folds in Haskell code; doesn't really mean anything in this discussion.

</comment></comment></comment><comment><USER18> Reduce is also known as "fold" in other languages.

[https://en.wikipedia.org/wiki/Fold_(higher- order_function)](https://en.wikipedia.org/wiki/Fold_\(higher-order_function\))

And especially when using immutable data it can be used for iterating, traversal (lists and trees, like say an in-order fold), filtering and other things. But there it is not an just an nice trick like for JS, but it is the canonical way of doing things.

<comment><USER19> Reduce is slightly different from fold because it does not use an initial value, which means its semantics differ somewhat with regards to restrictions on types.

<comment><USER20> Reduce in Javascript has the initial value as an optional parameter.

<comment><USER19> And it doesn't do types, so that's not really an issue either…

</comment></comment></comment></comment><comment><USER21> To balance all the negative comments about readability, I do think .reduce is often more readable than its traditional alternatives.

Simply because its use cases are always the same so you can guess the code without reading it:

* Reducing an array of numbers, with a number as initial value? => We are going to do some operations on those numbers.

* Reducing an array of objects, with a number as initial value? => We are going to do some operations on one or several props of those objects.

* Reducing an array of objects, with an empty object as initial value? => We are going to create a key/value object with computed key names.

Then just by reading the name of the variable on the left of the assignment, you know exactly what's going on.

And if you don't need to know about the details, you can just jump to the next statement.

        const products = [product1, product2, product3]
        const sumPrices = products.reduce(/* I don't need to read this */, 0)

        const users = [users1, users2, users3]
        const usersByFirstname = users.reduce(/* I don't need to read this */, {})
        const usersByLastname = users.reduce(/* I don't need to read this */, {})

</comment><comment><USER22> Reader mode is a huge UX upgrade here. Recommend it.

<comment><USER23> It doesn't show the code's comments though.

<comment><USER24> pocket's reader mode does though. (and the rest of the text looks pretty much identical to firefox's reader mode)

</comment></comment></comment><comment><USER25> reduce() is how you get imperative programming in a functional setting. JS is a perfectly good imperative language; for all these examples, you may as well use a for loop.

Personally I prefer a functional style, but if you're going to use an imperative style, just use JS's built-in imperative for loop and assignment operators.

</comment><comment><USER26> I seriously hope nobody takes the advice in this article seriously.

Here are the conclusions you should take away from the article: Don't use reduce to reimplement map. Don't use reduce to reimplement flatmap. Don't use reduce to reimplement groupBy. Don't use reduce to reimplement filter. The minMaxReducer is the only legitimate use of reduce in the entire article.

The above functions require less boilerplate code. With reduce you will have to write additional bookkeeping code for the accumulator and without mutable data structures [!] it would be incredibly inefficient.

[!] We are far away from functional programming at this point.

</comment><comment><USER27> While we're on the subject of reduction, I really think transducers [0] deserve a mention.

The general idea is to stack operations and use reduce to perform the entire transformation in one go, as opposed to chaining calls to map/filter etc.

Which means first class transformation pipelines and less wasted effort among other things.

[0] [https://clojure.org/reference/transducers](https://clojure.org/reference/transducers)

</comment><comment><USER28> When EcmaSCript 2019 hits the shelves it will have flatMap(). flatMap is the "corner-stone of monads" (poetically speaking) at which point monads will lose much of their mystique and things will be much advanced in the programmer land. You can use monads where you need them.

[http://2ality.com/2018/02/ecmascript-2019.html](http://2ality.com/2018/02/ecmascript-2019.html)

More on ES2019 at [https://medium.com/@selvaganesh93/javascript-whats-new-in- ec...](https://medium.com/@selvaganesh93/javascript-whats-new-in- ecmascript-2019-es2019-es10-35210c6e7f4b)

</comment><comment><USER29> It's funny to see other perspectives. I've never used array reduce for numbers.

</comment><comment><USER30> Optimize for readability above everything else. Almost all of these examples I'd argue would be better suited for something like .map(). Little point in being overly cute, and if you are working with arrays large enough such that doing multiple passes is that much of a performance hit client-side, you have other issues going on.

<comment><USER31> > Almost all of these examples I'd argue would be better suited for something > like .map()

Roughly half of his examples take an array and return either a differently- sized array, or a different data structure altogether. I can't imagine how one could argue for a map in these cases.

<comment><USER32> Use the right tool for the job. Array to potentially different sized array? Use flatMap (which he implements in his example, albeit not it an optimal way). Array to single object or value? Use reduce.

</comment></comment></comment><comment><USER33> <deleted useless comment>

<comment><USER34> Please don't do this here.</comment></comment>


How  To Make $1000 Per Month In College - <AUTHOR> http://www.collegefeed.com/blog/5-ways-make-1000-month-college/

<comment><USER2> These ideas are all right, but they don't necessarily address growing useful talents. Sure, managing your time effectively by grocery shopping every day helps you with your time management skills, but so does everything else.

I also do not agree with the idea that only college students can do these five things. A student is like any other person, and they are capable of learning any "useful" skill that they are interested in, to a certain extent.

If you really make it your goal, passively earning $1,000/month becomes easy. Then $2,000; $5,000; and $10,000 are just simple milestones.

If you're looking for a way to make that much, find someone who is making an equal amount by doing something you're interested in. Copy success, and adapt to your situation.</comment>