The Case Against Boeing - <AUTHOR> https://www.newyorker.com/magazine/2019/11/18/the-case-against-boeing <comment><USER2> This reminds me of the debate around not-quite-self-driving cars. Saying the product is safe to use, but that the user must be ready to do X immediately, despite evidence that the users you're selling to won't be ready to do X immediately. Then when people die you get to say it was totally safe, if they'd just done what they were supposed to do.

Or we could just design products that will be safe in the real world, rather than ones that could have been safe in a utopia of perfect people.

<comment><USER3> That comparison falls flat because planes are filled with technologies where the pilot has to be ready to do X and it works fine (see autopilot).

<comment><USER4> On planes pilots generally have time to take over if the autopilot fails. Falling from ten thousand feet takes a few minutes.

On cars, if autopilot fails, the driver might have a fraction of a second to recognize the failure, take over from the AI, and initiate corrective action. Generally, there isn't sufficient time for any of these steps, let alone the first one.

</comment></comment></comment><comment><USER5> This is off-topic, but WalterBright's participation here has reminded me of my own weaknesses. Everything I have read about the 737Max has put a pitchfork in my hands to go after Boeing. Walter's are the first comments I have read that make me think perhaps Boeing wasn't completely, utterly, criminally unjustified.

It is interesting that Walter has chosen to jump in like this, and to hold his position so firmly so publicly. He must realize that this action threatens to paint him very unfavorably to a lot of people. There seems to be no reason for him to speak out and take such a risk.

To do this seems to me to require either a certain level of stupidity or a certain level of conviction and courage. My impression is that Walter has considerable courage and some motivation to try to counteract public ignorance.

FWIW, Walter's courage has given at least one person pause. I'm going to put the pitchfork down for a little bit. Boeing still isn't on my good list, but now I admit that I don't know as much about this as I thought I did.

<comment><USER6> Can you be a little more specific about what WalterBright said that changed your mind? Because the only thing I see that could possibly be considered a mitigating factor is this:

> Both the LA and EA did make the adjustments within 10 seconds. They then did > NOT throw the cutoff switches

(Emphasis added, because I missed this the first time I read it.)

If I squint hard enough I guess I can see a tiny hint of merit in the argument that the fault for the two crashes lies at least in part with the pilots because they failed to throw the cutoff switches. But that seems like a mighty thin reed to me. Have I missed something?

<comment><USER7> I don't think you have. Bright's arguments have focused entirely on the design of the MCAS software, and have as far as I can tell completely ignored the fact that that software, driven by input from a single AoA sensor, creates a very short critical failure path which requires immediate and precise human intervention to avert a fatal accident. That such human intervention was imperfectly performed in two cases does not indict the humans in question, so much as it indicts a design which errs so far on the side of unsafety that perfection in human behavior is required to prevent it killing everyone on board a commercial aircraft.

Any competent engineer knows that a design which requires human perfection for safety is a design not only doomed to failure, but a failed design in itself. At least one Boeing engineer raised this very concern during the 737 MAX design process, only to be quashed by management. It would be invidious to suggest that at least one ex-Boeing engineer should argue in the defense of that design out of any motivation other than a genuine conviction of the merit in his argument. But conviction alone doesn't suffice to render that argument meritorious, and I'm surprised and disappointed to see anyone here or elsewhere claim otherwise.

<comment><USER6> Thanks, but I really would like to hear what supportlocal4h has to say about it. You're just repeating the party line. (And just for the record, I agree with the party line. But I think it's important to listen to and understand dissenting views.)

<comment><USER5> This it's how I read it:

1\. Boeing is not blameless. 2\. Boeing has a point about MCAS issues manifesting exactly like another well-known event in other models and having the exact same solution. 3\. The well-known solution to the well-known event is one that pilots must memorize because they don't have time to look it up. 4\. The pilots seem to have demonstrated that they recognized the problem and, in fact, executed the well-known solution in time. They just failed to complete all the steps for some unknown reason. 5\. Points 2-4 don't mean that Boeing is perfect. MCAS needs to be fixed. But it isn't completely absurd to argue that MCAS really is so similar in its misbehavior and so identical in the correct response that a reasonable person might expect pilots to do the right thing even if they had never heard of MCAS.

Taken together, this paints a picture to me that is different than the completely evil, conniving picture I had. I'm not sure where to draw the line between them, but probably not on the extreme end where I had it.

But my point is not so much about Boeing. I was observing the actions of a person who took what I expect to be a very unpopular stand in the face of overwhelming popular opinion. For what? Who cares if somebody else is mischaracterized? There's nothing you can do about it except get yourself muddy. Just let it happen and keep your head down.

I don't know why Walter is speaking up now. I'm not sure how much it changes my opinion. But I still tip my hat to a person who will say what they think is right even when they know they will be burned at the stake for it.

<comment><USER6> Thanks for the response. Two follow-up questions:

> MCAS issues manifesting exactly like another well-known event in other > models and having the exact same solution

By "another well-known event" do you mean a runaway trim? Because if you do, then you're mistaken. MCAS and runaway trim differ in significant ways. And if you don't, what do you mean?

> I don't know why Walter is speaking up now.

Have you considered the possibility that he's a shill?

<comment><USER8> > Have you considered the possibility that he's a shill?

A fair question. I left Boeing's employ (as a flight controls engineer) in 1982. I am not a spokesman for Boeing, paid or otherwise. The facts I've presented here are all public information (though routinely omitted from sensationalist articles about it). My interpretation of those facts is mine alone.

We'll see what the final NTSB report says. They have earned a reputation for going where ever the facts lead them, regardless of political pressure. I sincerely hope they continue with this tradition, as it is the only way to make airline travel safe.

This highly political case will surely test the NTSB's commitment to dispassionate examination of the facts. We shall see.

<comment><USER6> > I am not a spokesman for Boeing, paid or otherwise.

Isn't that exactly what an effective shill would say? It could even be true. "Shill" and "spokesman" are not synonyms.

FWIW, I went back and re-read some of your comments in other branches of this thread and it's really hard for me to figure out what your position actually is. For example:

> It's true that if the MCAS software requirements weren't inadequate, the > accidents would not have happened.

Apart from being a nearly-impossible-to-parse triple negative, it's just absurd on its face. No _requirements_ can ever prevent an accident. I can write down as a requirement: "MCAS software must never cause the plane to crash." But obviously the planes did not crash because someone failed to write down that requirement.

If you're really a flight controls engineer then you obviously meant something else. But have no idea what that something else could possibly be.

> But I don't see why the shortcomings in the MCAS software design > requirements were the result of cost savings.

Again, it is hard for me to wring any plausible interpretation out of this sentence under the assumption that you are well informed. It is well known that the reason MCAS exists at all is because Boeing attempted to make a radical change to an existing airframe design without getting it re- certitifed, and the reason for doing that was cost savings, both for Boeing and its customers. What other underlying reason could there possibly be for MCAS to exist at all?

> I did not defend Boeing's MCAS design.

OK, but do you see how someone could come away with that impression?

<comment><USER8> > Isn't that exactly what an effective shill would say?

Of course. There's no telling how deep this conspiracy to point out publicly available facts goes :-)

> No requirements can ever prevent an accident.

That's not what I meant by requirements. Boeing came up with a set of rules for what the software must do in each situation. This is called the requirements specification for the software.

Anybody who contracts with someone to write some software comes up with such a specification.

> What other underlying reason could there possibly be for MCAS to exist at > all?

There's nothing at all wrong with the concept of MCAS. There's a long history of flight control augmentation in jet airliners to make them behave better. In fact, you cannot control a jetliner at all without augmentation, it's too fast and heavy. It's the implementation that was faulty.

The B-17 was perhaps the largest successful airplane with no augmentation, and a strong man could barely handle it (source - my dad was a B-17 pilot).

The 757, which I worked on, has fully powered controls. The control column just opens and closes valves. In order to prevent the pilot from inadvertently making violent maneuvers a hydraulic "feel computer" was added to push back on the stick to fake the behavior of a manually controlled system. The forces it imparted had to be dialed back to accommodate the advent of female pilots, which caused some worry that the men would overcontrol the airplane. Fortunately, that turned out to not be a problem.

> OK, but do you see how someone could come away with that impression?

I not only never defended MCAS' design, I wrote that it was faulty several times. You should ask the someone why they conclude the opposite.

<comment><USER6> Fair enough. Thanks for the reply.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> >Good people in a bad system is still a bad system.

That line right there is essentially the same response I had for the Langewiesche's piece. It is not an excuse to pawn off the accountability for a catastrophic loss to the pilot when even the basic design is as fraught with failures to deliver even basic sanity checks as the MCAS system was. Make no mistake either, the issues that were found were _basic_. FMEA was not performed once, but never updated because it wasn't legally required, nor was a full fault-tree enumerated or kept consistent through the system's lifetime. Either of which would have forced a consideration of what would happen in the event of a sensor failure. Furthermore, the overall architecture of the flight computer failed to comply with design requirements that require no single point-of-failure which would have been revealed by doing what amounts to a textbook case of "what is the worst conceivable bit flip that could possibly happen right now?"

This is one of the few points I tend to respectfully differ from WalterBright on. I don't give a damn if every pilot were a Chuck Yaeger or Sully clone. That plane was dangerous by design.

A dangerous plane flown by a Good pilot is still a dangerous plane. There is no place in something manufactured to be deployed in a careless or cavalier manner, and the MAX rollout checks every box for organizational negligence in my book.

I'll let blame rest with the pilot in so much measure as it is do, but a machine that will actively frustrate its operator, while endangering the lives of everyone using it is a machine whose place is in a scrapyard; not in the sky.

<comment><USER8> We are in agreement that the MCAS design was dangerous. I don't think we disagree at all on the points you mentioned.

