Boeing Built Deadly Assumptions into 737 Max, Blind to a Late Design Change - <AUTHOR> https://www.nytimes.com/2019/06/01/business/boeing-737-max-crash.html <comment><USER2> I posted this as a comment the other day in another Boeing and MCAS discussion.

In my research into the topic the saddest bit of information I've seen is the image of the black box data for the flight (the first crash): [https://i.imgur.com/WJuhjlO.png](https://i.imgur.com/WJuhjlO.png) You can see from the graph that in the final minutes and seconds, the pilot put insane amounts of force on the control column (aka the yoke) to try to pull the plane out of the dive - to save the 189 people on board. But no, MCAS was overpowering and lacked the documentation for the pilot to try anything else.

Also interesting to see is the amount of times the pilots bring the nose up, only for MCAS to kick in and force the nose back down. 26 times.

All data from this Seattle Times article, which was written before the second crash occurred: [1] [https://www.seattletimes.com/business/boeing- aerospace/black...](https://www.seattletimes.com/business/boeing- aerospace/black-box-data-reveals-lion-air-pilots-struggle-against- boeings-737-max-flight-control-system/)

<comment><USER3> If the pilots were putting that much force on the yoke it is pretty apparent that the pilots really truly wanted the plan to do what they asked of it.

I am curious what scenarios the designers of the plan drove then to not trust that the human in the seat really has no idea what they are doing. Was the ignoring the wishes of the pilot and attempt to prevent a crazed irresponsible and unlicensed idiot from doing something? These are trained humans why does the computer totally ignore there efforts?

<comment><USER4> Perhaps related crash[0] where the autopilot was disabled because it was listening to user input, in this case a child.

[0] [https://en.wikipedia.org/wiki/Aeroflot_Flight_593#Accident](https://en.wikipedia.org/wiki/Aeroflot_Flight_593#Accident)

<comment><USER5> Oooof. Well the real lesson there is that unqualified people (especially children) shouldn't be in the cockpit of an airliner at all. Autopilot can't be made smart enough to determine if the person operating the controls actually knows what they're doing, and thus to follow/ignore them as appropriate.

<comment><USER6> I mean, pick your poison. Either the humans are more reliable or the computers are. Either way is subject to some level of fallibility.

<comment><USER7> The wikipedia article calls out that the compounding sequence of issues started when autopilot was silently disabled, so the human system was in control when the pilots did not intend it to be.

I think the critical issue in both cases is that the wrong system was in control against the pilots wishes.

So, the pilots can pick my poison based on their training and best judgement (and maybe not put their children in control?).

</comment></comment></comment></comment></comment></comment><comment><USER8> I really see this as a failure of the Systems Engineering process. With so many people unaware of the impacts of the changes, it's up to the systems types to have the big picture view and make sure these sorts of things are taken into account.

Especially if as the article says a failure of the AOA sensor on the system would be Hazardous (looks like it was Catastrophic when paired with MCAS in retrospect), that would have made the functional Design Assurance level for this system DAL B, which adds enough rigour not only in the software development process but so much before you even get to that in terms of Safety Assessments and ESPECIALLY change impact analyses when the function changes.

For sure there may have been pressure from management to keep MCAS out of the manual but it's not really up to he regulatory agency to be experts on the aircraft design, if things are being hidden by the company then I'd consider this bordering on professional misconduct on the parts of the engineers overseeing this work.

I say this as a Professional Engineer working as an aerospace systems engineer.

<comment><USER8> Thinking about this a little more, I also see a failure here in terms of naming things, which I have noticed in my career can be scoffed at but is so important.

As the article says, the function of MCAS changed and its operational envelope was greatly expanded. What if, internally at least, the new system was referred to as MCAS2?

This is somewhere that things can get political, as was exactly the case with the Max, where they did not want anything to be considered a change to the aircraft type, let alone knowing the MCAS system existed in two majorly differing versions.

<comment><USER9> This is so true. Naming to me is one of the most important decisions. When I see someone who frets over naming decisions for hours, or will sit down with me and really think through what we're going to name something - I know they get the gravity of the situation. I trust those kinds of people much more for big picture architectural or project lead decisions.

<comment><USER10> Do you have examples off the top of your head of really great names that have come as a result of this process?

</comment></comment></comment></comment><comment><USER11> This whole plane sounds like any ugly hack. They slapped very different engines on an existing airframe. Then, when it inevitability exhibited undesirable behaviour, they tried to paper over the cracks. Then they hid this information from their customers, regulatory agencies and the pilots.

It makes me wonder if there are other issues with the Max that the public doesn't know about yet.

I hope a thorough review of Boeing's internal communications is already underway. If there is proof that these decisions were made for financial gain, they should face criminal charges.

IMO, whether it was greed or just general incompetence, Boeing has demonstrated that they are not responsible enough to self-certify their aircraft.

<comment><USER12> The sad thing is that we'll probably see this plane fly again by the end of the year, because the millions of dollars in retrofits will still be cheaper than having to scrap all existing planes.

We have no idea what other potentially lethal corners have been cut. What if they go back into service, after several months of retrofitting all of them at Boeing maintenance hangers, and then the following year there are two more deadly crashes from some other overlooked hack.

Really, these planes need to be scrapped. The engines, equipment, seats, etc can all be stripped and used in other planes, but the air frames will need to be recycled and this line of planes should end here.

Even if it doesn't (probably won't), I highly doubt we'll see another generation of 737s. They did survive the rudder problems way back from the... 80s? or 90s? .. So their reputation might recover, but they still can't make the types of planes airlines want and keep that name/certification.

<comment><USER13> In what world is scrapping the airframes due to a (serious) software fault the best and most sensible solution? Do you believe there could be undiagnosed problems with the wings, fuselage, tail, hydraulics, electrics, fueling system, gear, etc.?

<comment><USER14> _In what world is scrapping the airframes due to a (serious) software fault the best and most sensible solution?_

A world in which the faulty software was required to fix faulty hardware.

<comment><USER15> The hardware isn't faulty. The problem is the way Boeing tried to achieve a zero training delta so pilots wouldn't have to get a second type rating.

<comment><USER16> the airplane did not have stable flight characteristics because of its physical design.

that's a hardware problem.

MCAS only exists because of that hardware problem.

the fact that boeing also did not train or tell pilots about MCAS, in order to make the airplane more financially appealing by retaining the 737 type rating, is a separate (also bad) issue.

<comment><USER17> Citation needed.

FAR 25 applies to all transport category aircraft. The section on stability (§§ 25.171 - 25.181). In exactly what manner is the airplane not stable, with or without MCAS?

<comment><USER14> From TFA

 _But a few weeks later, Mr. Wilson and his co-pilot began noticing that something was off, according to a person with direct knowledge of the flights. The Max wasn't handling well when nearing stalls at low speeds._

<comment><USER17> Insufficient. Stability requirements in FARs are clear, and not handling well might mean "substantially different from prior 737s" not unstable.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> The day someone very high up the corporate ladder truly gets held responsible for this type of greed & negligence and will be put a way for a long prison sentence would be a good day for society. But I am not holding my breath...

But I hope that the CEO Dennis Muilenburg deep down understands he seriously fuxxed up real bad and every now and then is having a hard time falling a sleep in his $10M mansion knowing that he is ultimately responsible for hundreds of peoples unnecessary deaths due to his failed values as a leader.

<comment><USER19> Your comment makes it sound like you believe there was a single person with nefarious intentions or criminal negligence who chose to put lives at stake in exchange for profits.

That is almost certainly not what happened. It is more likely a system of procedures and policies which failed. The company should take the hit, but unless an investigation reveals otherwise, I see no reason a single individual should take the blame for all of this.

<comment><USER20> > That is almost certainly not what happened. It is more likely a system of > procedures and policies which failed. The company should take the hit, but > unless an investigation reveals otherwise, I see no reason a single > individual should take the blame for all of this.

Aren't the insane compensations of executives justified by their "great responsibility"? So I think it makes them eventually responsible for what their companies do.

<comment><USER21> I heard someone say this and I can't remember who, but it seems very appropriate. One of the key responsibilities of the CEO (and by extension upper management) is to acknowledge reality. When the company is given permission to act on what it already knows, then employees have the right incentives to do the right things and not just the things that won't get them fired.

In that sense, it absolutely is the fault of Boeing management for not acknowledging reality.

</comment></comment></comment></comment><comment> tuna-piano How MCAS slipped through certification process was not the main issue (mistakes in complex products can happen). The main issue was Boeing not caring that MCAS was dangerous even after discovering it.

After the Lion Air crash, it was very apparent to Boeing that MCAS was not safe. This whole article focuses on how MCAS slipped through development+certification - but really even after Boeing new the dangers of MCAS, the MAX still was allowed to fly.

It was hidden and dangerous. Then it was open and dangerous but was still defended by Boeing. Damning.

<comment><USER22> _How MCAS slipped through certification process was not the main issue_

I think it's a huge issue, but perhaps not criminal. The hiding/lying/etc is a criminal issue in my view.

</comment></comment><comment><USER23> Great article. But for me there's a huge question being left unanswered, like the elephant in the room:

Why did exactly did the engineers/test pilots feel the need to "enhance" the original MCAS with the new, more powerful version that worked at lower speeds? What did they know? I doubt they did it for the hell of it. And therefore, what has changed that that enhanced functionality is now no longer necessary, and it's fine that MCAS is being returned to its original, more subtle implementation?

These things just don't add up for me and Boeing's constant pronouncements that they did nothing wrong, everything was fine, and now they're fixing it so everything will be even more fine ring very hollow indeed. I would almost like to see everyone involved in this subpoenaed so the public can learn the truth of what, exactly, took place.

Until we have some answers, especially to my main one - what was so bad about the airframe's handling that it was necessary to massively increase the power of the MCAS system, but is now apparently not necessary anymore and it's fine for them to nerf it - I don't think I'll be flying on a MAX.

<comment><USER24> The answer to why they wanted to "enhance" MCAS is that they wanted it to be certified as a 737 like all previous versions, which means pilots need to be able to fly it exactly like previous 737s without additional training, and a technical hack which "corrects" pilots' actions facilitates that.

</comment></comment><comment><USER25> Is this only me, or all this one-vs-two AoA sensor talk seems some kind of diversion from the real problem with this plane.

I mean, if one-sensor based MCAS failed twice so early in the life span of the plane model, what is the probability that a two-sensor model will fail pretty soon as well? The math should be simple, we have all data needed: combined hours flown by all planes of the type and number of failures (at least two known, which can help us to estimate a MTBF of the sensor).

<comment><USER26> The problem isn't failure, but detecting failure.

If the sensor had just stopped responding, there wouldn't have been any problem. The planes would keep flying, the sensors would get replaced, and everyone would be fine.

What happened was that the sensor gave erroneous readings. The MCAS system reacted to those erroneous reading and crashes the plane.

With two sensors, you can detect failure. It's very unlikely that both would fail simultaneously. If they did, it's very unlikely that both would provide the same erroneous readings.

<comment><USER27> _It's very unlikely that both would fail simultaneously._

Birgenair 301 crashed into the Atlantic because mud dauber wasps built nests in _both_ pitot tubes while the plane was on the ground. It happens.

<comment><USER26> Airspeed is required for safe flight. The failure on that flight was detected immediately, it just couldn't be handled. AoA on a 737 MAX is not required for safe flight and the system just needs to refrain from taking any action if it fails.

<comment><USER28> But MCAS was added because the plane doesn't handle well in some situations.

<comment><USER29> I haven't heard of it ever activating except in the incident/accident flights. It's required for certification, but you would either have to be mishandling the plane or get in some extreme weather for MCAS to activate.

Think about it like the Antilock brakes on your car. Suppose the wheel position sensor fails. It's fine if the car puts up a warning light and says that you don't have antilock brakes anymore. You can drive fine without them until you can get them fixed with a minor safety impact. It's not fine if the wheel position sensor fails and this causes the car to slam on the brakes going 65mph down the highway.

<comment><USER5> ABS isn't the best example because it does prevent lots of accidents in its own right, including a >50% prevention rate of some types of accidents in rainy, snowy, or icy weather. The overall fatal accident reduction is 15% for cars and 27% for trucks and light trucks. Source: [https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/...](https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/811182)

And, anecdotally, I've had ABS kick in in some occurrences for which I was very thankful.

<comment><USER29> Having a safety system that rarely _fails to prevent_ an accident is much different statistically than a safety system that rarely _causes_ an accident.

Suppose the crash probability on a normal flight is 1/1E7, but without MCAS it's 100x more dangerous, or 1/1E5. Suppose MCAS failure probability is 1/1E6, the probability of an additional crash due to the failure of MCAS is 1/1E11, which is acceptable.

The problem is that in practice, the crash probability if MCAS fails is empirically 2/3 instead of 1/1E5, because MCAS actually causes the crash rather than merely failing to prevent a crash.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> _Boeing engineers did consider [MCAS activation due to failed sensor] in their safety analysis of the original MCAS. They classified the event as "hazardous," ... could trigger erroneously less often than once in 10 million flight hours._

The incuriosity of all parties to an event categorized as hazardous is astonishing. Boeing says it's a system that's completely transparent to the pilot, and therefore there is no need to describe a failure that they say would be hazardous. What part of that passes a reasonable smell test? It's safe unless it fails, which would be rare, but if it fails people could die? But meh, it's rare so let's not even find out what would happen if it happened?

Boeing must be compelled to show their work for this probability computation, because it is clearly wrong. And both Boeing and the FAA have to answer why there's no mandatory testing of hazardous events. At least what does a simulator think will happen in various states of perturbed sensor data, and how does a pilot react when not expecting such an event?

Oh, and the part about depending on a single sensor is not, per Boeing, a single point of failure because human pilots are part of the system? That's a gem. The pilots are the backup? This poisonous form of logic is perverse.

<comment><USER30> If the pilots had recieved training, __then __they could be a backup. So probably whoever did that safety analysis was assuming pilots would know how and when to turn off the system, but the pilots in fact didn 't know this system existed at all.

<comment><USER31> Administrative mitigation like pilots are usually the least preferential ways of mitigating hazards. Humans are often the least consistent, most fallible part of a system. If there were engineering solutions available I would hope Boeing would implement them.

<comment><USER32> There are many examples of automated systems not accounting for novel or rare situations that the original designers didn't plan for or ignored. This is why manual override should always be available as a last resort if possible. No automated system we can design today is perfect. While protections and automatic mitigation should be implemented, taking away agency from pilots or whoever else is a recipe for disaster.

<comment><USER31> I wasn't implying that humans should be taken out of the loop. I was more referring to the hierarchy of mitigation. Most preferable are to design the hazard out of the system, followed by engineering controls, and lastly procedural/administrative mitigation.

Too often systems are designed with procedural mitigation as the primary way of controlling a hazard without realizing all the human factors that come into play. Maybe the pilot is distracted because she just had a fight with her spouse. Maybe her co-pilot a bad night's sleep. Or maybe he isn't physically capable generating the force necessary to move the trim wheel.

I think too often designs can over rely on administrative mitigation because the engineering controls seem too costly or difficult to implement. In some cases, this rationalization that a person "just" has to do XYZ activities to control the outcome falls short because we don't acknowledge all the factors that person is dealing with in the moment.

In this case, to someone like me without intimate knowledge of the Boeing process, it looks like they failed at their hazard analysis. They did not design the hazard out of the system (airframe design), the engineering controls were inadequate (MCAS), and the administrative controls were poorly managed (pilots did not understand the procedures for disabling MCAS or the procedures were not capable of being executed effectively). In other words, they did not apply appropriate hazard analysis and mitigation. Hindsight is easy, I know, but when schedule pressure hits a lot of these processes are rushed.

</comment></comment></comment></comment></comment><comment><USER33> This was premature automation caused by not fully understanding the context. Results in less friction at the cost of enabling a black swan. Bad trade off. The Viking Sky cruise ship that was 1 minute away from releasing its damage potential of about 1300 people. 4 engines stoped simultaneously to protect them selves. Risking the entire ship in one of Norway's most dangerous waters during harsh weather. There are so many similar examples. Tank turrets self protecting and killing soldier during peace time. Automatic gearbox on military vehicle self protecting against overheating although vehicle is under enemy fire, but the sensor can't know that.. we need to rethink how "security automation" should work. How do you know if an override is relevant? How to train the operator?

<comment><USER33> It's like these examples of security automation are designed to have the exact opposite effect as chaos engineering.

</comment></comment><comment><USER34> Whatever it's worth, this whole thing has traumatized me so much it makes me fearful of flying at all. But one thing's for sure, if I have any say, I'll probably never fly a 737 MAX again.

I'm sure there are many people who will do the same. In fact, every flight I do go on now, I check to make sure it is not a MAX.

I doubt there will be enough people who think this way that it would cause a problem economically for any airlines that carry this line, and I'm sure with time, people will forget, but I sure as hell will do my best not to.

</comment><comment><USER35> "As part of the fix, Boeing has reworked MCAS to more closely resemble the first version."

Be very wary if pilot training is not part of the "fix" to getting the Max back up in the air. If MCAS is being "rolled back" then certain situations such as "The Max wasn't handling well when nearing stalls at low speeds." come back.

<comment><USER36> Anything short of admitting "we fundamentally screwed up, and are rethinking the poor decision to pair this engine with this airframe" as well as "we are reviewing all our design processes and how the FAA oversees every step of the process" is unacceptable. MCAS is just the horrific bloody bandage that is peeling away, it's not actually the problem here.

This probably won't happen of course, all they seem to want to do is fix as little as possible as quickly as possible while denying they ever knew anything.

If I were someone powerful like a pilot union leader I would start throwing conniption fits in public and refuse to let my people fly on Max's at all.

<comment><USER37> _Anything short of admitting "we fundamentally screwed up, and are rethinking the poor decision to pair this engine with this airframe"_

Can you cite the basis for this often-expressed sentiment? There's absolutely no reason why a properly-designed and -vetted MCAS system wouldn't have been a perfectly acceptable solution to any handling irregularities caused by the engine configuration.

The idea was fine. The fault was 100% in the implementation.

And no, downvotes are not a valid citation.

<comment><USER38> It's not impossible to make it work, and in the future I'd expect more and more automated systems in planes for sure.

But you have to recognize the whole engine hack is just a convoluted workaround to avoid as much pilot training as possible. The entire goal of the project seems to be to avoid ever training pilots for as long as possible. It's a brand new plane, the newest plane on the market, and the first thing you need to do to take off is turn off the cabin air conditioning. Why? Because that's what we had to do 50 years ago in the first 737.

God forbid this plane startup any way besides turning off the cabin air conditioning. If we changed that, we'd have to... _gasp_ retrain pilots!

<comment><USER39> The problem with training pilots for a new machine isn't the training itself but rather, that a pilot is rated for one machine type only. If the MAX had a different type rating, MAX pilots would no longer be rated for the non-MAX 737. There are some larger US carriers which are 737 only, partly so that all pilots are trained for all of the machines. Having to split the fleet into two types would have a huge impact on business. Most likely these carriers would avoid getting any MAX as long as possible.

I don't know what is the correct answer to the problem, but clearly good safety regulations are trapping some carriers and Boeing. Sooner or later Boeing will have to build a true successor to the 737 (and I guess, they now wish they had sooner)

<comment><USER40> >The problem with training pilots for a new machine isn't the training itself but rather, that a pilot is rated for one machine type only.

Citation needed. I've never heard this before, except for some other person on a message board, and I've been involved with aviation and known pilots with multiple type ratings.

</comment></comment></comment></comment></comment></comment><comment><USER41> > It never tested a malfunctioning sensor, according to the three officials.

That one popped out to me. Man. Lots to learn.

> Boeing continued to defend MCAS and its reliance on a single sensor after > the first crash, involving Indonesia's Lion Air.

Also...how? So many non safety critical services use a load balancer and at least a couple of servers because who can trust just one thing working perfectly all the time?

<comment><USER42> Another one that popped out: test pilots were pushed to simulator-only by management, with simulators apparently being incomplete with regards to MCAS behavior. Bean counting and incompetence abound in safety critical areas of airplane design - I will think twice before stepping in another recent model of Boeing.

</comment></comment><comment><USER43> How would you design your bureaucracy so that this kind of thing can't happen? I see this type of failure all the time in organizations big and small. Sometimes things are just too complex to have an auteur that can understand the entire system and when every department strives to optimize for its specific goal shit can really hit the fan.

<comment><USER44> Eventually, artificial intelligence.

Maybe not in the near future, but as technology progresses and every manufacturer strives to optimize their designs with the latest features, it will become an unsourmountable task to oversee every aspect of it (efficiently). I'm not talking about actively designing, but rather for warning/flagging for potential error. In very complex enterprises like global transport or building skyscrappers there is a lot to learn from experience and little human time, but it might be very cost-efective to train all-observing self-learning AI to look over everyone's shoulder, and warn you about using the right type of bolts, or how the coming heavy rains in Guatemala might affect your supply chain.

It's not that far-fetched when you realize it doesn't need to really understand anything, just be very good at playing word association and micromanaging.

<comment><USER45> AI is only as good as its training data and goals/success conditions.

<comment><USER44> Yes, AI is designed in very particular situations to fit ver specific tasks. I never meant there to be a single mind controlling the whole world. Today you could program an assisting AI that told you when "you missed a spot" when painting your house. It's simply not cost effective. But eventually driving and medical diagnosis AI, while imperfect, will have a better success rate that humans. Do you really think that won't apply to industrial production eventually, say in a hundred years?

</comment></comment></comment></comment><comment><USER46> I've never understood why they make planes with 1-2 sensors for a crucial reading like airspeed.

Why not have 20 airspeed sensors of 5 different types? It's an obvious failure mode that your one sensor will fail and then the pilots and the computer will be left in a state of dangerous uncertainty about the situation.

</comment><comment><USER47> I am surprised that I haven't seen anyone make the connection to "normal accidents" [1] yet, but feel it is quite relevant in this case.

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

</comment><comment><USER48> All this talk about how mcas was not designed properly or how it could be prevented from failing is eroneous.

Good safe airplane design is about a neutral flying design without the need for complex systems.

This plane is fundamentally flawed because the engines are in the wrong position because the landing gear is two short to fit them in the correct position.

The test pilot was clear about very poor flying characteristics at slow flyong speeds requiring mcas to be more aggressive.

This plane should not be flying with this engine configuration as it fails the most fundamental principal of good aeroplane design of neutral handling.

<comment><USER17> FTA: _The Max wasn't handling well when nearing stalls at low speeds.

In a meeting at Boeing Field in Seattle, Mr. Wilson told engineers that the issue would need to be fixed. He and his co-pilot proposed MCAS, the person said._

It is not clear this translates into a fundamentally flawed design. It's a serious assertion, even though at the same time it's vague. Why did it need to be fixed? To avoid pilot training? Or to pass a FAR 25 airworthiness certification requirement? We can't tell from this reporting. Months after these accidents, people are still asking this question. The difference matters.

I'm very skeptical that software can legally be used to paper over aerodynamic flaws, as I read FAR 25. In fact, neutral design is not adequate, it must exhibit positive static and dynamic stability in all three axes. Fly by wire software doesn't make a plane with negative stability behave as if it has positive stability, the software provides various safeguards in a layered manner.

</comment></comment><comment><USER49> Sounds to me like the main failure here is that Boeing went _too far_ with optimising cost, in the sense that MCAS was not properly designed.

I'm certain correctly designed software can safely control critical functions, otherwise failure in a large category of aircraft systems would result in many more MCAS unrelated accidents.

This particular MCAS control philosophy seems to be a flawed control system. With reference to the the graph (link provided by obituary_latte):

[https://i.imgur.com/WJuhjlO_d.jpg?maxwidth=1640&shape=thumb&...](https://i.imgur.com/WJuhjlO_d.jpg?maxwidth=1640&shape=thumb&fidelity=high)

With only one sensor being "looked at" at any time, and with the system not having the sense to know to stop commanding pitch down after 26 times with attempted pilot overrides, it would seem almost beyond belief that any competent team of on-the-ground engineers (as per Boeing) would not see that the system is flawed.

Would be interesting to see if this was the case, and how the likely good engineering decision was overridden by the commercial aspect.

With increased tech, comes increased scope for this kind of cost optimisation, and we must be careful in many more industries. Eg Automotive self driving cars.

</comment><comment><USER50> This article reads to me like Boeing and the FAA have gotten their stories straight with each other and in naming names have settled upon someone who is no longer associated with either in an effort to take the heat off of both.

</comment><comment><USER51> Why didn't they just bring back the already-certified 757 instead of stretching the 737?

<comment><USER39> The problem isn't the certification of the plane, it is the certification of the pilot. A 757 or a true successor to the 737 would have meant that pilots would have to be certified for the new plane - and that means they lose their certification for the plain 737. The MAX is targetted at carriers which already have large fleets of 737 and the idea was that the same pilot could fly both.

</comment></comment><comment><USER52> How confident is everyone on all the other changes to the 737?

They've found the MCAS issues, but with a procedure this lax I'd expect several other issues to have gotten through.

</comment><comment><USER53> Empires destroy institutions.. they hollow them out until are barely cloths for one figure residing within. Proofing something to an institution is hard. Proofing something to one person is "easyish". The problem is not that one plane manufacturers internal culture allowed falling behind, but that this rot and decay bypassed controlling institutions, because these where hollowed out for empire reasons. You can not defeat this problem unless you solve the root node. Which are hidden deals instead of proper procedure replacing the physics of capitalism.

</comment><comment><USER54> how is it that boeing still has not admitted fault? i guess they bet to get out through a loophole in the investigation result; investigation that they are part of i assume? something like "it was 1% pilot error" is enough to make a pr campaign from.

</comment><comment><USER45> I'm surprised no one has mentioned Therac 25 or Normal Accidents yet.

For reference, the Therac 25 was a computer-controlled radiation therapy machine involved in several over-exposures due to replacement of physical controls with computer based ones without complete understanding of the interactions of the controls.

The Max feels very much like that. No one can really keep a whole aircraft in their head, much less a whole aircraft development project. We use computers for that, as well as mental heuristics. But if those computers and brains are not fed all the proper data and connections, they will not find the all the problems.

Additionally, there seems to be a lot of the tail wagging the dog. If this system is expected to perform according to X specifications, then by golly it will, and we will show that it does.

[https://en.wikipedia.org/wiki/Therac-25](https://en.wikipedia.org/wiki/Therac-25)

Edit: Please don't take the above as absolution of Boeing. Someone (a lot of someones) really should have known better.

<comment><USER55> I don't see these as equivalent, at least not based on what I've learned about the cases (feel free to correct). As I understand, Therac-25 was due to software bug and a genuine design process inadequacy that allowed it to cause a problem, that could happen with people acting entirely in good faith, simply because they didn't know better. That's why they created standards to address the design process. With 737MAX... pretty much literally everyone could tell you the decisions were bad, and so many seem to have been made in bad faith, specifically to e.g. avoid recertification and increase revenues in a pretty reckless manner.

<comment><USER45> It's not the equivalent, but it is the consequence of a chain of incremental changes, each of which is not sufficient to subvert safety margins, but together they change the paradigm.

As to bad faith, yes, I'm sure there was some of that, but generally decisions like these don't look like bad faith to the people making them. It's easy to get swamped by technical details.

<comment><USER55> > consequence of a chain of incremental changes

> As to bad faith, yes, I'm sure there was some of that

You're downplaying this. This is not downplayable, and this is not similar to Therac. "A consequence of incremental changes" is a rather gross way to paint this, as if it's hard for a single guy to see how e.g. non-redundant sensors is an extremely bad idea on its own, let alone everything else. There have been _multiple_ huge missteps, not made by accident, each of which is _individually_ worth a huge red flags obvious to people in different areas. That 1 single mistake wasn't enough to bring the plane down doesn't mean the mistakes must've been small or somehow downplayable. And no, this isn't some kind of gray area with people getting genuinely swamped by technical details. It's abundantly clear here's been a _ton_ of bad faith here, that there is still _ongoing_ bad faith even after the fact, and that they're _still_ unwilling to address the problem properly.

<comment><USER45> I'm sorry that it seemed like I was downplaying it.

What I was actually thinking is that this kind of thing is likely to crop up in complex systems, and if we work on complex systems we should be wary for it.

</comment></comment></comment></comment></comment><comment><USER56> I'm surprised noone yet on HN mentionned how Rust would have avoided the failure :)

</comment><comment><USER57> > a fundamental overhaul to an automated system that would ultimately play a > role in two crashes

Are they STILL blaming the computer instead of the unstable air-frame after the engines were moved?

<comment><USER58> The redesign did not make the aircraft unstable. I don't know how this became such a meme, but it's trivial to see that it's not true. Commercial passenger aircraft _must_ be aerodynamically stable by FAA regulation: [https://www.ecfr.gov/cgi-bin/text- idx?node=14:126.96.36.199.11#se1...](https://www.ecfr.gov/cgi-bin/text- idx?node=14:184.108.40.206.11#se14.1.25_1171)

The engine change really wasn't a big deal. The net effect is "flight stick feels lighter at high AoA with high thrust." That's it. My understanding is that the 737-MAX flys more like a 757 in this regard. Nothing crazy, just a difference.

Now, that's enough to require re-certification by FAA standards, because it's enough of a difference that it _could_ cause problems of pilot error. But going on like the aircraft wants to fall out of the sky isn't helping anyone here.

MCAS was intended to be a small tweak that avoids the re-cert. And it would have been fine if they had neutered the system such that it couldn't input such extreme trim angles, or else has more reliability as needed in a system that could have such dramatic effects when malfunctioning.

<comment><USER59> The meme comes from the fact that according to the technical definition of aerodynamic stability, the MAX has pitch instability at high AoA.

FAA certification regulations appear to be willing to accept minor deviance in regard to them so long as they can be convinced there are sufficient technological controls in place to manage the instability.

This is the danger of self-certification by the way. The company signs off that everything is fine, and the regulator is blissfully unaware they've been rused until after people have already died.

</comment></comment></comment><comment><USER60> "After Boeing removed one of the sensors from an automated flight system on its 737 Max, the jet's designers and regulators still proceeded as if there would be two."

No, no, no. This is just more of shifting the blame from Boeing upper management. They couldn't use two Angle of Attack (AOA) sensors as when there was a differing reading there would be no way to know the correct reading, which is why MCAS used a single AOA sensor on the right-hand side.

<comment><USER61> This doesn't seem correct to me, but I can't put my finger on why. Surely if both agree that's more certainty than a single sensor reading. Granted a disagreement would be bad, but at least you would have some warning that one of them is wrong, whereas you would have none at all if relying on a single sensor.

<comment><USER8> You wouldn't be able to know which one was wrong but you'd be able to know and annunciate an AOA MISCOMPARE (which was an option on the Max) and then disable MCAS.

<comment><USER62> Which was not an option to upper management because that would cause training for the event of disengagement and a new type rating.</comment></comment></comment></comment>


Twitter's 10 Rules for Radical Innovators (Umair Haque) - <AUTHOR> http://blogs.harvardbusiness.org/haque/2009/06/twitter_2.html

<comment><USER2> How about:

11\. Not having a business plan means all the tech blogs (cough _Techcrunch_ cough) and journalists in other media keep banging on about you. Read one theory that it's because Twitter make's no money that it seems so perfect: if it made $10 million a year, then if it started to earn $15 million a year it would only have increased by 50%. However, since they're earning nothing at the moment, any profit would be an _infinite_ increase in revenue. To many, this gives them the appearance of unlimited potential. Most of the other points in this article are basically "how to build a web 2.0 hype machine".

Since Twitter doesn't yet make money, and doesn't even seem to have any clear plans on how to make money, I'd hesitate to call it a business. It's a cool project, I'll give it that.</comment>


Diabetes, CVD Tied to Worse Prognosis for Covid-19 Infection - <AUTHOR> https://www.medscape.com/viewarticle/925681 <comment><USER2> Given the rise of type 2 as a co-morbidity in US health contexts, and links to poverty == inadequate treatment (probably also CVD) thus has potential to be very hard on lower economic status families in the USA.

Socialised medicine in Europe is going to make the impact different. I am sure there will be echoes of this but the corn syrup fructose disaster is lesser.</comment>


Autonomous truck cleared to drive on US roads for the first time - <AUTHOR> http://www.newscientist.com/article/dn27485-autonomous-truck-cleared-to-drive-on-us-roads-for-the-first-time.html#.VU-vqfSNFuE <comment><USER2> It's interesting that on the "what could go wrong" discussions on HN, the focus has been on the discussion of insurance and events like truck-jacking. Those are the issues of today. I think there's a far more interesting future at play.

These trucks can and will put people out of work. Right now a large majority of the testing of autonomous vehicles is focused on "perfect environments". Yes, Google will say that test driving autonomous cars in San Francisco is far from a perfect environment; however, in a future where people are loosing their livelihoods, ways to hack autonomous vehicles will be explored, and I'm not talking about just hacking a vehicle CAN bus. All of these vehicles rely on technologies like radar, LIDAR, IR vision, etc. None of which are fool- proof and each of which could fall to very specific attacks. I hope that the auto manufacturers are considering this future. After all, we have technologies today like GNU Radio and the HackRF One which have brought what was once the domain of the nation state to the general public.

<comment><USER3> 25% of Americans were farmers 80 years ago. Now it's 1%.

<comment><USER2> Farming is actually a great example. There were farmers who did fight back against farm machinery. Sabotage of tractors and equipment was an actual thing here in the US and abroad. You can even find whole groups of anti-tractor types in the American Amish country.

These days it's sabotage against GMO crops. You'll find Monsanto and other companies will place their GMO test fields in regions of the country known to be sympathetic and/or will keep them under armed guard.

<comment><USER4> The views of the Amish regarding technology have absolutely nothing to do with employment rates.

<comment><USER2> But yet everything to do with this topic. The Amish believe one must work in harmony with nature. Tractors as an example threaten this harmony. I'm just waiting for some religion somewhere to state that self-driving vehicles are the work of the devil, or a threat to the Protestant work ethic. There might even be some political aspects of this a they are a signal of the coming "liberal leisure society."

<comment><USER4> > The Amish believe one must work in harmony with nature.

I don't quite like that description either. I think it's more that they want to encourage interdependence within the community. They are not opposed to technology that they believe doesn't threaten that community dynamic.

</comment></comment></comment></comment></comment></comment><comment><USER5> The article reports about this model of truck, "the first to be cleared to drive on US roads," but I think that is a factually incorrect exaggeration, based on other reporting I have read about this same model of truck. A Washington Post report[1] says,

"Daimler's tractor-trailer, called the Inspiration Truck, relies on cameras and radar to guide itself. It does not use LIDAR, a sensor that is being used by other self-driving vehicle makers such as Google. Like all autonomous vehicles today, the Inspiration Truck has some limitations. It can't drive on its own during heavy rain, snow or crosswinds above 30 or 40 mph.

"Daimler developed a training system for its drivers that Nevada's department of motor vehicles approved. It's fairly simple, teaching them how to activate and deactivate the autonomous driving system. It says it picked Nevada because of how thorough its rules are for autonomous vehicles."

A thorough National Public Radio report[2] also describes this as a one-state, limited program of experiments.

[1] [http://www.washingtonpost.com/blogs/innovations/wp/2015/05/0...](http://www.washingtonpost.com/blogs/innovations/wp/2015/05/06/how- self-driving-tractor-trailers-may-reinvent-what-it-means-to-be-a-truck- driver/)

[2] [http://www.npr.org/blogs/alltechconsidered/2015/05/10/405598...](http://www.npr.org/blogs/alltechconsidered/2015/05/10/405598189/coming- soon-to-a-highway-near-you-a-semi-truck-with-a-brain)

</comment><comment><USER6> Yet another Simpsons' prediction come true: [http://en.wikipedia.org/wiki/Maximum_Homerdrive](http://en.wikipedia.org/wiki/Maximum_Homerdrive)

</comment><comment><USER7> Similar to a train. An operator is present, waiting to take control if necessary. I bet there'll be a dead man's vigilance device[1], just like in the rail industry.

[1] [https://en.wikipedia.org/wiki/Dead- man%27s_vigilance_device](https://en.wikipedia.org/wiki/Dead- man%27s_vigilance_device)

</comment><comment><USER8> Autonomous trucks will be there probably earlier than autonomous cars. For cars it would be a feature for people, but for trucks you would be able to save tons of money with it.

<comment><USER9> Where does the saving come from if they still require a driver? From the article, it sounds like the biggest gain is probably in hiring. Possibly also additional savings in fewer accidents. (lower overall fatigue)

<comment><USER10> Semi-autonomous road trains, assuming - and I admit this isn't a minor thing ;) - only the lead lorry need be occupied, would let you get more lorry-hours per driver hour. This might not actually improve the driver:lorry ratio, but by spreading one driver over multiple lorries you could operate the lorries in shifts with that same ratio.

Say currently one driver can drive 8 hours per day. So if you need to drive for 24 hours, it's going to take 3 days. If you had 3 lorries doing that journey, it would take 3 days.

But say you had your semi-autonomous road train. Now you could do the journey in 24 hours. One driver drives for 8 hours, then the next guy, then the next guy. The two lorries behind just tag along.

Imagine 3 x 25 hour journeys, where the destinations didn't quite match. Previously this would take 4 days. This time: there's 24 hours of shared journey and an extra unshared hour of travel at the end of the route. Now your drivers have to split up at that point. The guy who was driving the road train last will have to wait 16 hours, so his journey takes 24+17 = 41 hours; the guy who was driving before him will have to wait 8 hours, so his journey takes 24+9 = 33 hours; the other guy can jump in his lorry and go straight away, so his journey takes 25 hours.

<comment><USER11> > Semi-autonomous road trains

Actually, why aren't there _fully_ autonomous freight trains on railways yet? We have driverless commuter trains (Docklands Light Railway) why not the same for long distance freight? The infrastructure is there - automated signalling devices in cab, it doesn't seem too big a leap. One hurdle might be unions, I recall ASLEF or someone got upset about the DLR when it first appeared?

<comment><USER12> There are.

in Australia there are a few automation projects for mining rail.

</comment></comment></comment></comment></comment><comment><USER13> "In the meantime, several issues still need to be addressed. It is not yet clear how insurance companies might cover self-driving vehicles, for instance, or where blame would be attributed in a road accident."

Who is responsible is going to be the big make / break for all self-driving vehicles. I get the feeling this is going to be very messy.

<comment><USER14> I don't always understand this POV. My current car has radar guided cruise control and auto braking - if these fail, who's responsible? Isn't auto- driving cars the same thing on a larger scale?

<comment><USER15> You have controls to override the car if they fail and you shouldn't be purely relying on them, so you're at fault. If you don't have any means to override them and you're expected to purely rely on them, surely you can't be at fault because what could you have done?

<comment><USER14> How do I override the automatic brakes if they decide to engage while I'm driving down the freeway?

<comment><USER15> I always assumed it was similar to cruise-control insofar as it can be turned off?

</comment></comment></comment></comment></comment><comment> trimble-alum There are a raft of unaddressed safety and licensing issues to verify that autonomous navigation feedback systems can sense danger and perform evasive, ingenious maneuvers sufficiently to preserve life and property. This is one of the reasons why incremental features are less risky than going all in to uncharted waters.

</comment><comment><USER16> If trucks become completely autonomous what will prevent someone from standing in front of one causing it to stop and then robbing it?

Unlike with human drivers that may not stop if they believe they are in danger of getting carjacked I assume an autonomous system will be required to avoid hitting a human at all cost.

<comment><USER17> There are laws against robbing trucks. I guess they will stay about as effective as they are now; it is not as if there aren't ways for would-be robbers to stop a truck now (for example by crashing a stolen car in front of it)

As others said, the truck might call 911 before it has come to a stop. Also, 911 operators might get a remote override switch that allows them to instruct the truck to take some evasive action.

I do expect additional laws in the area of autonomous cars, but not to prevent robberies. If autonomous cars become really, really, good and ubiquitous, there is no reason for pedestrians to watch out for cars when crossing a street. That will lead to some funny, but disruptive (for the flow of road traffic) videos on YouTube (yes, you can play Frogger on a 8-line highway with your eyes closed and survive. The crocs aren't robots yet, though)

<comment><USER18> > yes, you can play Frogger on a 8-line highway with your eyes closed and > survive.

I wouldn't be so sure about that. I don't know about the US, but here in Germany the autobahn is supposed to be off-limits for people (and vehicles with a design speed below 60km/h for that matter). This is obviously to allow drivers to drive with the assumption that they don't have to be ever-vigilant about cyclists or children crossing the street.

Autonomous vehicles will likely operate on the same assumptions to behave more optimally given the constrained environment, i.e. drive in a more aggressive manner than they would do in a city.

I.e. strolling at moderate pace over a highway would probably have about the same risk as hiding ducked behind a parked car to jump in front of a bus in the city. Both are situations that no sane person should engage in and both are considered acceptable risks not worth defending against.

<comment><USER17> Cars on the autobahn will not want to hit deer, people getting out of their car while parked on the emergency lane, or people walking on the road to place a warndreieck ([http://de.m.wikipedia.org/wiki/Warndreieck](http://de.m.wikipedia.org/wiki/Warndreieck)) warning for their stranded car, a few hundred meters on, either.

And I expect that what constitutes an acceptable risk will go down and down, as long as technology allows for it. It's already happening al the time. Seat belts are compulsory, air bags are compulsory, ABS is compulsory, etc.

But yes, the frog get thing is not something I would advise to do. On the other hands certainly, in cities, it will be much, much safer for pedestrians to step out into traffic without paying much attention to that traffic. That will affect how pedestrians behave.

<comment><USER18> > And I expect that what constitutes an acceptable risk will go down and down, > as long as technology allows for it.

Well, I do think that the risk of pedestrians on the autobahn isn't something we optimize for.

In the city? Yes.

Reducing the risks of occupants? Yes.

Driving defensively on the autobahn because someone might walk into the traffic? No.

The potential optimizations for the restricted environment that will be made there will be for increased traffic flow, more flexible lane switching or things like that. Maybe even saving fuel by driving in the tailwind of another vehicle.

</comment></comment></comment></comment></comment><comment><USER19> truck driving is the most common job in the western states.

<comment><USER20> I have many truck drivers in the family. That's no way to live a life and they constantly talk of quitting. I think this news is very welcome.

<comment><USER21> What would they do if their jobs were all eliminated overnight? Would they go get a job that will give them a better life? Probably not, because they would have done that already.

<comment><USER22> Autonomous vehicles will not show up and take over overnight. My prediction will be close to full saturation(in most areas) in ~50 years. Improving the technology, infrastructure and regulatory hurdles will all be rolled out incrementally.

</comment></comment></comment></comment><comment><USER23> Driving jobs go byebye.

</comment><comment><USER24> when AI takes over it will be easier for them to run us down, or cut off supply chains.

<comment><USER25> Which is why I for one, welcome our new robot overlords.

</comment></comment><comment><USER26> "But they are not totally driverless. A human driver still sits behind the wheel, ready to take over in case of a lane change or unexpected hazard."

Autonomous with a requirement for a human driver doesn't sound like real progress. Title might be a little misleading.

<comment><USER27> Does automated factory equipment with a human overseeing its operation and correcting error cases sound like real progress over what came before? If so, why doesn't it sound like progress when we have an automated truck with a human overseeing its operation and correcting error cases?

<comment><USER28> Though, I agree this is progress, I don't think your analogy is correct here. The progress you're referring to allows 1 person to oversee machines that do several people's work. 1 person = 10 jobs.

With the trucks, you have the same person overseeing his own job, except that it'll be done safer. 1 person = 1 job (safer).

Your analogy would make more sense if the trucks were remotely supervised and 1 person could oversee several trucks via remote connection.

<comment><USER20> In time, all of that will happen. Right now there is too much (warranted) skepticism that society won't let a driverless truck running around alone. In a few years, after proving that the number of incidents is much less than with human drivers, everybody won't care.</comment></comment></comment></comment>


Open-source chip RISC-V to take on closed x86, ARM CPUs - <AUTHOR> http://www.computerworld.com.au/article/618724/open-source-chip-mimics-linux-path-take-closed-x86-arm-cpus/ <comment><USER2> I thought that microprocessor production and design was fraught with risk of infringing on other designers' patents (even for original ISAs). I can see that industry heavyweights have arrived to support RISC-V, so hopefully that comes with a team of professors/lawyers that could defend them. But, why now? Why couldn't this have happened sooner? Didn't Sun try to create an open SPARC processor design? What does RISC-V have that it didn't?

Is the intent for RISC-V to compete with modern high-end CPU designs, or do we just want to have royalty-free microprocessors for our embedded devices?

You might be surprised (at least I was) to learn that peripherals like hard drives and PCI-add-in cards usually have their own CPU executing their own software. Those processors are often MIPS/ARM/etc based and the manufacturer has to shell out to someone to be able to use that, even if they designed the processor themselves. I can see how this particular market is ripe for something like RISC-V. But does anyone expect RISC-V to really go head-to-head with Xeon, Opteron, ThunderX, Centriq?

I sound incredulous because this seems surprising to me, but I have no evidence to suggest whether it's as unlikely as I think. I've certainly seen open source software designs far superior to closed source ones, so maybe hardware design is no different?

<comment><USER3> The RISC-V team was very careful in establishing prior art for every design decision. The patents on ISAs tend to be on their quirks, so keeping things truly minimal helps avoid all of that complexity.

Like a lot of what Sun did, prior open chip designs weren't good enough. Academics starting with a clean slate and a 20+ years of additional experience gives RISC-V real advantages over MIPS and ARM.

The primary advantage is that RISC-V is truly RISC: they have a core ISA that is frozen but extendable. This means that they can have application-specific CPUs with intelligent fallback and full compatibility.

As to why now, well, they came up with RISC-V as a teaching ISA and started getting emails from industry asking why it had changed from last semester. It turns out that chip manufacturing has gotten cheap, with custom runs on 28nm processes going for $30K.

You are correct in that their early target market are co-processors and other niche components. Just getting a license from ARM is 10+ million dollars. But the biggest cost in building your own ISA is investment in software and tooling. RISC-V gives a common foundation for everyone to build on.

However, their intent is indeed to bring competition at every level. Their licensing scheme was chosen specifically to allow big players to create IP and keep the secret sauce to themselves, unlike SPARC V8 and OpenRISC.

Apple creates their own CPU and GPU designs, Google has custom hardware for machine learning, and Samsung is about to overtake Intel as the world's largest chip manufacturer. Why should they keep shelling out billions to ARM, Intel, and AMD _just_ to use their ISA?

<comment><USER4> > Just getting a license from ARM is 10+ million dollars.

 _Which_ license? ARM offers several different models.

> Apple creates their own CPU and GPU designs, Google has custom hardware for > machine learning, and Samsung is about to overtake Intel as the world's > largest chip manufacturer. Why should they keep shelling out billions to > ARM, Intel, and AMD just to use their ISA?

The Google hardware we know (TPU) for learning does not use ARM at all, so they would obviously pay nothing there. BigCo's like Apple or Samsung are probably ARM partners, so no per-design/unit fees.

Samsung _Electronics_ may become the biggest chip manufacturer soon, but much like with smartphones that's only by turnover, not profit. But profit is what ultimately finances your R&D.

An interesting titbit is that even Intel and ARM are, at least on paper, partners.

<comment><USER5> Well, a 10 million dollar license is nothing of you factor the Fab costs

<comment><USER6> Apples and oranges. The companies that design the chips and pays royalties for IP are mostly fabless (with rare exceptions like Intel). The fabs are owned by separate entities like TSMC, Samsung, SMIC that specialize in the production itself. The fabs don't pay for CPU IP (they sometimes pay for some other basic IP to be able to offer them as standard to their customers, but that doesn't cover CPUs/GPUs).

About Samsung, they're on both sides but with separate legal entities.

The licensing cost IS usually significant to most fabless companies, who come in many sizes. Most are not as big as Apple or NVidia. The fabless model comes from the very high cost of a modern fab, it allows sharing a fab through many fabless design houses.

ARM has the reputation of being cheap, because the typical IT/software people compare them to Intel. And yes, compared to Intel most anyone is cheaper ;) But in the embedded space, which is cost sensitive, ARM is not cheap. It's like what IBM and Microsoft were in IT: nobody got fired for choosing them, and they come with a very powerful ecosystem. Something they make client pay for.

In front of ARM, one can find good technical competitors depending on the target market (MIPS, Cortus, Andes, Beyond Semi...). But MIPS ecosystem is smaller, and for the others waaaaay smaller.

RISC V has an opportunity in time to provide a good technology, backed by a strong ecosystem, for lower costs. In the embedded space at least, this is a very powerful combination.

<comment><USER7> The older OpenRISC had already found a few niches. For example, the management core in some of Allwinner's newer ARM SoCs is apparently OpenRISC, presumably because they didn't want to license another lower-end ARM core or something. Similarly, some Samsung TVs apparently use it.

</comment></comment></comment></comment></comment></comment><comment><USER8> Many people claim to want an open-source chip, but end up balking at its price tag, this is exactly why Raptor Engineering's Talos failed. [1]

I've pretty much given up hope on a non-x86 based chip hitting our desktops, the closest to reach will be ARM.

The economies of scale aren't there, I pretty much end up rolling my eyes at each of these articles.

[1] [https://www.raptorengineering.com/TALOS/prerelease.php](https://www.raptorengineering.com/TALOS/prerelease.php)

<comment><USER9> The hole point of a free ISA is that many different people can produce them so that it will reach a economy of scale and chip producers will face competition making dirving down price.

Its not garantied to work but its a worty target.

<comment><USER10> Free is about freedom, not price.

<comment><USER11> So, freedom is only for the rich?

<comment><USER10> Freedom is sometimes efficient enough that it costs nothing to have freedom.

Other times, there are real or artificial barriers that mean freedom has a cost. In those cases, someone has to bear the cost or forego freedom.

</comment></comment></comment></comment></comment><comment><USER12> AFAIK, most advanced RISC-V design includes superscalar and OoOE (e.g. comparable to a MIPS R10000 (1995) or an Intel Pentium Pro (1995)), while the RISC-V for the IoT is comparable to a typical single instructions per clock RISC CPU, e.g. MIPS R3000 (1988).

The success in the IoT will depend not only in a cheaper price because of no royalties, but also in the "ecosystem": peripherals, buses, etc. Running Linux is a huge start, so I have no doubt it can be a success in this field.

Regarding the use in mobile and desktop, it will have to wait until SIMD extensions are introduced, and software being adapted (e.g. ffmpeg/libav including RISC-V assembly SIMD implementation for the codecs).

Anyway, realistically, for the RISC-V getting enough traction, some big player should bet on that, which is currently highly improbable, unless some Apple/Samsung/Huawei/Google gets crazy enough for doing it.

<comment><USER13> >Regarding the use in mobile and desktop, it will have to wait until SIMD extensions are introduced

I'm little confused about this talk and comments in here relating to open source in high performance applications (desktop, servers etc).

The RISC-V ISA is open source, I get that. There can also be open source Verilog/VHDL designs available. They are probably good for small low performance IoT applications and old processes.

But there is long way from ISA to silicon in high performance VLSI processor design for a new processes and foundries. Architecture, logic synthesis, timing analysis, floor planning, routing and placement, and ungodly amount of testing .. I don't see anyone spending hundreds of millions of chip design for RISC-V ISA and open sourcing it.

In other words, if you want competitive RISC-V chip, some company must spend hundreds of millions to develop their own RISK-V chip architecture and they will not open source it.

<comment><USER14> > In other words, if you want competitive RISC-V chip, some company must spend > hundreds of millions to develop their own RISK-V chip architecture...

I wonder if a country like Russia, wanting something that they can deploy without worrying that the NSA & Intel are cooperating on state spying, will eventually try and take something like this and bootstrap a domestic semiconductor line of business.

<comment><USER13> Russians have build their own processors for decades. They have used SPARC instructions sets and they also have their own VLIW Elbrus 64-bit ISA and processors are made by TSMC for 28 nm process. It has Intel x86 comparability with system-level dynamic translation.

Just adopting new Instruction Set Architecture (ISA) is not going to help to magically boost semiconductor business.

<comment><USER15> The Russians have Baikal (T1), the Chinese have Loongson (3A/B). Both are MIPS based. Unfortunately, even though both announced that there will be consumer hardware available over a year ago, it did not happen. So I'm not too optimistic regarding RISC-V.

</comment></comment></comment></comment></comment><comment><USER16> I want to buy RISC-V, both to play with and to support the cause. What are my options like and should I buy something now or wait for the next generation?

<comment><USER17> Apart from buying an actual dev kit like HiFive from SiFive, a great way to get into it is to buy SiFive's FPGA kits

[https://dev.sifive.com/freedom- soc/evaluate/fpga/](https://dev.sifive.com/freedom-soc/evaluate/fpga/)

The FPGA board can be used for other things too. If you are really adventurous, I'd suggest buying a FPGA board with better chip so you can fit in larger IP blocks in the future. It will work perfectly fine as a replacement for the above FPGA kit I've linked to.

My suggestion would be this[1]. It has a pretty large LUT count so you can go nuts. The RAM and Ethernet will be pretty useful if you want to run linux[2] and test out stuff. It'll be a bit hard to run linux on it right now.

On the other hand, you can choose a Parallela board[3] which comes with a FPGA chip along with a new (soon to be retired) arch called epiphany. Here[4] is a GSoC project which runs linux on that board using the FPGA.

[1]: [http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga- traine...](http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer- board-recommended-for-ece-curriculum/) [2]: [https://github.com/riscv/riscv- linux](https://github.com/riscv/riscv-linux) [3]: [https://www.parallella.org/](https://www.parallella.org/) [4]: [https://github.com/eliaskousk/parallella- riscv](https://github.com/eliaskousk/parallella-riscv)

<comment><USER18> I see that what they recommend for the freedom platform

[https://www.sifive.com/products/freedom/](https://www.sifive.com/products/freedom/)

today, is a dev board

[https://dev.sifive.com/freedom- soc/evaluate/fpga/](https://dev.sifive.com/freedom-soc/evaluate/fpga/)

that costs around 3500 USD:

[https://www.avnet.com/shop/us/p/kits-and- tools/development-k...](https://www.avnet.com/shop/us/p/kits-and- tools/development-kits/xilinx/ek-v7-vc707-g-3074457345626227804/)

Do anyone here know what kind of "classic pc" performance one is likely to get out of a board like that? Could you get on the order of low-end pc (~500 dollar soc / netbook with real gigabit ethernet, sata6 and usb3) from something like that, if paired up with a reasonable cpu design?

<comment><USER19> A somewhat speed-optimized IP CPU core [1] runs at 600DMIPs on a Virtex7. I would hope that SiFive is in the same ballpark, but it's probably slower.

Even in a best-case scenario, this is nowhere near a low end consumer PC.

edit: For reference, my 5 years old Thinkpad x230 does around 7400 DMIPs per core.

[1] - [https://www.xilinx.com/products/design- tools/microblaze.html](https://www.xilinx.com/products/design- tools/microblaze.html)

<comment><USER18> Well, that actually sounds a lot better than I feared - I have a aging aspire acer one that works fine as a lightweight Linux desktop.

</comment></comment></comment></comment></comment><comment><USER20> RISC-V is atleast 10 years away from competing with x86 and ARM. It is just now getting to a point where it can power arduino class hardware. Long way to go... but looks promising.

<comment><USER21> The Freedom E310 chip in the HiFive1 board is shipping today and is already competitive with embedded ARM: [https://www.crowdsupply.com/sifive/hifive1/#comparisons](https://www.crowdsupply.com/sifive/hifive1/#comparisons). It's comically faster (i.e., 100x) than the AVR chip in the Arduino Uno board, but the similar form factor makes it cheap & easy for early adopters to play around with.

I'd bet that within five years a good proportion, even the majority, of Amazon & Google servers, will be running on RISC V chips.

<comment> nezza-_- Is there a power consumption comparison?

<comment> nezza-_- (I know there is DMIPS/mW, but looking for a direct power consumption comparison)

</comment></comment></comment></comment><comment><USER22> As someone not knowledgeable about hardware, I really enjoyed reading Agner Fog's message board where he and others discuss creating a new open source instruction set: [http://agner.org/optimize/blog/read.php?i=421](http://agner.org/optimize/blog/read.php?i=421)

RISC-V is discussed some, and part of the discussion is how to improve it.

</comment><comment><USER23> I look forward to a RISC-V proc powering my laptop with some ridiculous Nvidia GPU. We must escape x86 :(

<comment><USER24> There is some gentle irony in wanting an open source ISA CPU paired with a GPU so proprietary the ISA is not even public knowledge.

<comment><USER23> I'm looking forward to the day we can operate dedicated, proprietary GPUs like black boxes we can turn on and off at will as optional accelerators. :-)

</comment></comment></comment><comment><USER25> Isn't ARM the RISC solution that is already here? Already dominating mobile, Microsoft is soon to be announcing x86 apps running on Windows on ARM

<comment><USER26> ARM is too license-encumbered. If we're going to switch away from x86, it might as well be to something that admits free development and production.

<comment><USER27> Things are not that straight forward, I wrote a better comment here: [https://news.ycombinator.com/item?id=14284409](https://news.ycombinator.com/item?id=14284409)

<comment><USER26> I'm aware that individual implementations of the ISA are nonfree. There's still a huge benefit to using the free ISA, because we can target nonfree hardware while necessary and our software will just work on free hardware when it's available. There are already some free low-power designs, and if RISC-V gains traction I expect some free high-power designs to come out of the woodwork.

A robust open processor ecosystem could be the impetus for a huge improvement in open-source EDA tooling and public EDA research. Even now, the absolute cutting edge in HDL research is free and open-source (and 100x more user- friendly than anything to come out of Xilinx or Altera), and I suspect the same would happen for silicon-targeting synthesis tools if there was a demand for it.

The idea would be to get 90% of Intel's performance for 5% of the work. Intel spends insane amounts of money on manual routing and optimization, extensive testing at every stage of prototyping and production, stuff like that. The creative laziness of the free software/hardware people could probably improve on that _very_ substantially with minimal losses to the finished product.

</comment></comment></comment></comment><comment><USER28> I wonder how of those fit in a zedboard. (not going to ask how many hours of tool fighting that would require though).

<comment><USER29> Running on a Zedboard is quite well documented; only took me a couple of hours to do it from scratch following their instructions: [https://github.com/ucb- bar/fpga-zynq](https://github.com/ucb-bar/fpga-zynq)

<comment><USER28> I meant in a SIMT fashion, more like a GPU

</comment></comment></comment><comment><USER27> I see on this thread a lot of people getting blind-folded by the "open-source" term attached to the headline of this article.

First of all RISC-V can mean more than one thing: it can refer to the architecture, which is in fact open and free to use, or it can refer to the implementation of the same architecture, which will not be necessarily free or open source. For example, check the so claimed SiFive company which was promising free and open source implementations of RISC-V: [http://www.eetimes.com/document.asp?doc_id=1331690](http://www.eetimes.com/document.asp?doc_id=1331690)

""A year ago there was quite a debate if people would license a core if there was a free version, [but now] we've seen significant demand for customers who don't want an open-source version but one better documented with a company behind it," said Jack Kang, vice president of product and business development at SiFive."

By the end of the day, they just decided to follow ARM's path by providing license fees to their CPUs.

Secondly, when people say that RISC-V is "free" and "open-source" and that will allow companies to create cheaper and more open hardware, that is just an illusion. There are many more things on a SoC other than a CPU (like memories, communication buses, GPUs, power management processors, and so on). Cutting costs on a CPU will not make the cost of an SoC go down to zero, the CPU is just a small part of the puzzle. With RISC-V, you either need to implement the CPU yourself (which will be extremely expensive and time consuming) or you will have to find someone who provides with CPU cores already implemented. And of course that you need to have support and guarantees that the cores you bought will work on silicon. There will be always a huge cost associated when shipping CPUs, you can't escape from that.

You can already imagine that open-source hardware doesn't play by the same rules as open-source software, it's a completely different game with completely different rules.

And people speak of ARM's royalties like if they were a very bad thing. Truth to be told, the royalties you pay ARM can be a very good deal taking into account that you get access to silicon proven CPU cores, support from the best engineers in the industry and you automatically get covered by the many CPU patents that ARM owns. And you can even choose on how you want to pay for ARM's CPU licenses: you can either choose to license an already implemented CPU design by ARM or you can buy an architectural license and implement your CPU completely from scratch (this is what Apple and Qualcomm are current doing). You don't need to be completely tied to ARM. Even in the royalty fees you can choose whether you want to pay a big upfront license fee but then paying low royalties per device or you can choose to pay a low upfront license but compensating on the royalties per device.

There is a lot of misinformation going around the possibilities of RISC-V, mostly of this misinformation coming from people involved in the development of the spec. Don't be fooled by the buzzwords "open-source hardware" and "free hardware".

<comment><USER21> > You don't need to be completely tied to ARM.

The point is that if you want to use the ARM ISA you have to pay ARM. Not so with RISC-V. Anyone is free to fab a RISC-V chip without paying royalties.

<comment><USER27> You are talking like you could download RISC-V from the internet and send it to the foundry for mass production without additional costs or effort.

RISC-V is just a document, is not an implementation. There are many costs involved into designing a CPU that end up costing much more money than paying a license fee.

Check this comment: [https://news.ycombinator.com/item?id=14284450](https://news.ycombinator.com/item?id=14284450)

<comment><USER30> How about this: [http://www.pulp-platform.org/](http://www.pulp-platform.org/) ? It still in development, but the plan is to release the full CPU. You still need process/foundry specific data of course (things like flash-cells).

<comment><USER31> The GAP8 is a real product based on the pulpino. It's a cpu, more of a low- power embedded dsp/mcu, and a good one at that.

[http://www.eetimes.com/document.asp?doc_id=1330188](http://www.eetimes.com/document.asp?doc_id=1330188)

</comment></comment></comment></comment></comment><comment><USER32> After enjoying coding on 680x0 in my youth and later being frustrated by x86, I acclaim that new ISA. There is a design decision I'm curious about but I could not find related information. How did they come with the names "x0, x1, x2..." for general purpose registers, instead of the more conventional "r0, r1, r2..."?

<comment><USER33> x for "fixed point". r for "register" is too vague.

</comment></comment><comment><USER34> What is so special about reduced ISAs, what's the differentiating factors between them?

I mean they are so reduced that the ones I've seen are largely the same few logic ops. RAM access and interrupts might differ some, but a) memory access should follow the implementation and b) essentially everything else is memory mapped (avr, c51, pic)

<comment><USER35> To fully appreciate this, one would need much experience with microprocessor implementation. It's not reduced for the point of being simpler or smaller, but because it represent a local optimum of perf/area for running C code, especially for small to medium implementations.

However, much like the Alpha, RISC-V has been carefully designed to be efficient to scale UP, that is, to superscalar out-of-order implementations.

Do read the spec and the footnotes; they are delightful: [https://raw.githubusercontent.com/riscv/riscv-isa- manual/mas...](https://raw.githubusercontent.com/riscv/riscv-isa- manual/master/release/riscv-spec-v2.2.pdf)

</comment></comment><comment><USER36> So many RISC options and almost none for CISC. If you want yet another low power chip, then it makes sense. If, however, you want to get real on efficient cache usage and a high instruction-per-execution ratio, just do yourself a favor and stop ignoring the costly experimenting results that the industry already paid for.

<comment><USER37> This just doesn't match the research I've read. CISC wasn't about speed of execution, and x86 isn't an asset, there. (As I understand it Intel's expertise in compilers, emulation of CISC by RISC, and manufacturing are wonderful compensating factors.)

</comment></comment><comment><USER21> Relevant article: [http://makezine.com/2017/05/03/sifive-brings-open-source- to-...](http://makezine.com/2017/05/03/sifive-brings-open-source-to-chip- level/)

</comment><comment><USER38> An opensource, non-licensed, low-cost embedded processor -> sifive sells it for 600.000$ minimum.

</comment><comment><USER39> I always thought ARM chips _were_ RISC. shows what I know

<comment><USER3> That's how they started out, but there is always pressure to add new instructions for niche markets. But since there isn't any coherent way to implement extensions it means they have to pollute the entire ISA. RISC-V was carefully designed to allow for extensions.

<comment><USER35> No it was never a [real] RISC. Even the very first version included predication and shift in most instructions. They weren't even fast. The event that changed everything was when DEC Alpha engineers (for reasons I don't know) decided to use their expertise to created StrongARM. This ironically ended up at Intel and was renamed XScale, before being spun out. (EDIT: grammar & typos)

</comment></comment></comment><comment><USER40> would there be a advantage to not only creating a reduced instruction set but a minimal instruction set and letting the compiler do the rest. especially when you can add a lot more cores, so that mul becomes a cpu core with a counter and add for example.

<comment><USER35> No.</comment></comment>


Ask HN: Business and CS double degree - <AUTHOR> Hello, I would like to know if someone has Computer Science and Business double degree. Does it bring any extra advantages if that person wants to work in the tech field? <comment><USER2> Those two degrees along with work experience is a wonderful advantage and can help give you an extra boost as you move forward in your career.

</comment><comment><USER3> Business(Finance specifically) and CS may be a thing. In NYC finance companies seem to like this combination.

<comment><AUTHOR> Any about Nordic countries?

</comment></comment><comment><USER4> Might want to look at an MBA instead of a BA or BS in Business.</comment>


Creating consistent development environments with Docker - <AUTHOR> https://hackernoon.com/how-to-create-consistent-development-environments-that-just-work-55be5417341b <comment><USER2> What percentage of time do developers spend troubleshooting code on different environments and trying to synchronize, probably 25-30% anyhow?

<comment><USER3> Sometimes more than that. Depends upon the size of the team and how well organized they are.</comment></comment>


Seniors Are More Conservative Because the Poor Don't Survive to Become Seniors - <AUTHOR> http://nymag.com/daily/intelligencer/2018/05/poor-people-often-dont-survive-to-become-seniors-who-vote.html <comment><USER2> That's a terrible article. Just awful.

> or instance, in 2015, research funded by the National Institutes of Health > and the Social Security Administration revealed that, since 1990, among the > bottom quarter of Americans with the least education, life expectancy has > either stagnated or decreased. That's for well over 40 million people.

That doesn't mean they don't get to be seniors, or even state what the numbers change from or too.

Just an awful set of vague ideas loosely linked together.

</comment><comment><USER3> I just had time to read the comments, here. Friend is waiting for me.

This is a bit meta, but regarding whether the title (and presumably, article) is correct or not: Whether or not it is, it's important to consider that a significant fraction of people _think_ this way.

And that thinking informs their actions. Whether or not they are "objectively" justified.

There is a voice in the U.S. (and elsewhere), growing increasingly loud at the moment, that claims that all disadvantage is the disadvantaged's own fault.

It become justification for taking all you can get.

And, in my opinion, leads to the destruction, and then subsequent, eventual reconstitution, of a society.

And yes, as I grow older, I wonder more and more whether my more "altruistic" approach to life is indeed wrong. I'm not entirely outside of the trap, myself.

The thing is, I'm most happy when I'm around other happy people. (Which tends to correspond with healthy people.) And some of my greatest pleasure comes from helping other people and working together (just not in a fucking cubicle nor open space -- not _that_ "together").

So, I tend to find that other people around me doing better -- at least in terms of health and environment -- tends to make things better for me, as well.

BUT, there is a significant fraction of people who don't think and act this way. Or they have a very limited "us" and feel free, even obligated, to screw the great big "them".

It doesn't matter whether it's "right". It's how some people think, feel, and function.

\--

P.S. And now, I'm late. A metaphor of sorts, I guess...

</comment><comment><USER4> Or, you know, with old age comes wisdom.

<comment><USER5> With old age comes aversion to change.

</comment></comment><comment><USER6> Did not know The WaPo has a blog called The Monkey Cage. Simian metaphors seem to be all the rage in the social media as of late.

</comment><comment><USER7> The old cliche applies here, "If you're not a socialist as a young person you have no heart; if you're not a capitalist as older person you have no brain."

If, as this title suggests, as an older person you're dead, well in that case you still have no brain.</comment>


Memory Management in Python - <AUTHOR> https://rushter.com/blog/python-memory-managment/ <comment><USER2> I've found it's easy to get much better performance in CPython by simply replacing their malloc with my own. Mine allocates a large block of memory on the stack, then pulls from it. Won't work for large programs, but for smaller scripts it's a good amount faster. I think this is because CPython makes something like 1000 malloc calls just to startup, so if those can be made ~instant you get a lot of benefit.

<comment><USER2> The repo: [https://github.com/JacksonKearl/cpython/blob/master/README.r...](https://github.com/JacksonKearl/cpython/blob/master/README.rst)

My allocator isn't included as it is part of a class project, but you can make your own malloc pretty easily.

Alternatively you can just do some LD preload magic, but I don't know much about that (and this was needed to match the class spec)

<comment><USER3> > My allocator isn't included as it is part of a class project, but you can > make your own malloc pretty easily.

Was this a class that you took, or one that you TA or tutored?

<comment><USER2> I was a TA.

</comment></comment></comment></comment><comment><USER4> Why does Python use its own allocation abstractions when the C allocator is likely doing the exact same thing underneath it? Or does it only employ these when it's directly getting pages of memory from the OS?

<comment><USER5> Author of the article here.

I don't think system allocators are clever enough to process and allocate 100-500k of very small objects each minute when Python is performing something very intensive.

It's a pretty standard way to speedup allocation for dynamic languages. Game developers use similar techniques as well.

I have some stats on Python's allocator:

[https://rushter.com/blog/python-object-allocation- statistics...](https://rushter.com/blog/python-object-allocation-statistics/)

<comment><USER6> Can Python actually return memory pages back to the OS, e.g. by sbrk() with negative argument?

I'm currently having a problem with this, where I load a large deep learning model into "CPU" memory then move it to the GPU, but I can't get rid of the memory reserved by the process.

<comment><USER7> I can't answer your exact question, but any large allocations/deallocations should be handled by mmap under the hood and in those cases the memory should be returned.

In your case you should first consider the possibility that there is a pointer to your model's objects that is for some reason not being released. It might simply be that even though you are moving your model the GPU and maybe removing any of your own references, there might be internal references to your model's data that is hidden from you. At least something to consider.

edit: To add to this, I'm now quite sure (though I could be wrong!), that whether python does or does not use sbrk with a negative value is beyond the scope of python. Python is making use of malloc/free under the hood:

[https://github.com/python/cpython/blob/master/Objects/obmall...](https://github.com/python/cpython/blob/master/Objects/obmalloc.c#L124-L128)

There's some flexibility for wrapping free in different ways in that file, but it seems like it'll basically always be using free at the core. At least on my system in a debugger I just verified that. So if it's true that python by default uses malloc/free, then the question of whether sbrk with a negative number comes into play is more a question of how your libc implements malloc/free.

Of course I might be wrong, but I think that you should probably stop worrying about it at that level and instead look into object references first as I detailed above.

</comment></comment></comment></comment><comment><USER8> Memory management was my favorite topic to study during my time as an undergrad. I considered going back to school to get my MS in CS solely because I loved learning about this topic so much. Fascinating to see how it works under the hood in Python. Bravo!</comment>


Ask HN: Which Low-Cost Micro-controller is the Best for Learning Assembly? - <AUTHOR>

I've recently started working in an IT Security position, and I'm trying to gain a solid foundation in assembly so I can start playing around with reverse engineering malware in my spare time. I've taken classes in Java and C++ before, and played around with HTML, JavaScript, and Python, but I haven't built anything significant yet, so I still consider myself to be a beginner. I've read a few articles, in an attempt to find out what I should start with, but there seems to be quite a wide variety of low-cost microprocessors out there.
I've read that the MSP430 is a good place to start, and it's definitely inexpensive, but I wonder if it would make more sense to just start with something more modern.
ARM processors are also supposed to be a good choice for a beginner, but there are so many choices, it's hard to figure out what I need.
Arduino looks interesting, and I hear about it all the time, but from the looks of it, most people don't use them to learn assembly. I know that they made an ARM version (which is hard to find) but I'm not sure what the difference would be between this and other ARM processors.
If anyone has a minute to share their thoughts I would be greatly appreciative. <comment><USER2> If you want to learn assembler to analyze malware, learning x86 assembler under linux or windows is where you should start. If you really want to start with a microcontroller, the AVR is a good place. You can use one of the Atmel XPlain boards or an Arduino with the Atmel Studio. I would recommend getting an AVR Dragon JTAG interface, being able to debug at the hardware level is invaluable when you are learning or doing "real" development in assembler.

Note that a good portion of the learning curve for AVR or other microcontroller assembler is learning the hardware environment and learning about interrupts, execution environment setup, etc etc. None of this is particularly useful for malware analysis on x86 hardware.

If you are going to analyse malware under Android/etc then ARM is not such a bad idea. The PI or the BeagleBone are excellent platforms for getting started. Be aware that ARM assembler is a bit of a beast and is probably not a good first architecture to learn.

</comment><comment><USER3> My advice - buy a Raspberry Pi model B (about 35$) and read these lessons (assembly programming on the Pi):

<http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/>

<comment><USER4> Accidentally downvoted you. Apologies. The link is good.

<comment><USER3> No problem.

</comment></comment></comment><comment><USER5> My answer relates to experiences getting started in malware analysis rather than microcontroller assembler, but it might be useful to you :)

I took an interest in malware analysis last autumn and cant recommend the book Practical Malware Analysis enough. It introduces the subject to a beginner including the wide variety of skills required and tools used. One of the best things about the book is the malware samples supplied for analysis at the end of each chapter and then the detailed walk-throughs of how it should have been done.

The book focusses on windows malware and thus discusses x86 assembly, both an introduction to and identifying the constructs of higher level languages on dissassembly.

I immediately looked to supplement the information on assembly however. First with the Linux Assembly and Windows assembly "megaprimers" on securitytube.net, then with the Intermediate Intel x86 series of video lectures on opensecuritytraining.info. The quality of the latter was very good, so much so that I may go back and watch the introductory x86 lectures as well. I'm not usually a fan of video tutorials, but I thought the format suited the topic quite well.

I've stopped looking into malware analysis for now due to work, part time college and side projects that will hopefully lead to better work in the short term. I do look forward to picking it up again in the future though, its really quite fascinating.

</comment><comment><USER4> Yes, the MSP430 is a good option. Its cheap (even free if you ask for a sample), and has good support. Though I don't get why you would need a micro- controller to learn how to reverse engineer malware with Assembly. There are many good (free) books out there that teach Assembly for the X86 architecture. Maybe you want to learn how to reverse engineer embedded malware/virii?</comment>


Mike Markson of Blekko: Eight hard truths about online media - <AUTHOR> http://brainstormtech.blogs.fortune.cnn.com/2009/09/11/eight-hard-truths-about-online-media/?section=magazines_fortune

<comment><USER2> Excellent article, all of the points I'd agree with. A couple more points and he'd almost have a ten commandments style guide to developing something worthwhile for the Internet.

</comment><comment><USER3> I don't really agree with his first point at all. Is there any data to prove that 'real world' names are better? If this was true then why don't more real world companies use real world names instead of names like "Alltel", "Hertz" or "Ruby Tuesdays"?

</comment><comment><USER4> Boring, same-old tear down. Lots of people are making good livings online with content businesses, but nobody wants to write about _that_.

Probably because the people who are making money at it want to charge money to tell you how they make money at it.

For the record, I have a domain name addiction and I register three or four really damn good ones a month. Not all the good names are "taken." There is not a finite pool of good names that can be depleted -- they are as infinite as human ingenuity.

And... I made $22k off my first (and currently, only) infoproduct -- $20k of that while it was in beta and with almost no promotion - with, in fact, zero traditional advertising (e.g. we didn't pay a penny.)

I'm tired of all the people who'd prefer to sit and whine, listing all the reasons online business is _not_ as easy as buying a domain and GoDaddy SiteTonite™, instead of actually doing something.</comment>