</comment></comment><comment><USER10> "Boeing decided to place the engines farther forward, just in front of the wing. The new position, and the greater thrust of the engines, produced an aerodynamic challenge during a maneuver called a windup turn — a steep, banked spiral that brings a plane to the point of stall, which is required for safety tests, though it's rarely used in typical flying."

This is a curiously disingenuous statement. Not only at 'windup turn' and not only for "safety tests", but most importantly when the engines were at maximum thrust such as at take off. Causing the air-frame to experience a pronounced nose-up attitude. The nacelles adding even more upward thrust.

'Boeing settled on a software feature called the Maneuvering Characteristics Augmentation System. As the nose of the jet approached a high angle, suggesting an oncoming stall, MCAS would adjust the stabilizer on the plane's tail, pushing the nose down, to alleviate the slackness in the control column. "They were trying to make it feel the same, so the pilots wouldn't require training,"'

No, they didn't tell the pilots as this would require retraining and this would require re-certification.

"Boeing considered the MCAS feature to be so minor that it removed mention of it from the 737 MAX's pilot manual."

Boeing lied by omission, that's why when MCAS kicked in on those two crashes the pilots were unaware of MCAS and had no way of knowing how to recover from an MCAS induced nose dive. It was Boeing executive decisions killed those people. If this had happened in the US there would have been uproar by now.

</comment><comment><USER8> It's true that if the MCAS software requirements weren't inadequate, the accidents would not have happened. It's also true that if the pilots had followed the runaway trim procedure, like the first Lion Air pilots did, like was reiterated to all MAX crews by Airworthiness Directive, the accidents would not have happened.

But I don't see why the shortcomings in the MCAS software design requirements were the result of cost savings.

<comment><USER11> Maybe one general remark, from one engineer who spent half his professional life in aerospace to another. Aerospace is, rightly so, proud of the whole industries relentless pursuit to eliminate errors, improve systems and learn from accidents. Your argumentation, in the whole discussion, conveys a different image and does no favour to the sector in general. Some people are already afraid to fly, so the very least we all can do is to be open and honest about errors in the system and the actions taken to prevent the same accident from happening twice.

And generally on engineering. If a system, regardless of the application, fails I consider it bad engineer behavior to single out the user. Systems, especially in aerospace, include everything from design over manufacturing, software, the parts to maintenance, logistics and ultimately training. Failure in any single one of these means failure of the system. Which directly implies all entities involved in development and certification. Failure in more than one is catastrophic. Defending it is bad engineering. Just my 5 cents.

EDIT: MCAS relied on a _single_ AoA sensor. Non-redundant safety critical systems in an aircraft? Seriously?

<comment><USER8> > Defending it is bad engineering.

I did not defend the MCAS software design. Not once. Quite the opposite.

> the very least we all can do is to be open and honest about errors in the > system and the actions taken to prevent the same accident from happening > twice.

I totally agree with that. That also means being open and honest about all contributing factors to these crashes.

<comment><USER12> I've read all your responses in this thread, and to be honest, I don't really understand what point you're trying to make. I don't really see anyone else arguing against the fact that there are things that the 2 crews could have done to not crash the plane, and that their actions contributed to the crash. But is there something you disagree with the following?

1\. In a safety critical system design, any change that results in fallible humans being more likely to crash their plane into the sea means the fault lies with the system, not the individuals.

2\. I think people are (rightfully IMO) so angry with Boeing because so many of their actions look like they were cost-saving measures. If the system worked exactly as it did, but Boeing had been very clear about the difference in handling MCAS caused, which would likely have required recertification and additional retraining of pilots, I think people would have at least been somewhat more sympathetic. But it looks like so many of the MAX design constraints were driven by the bean-counter directive of "don't do anything that would require recertification", and that's why people are pissed.

<comment><USER8> > that their actions contributed to the crash ... the fault lies with the > system, not the individuals

I believe these two statements are contradictory. The pilots were a contributing factor to the crashes. This needs to be investigated to determine why they did not respond appropriately, and corrective action taken. In addition to Boeing correcting the MCAS system, and the maintenance issues.

All contributing factors must be accounted for.

> I think people are (rightfully IMO) so angry with Boeing because so many of > their actions look like they were cost-saving measures.

Some of this anger seems to stem from inaccurate, incomplete, and sensationalist reporting, such as the cost saving one. The problems with MCAS were in the software requirements for it. Not bugs in the software, not outsourcing the programming, not in the design of the airframe, etc. The fix is in the software, too. Using the correct software rules in the first place would have cost the same amount of money. Having the MCAS software compare the two independent AOA sensor readings would not have cost more money.

</comment></comment></comment></comment></comment><comment><USER13> When the FAA Chief of Aviation Safety says there was "nothing he could have done", that is sign of deep systemic problems where someone else is to blame.

</comment><comment><USER14> I'm an Aerospace Engineer, currently working for the U.S. Gov, but have spent time on the Industry side. I don't have a thesis per se after reading this, but several thoughts:

\- I don't think it's unfair to vilify Boeing's accumulated divergence from "doing the right thing". On the other hand, it's quite sad that it takes significant events like this to force anyone to act against the long-term pressure of corporate behavior that leads to such events.

\- As per a thread I had with WalterBright, [https://news.ycombinator.com/item?id=21037522](https://news.ycombinator.com/item?id=21037522) , I agree Airbus has a number of significant flaws in their vehicle management systems for which there has been insufficient criticism and action.

\- It's not easy being on the side of the gov/regulators. There is continuous pressure from industry, and from up the management/political chain, to be a cooperative partner. Especially in light of how quickly industry can execute tasks, it's very hard to say "we need to take a pause" or "we need to go back, do some more homework, and be deliberative about this". If the gov/regulator is excessively slow, there are concrete costs that industry incurs. These realities, with the continued pressure, have trended in the U.S. to lead to ultimately less effective oversight.

\- The U.S. Government insufficiently values in-house technical expertise. In the aerospace realm, NASA is the principal exception. But within the DoD and FAA, while there is is technical expertise, much heavy-duty technical lifting is done by FFRDCs (e.g., Aerospace Corp., MITRE's CAASD, the national labs) or UARCs (e.g., Johns Hopkins Univ's Applied Physics Lab). In my view, the DoD and FAA should build in-house engineering capability sufficient to properly oversee and advise major programs without having to outsource as much as they do. You cannot do an effective job overseeing complex engineering developments if you are insufficiently technically-competent. The DoD is starting to realize this and places like AFRL are starting to swing back toward that direction, but there's a very very long way to go. If you are going to effectively push back against industry pressure, you have to be equipped to make strong technical arguments, not just appeals to precedent or vague statements about risk.

\- If you can find people with the right mindset and competence levels, it's better, in my view to have ex-Industry engineers working for the government. Those that go straight from school to government don't often have direct experience as practitioners, and as per my previous point, that often makes them less effective than they could be.

\- "Follow the plan," from the article, sounds exactly like what I've heard from Boeing. The article captured well the context and implications of that kind of talk.

\- "... engineers had to accept that they were no longer the center of the universe" really resonated with my own experience at another (non-Boeing) large American aerospace company. I was told by the man in charge of a major subsystem discipline that "engineering is out of favor [with the company management]". He was an engineer and on the side of engineers, he was just telling it the way it was. I couldn't believe what I heard then, and decades later, still can't believe it. How can engineering be "out of favor" in a company that specifically engineers systems at the edge of what humans can accomplish in hardware? I think you will find most large American aerospace companies helmed by people who really see no irony in making statements like that.

\- The aerospace industry is not one I would encourage my children to work in. I'm driven heavily by my passion for aerospace - it's an integral part of my identity. But it's really hard in industry to find job security, avoid rampant pigeonholing, avoid corporate mistreatment, work on multiple well-executed flight programs in your career (the equivalent of "shipping" software), and generally work somewhere where there is a strong corporate motivation to "do the right thing". It's a lot harder than in software for the corporate culture to not permeate everything around you because of how capital-intensive the field is. Also, the U.S. Government sucks as a customer, which makes it harder for small companies to thrive in the field. The job security issue can go away if you work in government, but then your ability to be an implementer (why a lot of people become engineers) also diminishes.

</comment><comment><USER15> >Boeing instructed pilots to deal with excessive downward pitching

That is my favorite newspeak so far.

<comment><USER10> @ReptileMan >> Boeing instructed pilots to deal with excessive downward pitching

> That is my favorite newspeak so far

Going by the faded out aspect of your post, someone here doesn't like you quoting facts.</comment></comment>


The Non-Maximizing Maximize Button - <AUTHOR> http://www.codinghorror.com/blog/2007/07/the-non-maximizing-maximize-button.html

<comment><USER2> Speaking for the blind.. Microsoft's interpretation is much more helpful when viewing text.</comment>


Linux – The beginning of the end? - <AUTHOR> https://www.dedoimedo.com/computers/linux-beginning-of-the-end.html <comment><USER2> > You cannot expect people from Finland, Spain, Turkey, Namibia, or Japan to > behave the same way, talk the same way, express themselves the same way. You > cannot expect them to just normalize to a cookie-cutter template and move > on. That does not work. And yet, that's the expectation, because that's how > the US-centric IT world is designed.

This. Right here. The fanatics in the OSS world (and Tech at large) seem to have forgotten that Silicon Valley != The World. This is not 1984 with a standardized society defined by the Big Brother in Menlo Park.

You will find that most of these "cultural/offensive" flame wars in tech are fought because someone forgot to step out of the silicon valley bubble they reside in. Take what happened with Redis. The Master/Slave terminology does not raise much eyebrows outside of USA simply because these parts of the world did not have large scale slavery of black people. And yet some SV people expect to everyone to know American history and culture. They seem to live in a dream world where only the American culture exists and then get violent when the reality hits them.

And before someone comes with a respect and work with my culture shtick, please remember that it is a two way street. We are not under any obligation to respect only your culture and mannerisms. You also have a responsibility to understand other cultures and respect them and understand their mannerisms and way of thinking.

<comment><USER3> > The fanatics in the OSS world (and Tech at large) seem to have forgotten > that Silicon Valley != The World

When it comes to attitudes and languages, Silicon Valley is sometimes quite different than tech in the rest of the US. As a developer in the northeastern US, one of the adjustments I've had to make in working for an archetypal Silicon Valley company is to the way people express themselves and particularly how they express disagreement or criticism (i.e. in a way that can be interpreted either as more gentle or more passive-aggressive depending on context). You raise a good point, but I think the differences are even greater than you (or the OP) think.

Of course, talking about this on extremely SV-centric Hacker News might not achieve very much.

<comment><USER4> Yea, if you've been in the SV bubble for too long you might not even perceive it!

One of the biggest cultural things I struggled to get used to when I moved out to the Bay Area for work (originally from the northeast too), was the extent to which I needed to constantly self-censor and water down my wording to the point of meaninglessness, simply to avoid offending someone or coming across as too harsh. People out here have such thin skin, and you're always walking on eggshells when you need to disagree with something. It's a kind of newspeak, where it colors every interaction with people and makes it impossible to deliver certain messages effectively, without sugar-coating or couching with "probablys" and "maybes". When you take this culture and these rules and assume the entire world plays by them, you're likely to end up looking totally out of touch.

EDIT: Self-censored a little. :-)

<comment><USER3> Here's a question I often like to ask myself about people I interact with:

> What is this person's equivalent of "F you"?

For a typical east-coaster or northern European it's likely to be exactly as in the question. ;) For some people, "I'm not sure I 100% agree" is about as close as you'll ever get. The left-coast average seems to be _much_ closer to the second option. I'm not saying it's a bad thing - in fact I find it quite pleasant - but it can trip you up until you get used to it. At my last job, it took me years to figure out how to interpret my Indian colleagues' responses correctly (if indeed I ever did). This kind of calibration is an under- appreciated skill.

</comment></comment></comment></comment><comment><USER5> I really, genuinely, don't understand why such a bland code of conduct would be a turn off to anyone. I may not be easy to be around, but I try not to be abrasive while, at the same time, making clear why I think something is the way I think.

If you think someone is wrong very often, I believe saying why the person is wrong on every occasion will provide them with actionable information much better than calling them an imbecile. The goal is not to make the person go away, but to help them produce better ideas.

If someone verbally assaults me, I'll defend my point or, when provided with valid reasons, I'll behave like an adult and correct it. If I ever come across as abusive, let me know and I'll try to be a better person in the future.

Is that really too much to ask?

<comment><USER6> Agree.

Open Source values will still remain - working in a transparent, open (not always nice) way.

More with CoC, harassing people will not be tolerated

<comment><USER7> The entire point of the CoC is it creates a process whereby people not involved in the project can harass members of the project while remaining anonymous.

Notice the people making a stink about Linus do it by taking out of context, lying about what he said and have managed to get people to think he should step down.(and are putting in place a "code" that lets them do it even though he's the kindest non-bigoted person you could think of.)

It's completely political and it's discriminatory.

<comment><USER8> > The entire point of the CoC is it creates a process whereby people not > involved in the project can harass members of the project while remaining > anonymous.

So there is a lot of people peripheral to these projects, that want nothing more than to disrupt by harassing people completely unknown to them, under a veil of anonymity? And that's the _point_ of these CoC's?

Who _are_ these people you speak of? Some secret cabal of "SJW's"?

You are saying the point isn't to codify some ground rules for collaboration and communication, which are then in rare cases _abused_ by some individuals, the abuse is the _point_? Please.

</comment></comment></comment></comment><comment><USER7> I am a gay man[0] who has contributed to a number of open source projects significantly. However I stopped when they implemented "Code of Conducts" that deny basic rights such as innocent until proven guilty and the right to face your accuser. (The popular one keeps accusers anonymous, thus the victim has no chance to defend themselves.)

The truth is a maintainer can eject someone without a CoC. The purpose of CoC, as stated by its author in her very bigoted and hostile twitter feed is to eradicate meritocracy.

CoC lets some random person with a political axe to grind derail a project with accusations about things done outside the project (Eg a disagreement on twitter) backed up with a gang of people accusing the project maintainers of being bigots if they don't eject their intended victim.[1]

This is bullying.

I won't invest time in projects where the contributors are not respected and maintainers will listen to a politically motivated mob over reason.

Since the proponents of CoCs seemingly are always people who violate them constantly (under the CoC its own author should be kicked from every project that adopts it based on her twitter comments) it's clear the intention is not to protect anyone.

The intention is to force their politics into open source projects.

[0] This means I get to see abuse from straight bigots as well as SJWs who hate me for being male and apparently think preferring men is discrimination against women! (Or so they have told me on twitter.). I only mention I'm gay here so you understand I'm not some neonazi. I've been jumped outside a bar and called a faggot in Oklahoma, but I don't feel these "codes of conduct" do anything to protect me, quite the opposite. So they don't address the key case that I'm guessing HN users will assume they do. Gay men are considered highly privileged these days, and thus subhuman.

[1] There are many examples, check the reddit threads in /r/Linux of the abuse of CoC.

<comment><USER9> Sorry to say but proven until guilty and basic rights does not apply to everything in life (tax law, private endeavors, I can refuse service to someone, I can kick you out from my home without listening to you if I think you did something wrong). If someone is accusing you and they don't want to hear you, stop contributing. It is is not criminal justice. You are not obligated to spend your time fighting with assholes. Find better proj to spend your time on, just as you written.

<comment><USER10> > If someone is accusing you and they don't want to hear you, stop > contributing.

You're assuming he's contributing privately and can stop at leisure.

<comment><USER9> He wrote he stopped.

</comment></comment></comment></comment><comment><USER11> I just want to reiterate what glandium wrote in a comment further down:

"He didn't step down. He's taking a break. It's not the first time he takes a break either. Let's not be too alarmist."

<comment><USER12> Also I fear this situation is at a loss loss interpretation. If Linus doesn't take time off he's a sociopath, if he does, linux is dead...

I do agree that it's somehow worrisome, but I tend to think that open discussion, and slowing down is a sign of health rather than the opposite. Time will tell.

<comment><USER13> Personally, I like to consider Linus taking time off to work on his social skills (whether it is really necessary or not) a sign of personal growth.

Time will tell how things will change in the Linux development world, but on a personal level, I think it is kind of admirable to face such an issue and be so open about it.

</comment></comment></comment><comment><USER14> I really think the internet should calm down; this is not even the first time Linus Torvalds takes a break — and in 2005, the result was git.

</comment><comment><USER15> I am a Linux developer and contributor for a few decades and the code of conduct simply killed any interest in contributing to it. It won't take long until backdoors are introduced on Linux. Activists that joined the community for money will have full control and the ability of banning any criticism. We really need Linus back.

<comment><USER16> Because behaving like a decent human being is that hard, isn't it? If a code of conduct hurts your feelings that much maybe you're just not cut out for collaborative work.

I really wonder where the great fear that CoCs will be abused to shut down disagreement comes from. I am not a fan of policing language, but there just aren't many real examples of such abuse out there.

Here is the actual list of examples from the CoC. Which of these do you need to do in order to feel happy to contribute to Linux development?

+Examples of unacceptable behavior by participants include: \+ +* The use of sexualized language or imagery and unwelcome sexual attention or \+ advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic \+ address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a \+ professional setting

Fight overreach, by all means. Make sure that the CoC contains means to fight overreach. That's all good. But the whole "I can't contribute to this project anymore because I find SJWs offensive" whinging strikes me as deeply hypocritical.

<comment><USER17> > Because behaving like a decent human being is that hard, isn't it? If a code > of conduct hurts your feelings that much maybe you're just not cut out for > collaborative work.

This is a personal attack, very thinly veiled. If Hacker News had the same code of conduct, your account would have to be banned at worst.

<comment><USER16> That's fair, it's definitely a way to read this. I shouldn't respond to hyperbolic language with the like. I'll edit it.

Edit: Too late, I can't edit anymore unfortunately. Let me rephrase:

"Behaving like a decent human being isn't that hard. It's work that anyone who wants to work in a collaborative project can reasonably be expected to do. If this is objectionable to you, then maybe this collaboration isn't for you."

<comment><USER18> > Behaving like a decent human being isn't that hard.

It can be quite hard to live up to _everyone 's_ standards of "decency". You just failed to do it.

> I shouldn't respond to hyperbolic language with the like.

Write that on the chalkboard one hundred times and maybe we'll let it slide. This time.

<comment><USER16> Yeah, I was called out on it, and I corrected myself. I wouldn't want to be part of a project that bans people who make an effort towards decency. The fact that standards differ and a consensus needs to be found for what constitutes decency is not an argument against it.

What point are you trying to illustrate? Are you saying I shouldn't have been called out on it? Because I disagree. The fact was, I found the post I replied to annoying, and I replied in a tone that was stronger than it needed to be. It's a good thing that was called out. Next time I'll take a breather before replying and we'll have a more constructive exchange.

<comment><USER19> I think part of the problem is that in the CoC context, the slighted party now looks at your username, cross references it against reddit and twitter, searches your posts for something else to take umbrage at, and makes the case that you should be excluded from the community. The result is a very real chilling effect on speech on all public platforms because now you're _never_ allowed to make a comment that might be taken out of context to offend now or at any time in the future.

<comment><USER20> This is the key to the whole thing and I'm glad someone finally said it. Open- source projects aren't incapable of getting rid of contributors who cause problems to the detriment of project productivity without having a formalized Code of Conduct. Why add something to a project that causes more problems than it solves? CoC proponents have good intentions but fail to see the chilling effect potential, even as it plays itself out in real time, right on cue (Ts'o).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> /r/linux has been full of arguments about this recently.

The moderation team claims that many of the people arguing against the CoC appear to be new to /r/linux.

> We have noticed a large influx of accounts this past week that have never > commented or posted in /r/Linux before. We have also seen a large number of > accounts being created just to comment on these posts. ~ /u/Kruug

From [https://aa.reddit.com/r/linux/comments/9i43t9/dont_worry_the...](https://aa.reddit.com/r/linux/comments/9i43t9/dont_worry_there_wont_be_anything_like_that/e6i66jp/)

<comment><USER22> Yes, the problem is there's a significant ""pro-abuse"" movement around who are willing to turn up anywhere these issues are discussed despite not having any previous involvement with the community and argue that they need to be continued to drive away marginalised people and anyone who doesn't have an extremely thick skin.

(Not directed at anyone specific, but I notice some green text in this thread too)

</comment></comment><comment><USER23> I find the doom-and-gloom over the CoC change absolutely silly. Plenty of projects have a CoC and none of them have just died a fiery death because there were rules against treating people badly. As other people pointed out, there's a big difference between putting everything into 15 layers of business speak and just not insulting people. Linus is, to me, obviously advocating the latter.

<comment><USER7> BSD is dying.

<comment><USER10> Does Netcraft confirm it?

</comment></comment></comment><comment><USER24> The phrases like "you need to go and learn some empathy through sensitivity training" are deeply offensive to autistic spectrum individuals, this is where the whole "inclusion" thing falls down on its double standards. Also the whole obsession with skin color and gender as if that would automatically mean that those individuals are more diverse is simply not true, you can't be diverse if you only allow homogeneity of thoughts and ideas (which is the most important part).

</comment><comment><USER25> Sigh. For 27 years, Linux has been maintained by a frankly abrasive person who weren't afraid to show middle finger to a big company, say some coders should be "retroactively aborted", and even say "shut the fuck up" to a co- contributor. We were told that it was part of Finnish culture of being direct, and although some people grumbled (and some thought that was a load of BS), people didn't really mind that much, worked together, and built the Linux we know now.

Now, for once, Linus Torvalds thinks it's time for change and maybe everyone could be a little nicer to everyone else, and suddenly we hear doom and gloom and how yielding to the American "SJW" culture will ruin Linux for everyone.

I wonder what choice words Linus-of-yesteryear would have uttered to see the shenanigan.

</comment><comment><USER26> There needs to be more frank discussions about corporate and vested interests and how to protect the independence of the kernel which Linus has managed well till now.

Automatic assumptions that what is good for Redhat or Google is good for everyone do not hold. These companies have real power, thousands of employees, media and industry support, funding, and lots of people reluctant to go against them or keen to curry favour so they can overwhelm any decision or discussion with resources. This must be recognized.

Linus is obviously not easy to replace but there should be some kind of succession planning and also thinking in detail about how to retain the independence of the development process from powerful interests.

This latter is something that not enough attention has been paid to in open source. Security fud is often used to raise complexity and indirectly encourage corporate interests and monopoly. The control of standards is also used to push complexity and raise barriers.

In the long term its only the ability of smaller groups to develop software that can ensure users are not held hostage by vested interests. The Linux kernel is hugely important to open source and it needs to be managed well to encourage and motivate the next generation of contributors.

</comment><comment><USER27> > Should he have apologized? Yes, privately

If you cross someone privately, apologize privately. If you cross someone publicly, especially a subordinate, you owe them a public apology. Because you burned _all_ their relationships.

</comment><comment><USER28> CoC encourages harrassment through doxing and witch-hunts. It actually has the opposite effect.

You were rude to me on a bug tracker? I'll dox you and find something you said 5 years ago which is offensive and report it to the committee to get you banned.

<comment><USER29> This is the CoC that many projects subscribe to: [https://www.contributor- covenant.org/version/1/4/code-of-con...](https://www.contributor- covenant.org/version/1/4/code-of-conduct)

The relevant snippet is here:

\</comment></comment><comment>--

Examples of unacceptable behavior by participants include:

The use of sexualized language or imagery and unwelcome sexual attention or advances

Trolling, insulting/derogatory comments, and personal or political attacks

Public or private harassment

 _Publishing others' private information, such as a physical or electronic address, without explicit permission_

Other conduct which could reasonably be considered inappropriate in a professional setting

\</comment><comment>--

i.e. the CoC explicitly mentions doxxing as against the CoC.

<comment><USER30> Oops, too late: [https://github.com/opal/opal/issues/941](https://github.com/opal/opal/issues/941)

</comment></comment><comment><USER31> I can relate to this, although for me it feels rather comical than offensive:

 _I find the phrase "I am excited" used in almost every business announcement to be offensive, because it is not genuine, nor does it indicate what type of excitement is being felt - excitement merely means an elevated state of emotions, could be good, could be bad_

</comment><comment><USER32> Oh come on. Linus isn't just direct in a culturally different way. He calls people idiots and belittles them all the time. You can be direct without that and I'm glad Linus has finally realised it (seriously; it's extremely difficult to admit your flaws).

Have a look: [https://www.reddit.com/r/linusrants/](https://www.reddit.com/r/linusrants/)

</comment><comment><USER3> To me, it seems that the biggest lesson here has to do with cults of personality. No matter how awesome he is, Linus should _never_ have been put up on such a high pedestal, given such a complete pass on everything he said, for so long. The longer it went on, the more he attracted both imitators and detractors. When he had a change of heart (and BTW I think the person who talked to him and finally made a difference was probably his daughter), neither of those two groups knew how to handle it gracefully. I've seen plenty of BS from both the Reddit/4chan troll army on one side (quite prevalent in this thread) and the anti-LF clique on the other (haven't seen them here yet) since then.

It's particularly interesting to contrast this with the relatively smooth process of the Python community. They adopted a code of conduct a while ago, and more recently Guido van Rossum - he for whom the term "Benevolent Dictator For Life" was invented - stepped down. There was some contention, but nothing like what we're seeing for Linux. I don't think it's because of the two projects' prominence. I think it's because Guido was never as polarizing as Linus. Again, the lesson is perhaps that _nobody_ should be allowed to drive a project of that size toward such a cliff.

<comment><USER20> This is a highly revisionist version of events.

<comment><USER3> OK, so what did I get wrong? Please explain exactly which facts are incorrect, and what the correct version would be. Or is "revisionist" just a content-free dismissal of something other than _your_ personal preferred narrative? Put up your version, and we'll see who the revisionist is.

<comment><USER20> The main thing is, I've yet to see any evidence that Linus' "abuse" actually hurt anyone in any way. Peoples' reactions ranged from amusement to cringing but I don't think anyone ever took his hyperbolic over-the-top profanity seriously. nobody was actually being hurt, and the Linux kernel developed into an amazing product that's in use everywhere around the world. Anyone who doesn't like the way Linus does things is free to fork the repo and do their own thing, and always has been.

Many people seem to want to paint Linux as having this terrible internal culture because mean ol' Linus was always randomly insulting people for no good reason, and I just haven't seen any proof of that myself. The idea that Linus _had_ to change strikes me as odd--he wasn't hurting anyone, and nobody thought he was, until recently.

<comment><USER3> > I've yet to see any evidence that Linus' "abuse" actually hurt anyone in any > way.

I have a feeling this will get dragged down into hair-splitting over what "hurt anyone" means, but I've known or known of several people whose careers were negatively affected. Sage Sharp comes immediately to mind. Some of the people who have tried to get security or real-time-scheduling patches in, only to met with a wall of invective, also come to mind. Sure, they probably went on to do their work elsewhere or maintain it as private patches, and were content doing so, but I'd still say that denied them recognition they deserved and also represent missed opportunities for Linux itself. I've personally stayed away from working on the Linux kernel, despite having worked on kernels since before Linux existed and thus knowing both the technical and cultural issues involved, because I just didn't want to be around him or Al Viro or some of the others I'd have to work with to get patches in.

So I have a different perspective than you. How is that "revisionist"? Couldn't that label be applied to your "nothing bad ever happened" version just as easily?

> The idea that Linus had to change strikes me as odd

Whether he had to or not, _he_ felt it was beneficial to do so. Maybe those who idolize him should consider that he might have been right this time too.

</comment></comment></comment></comment></comment><comment><USER24> Why is this article flagged?

</comment><comment><USER33> If Linux has survived the past vitriol, I'm pretty sure it would flourish in future civility.

</comment><comment><USER34> > Not a corporate-approved kangaroo court.

Is this really what happened? To me it appeared like a bunch of Linus's close friends told him he was acting like a jerk, and he agreed. Building this into some kind of global movement out to punish wrongthink smacks of conspiracy theory to me.

<comment><USER30> Has happened many times in the past in other open source projects: [https://github.com/opal/opal/issues/941](https://github.com/opal/opal/issues/941)

<comment><USER34> This doesn't address my comment.

</comment></comment></comment><comment><USER35> I get the impression (or maybe this is the point and I'm just dense) that the article is saying that Linus's aggressiveness matched corporate aggressiveness head-to-head, and that this meant Linux didn't get engulfed by corporate agenda to the extent that it lost its core integrity and values.

I also think I'm reading the notion that perhaps Linus' apology and temporary stepping-down to reflect introduces hesitancy about the authority/legitimacy/validity of his position and views.

Maybe so. I don't think this will have a negative impact on Linux itself though. For all the chaos it's wrought, the GPLv2 kind of saves things somewhat here; even if Linus steps down, we'll be fine: the whole world is Linux-specific, and while Linux is just a syscall interface it's also a _rather important thing_ that initializes and maintains the state of your hardware and peripherals for you, and this _rather important thing_ happens to be under this license that doesn't let you proprietary-ify it in certain ways.

This is awesome.

Until someone makes a perfectly Linux-compatible kernel with a different license model.

The idea makes sense. Notwithstanding whatever ideas you might associate with Lennart Poettering, I remember him saying (although I can't find it right now...) that Linux is pretty much the future and that nothing else (translation: BSD) really matters. I think this was regarding GNOME and/or systemd BSD support. Some may think FreeBSD (at least) might want to have a word with Lennart, but still...

So far Microsoft have a partially complete UNIX^HLinux reimplementation. Honestly quite an amazing 360° there... they currently seem to be trying to lure "modern developers" to Azure. I can't say I quite get the rationale there, but okay, cool. (Not dissing it, I genuinely don't "get" it.)

FreeBSD's quiet use in things like the PlayStation 4 is similar to MINIX's use in Intel CPUs: the fact that it's a UNIX is a throwaway implementation detail. Linux is completely different - compatibility encapsulates everything from the syscall table to the location of specific files, to the existence of /proc, /sys and similar, to the fact that graphics and windowing are (for now...) X11 based, to the fact that the shell works the way it does (read: that the shell uses the GNU coreutils).

Google decided to avoid the UNIX thing altogether, instead opting to create their own new thing. This makes sense: Google have server-side, client-side, and everything in between to think about, and it's going to simplify a _lot_ of subsystems, infrastructure, tooling, design, architecture, etc, if they can hand the same kernel to wearable device OEMs, phone/tablet OEMs, server OEMs, IoT device OEMs, "nonexistent"/internal network equipment OEMs, consumer network device OEMs; etc etc. This is a stretch and perhaps I'm looking ahead more ambitiously than Google is here, but I'd be _very_ surprised if this concept hasn't been floated. It's too attractive and makes too much sense.

I've been scared about Linux's future for a long time. It feels... _too_ successful, like things are going suspiciously well. I mean, right now I'm typing this on a machine running an OS I didn't have to pay anybody for, and if something breaks and makes me mad enough to want to do something about it, there's more things I can take apart and things I can open and shut that will fit in my attention span. And here's the bit that I'm suspicious about: that's the status quo, what we've come to expect. We have it ridiculously easy!

I guess the reason I'm suspicious is because, I'm afraid the nice status quo changing isn't a matter of _if_ but _when_ , and _when_ things fall apart, I don't want to be taken by surprise.

It would be utterly foolish for me to try to envisage how this would happen; the bazaar is WAY too big, sociopolitically speaking, for me to mentally model it. Nope. But I feel (hand-wavily) that something's gotta give, eventually. Not because of some concept of "where on earth is the fuel for all of this free stuff coming from, and when will it run out" but more in terms of the integrity of the fabric holding everything together, and how vulnerable that is to change.

</comment><comment><USER36> This whole thing reeks of personality cultism

</comment><comment><USER37> Betteridge's Law

<comment><USER38> tome's law [https://news.ycombinator.com/item?id=17978737](https://news.ycombinator.com/item?id=17978737)

</comment></comment><comment><USER39> Linux has survived and thrived, garnering support from many big companies without having to have a coc before.

That an admittedly mediocre tech-wise, and really quite odd person who publicly hates meritocracy will now presume to sit in judgment of others who have skills far greater than his, grates.

</comment><comment><USER40> I don't know about the end of Linux .. but I'd love to see Linus fork Linux just to see who follows and how this turns out. He could certainly afford to do it (economically and otherwise).

<comment><USER40> No need for a downvote :) I have witnessed Linux' rise from nothing to the dominating server OS. Back then there was a rich ecosystem of other Unix systems that we used at my workplace (HP/UX, Digital Unix, Irix) and when we started introducing Linux it was belittled for years as a toy until it was finally accepted and slowly the other systems disappeared.

Now if Linux came to an end (I don't think so) or Linus started some new OS project it wouldn't be the end of the world but the opportunity to start over and create something new. Eternal recurrence and all that ..</comment></comment>


I reduced my phone dependence using data analysis and gamification - <AUTHOR> https://medium.com/@neeravmakwana/how-i-reduced-my-phone-dependence-using-my-professors-advice-data-analysis-and-gamification-752dca43b541 <comment><USER2> this is also a very good article:

[https://medium.com/better-humans/how-to-set-up-your- iphone-f...](https://medium.com/better-humans/how-to-set-up-your-iphone-for- productivity-focus-and-your-own-longevity-bb27a68cc3d8#7a27)</comment>


OSX Lion: Where the flip are my spaces? - <AUTHOR>

Just did the OSX Lion update...So spaces are gone in OSX Lion?? Noooooooo <comment><USER2> Spaces and Expose are in Mission Control. Enter Mission Control and drag an application to the top of the screen.

</comment><comment><USER3> Steve says take it and like it. So shut up and do without.</comment>


Questions to Ask Before You Join a Startup - <AUTHOR> http://mediashift.org/2016/08/when-to-join-a-startup/ <comment><USER2> From my nasty 2002/.COM era experience with a startup would have said the 3 questions were:

1.) Do you like Kool-Aid, psychotic office politics & megalomania? 2.) Can you handle bizarre CXO behavior & feature requests designed for investors and not customers? 3.) Are you financially prepare to be underpaid for your skills AND have your paycheck 'not show up' one day when it tanks?

I hope to hell things have improved since then. I'm personally not willing to take the chance though.

<comment><USER3> still exactly like this

</comment></comment><comment><USER4> This piece wants to sell us the startup ethos. Be young, work 14 hours a day and get paid 40 kEUR. But we are in Lisbon and will throw in a surfing pass for Ericeira beach!

Other people recommend asking things like the amount of runway left, who the CFO is and how successful he was in past rounds of fundraising, if the founder is fresh out of academia and doing their first company, nevermind the location and the cost of real estate. And the usual things, like the immediate supervisor, company culture and benefits.

</comment><comment><USER5> "Startups are for grownups. [...] Grownups are willing to give the next five years of life to the pursuits of the startup — the people. Blindly."

Nothing to see here except more patronization. Move along.

</comment><comment><USER6> This is actually more an aspiration than a reality of startup life:

" Grownups do the difficult thing when it's the right thing to do, with composure. This means giving peers and employees critical feedback. It means saying the unpopular things about your startup's product or service offering and assuming responsibility for failures. It means being really honest about the strengths and weaknesses in the management team. This strength comes from surviving and overcoming difficult circumstances. Grownups can do this over and over without losing credibility or support of the team."

But I agree that I tend to find more of this kind of honesty in small startups than in big companies, and for this reason I prefer to work with startups.</comment>


3 coding puzzles 100% of a middle school class got, versus 50% of interviewees - <AUTHOR> http://blog.ktbyte.com/2014/06/17/3-coding-puzzles-100-of-our-middle-school-class-can-do-but-only-50-of-professional-interviewees-could/

<comment><USER2> If you are using Unicode, getting a character out of a string actually can be a bit difficult to do correctly (depending on the language).</comment>


Ask HN: Do you have a favourite language, but actually work in something else? - <AUTHOR> I, for example, work in JavaScript in my day job, but my favourite one is probably Elixir. They used to be worlds apart, but since ES7 JS is not that bad... I guess. Still, nothing really beats Elixir's immutable-by-default structures, pattern matching and clean concurrency.<p>Are you in a similar situation? <comment><USER2> When I used to interview job candidates I would often ask "what's your favorite programming language?" Then I would follow up with "what don't you like about it?"

Inexperienced programmers would have nothing. Experienced programmers would have things they didn't like, and the specifics were educational.

Going back to your question: languages are tools, and language design is just part of what makes them useful tools. E.g. Elixir doesn't have all of the libraries Python has for scientific programming, so if you need those you might choose Python even for something in Elixir's domain of relevance. You wouldn't use Elixir for software that is all about mutating state. And so on.

So instead of thinking about favorites, better to ask "what problems is this language best suited for? which is it not suited for? How do they differ? How are they the same?" (e.g. [https://codewithoutrules.com/2016/03/10/compare- contrast/](https://codewithoutrules.com/2016/03/10/compare-contrast/)).

Software is a tool, not a goal. The goal is to solve problems, which is easier when you use the right tool for the right job.</comment>


Ask HN: How do you imagine the future of household shopping? - <AUTHOR> Groceries & Staples, Fruits & Vegetables, Personal care, Breakfast & Dairy, Beverages, Home & Office needs, etc <comment><USER2> I'd love to see a more widespread version of something a company here has done and something that would be cool to have - I tap on my phone what I want/need and pick it up on the way home. They have only 1 location for now which makes it suck, also their mobile app is a react app that lags a lot.

I assume people will still want to go to the store (me including, it feels relaxing to have a walk around, thinking about different combinations of food, discovering new things) and I'd love for that store to be something like the Amazon's new store.

I envision a lot of specialty stores and return of manufacturing - the more we go towards certain things being common, the more "handmade" or "manufactured" ones are appreciated.

</comment><comment><USER3> Somewhat implausible future?

I spend some effort to make my house "perfect". Clean, fully stocked with groceries and bathroom supplies and everything like that.

At night, while I sleep, a robot or team of robots goes through my house to reset everything to it's "perfect" state.

It'll tidy up, wash the dishes and put them up, do the laundry in the laundry hamper and fold it when it's done. It would even order replacement supplies that are getting low, get them off of the front porch when a drone drops them off in the middle of the night, and put them up.

If a person sleeps lightly maybe the robot would do this during the day when the family is at work or school.

</comment><comment><USER4> Pre packaged goods will mostly be ordered online: anything people currently buy with feeling the need to physically inspect first.

Some people may buy fruit and vegetables sight unseen. I would suspect there would still be a sizeable market of people that won't and will still go to markets or stores.

I'm not sure if this means a return to smaller, specialty stores or if only big box stores that have everything in one place like Walmart, Will Survive.

</comment><comment><USER5> People ordering using voice based commands to an AI which adds those items to basket and places an order. Similar to what Amazon is doing with Alexa.</comment>


Best Linux Distro for Gamers in 2017 - <AUTHOR> https://freaksense.com/best-linux-distro-for-gaming/ <comment><USER2> SteamOS is one of the best Linux Distron and I am using it.</comment>


Show HN: A GraphQL server that executes multiple queries in a single operation - <AUTHOR> https://leoloso.com/posts/executing-multiple-queries-in-a-single-operation-in-graphql/ <comment><AUTHOR> In the blog post, there are a couple of GraphiQL clients. You can modify the query and click on the Run button to play with it</comment>


Ode to StackOverflow - <AUTHOR> http://therealstartup.com/ode-to-stackoverflow/

<comment><USER2> StackOverflow can be wonderful. It's a shame that overzealous power-mad moderators have ruined it.</comment>


JSON for Modern C++ version 3.0.0 released - <AUTHOR> https://github.com/nlohmann/json/releases/tag/v3.0.0 <comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


How do you fight procrastination? - <AUTHOR> I love programming, I really do, but lately I've spent countless hours gaming or watching videos. I really don't know how to fight this. <comment><USER2> Watch your health. Being unhealthy can make you want to choose easier (lazier) tasks. Also, make sure you sleep well (not just long enough, but of high enough quality) since poor sleep can lead to laziness and diminished stress tolerance. I would recommend meditation or playing an instrument if the problem appears to be having too many things going on mentally at once.

Also, entertainment items give near-instant gratification and often very high stimulation. If you have been exposed to a lot of these lately, it may be necessary to stay away from excess stimulation for a while before you can adjust to the calmness of programming. Going straight to software would be like walking out of a concert and into a quiet library. Taking a long walk in a peaceful place could help.

The trick afterward is to avoid the urge for instant gratification.

</comment><comment><USER3> Been currently using brain.fm to help focus. Allso looking for new work might be time if you're corporate. Also mediation/exercise can help alleviate this. Finally breaking big goals to tinier tangible goals can make something that usually you would procrastinate on more digestible.

</comment><comment><USER4> In level of severity:

0\. Control yourself 1\. Use tools to block problematic websites (e.g. K9, StayFocusd) 2\. Use tools to temporary disable internet (e.g. Freedom) 3\. Don't do programming, take up a hobby that doesn't involve dodging mental crack the whole time 4\. Get rid of your computer</comment>


What do you think about my shopify training website – be brutal - <AUTHOR> I recently created this website : http://adspify.com/ but seem like nobody cares. When did I go wrong ? <comment><USER2> I am the shopify expert! Checkout my website [https://truworthhomes.com/](https://truworthhomes.com/)</comment>


Power Poses Are Dead - <AUTHOR> http://marginalrevolution.com/marginalrevolution/2016/09/power-poses-dead.html <comment><USER2> This is very interesting. I think that the issue is probably true</comment>


Akin's Laws of Spacecraft Design (2003) - <AUTHOR> http://spacecraft.ssl.umd.edu/akins_laws.html <comment><USER2> >16\. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.

>19\. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.

Learning how to better thread the needle between these two is been one of the most important things I have learned in my career. Just because this is the way it was always done doesn't mean we have to do it that way, but the people who did it that way probably had some reason for it that is worth exploring and fully understanding.

<comment><USER3> I don't see these as opposed principles.

16\. They're not smart.

19\. You're not smart, either.

Assume everyone is an idiot, including yourself. Verify everything (your own work _and_ other people's work) using robust testing protocols. Don't use your own judgement; you're not smart enough for that. Gather evidence. But test your evidence-gatherers to make sure they're doing their jobs, too. Assume every component of your system-of-people is half-fallen-down and just barely limping along at all times. Make a system that works in the face of everyone coming to work with a concussion.

(And, if some component _isn 't_ barely limping along, then people are probably being too naive about its potential failures, so inject some chaos [monkeys] into it to get its reliability down to a level where routing around _it_ has to be operationalized, too.)

<comment><USER4> In WWII, bullet holes in planes had to be repaired. But the damage wasn't uniform - some areas got badly shot up, some areas were never damaged. So they added armour to the undamaged areas, because the planes that got shot there never came back.

Similar idea from another angle: superficial design flaws obscure fundamental design flaws (Douglas Adams on the Sirius Corporation Complaints Depatment)

</comment></comment></comment><comment><USER5> Number 40 is beautiful:

> 40\. (McBryan's Law) You can't make it better until you make it work.

This has been my credo for developing software for as far back as I can remember. If you approach creating something new as purely experimentation, you'll get to something workable sooner. You can then either polish your newly created turd or choose to scrap it for something new that builds on what you learned.

<comment><USER6> Turds have a way of living on in the software world.

<comment><USER7> They live on if they provide value.

And that's OK, because we're in the business of providing value, not building shiny monuments to our incredible cleverness.

<comment><USER8> There's turds and turds. I've seen many of them and no two turds are alike:

1\. A long time ago, we had this turd of a hardware abstraction layer that is every systems developer's nightmare. Windows drivers behind a middleware, with COM and whatnot. Support for USB devices, spanning back to Windows 98. No one dared touch it unless absolutely necessary. Fortunately, no one needed to touch it too often. The functionality it offered was rich enough that the trickier logic could be implemented at application level; it decreased code reuse to some degree, but then again, this was a critical enough piece of software that the time wasted by duplicating some logic among applications was offset by the testing effort required for changes in the HAL behemoth. Most of it was okay-ish, too; it crashed under a few circumstances, but not mysteriously -- we sort of knew _where_ the bugs were, but workarounds were available and they were generally deemed good enough.

This was a reasonable kind of turd. I mean, yes, there was technical debt in it, Jesus, it had comments like "TODO: This looks ugly but for some reason it's the only way to make it work on <some Windows 2000 build>. Maybe figure out a cleaner way?", but it didn't really bother anyone. The code was architected so that technical debt piled up on separate shelves, too. The PCI (not -X. PCI. Plain PCI) stuff, in particular, was only touched by one or two people -- but it was perfectly possible to work on other pieces of that code without breaking the drivers for those weird PCI peripherals.

2\. I was responsible for one of these turds. A while ago, we had to do a lot of fancy, detailed documentation for a custom logic design. This was going to be implemented in an FPGA which was going to sit in a pretty advanced medical device -- so you spec everything _before_ writing a single line of code.

One of the things I wrote to help me was a tool that sucked in the timing diagrams in our docs (docs were in LaTeX, diagrams were in some markup language) and generated the Verilog code that put out those signals. This was a bunch of Python code, not too hairy, but it hardcoded every single assumption I could make. It started as a tool I'd made for myself; it was reluctantly promoted to a tool that everyone used.

Some folks tried to adopt it in other projects as well but honestly, the damn thing just wasn't up to it. I suggested to (my, by this time, former) colleagues that they'd probably be better off picking a standard markup language for the timing diagrams (maybe TDML?) and write something that was going to be useful forever, more or less from scratch. Or, if not, get a commercial, off-the-shelf thing that does exactly that, written by people who were paid to write _exactly that_. The time, people and resources for either of these options turned out to be pretty hard to secure, though, so they ended up polishing the half-bad Verilog code by hand. Still better than writing it all by hand, I suppose.

Frankly, this was at least an _excusable_ turd. It was never meant to be used for so much. It got promoted from "a developer's hack" to "project infrastructure" through a combination of short-sightedness, lack of awareness of better options and bad communication, mine included. But it did provide _some_ value and, honestly, removed none -- it sucked in the end, but it still sucked less than the other alternative that was actually available.

3\. And then there's real turds. Like, there was this module I saw a while ago, as part of a bunch of firefighting meetings because the original developer had quit.

When it was initially written, it was rushed in, and the first thing that got crossed out from the list was IPv6 support. And fortunately for the schedule, it turned out some bits and pieces of another feature could be reused here and there.

The end result was a massive 30,000-line... thing, that not even its creator really understood by the time he was done. A good chunk of that code was there to glue the bits that could be "reused" to the new feature. There was no abstraction layer -- when IPv6 support had to be added in, what happened was _another_ massive dump of maybe 10,000 lines, that was interleaved with the other one via a thick forest of if-this-is-ipv4-do-ipv4-stuff-else-do- ipv6-stuff.

After humongous amounts of testing and bugfixing, it actually made its way out through the door. which effectively marked it as "too expensive to rewrite", and that was it.

Unlike the thing at #1, there was no way to extend it, in any way. Adding even the tiniest feature took weeks and spawned dozens of bugs. Unlike the thing at #2, this wasn't some internal tool, it was production code.

Truth is, _it works_ , or at least it worked the last time I had anything to do with it. But in terms of investment it was a really bad thing to do. It was so hard to extend that there was no way to accommodate customer requirements in any sort of realistic timeframe. Keeping up with the competition basically required two engineers working full-time, on something that wasn't necessarily a critical feature but you couldn't _not_ have it.

 _This_ turd probably removed way more value than it added. Or, if not, it certainly _prevented_ way more value from being added. It's my standard for turds.

<comment><USER9> > Truth is, _it works_

Yes, that's "value" in an important sense. But people rarely add in the opportunity cost.

We make decisions every week about what can be done based on the tech debt involved. Every time we punt on an improvement, that's a real cost. These boondoggles that forever wall off parts of the product as immutable have a cost week after week. What's the net value after you subtract that cost? Is there any?

<comment><USER10> "Evolution in action" is what comes to mind reading alxlaz's detailed, cathartic (I hope ;-), lamentation.

<comment><USER8> I meant it more like a recollection than a lamentation, but it was cathartic here and there :-).

I don't know if it's obvious from it, so I'd rather spell it out -- there are times when "turds" are useful and not to be disdained, much like their real- word cousins: cow dung can be a good construction material and a useful fuel. Certainly worse than concrete and uranium but if that's all you can find or all you can afford, it sure beats eating raw meat and sleeping under the stars.

This isn't true of _every_ piece of software shit in existence, though. Sometimes, " _but it works_ " is just a bad excuse.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> My favorite as an engineer/scientist who has sat through tons of terrible presentations:

20\. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

If people can't understand your ideas, you're counting on them to shrug and say, "Boy, this guy sounds smart! I guess we should do what he says!" If they're doing their job, they won't.

<comment><USER12> It's sad, really. In a perfect world, you'd have an awesome design coupled with awesome sales pitch. In reality, a _lot_ of people realized that almost the entire ROI comes from the sales pitch, so you can half-ass the design part (or even skip it entirely, if your sales person is good).

<comment><USER13> its also probably a supply/cost issue. People that are good at sales are more common, and cheaper to employ than people that are good at designing complex feats of engineering.

<comment><USER14> But they rarely find themselves in the same circles.

<comment><USER15> People that are _great_ at sales are very rare, though. And people that are great at sales _and_ have great platform skills are the ones who make it past director level to the executive suite.

Engineers do well when they spot such people early and make friends with them. "Early" is important, because by the time they make it to the executive suite, they (hopefully) already have trusted "technical advisers" who will tell them when their idea sucks before it gets sold and propagated throughout the organization. If they don't, then they will rely on their secret sales intuition and their defenses against common sense will be impenetrable.

This is usually the highest executive function of engineers / "technical advisers" in large enterprises. Not so glamorous, but critical to the health of any organization.

</comment></comment></comment></comment></comment><comment><USER16> I thought this one was interesting:

> 30\. (von Tiesenhausen's Law of Engineering Design) If you want to have a > maximum effect on the design of a new engineering system, learn to draw. > Engineers always wind up designing the vehicle to look like the initial > artist's concept.

I suppose a lot of new ideas come with a lot of "filler" details that weren't consciously decided on but end up as a permanent fixture of the design, and that whoever tries first to communicate the idea to others has a lot of unintentional influence over the final product.

<comment><USER17> This approach comes with hidden cost of adding unnecessary complexity. Think about B2 bomber design: it looks like some "artist" wanted to recreate a Batplane, or other sci-fi spacecraft and then it took a lot of engineering effort to make the thing of such ridiculous shape to actually fly in stable, predictable manner.

<comment><USER18> Actually the shape of a B2 is very much influenced by it's function and only mildly by the desire to "look cool". (Though that is important too, apparently the F35 contract went to Lockheed Martin instead of to Boeing because the specs of both proposal were nearly identical but the LM one looked much better)

A "stealth" aircraft is not stealthy from all directions (nor does it need to be) but is optimized for bouncing the radar waves away from the direction of its target. The best shape for this would be to build the plane in the shape of an infinitely long flat surface, but since those are too expensive the "infinitely long" part is usually scrapped. Even shorter flat surfaces have terrible aerodynamical properties though, so there's often a compromise to make it more like a triangle. Then of course it needs to carry stuff like pilots, engines and bombs, so it can't be extermely flat but has to be bulbous. The engines need air intakes but radar waves bouncing off the rotating blades of a jet engine compressor have a very distinct signature in the frequency spectrum, so it makes sense to move the air intakes to the top of the plane where ground based radars can't shine into them. A similar thing goes for the outlets, but those need to be extremely heat resistant as well. To prevent the hot gases from flowing over an extended area of the fuselage you move the trailing edge of the triangle a bit forward. Then there are some more requirements like visibility for the pilots during take off and landing that put bounds on where the cockpit can be. Looks were very much a last consideration for the B2 and pretty much all of of its shape is due to its mission requirements :)

<comment><USER19> > apparently the F35 contract went to Lockheed Martin instead of to Boeing > because the specs of both proposal were nearly identical but the LM one > looked much better

People love to repeat this, but it's wrong. Yes the Boeing plane was ugly with the large air scoop, but it also was a great plane whereas the Lockheed Martin plane was a terrific plane. At the time of selection, the Boeing plane could not VTOL with all the bodywork in place (landing gear doors for instance) yes the LM plane had just completed a vertical landing after a supersonic flight. Also, not since the age of propellers had Boeing designed a combat aircraft, whereas Lockheed did the SR71, U2, F117, and a host of other innovative aircraft.

The one thing that the Boeing aircraft had going for it was the single-piece wing. The JSF competition was primarily to design an affordable plane, and the Boeing probably would have been much less expensive to build and qualify.

</comment></comment></comment></comment><comment><USER20> > Any run-of-the-mill engineer can design something which is elegant. A good > engineer designs systems to be efficient. A great engineer designs them to > be effective.

This is awesome. I don't know how many times I've seen over engineering in the field. It's crazy. Well we may one day want to do X.

<comment><USER21> I'm having a hard time visualizing this one.

Say the problem is driving a nail into a wall for hanging up a picture.

In this case:

Elegant = solution is a glass cube

Efficient = solution is gasoline-powered nail driver which drives 1000 nails per minute

Effective = solution is hammer

<comment><USER22> Elegant = using magnetic paint and magents on the back of the picture. You thus do not need a nail, can hang the picture where ever you want, and remove it without leaving a trace.

You just have to repaint the house to be able to use it.

<comment><USER23> See I think of elegant as "set the picture on a table".

The engineer might _think_ it solves the problem and does so in a way that is seen as cheaper, easier, and faster. But in reality it's not what was needed and the elegance of the solution will come back to bite them when the first user wants the picture a bit higher (which is normally met with "why would you want to do that?")

</comment></comment></comment></comment><comment><USER24> 39\. (alternate formulation) The three keys to keeping a new human space program affordable and on schedule:

           1)  No new launch vehicles.
           2)  No new launch vehicles.
           3)  Whatever you do, don't develop any new launch vehicles.

Someone better tell Elon.

<comment><USER25> NASA insistence on the human-rating for their own commercial crew spaceflights greatly increases the cost. If I recall right two falcon 9 have been lost to accidents, one on the pad, another 150 seconds into the flight. But the overall ratio of rapid unscheduled disassemblies to successful flights is looking promising.

Compare the predicted likelihood of fatalities with how many FAA licensed amateur/kit built "experimental" airplanes crash each year, killing their sole occupant pilots...

The FAA seems to be relatively OK with that fatality rate, on an ongoing basis, but spacecraft are held to a much higher standard.

If there had been a human in the very first Dragon flight carrying a wheel of cheese, years ago, they would have survived and had a nominal flight.

<comment><USER26> I also wonder how many of NASA's own human launch vehicles would have actually passed the "human rating" requirements they're now applying to everyone else.

<comment><USER25> Few, considering the 1+0 lack of redundancy for major life support systems on the Mercury, gemini and Apollo. Their test method seemed to be "fly it unmanned a couple times, if it didn't explode or lose pressure, put some people in it".

<comment><USER27> And don't forget the space shuttle which had a lot of possible single-point-of failures during launch and landing (e.g. no way to do a survivable launch abort during the first phase of flight; no way to survivably compensate asymmetric thrust when one booster were to fail; no way to shut down or eject boosters until burned empty; no way to perform ballistic reentry and landing when orbital control thrusters damaged).

</comment></comment></comment></comment></comment><comment><AUTHOR> Credit to @tlb for surfacing it in a comment here: [https://news.ycombinator.com/item?id=16995612](https://news.ycombinator.com/item?id=16995612)

Reposting it here because I think it's awesome.

<comment><USER28> Agreed. I was looking for a posting so I could upvote it when it happened. There's a scary number of parallels with software development in there.

</comment></comment><comment><USER12> My all-time favourite is #6:

> _6\. (Mar 's Law) Everything is linear if plotted log-log with a fat magic > marker._

I also love btilly's explanation of why it's actually true: [https://news.ycombinator.com/item?id=5058211](https://news.ycombinator.com/item?id=5058211).

</comment><comment> maze-le > Your best design efforts will inevitably wind up being useless in the final > design. Learn to live with the disappointment.

Sounds like Software Architecture to me.

> At the start of any design effort, the person who most wants to be team > leader is least likely to be capable of it.

This might be true for any organization.

<comment><USER29> And product management. The cheery slogan there is 70 percent of what you do will fail, the remaining 30 percent will need at least 3 or 4 goes before you get it right.

<comment><USER30> An actually cheery way of putting that is "30 percent of your hypotheses will be validated, after some amount of refinement" ;)

<comment><USER29> Oh I like that. Sounds much better!

</comment></comment></comment></comment><comment><USER31> Great link!

>13\. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

This is YAGNI stated a different way.

<comment><USER32> I agree that you shouldn't spend a _lot_ of effort going beyond the requirements, but sometimes you will reap huge benefits because you happened to go _somewhat_ beyond the requirements in a given instance. It's like the property of brittleness - you don't want to spend too much time making everything adjustable and bendable, but neither do you want to make everything as hard and precise and brittle as possible.

Someone linked an article elsewhere on HN about the true meaning of mediocrity that I enjoyed and really made me think about this:

[https://www.ribbonfarm.com/2018/04/24/survival-of-the- medioc...](https://www.ribbonfarm.com/2018/04/24/survival-of-the-mediocre- mediocre/)

</comment></comment><comment><USER33> > 33\. (Patton's Law of Program Planning) A good plan violently executed now > is better than a perfect plan next week.

In case anyone's wondering about the use of "violently" \- this is supposed to be _General_ Patton's law about military plans. Just so happens to apply to other fields.

<comment><USER7> Except the "violently" here does not actually refer to the use of military force.

It's in the sense of "vigorously" or "forcefully". No hesitation. No hesitation, no waffling, no debate - "just do it". Or, as Amazon calls it "disagree and commit"

<comment><USER33> In the engineering context it means that. But in the original context, it meant both.

</comment></comment></comment><comment><USER34> > 37\. (Henshaw's Law) One key to success in a mission is establishing clear > lines of blame.

I feel like this applies to a lot more than just spacecraft design.

<comment><USER2> That is true, but the phrasing is a little aggressive. Assigning "lines of blame" makes it sound like it is about having someone to point to after the fact. It is really about every part of a project having a single owner who is accountable so nothing slips through the cracks of bureaucracy. A way to rephrase that without the negative connotations of "blame" is "when everyone is responsible, no one is responsible."

<comment><USER35> Hi! I'm Henshaw, and I coined this law. Dave Akin was my lab director in grad school.

You are correct in your analysis. Of course, the phrasing was _meant_ to be a little aggressive, otherwise it isn't memorable.

<comment><USER2> >Of course, the phrasing was meant to be a little aggressive, otherwise it isn't memorable.

That is totally true and was something I missed. A law is of no value if no one remembers it. I bet we could even find one of Akin's laws to explain why that is the case.

Side note, HN blows my mind sometimes in that I can make a comment on a term and within minutes the guy who coined the term is on here responding.

</comment></comment></comment></comment><comment><USER36> My personal favorite is 20:

"A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."

</comment><comment><USER37> That link is easily the greatest thing I've seen on HN. Thank you

Until 42, that was a buzzkill

<comment><USER38> There's a lot of fantastic nuggets in there, that's for sure, but I have a nasty feeling that in a few years time this one will have become firmly entrenched in the vile lexicon of management wank-speak:

 _31\. (Mo 's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees._

<comment><USER39> That one's gonna be the new "revolution vs evolution".

</comment></comment></comment><comment><USER40> Hey! I worked with Dr. Akin in my undergrad. Definitely learned some of these he hard way during my project:

11\. Sometimes, the fastest way to get to the end is to throw everything out and start over.

And

14\. (Edison's Law) "Better" is the enemy of "good".

</comment><comment><USER41> I saw a $96M startup fail, not because the product failed, but because the distribution function for the yield was not understood. It was too sharply peaked to be practical. There's a lesson there.

</comment><comment><USER10> > 29\. (von Tiesenhausen's Law of Program Management) To get an accurate > estimate of final program requirements, multiply the initial time estimates > by pi, and slide the decimal point on the cost estimates one place to the > right.

I was going to complain that Cheops' Law ("it always takes longer and costs more" is my version) was missing, but that's a useful elaboration providing a new target.

</comment><comment><USER4>
      15. (Shea's Law) The ability to improve
      a design occurs primarily at the
      interfaces. This is also the prime
      location for screwing it up.

This is the problem with the information hiding approach of ADT, OO and even APIs: makes it easy to change the module internals, but hard to change the module interfaces.

But, TBF, the real problem is dependencies.

</comment><comment><USER42> I blogged about how to apply ten of these to startups at [https://www.skmurphy.com/blog/2011/01/10/applying-akins- laws...](https://www.skmurphy.com/blog/2011/01/10/applying-akins-laws-of- spacecraft-design-to-startups/)

</comment><comment><USER43> >39\. (alternate formulation) The three keys to keeping a new human space program affordable and on schedule:

1) No new launch vehicles.

2) No new launch vehicles.

3) Whatever you do, don't develop any new launch vehicles.

Funny to see this on the list while NASA violates it year after year.

</comment><comment><USER44> 43\. Does it work in KSP?

Anyone else note the significance of stopping any list of questions at 42?

</comment><comment><USER45> I'm not an engineer, but i can relate a lot with that:

19\. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up

</comment><comment><USER46> As an engineer I don't understand "engineering is done without numbers". All engineering revolves around math. Granted, estimations are needed when your doing analysis on something with no simple formula or that 12 inch pipe has some unknown amount of grime between 1-4 inches.

<comment><USER47> It says "engineering is done with numbers."

</comment></comment><comment><USER48> Great!!! These laws work for _any_ kind of engineering project. Maybe any kind of project.

</comment><comment><USER49> This has to be one of the worst advice lists of its kind I've seen.

\- Too long to be remembered

\- Half of it is clever quips and not actual insights

\- A lot of the points contradict each other

A list like this mostly serves as a feel-good piece for experienced engineers rather than useful advice for inexperienced ones, since they don't know which part of the list to take how seriously and how to interpret the contradicting ones.

<comment><USER50> If long and contradictory lists are so bad, how do you explain the Ferengi culture's success in adopting the 300 or so Rules of Acquisition? [1]

[1] [http://memory-alpha.wikia.com/wiki/Rules_of_Acquisition](http://memory- alpha.wikia.com/wiki/Rules_of_Acquisition)

<comment><USER51> Quite easily: _Star Trek_ being a work of fiction, its contents are unconstrained by any aspects of reality other than the limitations of its medium (in this case, live-action television).

</comment></comment></comment><comment><USER52> Hmm, judging by that list we're all Rocket Scientists.

(or at least we have the same problems)

</comment><comment><USER53> Not a big fan of

14\. (Edison's Law) "Better" is the enemy of "good".

<comment><USER54> Same here. Also this one: 13\. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

To what level this is true depends on the complexity of the system I suppose, and how accurate the requirements actually are.

</comment></comment><comment><USER55> Honestly, I loved this! Thank you for posting.

</comment><comment><USER56> There's really nothing about spacecraft.

<comment><USER57> I mean, sure, it's mostly all stuff applicable to large, complex projects, but you should scroll down a bit...

> 39\. Any exploration program which "just happens" to include a new launch > vehicle is, de facto, a launch vehicle program.

<comment><USER58> This also though could be applied to any system that just happens to have a massive amount of work to get it even above the ground as well. Just change the language to the behemoth in your field of choice and it applies.

</comment></comment></comment><comment><USER59> I want these on a poster.

</comment><comment><USER60> This has been posted to HN 9 times

[https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Desig...](https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Design%20&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

The last one was only 1 day ago.

<comment><USER61> Not enough! These should be read at least once a month.</comment></comment>


Piano ChatRoulette Merton interviewed - <AUTHOR> http://www.wired.com/underwire/2010/03/merton-chatroulette/

<comment><USER2> The video interview would be a lot better if it was recorded at the other end. Let the questions come out half garbled and get the answers in good quality.

</comment><comment><USER3> What terms did the original video violate?

<comment><USER4> "Our understanding is that the video didn't violate any copyrights; instead, there were likely privacy issued involved, as most of the people in the video didn't know that they were becoming part of a viral video."

<http://mashable.com/2010/03/22/merton-removed-youtube/>

<comment><USER3> Well that's lame.</comment></comment></comment>


This Is the Innovation That Gave Birth to the Modern World - <AUTHOR> http://www.popularmechanics.com/_mobile/technology/gadgets/news/this-is-the-innovation-that-gave-birth-to-the-modern-world-17428408?%3Fsrc=rss

<comment><USER2> It's a nice article, but he chose the wrong comparison: The pyramids are hardly a bunch of limestone blocks piled on top of each other. The more you understand them, the more you appreciate the accomplishment they represent. For example, we're still trying to figure out exactly how they did it.

<comment><USER3> I think he used pyramid building precisely because it was such an astonishing achievement. Similarly with the space programmes. His point was that accomplishment wasn't enough; that innovation requires a transformative effect on people.

His examples of innovation all had a multiplicative effect on human labour, knowledge or communication. Pyramid building and space flight were impressive and inspiring but didn't have a lasting effect on how people live their lives.</comment></comment>


More millennials switch off social media - <AUTHOR> https://www.ft.com/content/5477680e-8ece-11e6-a72e-b428cb934b78 <comment><AUTHOR> Paywall workaround: Google search link ("web" above), opened to Incognito page.</comment>


CIA systems 'hacked' by googling. Dozens of informants globally killed as result - <AUTHOR> https://www.yahoo.com/news/cias-communications-suffered-catastrophic-compromise-started-iran-090018710.html <comment><USER2> According to the article the Iranians used advanced Google techniques like the "AND", and "OR" operators. Truly sophisticated work.

<comment><USER3> The CIA put their top-secret info on the public Internet, because password- protecting it was too inconvenient. Then adversaries found the info. US intelligence services treating foreign informants as expendable, as always. Also seen when US abandoned Afghan translators to be killed by Taliban.

<comment><USER4> I dought it's inconvenience... Most likely a form of incompetence, at some level, in some department. Everyone can recognize the severity of this information leaking to "enemies of the state".

The time-old saying applies here: "Never assume malice with what can readily be explained by incompetence".

<comment><USER5> From the article:

>Former U.S. officials said the internet-based platform, which was first used in war zones in the Middle East, was not built to withstand the sophisticated counterintelligence efforts of a state actor like China or Iran. "It was never meant to be used long term for people to talk to sources," said one former official. "The issue was that it was working well for too long, with too many people. But it was an elementary system."

>"Everyone was using it far beyond its intention," said another former official.

<comment><USER6> I find this the most baffling. I'm also of the mind that assuming malice here is a bit too much, but what's the point of info security if not to protect systems from being used in ways they weren't intended?

</comment></comment></comment></comment></comment><comment><USER7> Truly, truly; pathetic. Several dozen people at least knew better and instead of fixing it, tried to bury the guy who raised the alarm.

The IG _had_ this information and didn't act. Completely mind-blowing. Dozens of agents/assets killed. An entire _class_ exploded.

Truly, a national embarassment and of course no one is going to jail.</comment>